How do you design a game? I am learning UML, but it seems that UML doesnt fit to describe a game? What sort of UseCases I will have? Perhaps if we take some commercial game is an example and maybe you can explain how would you write the requirements, analasys and design of this game then I and many others will benefit from this? So lets take a look at the game battlefield 1942. How would you write the UML diagrams of this game? Thanks in advance

if you want to learn how to to this id recomend making a game from start to finish by yourself,
it dosent have to be a big game and you can use something like gamemaker but game design is such a broad area in my mind the best way is to just experiance for yourself what it takes to go from idea to game

Quote:

Original post by The C modest god How do you design a game? I am learning UML, but it seems that UML doesnt fit to describe a game?

I'm an old-school proponent of the GDD. You can find templates here on GameDev, and I have one on my website too (FAQ 2).

http://www.sloperama.com/advice/specs.htm
http://www.gamedev.net/reference/list.asp?categoryid=23#21
http://www.gamasutra.com/features/19970912/design_doc.htm

Good luck, The.
Tom

When I was growing up, before I had gained the ability to really create the ideas in my head, I wrote pages and pages of game design documents. The best way to design in my opinion, is to pick the best model of recording how you think. If you are working with a team, you will need to adjust that model to a way that other members on the team can understand it. UML really doesn't work that well in my experience for anything except class diagrams. If you are list oriented, you can make a lot of lists. If you are a visual sort of person, draw maps and visual diagrams. If you are wordy you can write paragraphs. Using a template is nice to know what kinds of things to keep in mind, but you should format it in a way that can help you think the best.

Since I have gotten into programming, I haven't done much designing, other than fairly general things or fleshing out a system that needs some detail work, as I have found if I do too much top-down design I find out later that some things just dont work in the game as I thought they would, and I have to backtrack a lot. Sometimes its really hard to think around a problem when I have already done extensive design work on it, its harder to get the old idea out of my head if it's been put to the page. So i do a lot of designing in my head, and then I prototype it, and if it fails its out of my head instantly :)

I just wanted to see some UML diagrams.
UML diagrams are a standard that every person who have learned UML can understand in some level.
Also, a diagram is usually more comprehensible then some 100 pages text document.
Maybe I was missing something, but I didnt see any UML design techniques used in the links you gave me. Maybe just for the requirements.
I don't want to read how someone have invented a specific method to design a game, I just wanted to see some UML diagrams for games or graphic engines.
Or do you claim that UML is not currently the best method to design a software and that some one else has inveted a better way to do it?

UML Tutorial: http://pigseye.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/what_is_uml.htm

Webpage about UML diagrams: http://bdn.borland.com/article/0,1410,31863,00.html

Diagrams: http://www.agilemodeling.com/essays/umlDiagrams.htm

How did I find all these? I don't know UML. I typed "UML diagram" into Google.

UML is really just a way to visualize a design - it's not a design method itself. Besides, those diagrams change on a regular base when the code itself is written.

A better approach would be to get experience writing games, because that really gives you the insight you need when designing a game. Without such experience, UML is pretty useless, I'd say. You won't understand why a designer made a specific decision by simply looking at the diagram only, you would have to know the real-life implications of the design.

I think the aspects of a videogame that are fit to be described in UML diagrams are boring and not very interesting or important: the use cases are very simple combinations of obvious commands like new game, save, load, quit, edit options and the like; state and interaction diagrams can describe simple game loops and network protocols; class and object diagrams are mostly irrelevant to the low level performance and algorithmic problems, and weakly connected to game rules.
Developing some UML diagrams can be useful for developer orientation documents or as an aid for the design of specific complex mechanisms, but most game code is much more sophisticated than UML diagrams of reasonable complexity.
For example, suppose you make an object oriented Pacman clone. How would you describe, in UML, critical features like the movement strategies of the four ghosts or the timing of Pacman and ghost movements? How could a clever card castle of OCL, annotations and contrived classes be more readable, useful and easy to produce than a simple text document with explanations and tables of figures?

UML is a useful *tool* in game design.

It isn't a method *for* game design.

