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.

Quote:Original post by The C modest god
How do you design a game?

Unfortunately for you, you're largely getting the answer to that first question you've asked from everyone; you typically design a game using such techniques as Design Documents and Storyboards.

What you seem to actually be interested in is the software implementation side of things - which is not typically what people will think of when they see "game design", and probably isn't best suited to this particular forum. In this area, yes, UML could be useful. I don't use it myself and therefore can't provide you with any examples, but I can suggest that you might get a better response in the Software Engineering forum.

UML can be great when you're designing how the code will work, but probably isn't all that useful with actual gameplay.

I thought desing also include the designing of the actuall software and not only the initial concept of the software.
For example design patterns refer to implementation designing.
But you are correct, this thread is more suitable to the software engineering forum.

Sure, it's just that most people will assume you're referring to the gameplay/level/setting design rather than the software implementation in this particular forum.

Quote:Original post by The C modest god
winterdyne, I am afraid you havnt learned how to use UML...

That's an assumption on your part. Never assume - verify or approximate, but do not assume. The classic three stages of documentation arise as the *easiest* way of incrementally taking a project from concept to implementation. I mentioned UML arises in the late technical documentation stage - at this point there are precise rules and datasets in use. Subsets or aggregations of these may have been used earlier (and UML (and a decent CASE tool) can help identify these), indeed some use cases may be explored at the functional stage, but it's VERY unlikely that a complete chain of dependencies will be discovered until the functional documentation is almost complete. It's also a point of fact that documentation isn't complete before moving on to the next stage - portions of a technical document may well be complete well before certain stages of the concept - for example going for a cel-shaded look will imply certain features be required in the engine. In this case the documentation set for the engine would have a cel-shader feature added.

In my experience, getting a fully developed concept from the client has *never* happened. It didn't with GW for Warhammer (and they've been developing that for over 20 years), and it hasn't in my consultancy since then. We get a few requirements 'um, guys, we want it to *feel* like warhammer', but this is pretty much as far as I've seen things go. There's often a lot of room to move in the concept a client gives you. There has to be a lot of communication to get something that the developer feels will work, and the client is happy with.

Stating that the concept stage isn't a part of the development process is like saying being conceived isn't part of your life cycle. All those drunken meetings in the pub to discuss the numerous evil ways of disposing of adventurers are an essential part of starting a project. Having the development team itself involved at this stage results in a more enthusiastic, dedicated team.

Completing all design before starting to code isn't going to happen. Completing the *documentation* isn't going to happen, especially when you bear in mind revisional documents late the life of an engine.

Re-reading my post, I realise that one important point wasn't made clear - documentation exists *separately* for each feature and major system, as well as an overall document for the project as a whole. Each document may reference at some point the same UML model to specify interfaces, but each system is documented (and effectively developed) as individual components.

I wholeheartedly agree that diagrams are an essential part of the design and documentation process, but I have to point out that most non-programmer designers are neither used to a system like UML, nor particularly interested in learning it. Having a strict method of communication (like UML) is only ever going to be useful if people can and will adhere to it. I've seen more (actually good quality) psuedo code come out of designers than UML. Similarly, the design team on a large project usually have a good amount of input *post-production*, so having them able to understand documentation is a requirement. Text documentation *has* to accompany diagrams.

The 'development life cycle' you hear about at university is very different in the real world. Shockingly so. Documentation that implies implementation (such as UML initiate cases) is so often invalid or poorly maintained against the actual implementation as to be almost worthless. Less rigid documentation that explains the purpose to the implementation (the functional documentation) often sheds much more light and proves more useful in an implementation task. Appropriate technical information detailing what was done is created afterwards.

