Quote:

Original post by The C modest god Is UML really impractical? I was considering taking a course about UML.

It depends on the complexity, if you for example want to have a game where you can interact with thousands of different items which react different (say: when you have a script for each item that's completely different than the others) it's highly encouraged to have an UML diagram. In this cases it's clearer to have an UML diagram. But when it's not as complex as told it's maybe to time consuming to build the diagram.

Good, so UML is usefull.

No doubt for small projest being done by one man, an off-the-cuff design document, or even none at all, might work to some extent. However, in my experience, anything I have to work on for more then 5 days or so needs some sort guiding light so to speak, to help me remember exactly what it was I wanted, and how I planned to do it. Typically though, I put a lot more effort into my technical documents then my overall design documents.. Maybe it's just because I suck at describing designs, whereas I love describing what things are doing and should be doing [grin] Either way, get into the habit of writing things, it will make your life a whole lot easier!

As a programmer, and having made many games, and failed to make many games, I will NOT work on a game without a design doc, I do not care how simple. And it doesnt even need to be that complex for me either. A page for a simple game will do.

I second that, Witchcraven.
I also have a backgorund of programming lots of games. I now have the procedure of not even beginning to look into something before there's some sort of design document (preferably quite elaborate, but that depends on the project).

I've worked in games for 6-7 years now, and taught college-courses on game-design, as well as graphics and game programming.

I started out with the 'must have everything nailed down' path;
- Game Mechanics document
- Game Script / Story
- Item Design Doc
- Monster Design Doc
- Quest Design Doc

It's worked out okaish on a released MMOG and a released Education RPG game, but had a couple of issues:

- Took forever to build, and noone read them
- Unresponsive to changes (which always come)
- Tends to lock you into linear implementation paths (as opposed to a more modular implementation path)
- Lead to over-design, which then had to be scissored off at the end.

These days I tend to go with a slightly different path:
- Noone reads anything beyond 20 pages, and most people won't read >5 pages of small text. We use powerpoint right now to flesh out the mechanics document, and add additional ppt docs if necessary for things like art-bible, per-level design documents, etc
- We've given up, in it's entirety, big MS Word files for content; EXCEL rules. We use this for items, monsters, anything that has a clear format. In most cases we build our data-tables straight from excel using VBScript->LUA.


I've also seen a couple of other paths to this:
- Wiki
- Forum

They worked ok in collaborate environments, and with one guy closing and maintaining it, you still had a decision-making process.

The final advice is one bitterly experienced:
"Monolithic Design Documents lead to Design By Rainman".

They're usually done in isolation by the design department (programmers and artists have better things to do than producing 100+ page documents). As their size increase, and the deadlines loom, they get less and less oversight by the people actually implementing them, and they start picking up designeritis and individual pet projects (litterally.. one designer stuck a complete pokemon/tamagochi monster capture/raising/training game in the RPG when I wasn't looking... wasn't happy when I found out).

Any document produced should have a specific target-group and purpose (for example, communicate the combat-system to the 2 programmers, 2 artists and 1 designer implementing the combat mechanics), the more diffuse the target or topic, the less chance it has of being read. Any document produced should be read and signed off by the lead programmer, lead artist, lead designer and producer.

And for the love of Gaia, save the trees. If I ever see another soon-to-be-obsolete 60+ page design-document that noone reads, printed and bound, I'll weep.

Allan

I consider these to be the basic documents needed for any game project: Technical Design Document, Game Design Document, Project Plan AND Business Plan.

The GDD is what most of us consider a "Game Document". It has the levels, the quest, the story, the stats, etc, but not a single word about the programming language or any other implementation. The TDD is where the nuts and bolts go...here are the UML diagrams, the pseudo-code, the classes and objects. The Project Plan is critical to make sure you have the time, budget, and performance clear before you start. Finally, even if you are a non-commercial game, building a Buisness Plan will truly solidify who you are making this game for and why they will like it.

This set can be 4 pages or it can be 400...depends on the game but if you don't have some documentation behind you game project, you will fail

I disagree that a single programmer or simple game can bypass this req. As a single programmer, you might take a week or a month off from you project for real life. In this time, you will forget why act_tyu = 45; and why test.variable = null;.

Finally, if the Documents aren't being read, it's my guess that they aren't being used or updated. These documents are a living project, not just write once and follow to completion. Part of the Project Plan is a Project Change procedure which outlines how to make changes to the game. As such, your documents should ALWAYS be changing and this means they are ALWAYS being read.

No one reads a traditional design doc except the guy who wrote it. Wiki's work better in practice because you can get to the information you need quickly, and it's easy to make changes and extend ( or chop down ). And believe me, you're going to be making changes to the design. I've worked on projects that sounded great on paper, and were thoroughly fleshed out, yet when it all came together it simply wasn't fun.
As for UML diagrams, the process of CREATING them can be somewhat useful for sanity checks before you start coding, but REFERRING to them does my head in for any non trivial system, so I've never found them to be terribly useful. ymmv

Daniel

wiki's are great for an established team and workflow. They are useless or counterproductive if you have a new team or an unestablish workflow. In the latter case, you'll end up with redundent and contradictory contributions and the signal to noise ratio drops drastically as people post willy nilly unto the wiki.

Further, unlike my esteemed collegue, I say FUCK the trees. Perhaps its because I grew up reading alot of books, but the final drafts of my DD must be printed out. There is something about being able to spread out any number of pages against each other that I can't do even at 2048x1056 on my 21 inch screen! There is also something about taking pen to paper to make corrections that you just can imitate on screen.

I find UMLS to be more useful the more I use them. I diagram to make sure that it's concrete in my head and then use it as a "script" to guide me during programming. My diagrams progress from the simple (use case) to the complex (collaboration diagrams) and without them, there is NO way I could have kept a 10 application, distributed, networked server farm documented if not in pictures. And after not working on the code for 6 months on a recent hiatus, I came back to it, spent some time with my diagrams and my code, and in a few hours I was right back to where I was. No way I could have done that with a textual only DD; the information flow alone would take pages to describe and would still not give you as clear a picture as "seeing" what flows where.

Quote:

Original post by fastlane69 I consider these to be the basic documents needed for any game project: Technical Design Document, Game Design Document, Project Plan AND Business Plan.

I'd say this is more of a company focus thing; BizPlans are mainly usefull if you're trying something original; if you're on a contract to deliver a 3rd party console/pc/handheld title, writing out a 20 page bizplan is intellectual self-gratification.

Project plans are always usefull, but keep them readable. I think unreadable documents are probably the greatest Sin ever, one that's taught to us in university. Documents have only ONE reason; to communicate. Once you start obfuscating that with fancy writing or structure, you've messed up.

GDDs; I ranted halfway up the page, so I won't repeat myself. Noone except the designer reads a 60 page document. You don't have to believe me; go and try. Seperate systems, story and content design into seperate formats, and don't force yourself to use the same tool for all of them. Make small mini-docs for specific sub-groups that document JUST the things they need for their chunk.

TDDs; I've never seen a project that tried to sketch out the pseudo-code, class defintion and a rigid TDD up front be successfull. I'm sure there are plenty of examples (something like FIFA or NBA should in theory be quite easy to map to UML), but it's inemical to rapid prototyping. If you want a formal framework, use something more flexibile, like SCRUM. Anything else is a collosal waste of time, and you tech-lead will hate you for trying to impose it on him. Especially when you change the design document (to introduce new ideas, respond to licenseholder issues, because the publisher wanted a change, or just because the original wasn't fun). Each original sub-system should ideally have a couple of hours spent on it (we usually did this in the tech-team meetings), with the implementer spending 10-20 minutes discussing his implementation strategy, and soliciting feedback; the end product of that was a small txt file that went into the /docs folder in CVS. Assume it'll change as you come up with better ideas / need more features, etc. Some overall arch-issues (memory maps, process guidelines, coding guidelines, etc) also go into that folder.

Quote:

Original post by fastlane69 Finally, if the Documents aren't being read, it's my guess that they aren't being used or updated. These documents are a living project, not just write once and follow to completion. Part of the Project Plan is a Project Change procedure which outlines how to make changes to the game. As such, your documents should ALWAYS be changing and this means they are ALWAYS being read.

Sounds like one of those ideas from traditional SW Eng projects that people keep trying to port back into gamedev. Try walking the publisher through a Change-request form, and see how it reacts :)

Personally, I've found that the faster a big 60+ page doc changes, the less likely it is to be read. Especially when E3, or another major milestone, is comming up, and the other teams are busy. All you accomplish is lack of buy-in from anyone except the few that actually struggle through the document.

In a traditional project, you can spec out the entire project up-front. As long as it does what it said in the original document, you're fine. Games, on the other hand, need the constant tweaking, modifications and new ideas that come throughout the development process; otherwise they simply won't be fun. It's good if internally you have the processes to help manage, prototype and green-light that, but assuming that what you spec is what you get will lead to disaster.

Allan