aspose file tools*
The moose likes Agile and Other Processes and the fly likes User requirements for a game. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "User requirements for a game." Watch "User requirements for a game." New topic
Author

User requirements for a game.

Tonny Tssagovic
Ranch Hand

Joined: Dec 30, 2003
Posts: 226
Hello people,
I was just wondering how onw could write use requirements for a game. I can think of few use cases like view top score, or upload your score, but how about the "play" use case. One is not going to write Jump use case, and fire use case.. it does not give any sense to me.. Any ideas?
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
One is not going to write Jump use case, and fire use case..
Can you explain why you think these wouldn't make reasonable use cases? They are certainly observable features which can be used to plan and measure development progress.


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Something we realized after a while ... whether you make one giant Play use case with flows for all the things you can do in the game, or if you make separate use cases for all those things, you build exactly the same software. The size and granularity of your use cases makes some difference in how you write the documents, organize them, review them, etc. For example, small ones might be good or bad - more readable or harder to keep track of. But neither small or large is "wrong" if writing them helps you discover requirements. It's easy to spend more time arguing about the correct use case structure than you would ever save or lose by having one structure or another. Relax, have fun, do what feels right to you.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:
Something we realized after a while ... whether you make one giant Play use case with flows for all the things you can do in the game, or if you make separate use cases for all those things, you build exactly the same software.

I think that depends on what you use the use cases for.
For example, if you use them for estimation, the more focused the use cases, the more accurate the estimates might be.
If you use them for prioritization of features, a big use case might contain both important and less important functionality. Breaking it down into several smaller ones gives you the opportunity to give them differing priorities. (And you might actually only see this *after* breaking them down!)
Also, I find smaller use cases (which can be implemented in a couple of days) to be more motivating, because every time one is finished, you have something to be proud of.
It's also important to notice that the optimal size might well depend on the state of development. For early estimates, some big use cases might suffice; but you might want to break them down into smaller ones when you start on implementing them, for example.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Tonny Tssagovic
Ranch Hand

Joined: Dec 30, 2003
Posts: 226
Originally posted by Frank Carver:

Can you explain why you think these wouldn't make reasonable use cases?

Frankly I don�t know Frank . I think that use cases should represent something of �value� to the actors and I don�t really think jumping is a mean in itself, but rather part of the �play the game� use case.
Michael D. Brown
Greenhorn

Joined: Nov 22, 2003
Posts: 29
Originally posted by Tonny Tssagovic:

Frankly I don�t know Frank . I think that use cases should represent something of �value� to the actors and I don�t really think jumping is a mean in itself, but rather part of the �play the game� use case.

Tony,
Try to think of it this way. Making one large "play the game" use case would be similar to making a "Use the Application" use case. While it is possible to start at that point, it defeats the point of use cases and OOA/D in general. It's possible that a "Jump" use case is too granular. So where is a middle point?
How about a "move character" use case.
1. User presses a motion key
2. System interprets user's input (this can be another Use Case itself)
3. System runs update routine (this would be another Use Case)
By breaking down the move character use case, we discovered two more UCs
"Interpret input"
"Update"
You can further break down your Use Cases to a granularity you are comfortable with. If you feel you can identify all of your subflows from a generic "play game" use case, feel free to do so. Nothing says you have to break down your cases. Just make sure that the level you select is good enough for your team to interpret and develop from.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Michael D. Brown:
Try to think of it this way. Making one large "play the game" use case would be similar to making a "Use the Application" use case.

Yes, I agree!

How about a "move character" use case.

But you can move the character without jumping - and you probably can design the levels so that you could play the game without jumping at all. So, being able to move the character in general probably is more important than being able to jump. That's why I think "jump" actually *is* a good use case.
By breaking down the move character use case, we discovered two more UCs
"Interpret input"
"Update"

In contrast, I think these are more like development tasks than use cases. It simply doesn't make sense to the user of the system to have one without the other.
On the other hand I *could* imagine the customer to stating "we only have one week left until this important presentation to the press. I'd really like to present them this cool laser-sword thingy we talked about. Jumping really wouldn't impress anyone, so we can defer that to after the presentation."
You can further break down your Use Cases to a granularity you are comfortable with. If you feel you can identify all of your subflows from a generic "play game" use case, feel free to do so. Nothing says you have to break down your cases. Just make sure that the level you select is good enough for your team to interpret and develop from.

... and to make good estimates and for your customer to prioritize them in a sensible way, I'd add. (Unless you use some other means than use cases for that, of course.)
Michael D. Brown
Greenhorn

Joined: Nov 22, 2003
Posts: 29
Originally posted by Ilja Preuss:
In contrast, I think these are more like development tasks than use cases. It simply doesn't make sense to the user of the system to have one without the other.

While I agree that they are development tasks, if you are using Use Cases as your final requirements documentation, I feel they should be captured. Although the user never accesses it directly, it does provide value to the user and the user provides input to it (through the "Move Character" use case). Jumping would be defined in the "Interpret Input" UC.
Of course, it doesn't have to be captured in a use case; but it should be captured somewhere in the requirements.

Actually I read your post more in depth. I understand what you're saying now. We are splitting hairs. I look at jumping as an alternate flow within a larger UC and you say it can be mapped to its own UC. Either way it will get captured properly. It's just a matter of choice.
Michael
[ February 11, 2004: Message edited by: Michael D. Brown ]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Rat on about large use cases being harder to estimate. The stuff really hits the fan when large use cases show up on the plan. It's silly to think that every feature in a large use case has the same priority and they should all be implemented at once. (been there, done that, didn't work, hated it)
I find the story planning and development techniques compelling. We build our use cases one story at a time. You get a story assignment, interview the user, write a use case flow, start coding. (Right, it's not XP.) You build the use case over time and the structure of the use case docs becomes even less important.
Now you can ask yourself if you want to write and save the use case at all. Our answer is still a solid "Yes" but you might find a stack of story cards with some notes from the user interview on the back are all you need to keep, or maybe only the user acceptance tests.
This game thing sounds perfect for incremental development of very small features. Hope it's a lot of fun to do, no matter how you document them!
[ February 12, 2004: Message edited by: Stan James ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: User requirements for a game.