• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

User requirements for a game.

 
Ranch Hand
Posts: 226
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Tonny Tssagovic
Ranch Hand
Posts: 226
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
All of the following truths are shameless lies. But what about this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic