I''m currently working on a chapter/article entitled "Using the UML in Game Development" that is to appear in a future book. While I have my own methods and ideas on how to use the UML as applied to games, I started thinking of other possible methods and ideas, and as a result I''m interested in hearing others'' experiences and ideas on the UML as well. Any takers?
Kevin "Khawk" Hawkins
CEO and News Director, GameDev.net
Author, OpenGL Game Programming
Developer Diary
UML in game development
Khawk, I''m covering some of this in the project I''m doing for my degree. I''d be interested to hear of any insights you''ve got.
So far, I''ve determined that the main benefit of using UML in game development is in the standard documentation itself, rather than as a part of the Rational Unified Process. Using diagrams in ways they weren''t quite intended can still be useful.
For example, a State diagram can be used to model any of numerous finite state machines, but you don''t necessarily have to specify that the messages that move the object from one state to another have to be function calls. They could be abstract events such as ''Enemy Approaches'' and the value of the diagram is not lost.
Use case diagrams are pointless.
Use cases themselves are not so pointless, but the diagrams buy you nothing. However, even use cases are marginalised in games and simulations where most of the events are generated from within the system rather than outside the system. So you either have to ignore use cases (which is what they did in the game case study in Using UML), or twist use cases into something they weren''t intended for (model internally generated events).
Class diagrams are useful, especially if you start off with a simple specification model that only shows the basic system structure, rather than all the variables and so on. It may be useful to make a diagram showing packages, and splitting each package into its own class diagram later in the design phase.
However, class diagrams tend to change so much that they become more of a burden than a help to single-programmer teams. Such teams should probably only use them as a baseline. Other teams should make an effort to keep them up to date.
Interaction (both collaboration and sequence) diagrams seem to be more hassle than help. (This is all looking negative so far, isn''t it?) Generally, a good programmer would have thought through the collaborations in their head when they were constructing the responsibilities and interfaces on the class diagram, so these diagrams end up as little more than a formality. Admittedly, sometimes some feature is overlooked, and the act of drawing these diagrams might help highlight deficiencies in the interface, which always ends up more polluted than you first imagined it would. However, I found that attempting to code the collaboration was more effective at finding the deficiencies (100% effective in fact - it won''t compile until all dependencies are totally resolved) and took about the same length of time as drawing the interaction diagram that is unlikely to catch all the errors...
So in my experience, UML has not been anywhere near as useful as I had hoped for
This is perhaps because, being a single programmer, it is far easier and quicker for me to code something to test it than to diagram it. And I have no need for centralised documentation as there is only ever 1 person working on the source, which serves as its own documentation. Apart from the small degree of clarity served by laying out an initial class design, I don''t feel that I gained any benefits from any of the diagrams I made.
Hopefully you have some better applications than I do!
[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]
So far, I''ve determined that the main benefit of using UML in game development is in the standard documentation itself, rather than as a part of the Rational Unified Process. Using diagrams in ways they weren''t quite intended can still be useful.
For example, a State diagram can be used to model any of numerous finite state machines, but you don''t necessarily have to specify that the messages that move the object from one state to another have to be function calls. They could be abstract events such as ''Enemy Approaches'' and the value of the diagram is not lost.
Use case diagrams are pointless.
Use cases themselves are not so pointless, but the diagrams buy you nothing. However, even use cases are marginalised in games and simulations where most of the events are generated from within the system rather than outside the system. So you either have to ignore use cases (which is what they did in the game case study in Using UML), or twist use cases into something they weren''t intended for (model internally generated events).Class diagrams are useful, especially if you start off with a simple specification model that only shows the basic system structure, rather than all the variables and so on. It may be useful to make a diagram showing packages, and splitting each package into its own class diagram later in the design phase.
However, class diagrams tend to change so much that they become more of a burden than a help to single-programmer teams. Such teams should probably only use them as a baseline. Other teams should make an effort to keep them up to date.
Interaction (both collaboration and sequence) diagrams seem to be more hassle than help. (This is all looking negative so far, isn''t it?
) Generally, a good programmer would have thought through the collaborations in their head when they were constructing the responsibilities and interfaces on the class diagram, so these diagrams end up as little more than a formality. Admittedly, sometimes some feature is overlooked, and the act of drawing these diagrams might help highlight deficiencies in the interface, which always ends up more polluted than you first imagined it would. However, I found that attempting to code the collaboration was more effective at finding the deficiencies (100% effective in fact - it won''t compile until all dependencies are totally resolved) and took about the same length of time as drawing the interaction diagram that is unlikely to catch all the errors...So in my experience, UML has not been anywhere near as useful as I had hoped for
This is perhaps because, being a single programmer, it is far easier and quicker for me to code something to test it than to diagram it. And I have no need for centralised documentation as there is only ever 1 person working on the source, which serves as its own documentation. Apart from the small degree of clarity served by laying out an initial class design, I don''t feel that I gained any benefits from any of the diagrams I made.Hopefully you have some better applications than I do!
[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]
quote:
Khawk, I''m covering some of this in the project I''m doing for my degree. I''d be interested to hear of any insights you''ve got.
What is your degree in?
quote:
For example, a State diagram can be used to model any of numerous finite state machines, but you don''t necessarily have to specify that the messages that move the object from one state to another have to be function calls. They could be abstract events such as ''Enemy Approaches'' and the value of the diagram is not lost.
Agreed. In fact, I don''t think STD''s need to have function calls at all, but rather just the event that causes the state to change to another state.
quote:
Use case diagrams are pointless.
I disagree.
I do see potential for use cases - not as they are traditionally defined, but definitely in a modified form. The diagram is only useful for giving a developer a quick overview of what actors interact with what use cases, without having to dig through specifications. As for a modified form, my current though process involves defining an actor as any entity that acts on or in the game world. Obviously, the player is always an actor, but other actors might include enemies or special objects. One thing to note is that the use case is for analysis, and not design, so I see the use case as a tool for helping determine and revise the game design. However, at the same time, the use case specification can be used to determine classes and class interactions further into the process.quote:
Class diagrams are useful, especially if you start off with a simple specification model that only shows the basic system structure, rather than all the variables and so on. It may be useful to make a diagram showing packages, and splitting each package into its own class diagram later in the design phase.
Agreed. Class diagrams are naturally useful as a static view of the system. I disagree with you on the design phase. Packages (I may call them categories) should be determined in the analysis phase, early on in the process. Now it''s possible that there may be sub-packages or sub-categories, so if that''s the case, then the lowest level sub-category diagram should have the final class diagram for that category. (hope that doesn''t sound confusing)
quote:
However, class diagrams tend to change so much that they become more of a burden than a help to single-programmer teams. Such teams should probably only use them as a baseline. Other teams should make an effort to keep them up to date.
This would be entirely team dependent I think, as you seem to point out, including single-programmer teams. If the person is comfortable using UML, or using a process that supports UML, then I think they should go for it. Being that every development team is different anyway, there is no "silver bullet" development process (had to throw it in there).
quote:
Interaction (both collaboration and sequence) diagrams seem to be more hassle than help. (This is all looking negative so far, isn''t it?
Interaction diagrams are a great help in the analysis phase if done properly. Personally, I like the sequence diagrams more than the collaboration diagrams. In my proposed process, you create a Category Interaction Diagram for each use case where you have the actors interacting with each category (or package) involved in the use case. Detail here is not very high, but that''s ok because the idea is to just get a start.
I wish I had time to go into lots of detail about my ideas, but maybe they''ll surface at some point.
I think some of the main points are:The need to separate analysis from design - you can''t go straight from a design document to a technical design if you don''t understand precisely what you''re designing. This may explain some of your difficulties with spending too much time drawing a diagram. (?) The only difficulty is that when using an OO process, there''s a very thin line between analysis and design. For this reason, you need to have a well defined UML driven process that tells you when you''re doing analysis and when you''re doing design. A UML driven process needs to be iterative, meaning if you change something in a later phase, then it needs to be addressed in a previous phase. As much of a pain as this sounds, it really does help find problems in the design moreso than just going through a single time and changing things for each diagram. This also helps with requirements traceability.
Ok, I think that''s all for now.
Kevin "Khawk" Hawkins
CEO and News Director, GameDev.net
Author, OpenGL Game Programming
Developer Diary
My degree is in ''Computing(Visualisation)'', which is a fancy way of saying that it''s a general purpose computing degree with a bias towards virtual reality and graphics.
I just can''t see any value in use case diagrams. The diagram itself says virtually nothing, and even that which it does say has to be largely taken with a pinch of salt because it models the system in a procedural way rather than an object-oriented way. I''m still not sold on these.
When I mentioned separating packages out into classes later in the design phase, I was using sloppy terminology and meant the analysis phase. (However, it would probably also be a mistake to tie UML usage too closely to the RUP requirements-analysis-design-implement-test loop. In particular, the RUP lends itself far better to bespoke software developed for a client than retail software developed almost speculatively.) Anyway, some separation could well take place at the analysis stage, while you''re still finding domain classes as opposed to inventing design and implementation classes.
I think I am comfortable using UML, in that I can translate a design to a diagram quickly, but I still doubt the effectiveness. If I can diagram it, I can imagine it. And if I can imagine it, I can code it. I just can''t see the benefit. Reading code is quicker and less ambiguous than reading a diagram once you''ve started implementation. (This either makes me a really good programmer, or a really bad documenter. I will leave that judgement to someone else.)
Interaction diagrams... I still don''t see the benefit. By the time I know exactly what needs coding, I will have coded it. Or to put it another way - by the time the diagram is done and complete, I could have just typed all that into the C++ editor and had the working design anyway.
Maybe this is because I think algorithmically anyway. Starting with BASIC at age 10 means that I think of real world objects in terms of computer stuff, rather than thinking of computer stuff in terms of real world objects.
As you might have guessed, I''m coming to the opinion that UML is only really useful where it models things at a higher level than the code itself, or when the aspect it''s modelling is going to be split among more than one coder such that a documented interface is necessary. Reading through "Using UML" and "UML Distilled", it still seems like UML is a solution to a problem I don''t have. 99% of the time, I understand my system well enough to not need documentation. The other 1% of the time, I don''t understand the system well enough to document it.
[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]
I just can''t see any value in use case diagrams. The diagram itself says virtually nothing, and even that which it does say has to be largely taken with a pinch of salt because it models the system in a procedural way rather than an object-oriented way. I''m still not sold on these.
When I mentioned separating packages out into classes later in the design phase, I was using sloppy terminology and meant the analysis phase. (However, it would probably also be a mistake to tie UML usage too closely to the RUP requirements-analysis-design-implement-test loop. In particular, the RUP lends itself far better to bespoke software developed for a client than retail software developed almost speculatively.) Anyway, some separation could well take place at the analysis stage, while you''re still finding domain classes as opposed to inventing design and implementation classes.
I think I am comfortable using UML, in that I can translate a design to a diagram quickly, but I still doubt the effectiveness. If I can diagram it, I can imagine it. And if I can imagine it, I can code it. I just can''t see the benefit. Reading code is quicker and less ambiguous than reading a diagram once you''ve started implementation. (This either makes me a really good programmer, or a really bad documenter. I will leave that judgement to someone else.
)Interaction diagrams... I still don''t see the benefit. By the time I know exactly what needs coding, I will have coded it. Or to put it another way - by the time the diagram is done and complete, I could have just typed all that into the C++ editor and had the working design anyway.
Maybe this is because I think algorithmically anyway. Starting with BASIC at age 10 means that I think of real world objects in terms of computer stuff, rather than thinking of computer stuff in terms of real world objects.
As you might have guessed, I''m coming to the opinion that UML is only really useful where it models things at a higher level than the code itself, or when the aspect it''s modelling is going to be split among more than one coder such that a documented interface is necessary. Reading through "Using UML" and "UML Distilled", it still seems like UML is a solution to a problem I don''t have. 99% of the time, I understand my system well enough to not need documentation. The other 1% of the time, I don''t understand the system well enough to document it.
[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]
quote:
I just can't see any value in use case diagrams. The diagram itself says virtually nothing, and even that which it does say has to be largely taken with a pinch of salt because it models the system in a procedural way rather than an object-oriented way. I'm still not sold on these.
The value is not in the use case diagram, but rather the use case scenarios or specifications. As I said, use case diagrams are only useful as an overview of the actors and the use cases that they interact with. The real meat is in the use case scenarios. That, I don't think anyone can disagree with.
quote:
When I mentioned separating packages out into classes later in the design phase, I was using sloppy terminology and meant the analysis phase. (However, it would probably also be a mistake to tie UML usage too closely to the RUP requirements-analysis-design-implement-test loop. In particular, the RUP lends itself far better to bespoke software developed for a client than retail software developed almost speculatively.) Anyway, some separation could well take place at the analysis stage, while you're still finding domain classes as opposed to inventing design and implementation classes.
I wouldn't use the RUP process either, but rather a modified version. Keep in mind, however, that most software engineering principles are geared toward the large software project. A simple game might not be considered a large software project, but let's say something like Black & White with it's 1,000,000 LOC - now that's a large piece of software. There are such things as the Personal Software Process (PSP) for smaller, invidual projects, and the Team Software Process (TSP) for the small-medium team project, but those are typically only used to develop modules of a larger system. UML can be integrated into any process. It all depends on the developer/organization.
On another note, consider the guy that has the title "game designer" as the client. When you first start development, he typically doesn't know exactly what he wants just as a client would be in other software sectors. As the project evolves (in this case the game), the client and the developer both must come to terms with what it is exactly that they're building. The job of a true analysis phase in OO is to help narrow down these requirements. In a game, I would consider this the game design. Granted, you can't get all the little gameplay tweaks that are necessary toward the end of the project, but you can definitely narrow the field down using some analysis.
quote:
I think I am comfortable using UML, in that I can translate a design to a diagram quickly, but I still doubt the effectiveness. If I can diagram it, I can imagine it. And if I can imagine it, I can code it. I just can't see the benefit. Reading code is quicker and less ambiguous than reading a diagram once you've started implementation. (This either makes me a really good programmer, or a really bad documenter. I will leave that judgement to someone else.
I perfectly understand what you're saying, but at the same time I can see potential problems. For instance, how often do you find yourself recoding or redesigning something? How about if you don't touch some code from a project for a while.. what's the learning curve for figuring out what's going on? What about maintenance? (fact: 50% of a project's budget is spent on maintenance)
quote:
Interaction diagrams... I still don't see the benefit. By the time I know exactly what needs coding, I will have coded it. Or to put it another way - by the time the diagram is done and complete, I could have just typed all that into the C++ editor and had the working design anyway.
It isn't so much the design before coding, as it is the understanding of what you're coding before you code it. I have a hard time believing you can understand everything happening in something greater than 10,000-15,000 LOC.
Not even the best coders I know can admit that they know everything happening. This is of course without spending a decent amount of time going through things.quote:
Maybe this is because I think algorithmically anyway. Starting with BASIC at age 10 means that I think of real world objects in terms of computer stuff, rather than thinking of computer stuff in terms of real world objects.
I learned the same way and didn't really get into OOP until about 4 years ago.
quote:
As you might have guessed, I'm coming to the opinion that UML is only really useful where it models things at a higher level than the code itself, or when the aspect it's modelling is going to be split among more than one coder such that a documented interface is necessary. Reading through "Using UML" and "UML Distilled", it still seems like UML is a solution to a problem I don't have. 99% of the time, I understand my system well enough to not need documentation. The other 1% of the time, I don't understand the system well enough to document it.
I can't argue with that. I definitely don't use diagramming when I don't need it. However, your opinion is actual fact.
UML's purpose is of course to model your system at a higher level than the code itself. It's a useful documentation tool, and it's a standard, so of course it's for teams of 2 or more. Not that it's necessary, but rather that it's a communication device for the developer. It's also a communication device to the client, particularly in the analysis phase. I recently read (and I mentioned this above) that one of the most useful aspects of a standard like UML is how it helps with maintenance (the part after your product is complete). With 50% of your budget spent on maintenance, you need some way to combat that cost as much as you can. UML is one of your weapons.*edited (was being misinterpreted)*
Kevin "Khawk" Hawkins
CEO and News Director, GameDev.net
Author, OpenGL Game Programming
Developer Diary
I''m not sure why you are writing this article/book if you say UML is not necessay.
I''ve been using UML for quite a while now, and am even using it now in a game context. The quality I can create with UML is infinately better than what I can create without using UML. My code is just about as simple as it can possibly be, because I spent time designing and re-designing it to be simple. Not to mention my system is completely documented which means bringing in new people is cake.
If you mean UML and a software process are not necessary in that you can create a software project without it, then ya, it''s not necessary. But it most definately is necessary to create a large scale project where where you want to meet not only the requirement of "Does it work", and add maintainability, expandability, re-usability, and best quality, then I''d say UML is invaluable.
I''ve been programming since I was 10, and I''m now 26. So I''m am quite capable of hacking out code that will work for any project. I switched from hacking to using UML about 2 years ago, and the results are staggering. I thought I was Good before, the stuff I can create now is GREAT. Ok, ego asideusing UML made me a much better developer.
I''ve been using UML for quite a while now, and am even using it now in a game context. The quality I can create with UML is infinately better than what I can create without using UML. My code is just about as simple as it can possibly be, because I spent time designing and re-designing it to be simple. Not to mention my system is completely documented which means bringing in new people is cake.
If you mean UML and a software process are not necessary in that you can create a software project without it, then ya, it''s not necessary. But it most definately is necessary to create a large scale project where where you want to meet not only the requirement of "Does it work", and add maintainability, expandability, re-usability, and best quality, then I''d say UML is invaluable.
I''ve been programming since I was 10, and I''m now 26. So I''m am quite capable of hacking out code that will work for any project. I switched from hacking to using UML about 2 years ago, and the results are staggering. I thought I was Good before, the stuff I can create now is GREAT. Ok, ego aside
using UML made me a much better developer.
quote:Original post by shaft
I''m not sure why you are writing this article/book if you say UML is not necessay.
Quite wrong, I''m saying in Kylotan''s case it might not be necessary. In very small projects it might not be necessary, but, and I did say this, it''s a good practice for large projects, including games.
quote:
I''ve been using UML for quite a while now, and am even using it now in a game context. The quality I can create with UML is infinately better than what I can create without using UML. My code is just about as simple as it can possibly be, because I spent time designing and re-designing it to be simple. Not to mention my system is completely documented which means bringing in new people is cake.
If you mean UML and a software process are not necessary in that you can create a software project without it, then ya, it''s not necessary. But it most definately is necessary to create a large scale project where where you want to meet not only the requirement of "Does it work", and add maintainability, expandability, re-usability, and best quality, then I''d say UML is invaluable.
I''ve been programming since I was 10, and I''m now 26. So I''m am quite capable of hacking out code that will work for any project. I switched from hacking to using UML about 2 years ago, and the results are staggering. I thought I was Good before, the stuff I can create now is GREAT. Ok, ego aside
Everything you said is exactly my point. I''m writing the article because I advocate the use of UML in games development, along with many other software engineering methodologies. The problem, however, is that I''m finding that people in games aren''t using UML for anything more than something like a class diagram. This is fine I''m sure, but I see potential in using other aspects of UML in game development, and that is the point of my article.
Kevin "Khawk" Hawkins
CEO and News Director, GameDev.net
Author, OpenGL Game Programming
Developer Diary
Well here''s my 2 cents of how I''m using UML in our project (Note I am doing this as indieware, we are not a professional game house, we are a group doing a game in our spare time for fun - but we''ve been together for more than a year, so we are pretty serious).
Anyways,
1. Use Case diagrams - Limited in use in the standard way of doing things from the game players perspective. However, when you break your game down into modules (sound, graphics, object management, etc.) you can do use case diagrams where you say a module is the actor. It''s fairly useful in telling you how to define the interfaces between your modules.
2. Class Diagrams - These are invaluable. Before you start writing code, create some class diagrams. Move things around to make your diagram "Pretty". MAke things as simple as humanly possible. Code up to a point, and then go modify, and expand your class diagrams. An interative approach works well. Always look back.
3. Sequence Diagrams - These are great for testing your class diagrams. Do sequence diagrams for your major use cases like "Spawn Object" (Missile launcher spawns a missile object). In our game our entire object management system is done through our scripting engine (every object is scripted), so spawning a new object is pretty complex. If your sequence diagram is not simple, then you need to look at "Fixing" your class diagrams.
4. State diagrams - I personally haven''t use them yet, but we are still in the component phase. Although I believe we will use them when we start to model the UI and game logic. Like maybe when the player presses "ENTER" they enter a chat state where things they type are no longer ignored, but actually sent across the network and displayed as messages. We are still developing our components (almost done though), and we haven''t used these yet, but I can definately see the usefulness later on when we are building the game out of our components. Another example would be a virtua fighter game, when you are hit you enter a HitOnce state (which has a timer), get hit again while in that state and a "DOUBLE HIT" bonus is added to the score. Game logic stuff.
That''s pretty much how we use UML. And the quality we are getting is very good. Plus keep in mind we are an internet team who has to communicate without face to face meetings. The UML documentation is VERY helpful here.
Anyways,
1. Use Case diagrams - Limited in use in the standard way of doing things from the game players perspective. However, when you break your game down into modules (sound, graphics, object management, etc.) you can do use case diagrams where you say a module is the actor. It''s fairly useful in telling you how to define the interfaces between your modules.
2. Class Diagrams - These are invaluable. Before you start writing code, create some class diagrams. Move things around to make your diagram "Pretty". MAke things as simple as humanly possible. Code up to a point, and then go modify, and expand your class diagrams. An interative approach works well. Always look back.
3. Sequence Diagrams - These are great for testing your class diagrams. Do sequence diagrams for your major use cases like "Spawn Object" (Missile launcher spawns a missile object). In our game our entire object management system is done through our scripting engine (every object is scripted), so spawning a new object is pretty complex. If your sequence diagram is not simple, then you need to look at "Fixing" your class diagrams.
4. State diagrams - I personally haven''t use them yet, but we are still in the component phase. Although I believe we will use them when we start to model the UI and game logic. Like maybe when the player presses "ENTER" they enter a chat state where things they type are no longer ignored, but actually sent across the network and displayed as messages. We are still developing our components (almost done though), and we haven''t used these yet, but I can definately see the usefulness later on when we are building the game out of our components. Another example would be a virtua fighter game, when you are hit you enter a HitOnce state (which has a timer), get hit again while in that state and a "DOUBLE HIT" bonus is added to the score. Game logic stuff.
That''s pretty much how we use UML. And the quality we are getting is very good. Plus keep in mind we are an internet team who has to communicate without face to face meetings. The UML documentation is VERY helpful here.
> I think I am comfortable using UML, in that I can translate a
> design to a diagram quickly, but I still doubt the
> effectiveness. If I can diagram it, I can imagine it. And if I
> can imagine it, I can code it. I just can''t see the benefit.
> Reading code is quicker and less ambiguous than reading a
> diagram once you''ve started implementation.
Maybe you''re not using the right UML tool. Good UML tools act as graphical macros for creating code - check out Rational Rose, which can generate a complete class hierarchy from a class diagram. My dream is that DevStudio 9 or 10 will present a class diagram that you code into, instead of using archiac text files.
OK, here are some general notes and thoughts in no particular order:
- If you contract out your software engineering services, your analysis phase is your bidding phase, and is mandatory if you''d like to get paid fairly for your work.
- One downside to UML: it makes it easy to overengineer things. IMX when I create classes directly inside .h files they''re bound tighter to the specific code problem I''m working on, and when I generate them through UML I tend to come up with something more general. It''s these general classes that can lead to code bloat and overengineering. Of course the flip side is that the general ones are also more useful.
- I''ve used sequence diagrams to capture all of the misc stuff in a game not directly associated with gameplay. i.e., how to start a multiplayer game, practice game, load a saved game, etc.
- Sequence diagrams are also useful for documenting the player''s flow through a level. i.e., "Go get blue key, use blue key to unlock door 1, go get red key, picking up red key causes enemies to fall from the sky," that sort of thing.
- State diagrams are good for AIs.
- Use cases are good for hero actions. Think of actors not as the human playing the hero in the game, but as the human''s character interacting with the game world. You can also use actors for NPCs as well.
Anything that gets you thinking about code before you write code is helpful. UML makes you think about all the important areas, even if you end up realizing that most areas are trivial (remember, UML is addressing the problem of software design across the board, so a design for any one particular circumstance will not use every single feature). Don''t write things down for the sake of writing them down. Write them down because they help you visualize (or communicate) your ideas. There''s no sense in using UML for UML''s sake, and IMX I''ve found that the people who say UML doesn''t give you anything more than normal code would aren''t using UML correctly. Sort of like C programmers who say C++ doesn''t offer anything of value. The value''s there, you just have to work with it until things click and you begin to think UML.
Just my $0.02. Good thread!
Mason McCuskey
Spin Studios
Author, Special Effects Game Programming With DirectX 8.0, ISBN: 1-931841-06-3
"Specialization is for insects." - Robert A. Heinlein
> design to a diagram quickly, but I still doubt the
> effectiveness. If I can diagram it, I can imagine it. And if I
> can imagine it, I can code it. I just can''t see the benefit.
> Reading code is quicker and less ambiguous than reading a
> diagram once you''ve started implementation.
Maybe you''re not using the right UML tool. Good UML tools act as graphical macros for creating code - check out Rational Rose, which can generate a complete class hierarchy from a class diagram. My dream is that DevStudio 9 or 10 will present a class diagram that you code into, instead of using archiac text files.
OK, here are some general notes and thoughts in no particular order:
- If you contract out your software engineering services, your analysis phase is your bidding phase, and is mandatory if you''d like to get paid fairly for your work.
- One downside to UML: it makes it easy to overengineer things. IMX when I create classes directly inside .h files they''re bound tighter to the specific code problem I''m working on, and when I generate them through UML I tend to come up with something more general. It''s these general classes that can lead to code bloat and overengineering. Of course the flip side is that the general ones are also more useful.
- I''ve used sequence diagrams to capture all of the misc stuff in a game not directly associated with gameplay. i.e., how to start a multiplayer game, practice game, load a saved game, etc.
- Sequence diagrams are also useful for documenting the player''s flow through a level. i.e., "Go get blue key, use blue key to unlock door 1, go get red key, picking up red key causes enemies to fall from the sky," that sort of thing.
- State diagrams are good for AIs.
- Use cases are good for hero actions. Think of actors not as the human playing the hero in the game, but as the human''s character interacting with the game world. You can also use actors for NPCs as well.
Anything that gets you thinking about code before you write code is helpful. UML makes you think about all the important areas, even if you end up realizing that most areas are trivial (remember, UML is addressing the problem of software design across the board, so a design for any one particular circumstance will not use every single feature). Don''t write things down for the sake of writing them down. Write them down because they help you visualize (or communicate) your ideas. There''s no sense in using UML for UML''s sake, and IMX I''ve found that the people who say UML doesn''t give you anything more than normal code would aren''t using UML correctly. Sort of like C programmers who say C++ doesn''t offer anything of value. The value''s there, you just have to work with it until things click and you begin to think UML.
Just my $0.02. Good thread!
Mason McCuskey
Spin Studios
Author, Special Effects Game Programming With DirectX 8.0, ISBN: 1-931841-06-3
"Specialization is for insects." - Robert A. Heinlein
Quick disclaimer - if I sound negative or sceptical, it''s because I''m trying hard to find a way in which the game development process can be improved, and everything I research seems to be very overhyped and not very useful. Please feel free to smash any of my claims with counter-evidence. However, everything I say is true in my (limited) experience.
Khawk:
Ok, so scenarios and use cases may be useful in some ways, but if you take out the diagram, I think you are talking more about a methodology than UML then. Picky, I know, but I still don''t think "use case diagrams" are of any use except to show to a customer. (And if, as you suggest later, you treat the designer as the customer, even this benefit is lost.)
Ok, I find myself recoding things occasionally, but not often. Usually any changes come about as a result of the Game Design part of mind deciding something different, which forces the Game Programming side to rewrite code. These are changing requirements, not unforeseen ones, nor developmental oversight.
As for learning curves and so on... I must honestly say that I never have a problem understanding my own C++ code, even years on. Maybe the same does not go for anyone else. I can only speak for myself
But as for the 50% figure spent on maintenance... is that really true? You assert it as a fact, and I don''t doubt you got it from a reputable source, but it is obviously an overgeneralisation. In fact, I would make the claim that this is one of the areas that singles development for retail products out from bespoke software for a given client - retail software does not have anything near that much time spent in maintenance. On the Gamasutra site, people say in the postmortems that the project took between 1 and 3 years in general. Can you find me a game, outside the MMORPG genre, where they spent a year in full-time work maintaining the product? I seriously doubt it. I expect that for computer games (excluding MMORPGs again) the percentage is between 1% and 20% at an absolute maximum. And if you code operating systems, it''s possibly nearer 90%. So the mean average across all software development projects may be 50%, but it''s an inaccurate figure to base specific choices upon. IMHO (Note that I am using the ANSI/IEEE standard definition of software maintenance: "the modification of a software system after installation to correct faults, improve technical performance, or adapt functionality to a changed environment". I equate ''installation'' to ''shipping to retailers''.)
Therefore if one of UML''s main benefits is to reduce the cost of maintenance, this would explain a lot to me. It would make it clear why ''traditional'' software developers rave about it being some sort of documentational silver bullet, and yet why most game developers have zero to little need for it.
My MUD project is (according to my MSVC line counter add-in) 54194 lines total, 32397 code, 14204 comments, 1998 mixed, 9591 blank, net lines 44603, net code 34,935. So let''s say it''s 35KLOC. Parts of it are 4 years old. Yet I understand every bit of it - or at least I will understand any bit of it if I look at it for 30 seconds. Admittedly, MUD code is often quite simple. But I really don''t have any problem with it. Perhaps I am just not in UML''s target audience? Perhaps it''s aimed at people less able to comprehend large bodies of code than myself? That sounds too arrogant, but I really don''t know. All I do know is that 35 thousand lines of code is not a problem for me given that it''s arranged and commented well.
Shaft:
How do you generate your use cases? Since you find sequence diagrams so useful, and base them on your use cases, then obviously your use cases are the important part of the process. You make it sound like you are using use cases to capture the interface of the system - but I thought that was largely what the class diagram was for anyway.
The usefulness in using UML for internet communication of ideas is very understandable though. It''s far easier to send one class diagram than a whole lot of C++ header files.
Mason:
You''re right, I''m not using much of a tool, but in all fairness the language is not the tool. Pretty much anything is good if you have a decent enough tool to manipulate it with. However, I hated Rational Rose on the couple of occasions I tried to get it to do something intelligent and gave up at that point. From what I remember, I can''t afford it for my home PC anyway so there''s little point me learning it now.
I understand what you''re saying when you suggest that someone like me would just have to keep working with UML to see the benefits, but I would need to be convinced that such benefits exist first As I already said above, I have absolutely no problem understanding my code, no matter how much of it there is or how old it is. Nor do I have any need to communicate my ideas to others, although I am very well aware that this will change should I enter a team environment. So, what does UML buy me, as a single programmer with a good knowledge of C++.
Additionally, I would be very interested if those of you who use UML could post some sample diagrams here. It would be useful to see what it is exactly that helps the coding.
[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]
However, everything I say is true in my (limited) experience.Khawk:
Ok, so scenarios and use cases may be useful in some ways, but if you take out the diagram, I think you are talking more about a methodology than UML then. Picky, I know, but I still don''t think "use case diagrams" are of any use except to show to a customer. (And if, as you suggest later, you treat the designer as the customer, even this benefit is lost.)
quote:For instance, how often do you find yourself recoding or redesigning something? How about if you don''t touch some code from a project for a while.. what''s the learning curve for figuring out what''s going on? What about maintenance? (fact: 50% of a project''s budget is spent on maintenance)
Ok, I find myself recoding things occasionally, but not often. Usually any changes come about as a result of the Game Design part of mind deciding something different, which forces the Game Programming side to rewrite code. These are changing requirements, not unforeseen ones, nor developmental oversight.
As for learning curves and so on... I must honestly say that I never have a problem understanding my own C++ code, even years on. Maybe the same does not go for anyone else. I can only speak for myself
But as for the 50% figure spent on maintenance... is that really true? You assert it as a fact, and I don''t doubt you got it from a reputable source, but it is obviously an overgeneralisation. In fact, I would make the claim that this is one of the areas that singles development for retail products out from bespoke software for a given client - retail software does not have anything near that much time spent in maintenance. On the Gamasutra site, people say in the postmortems that the project took between 1 and 3 years in general. Can you find me a game, outside the MMORPG genre, where they spent a year in full-time work maintaining the product? I seriously doubt it. I expect that for computer games (excluding MMORPGs again) the percentage is between 1% and 20% at an absolute maximum. And if you code operating systems, it''s possibly nearer 90%. So the mean average across all software development projects may be 50%, but it''s an inaccurate figure to base specific choices upon. IMHO
(Note that I am using the ANSI/IEEE standard definition of software maintenance: "the modification of a software system after installation to correct faults, improve technical performance, or adapt functionality to a changed environment". I equate ''installation'' to ''shipping to retailers''.)Therefore if one of UML''s main benefits is to reduce the cost of maintenance, this would explain a lot to me. It would make it clear why ''traditional'' software developers rave about it being some sort of documentational silver bullet, and yet why most game developers have zero to little need for it.
quote:I have a hard time believing you can understand everything happening in something greater than 10,000-15,000 LOC.
My MUD project is (according to my MSVC line counter add-in) 54194 lines total, 32397 code, 14204 comments, 1998 mixed, 9591 blank, net lines 44603, net code 34,935. So let''s say it''s 35KLOC. Parts of it are 4 years old. Yet I understand every bit of it - or at least I will understand any bit of it if I look at it for 30 seconds. Admittedly, MUD code is often quite simple. But I really don''t have any problem with it. Perhaps I am just not in UML''s target audience? Perhaps it''s aimed at people less able to comprehend large bodies of code than myself? That sounds too arrogant, but I really don''t know. All I do know is that 35 thousand lines of code is not a problem for me given that it''s arranged and commented well.
Shaft:
How do you generate your use cases? Since you find sequence diagrams so useful, and base them on your use cases, then obviously your use cases are the important part of the process. You make it sound like you are using use cases to capture the interface of the system - but I thought that was largely what the class diagram was for anyway.
The usefulness in using UML for internet communication of ideas is very understandable though. It''s far easier to send one class diagram than a whole lot of C++ header files.
Mason:
You''re right, I''m not using much of a tool, but in all fairness the language is not the tool. Pretty much anything is good if you have a decent enough tool to manipulate it with. However, I hated Rational Rose on the couple of occasions I tried to get it to do something intelligent and gave up at that point. From what I remember, I can''t afford it for my home PC anyway so there''s little point me learning it now.
I understand what you''re saying when you suggest that someone like me would just have to keep working with UML to see the benefits, but I would need to be convinced that such benefits exist first
As I already said above, I have absolutely no problem understanding my code, no matter how much of it there is or how old it is. Nor do I have any need to communicate my ideas to others, although I am very well aware that this will change should I enter a team environment. So, what does UML buy me, as a single programmer with a good knowledge of C++.Additionally, I would be very interested if those of you who use UML could post some sample diagrams here. It would be useful to see what it is exactly that helps the coding.
[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