This is an important distinction. Diving straight in to UML before your concept is ready is daft, and unproductive. UML works as a tool at the late technical design document stage - ie to illustrate behaviour of entities to the programmers responsible for turning them into working objects in code.

Typically, there are three 'classic' stages of design documentation, for each and every major feature in the game - for example an economic subsystem, combat resolution, UI 'contexts' (menu 'screens' to 'huds') etc. These are often developed simultaneously, with advances in one document having an effect on others as interfaces between the systems are developed.

The three stages are concept, functional, and technical design. Sometimes you'll hear of revisional documents - these are things altered after the systems are 'done', usually as a result of beta testing or public feedback for a patch. These are important if your product is intended to have a long shelf life or maintenance period - people joining the project at these stages will need to know what if anything has changed from the bulk of the design documentation (which will all be cross-referenced and indexed, won't it?).

So what's in each of these?

Your concept document is effectively a brief pitch for why the subject of the document should be included in the game. I wouldn't expect one of these to run much past three or four pages of text. They explain the purpose of the feature, why it's fun, provide a concept of how it should work in gameplay and so on, including whether it is *intended* to have a major effect on other systems. These often help in deciding which features to include, or cut out as development progresses. There will also be an additional concept document drafted for the whole game, which will refer to the individual feature concepts. Think of these as a 'what and why' document - they say what features there are, but don't go into any great detail as to how the systems function.

The functional document is very much of 'what exactly' to the vagueness of a concept. These explain exactly how the feature is intended to work - down to what options will be on the menus, how events spread through the game world and so on. The functional document should NOT approach code, but some 'technical' work (such as entity normalisation) is done. These documents are used to communicate the design departments intent to the programming department. They have to be detailed, precise and non-contradictory. You could think of these as 'on paper' rules for your game.

When the functional document hits the code design team (where implementation is done) the lead programmer will assign functional documents to code team members to draft technical documents. These are the 'implementation' plans, and will usually include entity normalisation, some kind of formal behaviour specification (UML / SSADM / Z) for the code team to work from. These are 'how' documents, and explain how the functional specification is to be implemented, together with reasons for choices made. It is the responsibility of the lead programmer to ensure that technical documents required exist.

Wow, sounds like a lot of work! And it is. That said in my opinion, it's the second stage (functional design) that is the keystone of the design process. A *good* designer here can come up with a functional spec that reads to a layperson like a concept, and to the code team as a non-contradictory (important to remember) technical spec. The key is not what modelling method you use (UML is the current favorite) but that your design at the end of the day is clear, non-contradictory, and logical.

Looking at a UML diagram doesn't give an idea of gameplay. Especially of a whole game. You'd go mad trying to follow it. Well structured english is as good a medium as any. Simple diagrams are great - if required, but there's no need to draw a picture of every dialog box in your game. You *do* need to state what goes on each though.

Ok, now how many of these documents do you need? This is a question only you can answer. BF1942 is far too complex an example. Lets use Pong.

First, an overall concept document - this explains what Pong is, and how to play it. We won't need any further concepts. For the sake of argument, we want to make a visually appealing pong, so the background of the game will be various interesting 3D scenes.

Next, a functional document - this explains how the players move their paddles, how the ball moves, how it bounces off the walls, how goals are scored, how long a game lasts and so on. It shouldn't (classically) mention screen position, size etc, or any other implementation level detail. The mathematics behind the bounce ARE a functional detail, and so should be included here. They would be the same regardless of the technology used to implement the game.

Finally, the technical document. Here we assign sizes to the paddles, ball and screen. We specify the information each bat requires, whether they are types of a 'pong entity', what that requires, how collisions are detected and handled and so on. Perhaps all the entities are in 3D, and the pong game as per the functional document is played on a single plane, in order to meet the visual criteria set in the concept document. Perhaps we're using alpha blended sprites over a pre-rendered image.

