Utilising UML in Game Development?
Author
Hi,
I just started learning UML and I would like to know how useful is it in game development. Most of the models I''ve seen in books and articles use it for databases and stuff and I can''t think of how effective it can be utilised in game design. Has anyone here ever made use of UML effectively in his/her game design. I would appreciate some links to sample UML game models if there is any. Thanks.
I'm doing a game for my Honours project, so I darn well hope it's useful 
.
UML can be very useful. It can help clarify heirarchies (e.g. creature -> human -> player kinda thing), and if you're game is any kop then you should be able to have a fair few classes. If you find you've only got a "game" class and a "player" class, then just give up now, lol.
One technique for writing games is to use finite state machines. UML should allow you to specify this well. I dunno yet, because I'm starting the design stage for my game next week.
Last year I was doing a Monopoly game for a team project. UML really pulled its weight then, and allowed a fantastic design that made implementing the code easy. I don't know how it fares with action games, but it should do just as well (if you take care).
Alistair Keys
"There are two kinds of people, those who finish what they start and so on."
-- Robert Byrne
P.S. I'll try to dig up my old class design, but I doubt it's still around. The uni has changed CASE tools, and I think the old work was deleted at the same time. I'll also let you know how UML helps (or hinders) my project.
Edited by - Alimonster on November 16, 2001 8:08:40 AM
.UML can be very useful. It can help clarify heirarchies (e.g. creature -> human -> player kinda thing), and if you're game is any kop then you should be able to have a fair few classes. If you find you've only got a "game" class and a "player" class, then just give up now, lol.
One technique for writing games is to use finite state machines. UML should allow you to specify this well. I dunno yet, because I'm starting the design stage for my game next week.
Last year I was doing a Monopoly game for a team project. UML really pulled its weight then, and allowed a fantastic design that made implementing the code easy. I don't know how it fares with action games, but it should do just as well (if you take care).
Alistair Keys
"There are two kinds of people, those who finish what they start and so on."
-- Robert Byrne
P.S. I'll try to dig up my old class design, but I doubt it's still around. The uni has changed CASE tools, and I think the old work was deleted at the same time. I'll also let you know how UML helps (or hinders) my project.
Edited by - Alimonster on November 16, 2001 8:08:40 AM
My Honours project is actually researching the Pros and Cons in using UML and OOP in game design and programming 
Basically it''s 1/3 research (talking to other developers about their experiences and opinions) and 2/3 case study (analysing my own game design using UML and OOP). If you have any good references or anything, I''d be interested to hear them.
Basically it''s 1/3 research (talking to other developers about their experiences and opinions) and 2/3 case study (analysing my own game design using UML and OOP). If you have any good references or anything, I''d be interested to hear them.
Well I''m currently creating a pretty complicated project with several other people, and UML has been critical.
UML is great for designing an architecture that can be split among people. Those architecture can be further broken down into complete designs, and the end product is a great design and complete documentation on how the code works.
Here''s how we are using it.
Created a class diagram of the different systems (as packages).
The scripting engine, the network module, the graphics engine, etc.
Then create sequence diagrams of how a game "tick" works. UserInput -> GameCode -> Scripting Engine -> Game Data ... This helps make it easy to figure out the interfaces of how the different modules will talk to each other. Once you have the interfaces figured out, your people can begin designing their modules. And since you''ve already figured out the cross-module interfaces, you know that the design the come up with will fit into the game.
Also UML rocks for the module design too. I''m doing the scripting engine for our game, and the design and implementation is coming out awesome. I''ve just finished the pre-alpha version, and it rocks. It''s about 10 times faster than unreal script, and about 1,000,000 times more expandable.
Most UML books are dedicated to database type programs, which doesn''t translate well to games. They are based on many simple user use cases like - open, load, save, read, write, etc. These don''t really exist in games in the book form. Most things are tied up around one really complicated use case - "Tick".
So you can still use the book techniques, you just need to break the "Tick" use case up into several smaller use cases.
UML is great for designing an architecture that can be split among people. Those architecture can be further broken down into complete designs, and the end product is a great design and complete documentation on how the code works.
Here''s how we are using it.
Created a class diagram of the different systems (as packages).
The scripting engine, the network module, the graphics engine, etc.
Then create sequence diagrams of how a game "tick" works. UserInput -> GameCode -> Scripting Engine -> Game Data ... This helps make it easy to figure out the interfaces of how the different modules will talk to each other. Once you have the interfaces figured out, your people can begin designing their modules. And since you''ve already figured out the cross-module interfaces, you know that the design the come up with will fit into the game.
Also UML rocks for the module design too. I''m doing the scripting engine for our game, and the design and implementation is coming out awesome. I''ve just finished the pre-alpha version, and it rocks. It''s about 10 times faster than unreal script, and about 1,000,000 times more expandable.
Most UML books are dedicated to database type programs, which doesn''t translate well to games. They are based on many simple user use cases like - open, load, save, read, write, etc. These don''t really exist in games in the book form. Most things are tied up around one really complicated use case - "Tick".
So you can still use the book techniques, you just need to break the "Tick" use case up into several smaller use cases.
quote:Original post by shaft
Most UML books are dedicated to database type programs, which doesn''t translate well to games.
Although one could argue that most games are nothing more than fancy real-time interfaces to databases
--
Sorry Kylotan, but I can't give you much help. Mostly, I've looked at game design articles on Gamasutra. I've found some other good things (like Doom's design doc, which sucks ) and Xenon 2000's source code (it came with a PC Format issue). That's a really well designed game, by the way.
However, when it comes to UML I haven't done much. All I can recommend is the standard bumff, like the "Gang of Four" (GoF). I haven't stumbled across any example UML designs for games yet, although I haven't checked. I'll do that sometime, I suppose.
Next week is going to be fun. I've got one week left of the design stage, according to my project schedule. In that time, I need to do: candidate class list, UML, use cases, interface prototypes, a Game Design document... etc. The only saving grace is that I've done my Requirements Spec. Looks like I'll have to get busy and spend less time being bothersome on these forums.
Alistair Keys
EDIT - whoops, I think I'm getting confused. The Gang of Four are for design patterns, aren't they? I can't remember if they've anything to do with UML at all. My bad (looks like it's time to review last year's lecture slides again).
"There are two kinds of people, those who finish what they start and so on."
-- Robert Byrne
Edited by - Alimonster on November 17, 2001 9:58:04 AM
) and Xenon 2000's source code (it came with a PC Format issue). That's a really well designed game, by the way.However, when it comes to UML I haven't done much. All I can recommend is the standard bumff, like the "Gang of Four" (GoF). I haven't stumbled across any example UML designs for games yet, although I haven't checked. I'll do that sometime, I suppose.
Next week is going to be fun. I've got one week left of the design stage, according to my project schedule. In that time, I need to do: candidate class list, UML, use cases, interface prototypes, a Game Design document... etc. The only saving grace is that I've done my Requirements Spec. Looks like I'll have to get busy and spend less time being bothersome on these forums.
Alistair Keys
EDIT - whoops, I think I'm getting confused. The Gang of Four are for design patterns, aren't they? I can't remember if they've anything to do with UML at all. My bad (looks like it's time to review last year's lecture slides again
)."There are two kinds of people, those who finish what they start and so on."
-- Robert Byrne
Edited by - Alimonster on November 17, 2001 9:58:04 AM
I recently used UML for a PS2 game and found it a very positive experience. Some might criticise the use of it for games but it''s important to remember that UML is a notation and not a process, you can use as much or as little of it as you want and admittedly some of it is definately overkill.
A point I always like to make is that when you are drawing little plans on paper, regardless of whether you use boxes, clouds or your own form of notation, you are doing exactly that - using a notation to do your modelling. By using UML...you are merely using a standard form of notation. Being a standard, it can help form a vocabulary between programmers and I think it''s generally agreed that this can only be a good thing.
For me the main use was package and class diagrams. State machine diagrams can be useful to some extent, as can some of the other types of diagrams that I would perhaps describe as ''flowcharts for OO programming''. These extra features should be used in moderation, to elaborate on something in more detail than a class or package diagram can offer. Even this should be done only when necessary, or certain information cannot be easily explained or even taken for granted.
I thought use cases sucked because they only replace what worked well enough already as a simple list of words. It seems even the UML community are coming around to this way of thinking, now that the novelty period is over.
You could go to the trouble of doing everything to the nth degree using every type of UML diagram, but common sense asks the question as to whether you are trying to deliver documentation or a finished program.
A point I always like to make is that when you are drawing little plans on paper, regardless of whether you use boxes, clouds or your own form of notation, you are doing exactly that - using a notation to do your modelling. By using UML...you are merely using a standard form of notation. Being a standard, it can help form a vocabulary between programmers and I think it''s generally agreed that this can only be a good thing.
For me the main use was package and class diagrams. State machine diagrams can be useful to some extent, as can some of the other types of diagrams that I would perhaps describe as ''flowcharts for OO programming''. These extra features should be used in moderation, to elaborate on something in more detail than a class or package diagram can offer. Even this should be done only when necessary, or certain information cannot be easily explained or even taken for granted.
I thought use cases sucked because they only replace what worked well enough already as a simple list of words. It seems even the UML community are coming around to this way of thinking, now that the novelty period is over.
You could go to the trouble of doing everything to the nth degree using every type of UML diagram, but common sense asks the question as to whether you are trying to deliver documentation or a finished program.
quote:Original post by freakchild
I thought use cases sucked because they only replace what worked well enough already as a simple list of words. It seems even the UML community are coming around to this way of thinking, now that the novelty period is over.
Amen!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
