Archived

This topic is now archived and is closed to further replies.

khawk

UML in game development

Recommended Posts

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

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 ]

Share this post


Link to post
Share on other sites
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. 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).



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? ) 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...



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 ]

    Share this post


    Link to post
    Share on other sites
    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 aside using UML made me a much better developer.

    Share this post


    Link to post
    Share on other sites
    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 using UML made me a much better developer.



    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.

    Share this post


    Link to post
    Share on other sites
    > 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

    Share this post


    Link to post
    Share on other sites
    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.)

    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 ]

    Share this post


    Link to post
    Share on other sites
    Kylotan,

    I don''t do sequence diagrams from my use case diagrams (Normally in UML and the unified process you should) because I don''t find use case diagrams all that useful in a game context. I do sequence diagrams for operations that will trace through several major components. That way I can see how the code interacts, which is pretty nice for quick refresher documentation as to how things work, and it gives me a clue as to whether my class diagrams are simple enough.

    If you can trace through your year old code and understand it in a second, you are damn lucky. I can''t even remember what I had for lunch today, let alone my train of thought from a year ago. But, what about your teammates. Can they as quickly understand your code and understand perfectly how to use it in just a few seconds. Give someone a class diagram and a few sequence diagrams, and they can.

    I do understand where you are coming from, though. I started using UML for a very small personal game project and within a week, said this is damn useless. I then learned UML and software engineering from school and did it for some business type projects, and then later tried it again for game stuff, and it worked out much better. Learning the unified process and trying to link it to a game is a major jump. Learn how to use it the way it was intended to be used (for apps), and then tweak it for games is much easier.

    UML and software engineering is one of those things that you prety much hate and find useless until you get good at it. And then you can''t live without it.

    Share this post


    Link to post
    Share on other sites
    quote:
    Original post by shaft
    I don''t do sequence diagrams from my use case diagrams (Normally in UML and the unified process you should) because I don''t find use case diagrams all that useful in a game context. I do sequence diagrams for operations that will trace through several major components. That way I can see how the code interacts, which is pretty nice for quick refresher documentation as to how things work, and it gives me a clue as to whether my class diagrams are simple enough.

    You did say that you do them for your major use cases though. (Not use case diagrams, I know.) I still don''t see the benefit of the sequence diagram. I find jotting down the basic algorithm on paper is sufficient documentation for how the interaction is going to go. No wasting time drawing a lot of lines from one component to the other... It''s not very object oriented, but then neither are use cases...

    Where exactly is the benefit? Is it just that the sequence diagram is on one sheet of paper whereas the code is in several files? The amount of text is going to be approximately the same in each case.

    quote:
    If you can trace through your year old code and understand it in a second, you are damn lucky. [...] But, what about your teammates. Can they as quickly understand your code and understand perfectly how to use it in just a few seconds. Give someone a class diagram and a few sequence diagrams, and they can.

    Yep. I am not trying to boast or anything, but I have no trouble understanding my own code. I learned C primarily by reading source code - not ''hello world'' code but complete systems of 20 or more files. And my own code is organised and documented far better than that ever was. I don''t need to remember my train of thought, as the details are all in the code. It''s like reading a book to me.

    Again, I admit this is not the case for everyone, and I think I already conceded above that UML is a quicker way to communicate ideas than the code is, and would work better in a team environment. I was just asking if there is any benefit in a single-person environment - that is, are there any benefits beyond person to person communication? Currently, I don''t see any. I''d love to be made aware of some. I would be a willing convert, if only the evidence was there. I have read various UML books to try and gain some insight, but no luck yet...



    [ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]

    Share this post


    Link to post
    Share on other sites


    This is an example of one of my sequence diagrams. It is how I insert a conroller object into the scripting engine (actually this is a very old diagram, and it's not quite done this way - but I'm at my work computer so you get what I have here ). On a single page in an easy to follow diagram, people can see what classes are involved, What methods are used, etc.

    In 5 seconds you can understand what's going on. You don't need to follow a single line of code.

    Also, note this diagram shows code in several .dlls, and classes in 2 languages. Some classes are Java, some are C++. Trust me, following this guy via source code would not be a simple task.



    [edited by - shaft on March 29, 2002 12:36:17 PM]

    [edited by - shaft on April 1, 2002 1:38:07 PM]

    [edited by - shaft on April 1, 2002 1:39:32 PM]

    Share this post


    Link to post
    Share on other sites
    Dang it, I screwed up the image thing, I was thinking the image got uploaded, not just a link. I''ll fix it later. Sorry.

    Share this post


    Link to post
    Share on other sites
    I''m also trying to figure out how to apply UML (and even RUP) to game development. I''ve done a fair bit of large scale development, and I''m evaluating whether or not those process will work on smaller, single person projects.

    Ok, first off, UML is a communication tool foremost. It''s primary purpose is not to help you design your own classes, it''s to help you express your ideas to the next guy on your team. It defines a standard syntax that everyone can use, regardless of technical ability or team role. If you''re a single person shop, then you''ve already lost the really import part of UML. Same thing applies to RUP, it''s primarily a method for interacting with everyone else on a team to deliver a product. On the other hand, with a development team of more than two people, I think that UML (and even RUP) help immensely, regardless of whether it''s a shrink wrapped product or an in-house application.

    Second, UML is still useful for a single person, as far as expressing design. I tend to write everything in UML first, then translate it to whatever programming language I''m using, for all but the most trivial projects. Here is my personal method, which may or may not work for anyone else.

    First, figure out the actors and use cases. Games don''t seem at first blush to be very well suited for use cases, but I disagree. A use case is anything that the user can do that has an effect on the system. So shooting someone in a FPS is a use case. Building a unit in an RTS is a use case. Finding the magic doomathingy in an RPG is a use case. These are all things that have to be thought out, and it''s cheaper (and faster) to think them out ahead of time. If you are working on a network game, then any network player is a separate actor. If it''s a client server type game (like a MMORPG), then the server itself is an actor.

    Then from your use cases, figure out your top level "domain" objects. This is a sort of very high level view of how the overall architecture should go. This helps to divide up modules and responsibilities, so you don''t have things like input getting handled in your graphics module.

    Then I start doing sequence and interaction diagrams, each designed to fulfill a use case, creating classes and methods as needed to make the sequence work. By the time I''m done with that, I have a complete set of classes, complete with the methods that they need to implement and the data attributes they contain. When it''s done, and everything works on paper, then I do the "real" code.

    Some UML tools will actually generate code for you, but I tend to shy away from that. Although Rose is getting a lot better, you just have to clean it up a bunch.

    Obviously there are still going to be design decisions that have to be made as I''m actually coding the object, but the bulk of them have already been decided, before I ever wrote a line of code.

    Once the coding is done (and I haven''t gotten this far, so this is conjecture extrapolated from my experience on big team projects), you use your use cases and sequence diagrams to generate test cases. Since you know the line of control for every sequence through the system, you have a road map to build test cases from.

    Whew! Sorry that was so long. I''m still trying to see if this system works, but for me, it''s been pretty good so far.

    It seems to me that the game industry is really lacking in established development methodologies. Perhaps that''s why the closest thing to a schedule (for most) is "it''s done when it''s done". That kind of attitude rarely works in the rest of the industry.

    Take care,
    Bill


    Share this post


    Link to post
    Share on other sites
    quote:
    Original post by Siebharinn
    First, figure out the actors and use cases. Games don''t seem at first blush to be very well suited for use cases, but I disagree. A use case is anything that the user can do that has an effect on the system. So shooting someone in a FPS is a use case. Building a unit in an RTS is a use case. Finding the magic doomathingy in an RPG is a use case.
    [...]
    Then from your use cases, figure out your top level "domain" objects. This is a sort of very high level view of how the overall architecture should go. This helps to divide up modules and responsibilities, so you don''t have things like input getting handled in your graphics module.

    How would any of the above use cases yield anything like a graphics module? I agree that they could be useful for finding domain objects, but I don''t see how this carries forward into your modules at all. And how do you find examples for things that aren''t directly caused by actors? If I start a game of Command and Conquer and just sit there doing absolutely nothing, eventually the bad guys will hunt me down. Yet this isn''t adequately covered in any definition of use cases I''ve seen. They''re still geared towards the client-server or batch job operation, where the system sits idly until An Event happens, usually user input. The event is processed and then the system sits still again. The traditional use case concept of an actor/system interaction is insufficient for bidirectional and continuous interactive systems such as games and simulations. IMHO

    quote:
    Once the coding is done (and I haven''t gotten this far, so this is conjecture extrapolated from my experience on big team projects), you use your use cases and sequence diagrams to generate test cases.

    I think the idea is that each use case covers a variety of scenarios, and you should test each scenario at least once.

    quote:
    Since you know the line of control for every sequence through the system, you have a road map to build test cases from.

    I don''t agree with this, which is a large part of why I don''t think use cases have more than a trivial role to play in game development. It seems to me that there are way too many concurrent objects and factors taking place for a sequence diagram of anything non-trivial to be anything more than a basic overview of which functions need to be implemented. A complex system will be more than a list of if-then checks - it will have varying behaviour based on some continuous variables. Sticking conditionals above the message arrows can only go so far. A good example would be something like AI - how do you represent a neural net or fuzzy logic in this?

    quote:
    It seems to me that the game industry is really lacking in established development methodologies. Perhaps that''s why the closest thing to a schedule (for most) is "it''s done when it''s done". That kind of attitude rarely works in the rest of the industry.

    I agree, but my research so far is telling me 2 things:

    a) More published patterns would probably be more beneficial than concentrating on documentation such as UML or methods such as the RUP. I find a lot of my games include certain collaborations that could usefully be called a ''pattern'', and which are not directly represented in the Design Patterns book.

    b) Use cases just don''t cut it for requirements capture or internally-generated events in game development. There needs to be some new system of categorising events, activity, input/output and so on, that more closely correlates to game programming.

    I intend researching both these things when I get a chance.

    [ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions ]

    Share this post


    Link to post
    Share on other sites
    quote:
    Original post by Kylotan
    How would any of the above use cases yield anything like a graphics module? I agree that they could be useful for finding domain objects, but I don''t see how this carries forward into your modules at all. And how do you find examples for things that aren''t directly caused by actors? If I start a game of Command and Conquer and just sit there doing absolutely nothing, eventually the bad guys will hunt me down. Yet this isn''t adequately covered in any definition of use cases I''ve seen. They''re still geared towards the client-server or batch job operation, where the system sits idly until An Event happens, usually user input. The event is processed and then the system sits still again. The traditional use case concept of an actor/system interaction is insufficient for bidirectional and continuous interactive systems such as games and simulations.



    Actually, the system itself is often considered an actor. This is useful for when the system is idle, and something needs to occur. For instance, in your C&C example, some use cases might be "Computer Builds Unit", "Computer Evaluates Status", "Computer Moves Unit", and so on.

    quote:
    I think the idea is that each use case covers a variety of scenarios, and you should test each scenario at least once.


    This is not a direct reply for Kylotan...
    I don''t know about sequence diagrams, but I can see how use cases are useful for generating test cases. I guess it depends on what type of test it is as well though.

    quote:

    I don''t agree with this, which is a large part of why I don''t think use cases have more than a trivial role to play in game development. It seems to me that there are way too many concurrent objects and factors taking place for a sequence diagram of anything non-trivial to be anything more than a basic overview of which functions need to be implemented. A complex system will be more than a list of if-then checks - it will have varying behaviour based on some continuous variables. Sticking conditionals above the message arrows can only go so far. A good example would be something like AI - how do you represent a neural net or fuzzy logic in this?


    If they can use the UML in real-time system development, then they can definitely use it in game development. RT systems have plenty of concurrency going on, yet sequence diagrams are integral to modern RT system development. If I can find a good example of a sequence diagram from a complex system, I''ll post it here.

    Also, a neural net or fuzzy logic would probably not be represented in this way. A state transition diagram, or statechart, seems better suited to the task.

    quote:

    I agree, but my research so far is telling me 2 things:

    a) More published patterns would probably be more beneficial than concentrating on documentation such as UML or methods such as the RUP. I find a lot of my games include certain collaborations that could usefully be called a ''pattern'', and which are not directly represented in the Design Patterns book.

    b) Use cases just don''t cut it for requirements capture or internally-generated events in game development. There needs to be some new system of categorising events, activity, input/output and so on, that more closely correlates to game programming.

    I intend researching both these things when I get a chance.



    a. I agree with the patterns, but it has no correlation to whether or not UML documentation or the RUP is useful. It''s also not just about documentation. It''s about analysis design.

    b. Refer to my above statement on use cases. You might change your mind when you really think about it. I do agree that use cases need to be tweaked in the context of games, but that''s no big deal. Everything in software engineering needs to be tweaked and customized to fit your needs.





    Kevin "Khawk" Hawkins
    CEO and News Director, GameDev.net
    Author, OpenGL Game Programming
    Developer Diary

    quote:
    Original post by Khawk
    Actually, the system itself is often considered an actor. This is useful for when the system is idle, and something needs to occur. For instance, in your C&C example, some use cases might be "Computer Builds Unit", "Computer Evaluates Status", "Computer Moves Unit", and so on.

    Any references to the ''system as an actor'' idiom? I''ve not come across this in any of the books I''ve read, so I assumed it was considered ''wrong''. Generally they stress that actors are external and the system is internal, by definition. "An Actor is the role that a user plays with regard to the system" (UML Distilled 2nd Ed, pg 42). I''m not trying to be pedantic here: I''m just trying to say that although you may be using the diagrams, you''re moving away from the expected semantics towards something different.

    quote:
    If they can use the UML in real-time system development, then they can definitely use it in game development. RT systems have plenty of concurrency going on, yet sequence diagrams are integral to modern RT system development. If I can find a good example of a sequence diagram from a complex system, I''ll post it here.

    Fair enough. But it seems to me that the RT stuff was tacked on to UML as "something we don''t yet do properly and really ought to", in the form of State diagrams and Activity Diagrams (aka legitimized flowcharts). State diagrams would certainly be useful for AI states, or animation states, etc. Activity diagrams are potentially replacements for interaction diagrams in that they''re better suited to showing algorithms - but then you''re moving away from object-orientation aspect. This may not be a problem for you in your book, however, if you are treating UML as a stand-alone tool.

    quote:
    Also, a neural net or fuzzy logic would probably not be represented in this way. A state transition diagram, or statechart, seems better suited to the task.

    The problem is that neural nets and fuzzy logic exist as a deliberate attempt to get away from the concept of finite and discrete sets. Now, I''m not suggesting you model the NN or Fuzzy Logic calculation directly (although you could, if it helped to create it in the first place), but the problem is that the UML does not adapt well to the continuous output that many functions produce. In fact, I''m having trouble seeing how any high level AI concept apart from a simple finite state machine or a tree of conditional statements can be modelled. It would be a shame to see designs limited merely because the development team''s standard documentation rules couldn''t express the concept adequately.

    quote:
    Refer to my above statement on use cases. You might change your mind when you really think about it. I do agree that use cases need to be tweaked in the context of games, but that''s no big deal. Everything in software engineering needs to be tweaked and customized to fit your needs.


    I''ve thought about it a lot, in the last 6 months I''ve spent on my ''software engineering in game dev'' project, as well as the previous 6 months in my ''advanced analyis and design'' class. I certainly agree that almost any of the UML diagrams can be tweaked to fit the need for game development documentation, but I am concerned that this is a ''local minima'' as they say, which distracts us from the likelihood that we need to develop more specialised and domain-centric documentation for games. In my opinion, some UML diagrams fit well (state, class, package), some fit averagely (sequence, activity), and some are more trouble than they''re worth (use case, collaboration).

    Again, please don''t take this as being unnecessarily argumentative. We''ve obviously both done research and come to different conclusions: such is the nature of science Hopefully by the time your chapter is published I''ll be able to afford to buy the book so that I can see your examples

    [ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions ]

    Share this post


    Link to post
    Share on other sites
    I''ve recently been studying UML with the intention of using it in a game design project, so some of the comments I''ve seen here are very interesting. But it seems to me that there is a different way of using UML for games than has been discussed here so far. Maybe it''s because I''m new to UML and I''m seeing more potential than is really there, but here is a thought I had when reading about Use Case diagrams and wondering if there were any users other than the player. It occurred to me that, if I consider the system I am modelling to be more than just the end product that the player sees, but to also include the in-house tools and workflow, I would see many opportunities for improvement of the overall design process. In this view, the various artists and other content creators for the game, as well as the QA team, would be considered users of the system (and therefore actors needing use cases). They all need ways to insert the assets they have created into the game, they would all benefit from having ways to test those assets easily, etc. Look at a few game postmortems, and count the number of times they list the ability to do these things quickly and easily as a major factor. If you take this approach, then you are not just designing a game, but a whole game development process. This might be of particular benefit to those who wish to reuse the engine on which their game is based, as the tools and workflows that are first used with an engine are typically also reused.

    Just a thought.

    Share this post


    Link to post
    Share on other sites
    quote:
    Original post by Kylotan
    Any references to the 'system as an actor' idiom? I've not come across this in any of the books I've read, so I assumed it was considered 'wrong'.


    This type of referencing is mostly used in embedded systems. The Real-time UML book shows several examples which you can refer. There is even a real-time development process created by the author.

    Besides, there is a business use case and a system use case. There seem to be some confusion as to which one is being refered to, no?

    According to UML Distilled:
    Business Use Case = How a business responds to a customer or event. In game development context, I think this can be translated to how the engine run things. Actors = modules.

    System Use Case = interaction with the software. In short, modeling user actions and system response. I guess the requirements are extracted from here.

    [edited by - cdtrrrst on April 16, 2002 4:59:15 PM]

    Share this post


    Link to post
    Share on other sites
    Plasmadog, that''s an interesting usage, but it''s addressing the game development process system, rather than the system created by the game development process. As such I can see it might be useful for established companies, but I don''t see it would help much for the average small team.

    [ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions ]

    Share this post


    Link to post
    Share on other sites
    quote:
    As such I can see it might be useful for established companies, but I don''t see it would help much for the average small team.

    Unless it''s a new team of course.

    Share this post


    Link to post
    Share on other sites
    UML is useful for any team, so long as the project is atleast of moderate size.

    Step back and look at all the side-effects you get with UML... 1. Documentation, 2. A better design (because you are able to look at the whole and not just the micro view), 3. A standard way to communicate your software to anyone (like team members), 4. Inherant reusability that comes with good design, and solid documentation on how to re-use. And the list goes on.

    The problem with software engineering is it is NOT programming. Talented programmers assume that if they know programming they should be able to pick up software engineering in 2 seconds. When they don''t see it''s uses in 2 seconds, they assume software engineering isn''t worth it.

    It took you a long time to do programming in a useful way, it takes some time to learn to use UML and software engineering in a useful way. It wasn''t until my second large project using UML that I started to see it''s usefulness.

    Share this post


    Link to post
    Share on other sites
    quote:
    Original post by shaft
    Step back and look at all the side-effects you get with UML... 1. Documentation, 2. A better design (because you are able to look at the whole and not just the micro view), 3. A standard way to communicate your software to anyone (like team members), 4. Inherant reusability that comes with good design, and solid documentation on how to re-use. And the list goes on.

    1, I don''t need, not in the way that UML provides it. The documentation it produces is largely useless for me. That sequence diagram you showed above could probably be represented in 1/5 the space with a simple description of the algorithm.
    2. I don''t need diagrams to envisage a system. You need to be able to envisage it to draw it anyway, so this is is a vacuous claim in my opinion.
    3. This is true.
    4. Just 1 and 2 reworded. I never needed UML to achieve reuse or good designs now, and using UML has not helped me do so. Maybe it brings a less skilled system architect up to my level, which I can''t comment on, but it has not made me any better.

    quote:
    When they don''t see it''s uses in 2 seconds, they assume software engineering isn''t worth it.

    Where 2 seconds equals many months in my case. I wouldn''t sell any other concept to anyone on the basis of "just try it; you''ll see I''m right in the end", so why sell UML on that basis? I have good reasons to recommend OOP to people. I have good reasons to recommend the STL and generic programming to people. I have good reasons to recommend patterns, abstraction, the RUP, C++, so on. But I have no good reason to recommend UML to single game developers. Simply because none of the so-called benefits of UML seem to apply to me, and no-one else seems to give any concrete examples of benefits beyond standardisation. Is it so hard to produce a good argument in its favour?

    Summary: I really don''t see the point apart from the communication benefits. Can anyone give me a good rebuttal with some actual content? I wouldn''t labour the point if I didn''t want to be proved wrong.

    [ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions ]

    Share this post


    Link to post
    Share on other sites
    quote:
    Original post by Kylotan

    2. I don't need diagrams to envisage a system. You need to be able to envisage it to draw it anyway, so this is is a vacuous claim in my opinion.



    If you do any sort of drawing when designing software, you are doing a diagram. You might not be using a standard notation (i.e. UML), but you're doing a diagram. Your first design is never as good as the final design, anyway, so what you envisage initially is not your best because you need to be able to see it and go through its parts..particularly as the system gets more complex. I imagine that you do some sort of iterative design process anyway.

    Now something to think about.. (because I'm rather positive you draw your designs out.. I don't know any programmer that doesn't ).. do you use the same notation everytime you design? If you do, then wonderful, and kudos to your self-implemented syntax, but chances are that you don't. So let's say you come up with an elegant design to a difficult solution, and you have this diagram on a piece of paper that you whipped up while trying to solve the problem. A few years pass, and you come across the same type of problem again, and you remember that you have this solution for this problem, so you get out this piece of paper with the design (i.e. the purpose of design patterns). You start looking at it, but the notation that you use for your designs has changed over the years, so you don't know exactly what you meant by a particular symbol, line, or even text in the diagram. What do you do? Design from scratch? Dig out the code and reverse-engineer the design? Try to remember what you meant by this diagram? Whatever you decide to do, I personally think it would be much easier if you had used a notation that has been consistent for about 7 years now, that has good documentation on the notation itself (so you could look up things if needed), and that will be viable in the future - UML.

    ** appended below **

    UML is nothing revolutionary. Its primary benefit is standardization. There are plenty other OO design notations out there (OMT, Booch, Rumbaugh, etc), but UML is good because it provides different views of the system in a coherent and standard way. That may explain why people are having trouble coming up with an argument other than standardization - THAT is the primary goal of UML.


    Kevin "Khawk" Hawkins
    CEO and News Director, GameDev.net
    Author, OpenGL Game Programming
    Developer Diary