This is a bit of overkill for a Pong clone, but if you were to sit down and write each of these documents as an exercise, and actually think about how each feature is to be implemented, full documentation (including entity modelling at the technical stage) will run to (I'd guess) around 50 pages of text. For a Pong clone.

Bear in mind most games are built around *engines*. Engines are long term, high commitment projects, and involve the bulk of the technical design and implementation work. The thing to remember (other than non-contradiction) is that you can reference other documents - you shouldn't need to define what a 3D entity is if Ogre (for example) already has one - your technical documentation becomes much smaller when it's referencing something else. This of course does mean that you'll need to keep the documentation consistent - ie make sure its for whatever version of the engine you're using, and that if you do upgrade the engine mid-development that any changes to it are compatible with your technical design.

Note that so far this is assuming a pure software design. This simply is never the case for games. Art and audio both have their own design stages as well.

The art side mirrors the code documentation fairly closely. The lead artist is responsible for the creation of a style guide based on the overall concept document. This will have a LOT of pictures in it, not all original, but indicative of the 'feel' of the game. Some may be specially commissioned for the purposes of the style guide, and some may be 'borrowed' from films etc. The style guide usually also includes information on what is considered feasible for the game being developed, in the opinion of the lead programmer - this is used to approximate poly count limits, texture sizes etc, and boils down to educated guesswork.

The style guide is referred to by concept artists working on producing anatomical sketches (where joints are, as well as details) of items and entities to be 'properly' modelled later on. These are then passed on to the art team who perform the final modelling, texturing and animation duties. It is usual for a different artist to perform each of these steps. The concept sketch stage is quite often omitted if there's easy reference material available or the objects are very well known. I can't think of any studios which would require concept sketches for a wooden crate.

Audio design is often sadly neglected. Stock tunes are often used with no thought for the environments or situations they need to portray. Depending on the concept and functional documents of the game there may be a need for leitmotif (thematic) work for characters, in which case the composers will usually appreciate concept art of the character they're writing around to get a feel for them. Often the art style guide is also helpful in getting an overall feel for the game world, so that music can be written to complement it.

For games though, audio is usually the most expensive resource (in terms of file size for distribution, unless using midi). As such it is reused wherever possible, and so tends to be dictated by approximate situation ('combat', 'woodland') rather than precise situation. There have been attempts to make systems that 'improvise' music, but these usually sounded worse than cross-mixed tracks. Designing the audio for a game is mostly a case of identifying situations that are important in the game, and providing the composer with the necessary information to imagine that situation (and the music for it). Getting the audio right can make your game a lot more immersive and enjoyable. Getting it badly wrong can make your game simply irritating.

That covers the bases I can think of right now. I hope this helps!

winterdyne, I am afraid you havnt learned how to use UML.
UML may refer to the diagrams, but you dont use UML as some bunch of diagrams to help you in the desgin process.
People have already thought about how you should develope a software starting from the need of the client and ending at the death of the software or becoming abandon.
A software is an evolotional entity. That means that the software has life cycles, each cycle you get some products. And each cycle your software becomes bigger and better.
Until 1990 it was accepted to complete all the design of the software before starting to code it, but although thwy thought about it like this, what really happend was that their software was developed evolutional but in a bad way.
So briefly, how a software can be developed?
The initial documentation you talk about, the concept documentation. Is not directly part of the developement process. It is something given to you by the client, from this you will create your requirements documentation.
In each cycle you use UML and documentation to do the following:
1)Requirements
2)Analysis
3)Design
4)Implementation
5)Integration
6)Deploynment

So each cycle you get new and improved documents, UML diagrams and applications.
Text documents are required, such as in the requirements phase.
However, the conecpt is to trying to have as less text documents and as more diagrams instead.
Becuase Diagrams have a standard, text document dont.
If you can express the same idea with diagrams and text document, but the language of the diagrams is narrower then english, then it is better to use a diagram.
Graphical presentation is usually easier to percept then text presentation, as long as the two express exactly the same concept with the same amount of details in them.
Would it be easy for you to understand this?
A connected to B
C connected to B
D connected to C
A connected to D

Can you see a circle here or not?

Using diagrams and documentation for a big long term project is the way to go.
Using it the way people already thought it should be used and not reinveting the wheel is also the way to go.
It is true that some companies can create software without any of these methods, but their product will be of lower quality and will require double effort to maintain.
Think of it as programming in C++ instead of in C.