Quote: Title: Using environment items as weapons. Description: A character can pick items and use it as weapons to hit enemies. Actors: Main Character (MC), Enemy Character (EC), item (weapon). Principal flow: - MC approaches an item he wants to pick. - Item gets added to MC's inventory. - MC activates item as principal weapon. - MC hits EC with his principal weapon.Surely it need a lot of refinement and maybe splitting in two (or more?) use cases, but I've written it from the top of my head. My questions are, who would be the actors on the engine? Should I consider each subsystem separately from the whole engine/game (each one with its own actors, which can be other subsystems)? And another one, there would be lots of use cases for a whole game, so maybe there should be high-level use cases that encompas lower level functionalities. What do you think? Any comments advices are greatly apreciated, i have no experience using UML and that for game designing. Thanks.
Use Cases for game design
Author
I've been reading about UML and use cases for my SE classes at uni. I thought I could use those tools to help me designing a game.
After reading (fast reading) the thread 'UML for games', it left me thinking if it's actually worth the use in game design.
So, what could be a (good) use case for a game? What do you think of something like this?
UML is great for Game Design and Implementation IMO. It gives you a nice design workflow while providing deliverables at each stage. I use an iterative waterfall method to design my games. Here is how I use it:
1) Use Case Diagram: I take the entire game as my system, the player as the actor and diagram the basic use cases. I'm not concerned about capturing every nuance of the game, just get some foundation. Also note that the Player doesn't have to be the end-user...the player could very well be in control of the computer, as in cut scenes.
2) Classes and Objects: My next step is to identify the classes and objects that will comprise my system. In a game environment, these might be rendering classes, keyboard objects, etc. In a Multiplayer Game, the objects might be client and server.
3) Use Case Narrative: This is the last stage of the requirements phase and the start of design. In your narrative you put what triggers the Use Case, what causes it to end, what it actually does, etc.
3) Activity Diagram: Now we start designing proper. For each Use Case, I take my classes and objects and make a simple actifvity diagram listing what each object and class is responsible for. This allows me to see for the first time how the Use Cases flow thorugh the objects and how the objects allow the Use Case to be realized.
4) Sequence Diagram: Here we start implementing. Based on all prior diagrams, I now create a SD for each Use CAse. This very specifically tells what messages get passed from object to object, what synchronoous and asynch calls need to be made etc.
5) Componenet Diagram: This is the final stage of implementation where you put all the componenets of your system and see how the information flow between them, with as much detail as possible. By this stage, you should be able to make a one to one correspondance between a componenet and a piece of code.
After these steps are complete, I go back to the begining and refine my original Use Cases. So in answer to your questions, the Use Case should be as high level as possible, capturing requirements and not implementation. You can most definitly have subsystems with their own actors and cases, but generally it's overkill early in the game design process and only needed for very complex systems (such as multiplayer games).
1) Use Case Diagram: I take the entire game as my system, the player as the actor and diagram the basic use cases. I'm not concerned about capturing every nuance of the game, just get some foundation. Also note that the Player doesn't have to be the end-user...the player could very well be in control of the computer, as in cut scenes.
2) Classes and Objects: My next step is to identify the classes and objects that will comprise my system. In a game environment, these might be rendering classes, keyboard objects, etc. In a Multiplayer Game, the objects might be client and server.
3) Use Case Narrative: This is the last stage of the requirements phase and the start of design. In your narrative you put what triggers the Use Case, what causes it to end, what it actually does, etc.
3) Activity Diagram: Now we start designing proper. For each Use Case, I take my classes and objects and make a simple actifvity diagram listing what each object and class is responsible for. This allows me to see for the first time how the Use Cases flow thorugh the objects and how the objects allow the Use Case to be realized.
4) Sequence Diagram: Here we start implementing. Based on all prior diagrams, I now create a SD for each Use CAse. This very specifically tells what messages get passed from object to object, what synchronoous and asynch calls need to be made etc.
5) Componenet Diagram: This is the final stage of implementation where you put all the componenets of your system and see how the information flow between them, with as much detail as possible. By this stage, you should be able to make a one to one correspondance between a componenet and a piece of code.
After these steps are complete, I go back to the begining and refine my original Use Cases. So in answer to your questions, the Use Case should be as high level as possible, capturing requirements and not implementation. You can most definitly have subsystems with their own actors and cases, but generally it's overkill early in the game design process and only needed for very complex systems (such as multiplayer games).
Author
Thanks for your answer, now I see the process better defined. I know there are other processes to develop SW, but I have to start somewhere :)
Could you post an example of a typical use case for a game? I'll be good to have a basic idea of how abstract or concrete should a use case be.
Could you post an example of a typical use case for a game? I'll be good to have a basic idea of how abstract or concrete should a use case be.
Title:
Move Player
Assumptions (things that must be true for the Case to work, but isn't checked by the case):
-Keyboard plugged in
-Keyboard arrow keys funtioning properly
Pre-Condition (things that must be true for the Case to work and ARE checked by the Case):
-Player must not be frozen in place
-Players intended path must not be blocked
Dialog (main actions of the Use Case):
-The end-user presses an arrow key
-The Player animation switches from Idle to Moving
-The Player moves to the new position
Termination (What event(s) cause this use case to end):
-End User releases arrow key
Post-Condition (What the condition of your system is after this Use Case is enacted):
-Player position has changed
This Use Case would then be proceeded by another "Stop User" Use Case. See how I'm breaking the Use Cases down by functions and letting each one do just a little bit or the grander picture:
--------------------------------------------------------------------------
Title:
Stop Player
Assumptions:
-None (never leave a field blank; it lets your reader know that you have considered this entry and not simply forgot about it)
Pre-Condition:
-Player was previously moving
Dialog:
-The Player "Stop" animation sequence plays
-The Player remains in-place
Termination:
-Player comes to a rest
Post-Condition:
-Player remains still at a set position
This use case would then be followed by "Idle Player" where we show how to deal with a Player just standing around. We can easily see how we are building up a sequence of Use Cases related to movement (Move->Stop->Idle) and as a bonus, I can consider each Use Case a "state" and keep that in mind when it comes time to implementation.
--------------------------------------
As to your posted example, it's too "dense" and trying to do too much at once. I would split that up into "Pick Item up" and "Use Item as Weapon". Furthermore, the EC is not an actor since it is not "activating" the Use Case. You CAN (and I encourage) make Use Cases from the POV of the enemy but not for the items. This is because the enemy will do things on it's own (attack, agro, retreat) but an item always has things done to it. Of course if you have a complex inventory system, it may pay off to do just that an have a Item Use Case such as "Activate Ability" or "Change Ammo Type"...although as you can see by the language, this is best left as Use Cases the player does on the Item.
[Edited by - fastlane69 on December 5, 2005 12:41:29 PM]
Move Player
Assumptions (things that must be true for the Case to work, but isn't checked by the case):
-Keyboard plugged in
-Keyboard arrow keys funtioning properly
Pre-Condition (things that must be true for the Case to work and ARE checked by the Case):
-Player must not be frozen in place
-Players intended path must not be blocked
Dialog (main actions of the Use Case):
-The end-user presses an arrow key
-The Player animation switches from Idle to Moving
-The Player moves to the new position
Termination (What event(s) cause this use case to end):
-End User releases arrow key
Post-Condition (What the condition of your system is after this Use Case is enacted):
-Player position has changed
This Use Case would then be proceeded by another "Stop User" Use Case. See how I'm breaking the Use Cases down by functions and letting each one do just a little bit or the grander picture:
--------------------------------------------------------------------------
Title:
Stop Player
Assumptions:
-None (never leave a field blank; it lets your reader know that you have considered this entry and not simply forgot about it)
Pre-Condition:
-Player was previously moving
Dialog:
-The Player "Stop" animation sequence plays
-The Player remains in-place
Termination:
-Player comes to a rest
Post-Condition:
-Player remains still at a set position
This use case would then be followed by "Idle Player" where we show how to deal with a Player just standing around. We can easily see how we are building up a sequence of Use Cases related to movement (Move->Stop->Idle) and as a bonus, I can consider each Use Case a "state" and keep that in mind when it comes time to implementation.
--------------------------------------
As to your posted example, it's too "dense" and trying to do too much at once. I would split that up into "Pick Item up" and "Use Item as Weapon". Furthermore, the EC is not an actor since it is not "activating" the Use Case. You CAN (and I encourage) make Use Cases from the POV of the enemy but not for the items. This is because the enemy will do things on it's own (attack, agro, retreat) but an item always has things done to it. Of course if you have a complex inventory system, it may pay off to do just that an have a Item Use Case such as "Activate Ability" or "Change Ammo Type"...although as you can see by the language, this is best left as Use Cases the player does on the Item.
[Edited by - fastlane69 on December 5, 2005 12:41:29 PM]
Author
Ok, now I get the point on Use Cases, I really needed some guidance :)
I also thought that my use case was trying to explain many actions, but i didn't notice that there are all that fields to describe the use case.
As for the 'writing use cases for each subsystem', I see now that it's innecesary because it would describe what the system has to do and not what the user can do with the system.
I also thought that my use case was trying to explain many actions, but i didn't notice that there are all that fields to describe the use case.
As for the 'writing use cases for each subsystem', I see now that it's innecesary because it would describe what the system has to do and not what the user can do with the system.
Keep in mind that UML is all about gaining different perspectives on the same problem. This is what lead my former buisness partner to consider it "a waste of time" because he understood the system in his own way and felt that the extra diagrams didn't say anything extra. Well, that is saying something because then this means the diagrams have captured your entire intent and this means that someone from outside our company can also understand what we are doing.
But, my point is that you CAN in fact make a set of use cases with the System as the Actor. In this case, you are outlining what the system has to provide the End User. The thing to keep in mind is that these set of Use CAses and the one's with the End User as an Actor are complementary but not equal. So you can't "mix and match" Cases from these Packages. However, it will give you great insight into whether your system, as planned, can actually accomplish what you set out to do. I don't recommend this approach for any but the most complicated game systems (those with extensive AI or Multiplayer) since in most normal single player games, end user Actors will capture pretty much everything about your system anyway.
As an example, consider a client/server network architecture. If we make the Client the Actor, we have a very similar use case package than with single player games (move player, attack enemy, etc) as well as some specific ones to MP (Login Player, Logout Player). However, if we "switch" and now consider the Server the Actor, we have a whole new view of the situation with Cases such as "Process Player Request" or "Move Enemy". Like I said these are complementary (a "Move Player" clientside is always followed by a "Process Player Request" serverside) but we cannot apply a "Move Player" Use Case on the Server anymore than our Client will be "Processing Player Requests".
But, my point is that you CAN in fact make a set of use cases with the System as the Actor. In this case, you are outlining what the system has to provide the End User. The thing to keep in mind is that these set of Use CAses and the one's with the End User as an Actor are complementary but not equal. So you can't "mix and match" Cases from these Packages. However, it will give you great insight into whether your system, as planned, can actually accomplish what you set out to do. I don't recommend this approach for any but the most complicated game systems (those with extensive AI or Multiplayer) since in most normal single player games, end user Actors will capture pretty much everything about your system anyway.
As an example, consider a client/server network architecture. If we make the Client the Actor, we have a very similar use case package than with single player games (move player, attack enemy, etc) as well as some specific ones to MP (Login Player, Logout Player). However, if we "switch" and now consider the Server the Actor, we have a whole new view of the situation with Cases such as "Process Player Request" or "Move Enemy". Like I said these are complementary (a "Move Player" clientside is always followed by a "Process Player Request" serverside) but we cannot apply a "Move Player" Use Case on the Server anymore than our Client will be "Processing Player Requests".
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