UML is a lot like hungarian notation (in the late 90's) in my opinion, it's exceedingly useful (in its place) but it has a tendency to be over-used and wielded club-like by its evangelists.

I don't think you want to start implying that using UML *will* result in a better product - it can help, but it's certainly not the only, or necessarily the best, tool for the job.

Ok.
So I didnt uderstand what is the role of the documents you talked about, or you stated several roles to the documents.
Some documentation is of course very useful, such as comments in the code, stating who made this method, what it does and things like that.
Or a catalog of all the art work in the software.
I didnt refer to those kind of documents, I refered to specificly analysis and design tools. The stages before coding.
But what are all the roles of the documents you refer to? and in what stage of the developement does these documents belong?
About the evolutional model of a software, not all the cycles of a software produce equal amount of product from every type.
The first cycles will produce less code and more documentation and diagrams for instance.
Its not symmetric.
I dont think every text documentation is self explnatory. What is worse, things can be understood completly different by two different people from the same document. Especially when you dont have a standard form.
Also, a non standarized text document may be not compatible for maintaining. Its like writing a software, if you use the same explicit number 3.14 instead of a constant M_PI in your software it may be very hard to maintain aftwerwards.
You can make the same types of mistakes in a text document, and it becomes worse becuase you use the english language which does not bound you, as opposed for a programming language for instance or a UML diagram.

Code commenting is NOT documentation. Doxygen etc are useful in building code reference, but they're no use at all when planning or evaluating something. It's not what they're for - code commenting (and comment-generated documentation) is a maintenance and integration asset. Yeah, it's useful if you haven't looked at your codebase in weeks and you're just starting off again but it doesn't give you the 'big picture' that you sometimes need.

The thing you have to remember about your design documentation is that it ISN'T (and really cannot be) limited to one stage of development. It's constantly in use, being referred to or having details modified (especially in technical documents) (whilst the particular feature it's related to is involved in development), almost right the way up to release.

I've mentioned that a set of documentation exists for most major features of a game (assuming a somewhat more complex game than pong). Concept documents are answers to 'what is it?' questions. Functional documents are 'what does it do?', and technical documents are 'how does it do it?'. It pretty much is as simple as that. Additional documents are drafted as required - ('hmm, we need an economic system') and basic concept documents are drafted detailing as many major subfeatures are are wanted or required. These subfeatures in turn can generate additional documents. It isn't required that *every* feature has precisely one concept, one functional and one technical document. This is simply anal, and counter-productive.

You have a point in mentioning constants - and this is another reason for the segregation of technicality from concept - 'a deep space game with newtonian physics' is that whether we use a double precision coordinate system based on a single origin, or a floating origin system and floats. The mathematical model behind it is (for most intents) a technical issue, and has little or no bearing on the actual function of the game. What if we want to implement the game in a non-typed language? The technical documentation may need to be revised, but the functional docs should be fine as they are, acting as a layer of abstraction between the concept and the implementation level documents.

I'm trying to get across that assuming your development will follow a cleanly defined cyclical pattern is not a great idea - people don't work that way - writers have creative spurts then block for a while, coders have off days, etc. A pattern of task and dependencies is usually used in the production lifetime - with many people working on quite different tasks. Everyone is saying the same thing - just text is not enough - there WILL be diagrams, sketches, the occasional flowchart - anything to make sure that nothing is ambiguous or misunderstood. If everyone's familiar and comfortable with UML, use it! But you can bet they're not.

I know it all seems a bit vague (and to some extent it is), so to take the life cycle as you describe it:

1) Requirements - this is the initial generation of concept documents for the overall project / game. Some important subsystems will have concept documents written for them.

2) Analysis - taking the concepts will give choices of function - skill or class based RPGs actually *operate* in very different ways, regardless of how the classes and entities are modelled. All this is described in functional documents.

3) Design - First draft functionals are given to the code team, who draft first draft technicals, most likely in conjunction with testbed R&D code work. Feedback from these is used to draft 'working' functional documents. These are evolutionary, and will represent the 'current' thoughts on how the concepts should work.

4) Implementation - Working functional documents are used by the code team, along with first draft technicals and any other relevant research results to draft a 'working' technical document. This details *precisely* how things work, not necessarily down to types (especially if such types are the responsibility of an overall model elsewhere). Production code is started.

5) Integration - By now the production code is coming on well, and there are 'firm' technical and functional documents. Firm documents are mature and don't change much. These assist in the integration of separate systems both from an abstract sense (by observing the cross references in the functional document) and in a technical sense (by implementing the interfaces suggested in the technical documents).

6) Deployment - Hah, think you're done? No - you've just hit alpha. Time to test it and see if you can break it. Then beta, where you get more people to do the same. Round about now, your client'll come along and say they've changed their mind about the style of the game...