Software Engineering in Games (UML)
Author
Hi,
I study ''Software Engineering'' and i try to use the technics i learn there for game development. I tryed many different approaches on designing a game in the past.
Now i started a new game and wanted to try modelling it with UML.
Well first i designed a normal Design Document, with gattering most of the details together and designed the class view (UML) in a well way.
But what does me drive crazy is how to design USE CASES for the game and stuff like that. It is a bit different for doing it for a game, then for some application software, at least i think so.
Does anyone has made some experiences with using UML or any other technique?
Use Cases for games are really tricky. Because games often rely on random numbers, there are really too many possibilities. For a use case path that uses rand() ten times, we choose 5 values, INT_MIN, INT_MAX, 0 and one positive and negative number. We have to analyze the path with rand() returning each of those 5 numbers, meaning 5^10 = 9765625 cases for one path, and that''s if there are no choices based on the random numbers.
The standard method is to identify each feature of the game and make sure that the testers experience each feature in many reasonable ways, and any extremes that can be thought of.
Software Engineering is very neglected in game development, but I am of the opinion that adopting these principles can only improve the quality and timeliness of our games. p
Pax
The standard method is to identify each feature of the game and make sure that the testers experience each feature in many reasonable ways, and any extremes that can be thought of.
Software Engineering is very neglected in game development, but I am of the opinion that adopting these principles can only improve the quality and timeliness of our games. p
Pax
Author
Yes i came also to the point that there were just to many use cases for it, mmh, only making the extremes, could you give me an example?
What methodes you already tryed/used for game development?
I think that using SE for games, is a MUST for the future. But cause nothing out there shows how to use it in a game, it''s a bit tricky.
Does anyone has some good resources about it?
"¨¨°º©o.,MiNdCRY,.o©º°¨¨"
------------------------------------------
http://mindcry.cjb.net
------------------------------------------
What methodes you already tryed/used for game development?
I think that using SE for games, is a MUST for the future. But cause nothing out there shows how to use it in a game, it''s a bit tricky.
Does anyone has some good resources about it?
"¨¨°º©o.,MiNdCRY,.o©º°¨¨"
------------------------------------------
http://mindcry.cjb.net
------------------------------------------
This kind of leaves me wondering, what on earth are you trying to do with your use cases? Sounds like you are going into a ridiculous amount of detail, if you actually have random numbers in there.
Use cases are meant to resemble the tasks that different types of user might perform with your application, at a very high abstraction level ( i.e. a low level of detail ).
People might not remember what you said, or what you did, but they will always remember how you made them feel.
Mad Keith the V.
Use cases are meant to resemble the tasks that different types of user might perform with your application, at a very high abstraction level ( i.e. a low level of detail ).
People might not remember what you said, or what you did, but they will always remember how you made them feel.
Mad Keith the V.
I think Extreme Programming is a much more practical software engineering methodology for games than UML and all the assorted cult-of-Booch jibber jabber.
Author
MadKeithV:
Give me an example of the uses cases a game has, cause there are so many different states a game can have.
Anonymous Poster:
I don''t think so, designing is very important. A few years ago i thought also, just type down the code, but then you change it here and there and etc. with a good design you think through the game structure and cameup with many problems before you have written any code. And sothe whole sourceis much better designed, think about someone builds a house without a plan, after he has finished it, he sees that he needs a second bath. Now what? Dig a hole in one of the waals and enhange the house? Much more work then you would had with a good design.
MC
Give me an example of the uses cases a game has, cause there are so many different states a game can have.
Anonymous Poster:
I don''t think so, designing is very important. A few years ago i thought also, just type down the code, but then you change it here and there and etc. with a good design you think through the game structure and cameup with many problems before you have written any code. And sothe whole sourceis much better designed, think about someone builds a house without a plan, after he has finished it, he sees that he needs a second bath. Now what? Dig a hole in one of the waals and enhange the house? Much more work then you would had with a good design.
MC
Merging XP and UML (and elements from the Unified Process) is quite appropriate. XP specifically states that change to the process must be done if there is a need, and UML/UP is certainly built for extensibility. The main clue here not to forcibly extend, but to evalute the need for the specific elements in each methodology against the size of the project, the size of the team and the type of project (research/prototyping, in-house-level or commercial) and then use only thos elements that deem appropriate. Try not to use an element if it has no real value, that only gives you more over-head and administration.
For the use-cases, they are designed to be used to really understand the requirements for the project. As stated, they should be seen from the view of the end user, in this case the player, and should NOT contain elements of how the implementation will be done. If the developer is not certain on how a specific problem could be solved, a small research phase/project could be in order.
Possible game use case examples (from the RPG genre):
- The game is startet and the player is confronted with options to build a new character, load a previously saved one or quit the game.
- During walking around in the game world, the character is spotted by a hostile creature. The creature advances and the player may run away or engage in combat.
- The inventory list is opened and the player may rearrange the inventory, equip the character with items or throw away items. Items thrown away will be accessible on the ground as long as the character has not walked so far away from the items as to leave them outside the characters visible area (could be the screen or something else).
Mapping this to design:
- There must exists a specific character scheme to hold the character stats. These can be loaded from disk and the game goes in to the game world. If the player want to generate a new character, there should be either a semi-random method of building the stats or a pre-defined way. Maybe a stat cap mechanism is in order. The stats could also be generated based on selected character classes and the balance calculus is dependent on these classes.
- The game keeps track of a set of creatures that wander around following some internal algorithm (AI-related). Tests for visibility and distance of the player character for these creatures are done periodicly. When the creatures spotting threshold is met, tests for reaction are done. If this ends in hostility, the wandering scheme for the creature changes to a more pursue-like scheme. Weapons (including natural defences) on the creature dictates when combat is engaged on behalf of the creature. If the player character runs away, new tests for visibility and distance are performed on the creature again. If a different threshold is met (indicating that the creature lost track of the character), the creature state is returned to the more loosly wandering scheme.
- The inventory may or may not freeze the game time. There should be an internal structure holding the neccessary items on the inventory and their placement (both on the inventory and possibly on the character). There are type-based limitations on the items as to where they could be placed on the character (if possible at all) and possible other restrictions (weigth, size, combat modifiers, etc). Rearranging the items is as easy as modifying some of these properties and updating the view. Dropping an item means transfering the internal structure to the world owner (a global ''character'' to hold world items) and linking it to a character-specific ''previous-ownership'' collection. During walking, tests are performed to see whether removing the items permanently from the world is in order. If so, remove the item links from the character and the item structures from the world owner.
This is the design level you should do first. DO NOT go any further. Do not try to detail out class names (if doing OO-development), structures, loop sequence or anything related to the implementation. This will only encumber the progress and quite possibly divert your focus to elements that could be changed in the next iteration. Some dicipline here is called for.
As you may see, this level in the design-process is based on the player view only. Most work here end in a text-based document (or database or notes) specifying all the elements the game should provide. Iterations through this material is neccessary to filter out inconsistencies, unfinished elements or elements that would violate the project restrictions.
When you are left with the feeling that these elements are complete and to your fatisfaction (afte at least 3 iteration or walk-throughs), you may proceed to the detailed stage of design. Remember to be open for changes and to always try to catch those parts of the project that you feel uncertain about through research and pre-testing. The detailed design should result in UML-diagrams, documentation and possibly a code skeleton.
For the use-cases, they are designed to be used to really understand the requirements for the project. As stated, they should be seen from the view of the end user, in this case the player, and should NOT contain elements of how the implementation will be done. If the developer is not certain on how a specific problem could be solved, a small research phase/project could be in order.
Possible game use case examples (from the RPG genre):
- The game is startet and the player is confronted with options to build a new character, load a previously saved one or quit the game.
- During walking around in the game world, the character is spotted by a hostile creature. The creature advances and the player may run away or engage in combat.
- The inventory list is opened and the player may rearrange the inventory, equip the character with items or throw away items. Items thrown away will be accessible on the ground as long as the character has not walked so far away from the items as to leave them outside the characters visible area (could be the screen or something else).
Mapping this to design:
- There must exists a specific character scheme to hold the character stats. These can be loaded from disk and the game goes in to the game world. If the player want to generate a new character, there should be either a semi-random method of building the stats or a pre-defined way. Maybe a stat cap mechanism is in order. The stats could also be generated based on selected character classes and the balance calculus is dependent on these classes.
- The game keeps track of a set of creatures that wander around following some internal algorithm (AI-related). Tests for visibility and distance of the player character for these creatures are done periodicly. When the creatures spotting threshold is met, tests for reaction are done. If this ends in hostility, the wandering scheme for the creature changes to a more pursue-like scheme. Weapons (including natural defences) on the creature dictates when combat is engaged on behalf of the creature. If the player character runs away, new tests for visibility and distance are performed on the creature again. If a different threshold is met (indicating that the creature lost track of the character), the creature state is returned to the more loosly wandering scheme.
- The inventory may or may not freeze the game time. There should be an internal structure holding the neccessary items on the inventory and their placement (both on the inventory and possibly on the character). There are type-based limitations on the items as to where they could be placed on the character (if possible at all) and possible other restrictions (weigth, size, combat modifiers, etc). Rearranging the items is as easy as modifying some of these properties and updating the view. Dropping an item means transfering the internal structure to the world owner (a global ''character'' to hold world items) and linking it to a character-specific ''previous-ownership'' collection. During walking, tests are performed to see whether removing the items permanently from the world is in order. If so, remove the item links from the character and the item structures from the world owner.
This is the design level you should do first. DO NOT go any further. Do not try to detail out class names (if doing OO-development), structures, loop sequence or anything related to the implementation. This will only encumber the progress and quite possibly divert your focus to elements that could be changed in the next iteration. Some dicipline here is called for.
As you may see, this level in the design-process is based on the player view only. Most work here end in a text-based document (or database or notes) specifying all the elements the game should provide. Iterations through this material is neccessary to filter out inconsistencies, unfinished elements or elements that would violate the project restrictions.
When you are left with the feeling that these elements are complete and to your fatisfaction (afte at least 3 iteration or walk-throughs), you may proceed to the detailed stage of design. Remember to be open for changes and to always try to catch those parts of the project that you feel uncertain about through research and pre-testing. The detailed design should result in UML-diagrams, documentation and possibly a code skeleton.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
