Out of experience, my docs are about 3-4 pages. Most of the time the game evolves into something slightly different.
A few years ago i thought that without a design document, the world is doomed. At some point i decided to make a new game based on a simple concept of a topdown platform/puzzle game with an ant pushing stuff around to make it's way from point A to point B, avoid monsters, etc. So i started writing a design document, with sketches (made with mouse , mock-up screens, description for the ant's movement, monster behaviour, the theme for each level (grouped in packs), powerups, traps, etc. It came to be around 30-35 pages long. The thing is, i never made that game. In fact i had forgotten about it until i accidentally saw the doc i made while looking in some old backups . KM's Invaders, Nico Tuvla and Nikwi are my only "finished" games. Yet, none of them have any kind of design document (i tried to make a design document for Nico Tuvla at some point while i was in the middle of development, just to streamline the game a bit, but i ended writing a couple of pages and forgetting about it). So from the above experiences, i believe that you don't need a design document for a very simple game. If the game becomes more complex or your teams grows more than 3-4 people, then it's a good idea. If you're making a big game, then it's necessary. However, currently i try to make very simple games thus i don't need design docs. I just have everything in my head .
Totally agree. Every game I did I never bothered with a design document, the smaller games were finished while the larger ones just became a spaghetti code of features and hacks. I barely have much of a design document for my current game (only 20 pages) and as a result I can't count the number of times I've had to re-structure code to allow for some unexpected (but required) feature.
If I work for somebody else then it has been known to run in 20-30 pages or even more... if I work alone on my own stuff I keep most of it in my head or on the back of a fag packet or post-it note to be honest
We use a wiki to keep all our design docs in an easily viewable and easily modified space. Since we do many iterations of a game its good to have the design doc be as flexible as it has to be, and track its changes in an a non-hideous interface. The design document for Antskrieg didn't change much from its original submission I wrote about 3 months before we finished it, but game balancing issues like cost of spells and cooldown timers changed A LOT as we began beta testing. Its 6 pages long, 2558 words. That includes notes on graphics, layout, sound, music, game play mechanic, interface, spells in the game, etc. Here is what that design document produced: http://www.skillcitygames.com/games-ants.html
The size of your GDD is going to depend on the type of game and the method of development. I'm banking on fully designed blueprints to ensure a speedy and straight-forward development. And I hope that prospect is going to attract a strong creative team when I'm ready to recruit. The pitch for the game is 30 pages. The design abstract that explains each part of the game is 150 pages. The databases (for the first episode, 1 hour of gameplay) that contain all the guts to the game (enemies, items, rooms, etc) is 150 pages. So about 330 pages.
I guess if you count me pitching my idea to a relative or friend, it's only about a paragraph or two.
What is your plan if something doesn't work out as expected? Is your document set up so that it's fairly easy to make a change and not peruse all 330 pages to make sure the change doesn't upset some other design element? I've never had a design document that wasn't rewritten at least twice during development. One time the scoring needed to be changed to be more clear, another time the difficulty ratings had to be revised because the "easy" setting was too hard. A design document needs to have some flexibility.
But it's pretty much a myth that you can anticipate everything. You can sit and ponder and sit and ponder your GDD all you want before you start coding. Thought experiments will take you places, but you're going to hit a point of diminishing returns as far as what you can foresee. At some point you simply have to start working with a live product and deal with the consequences of that. There was some game studio that wrote an article on Gamasutra about using the "First Playable" prototype instead of a design document. But now I can't find the article. It was probably from the early 2000s.
Indeed. Mark Cerny pushes what he calls his "Cerny Method": a rapid development paradigm stressing playables, rather than documentation. By no means revolutionary in many (most?) industries, but in game development, it certainly is something rarely employed. (And for no apparent good reason.) I'm a huge fan of the Cerny Method, although by any thoughtful individual's standards, it comes across as rather "well, duh." Check out some more info about it: http://www.gameindustry.com/interview/item.asp?id=3 http://www.gamasutra.com/features/slides/cerny/index.htm (Unfortunately, you need RealPlayer to hear the lecture) http://store.cmpgame.com/product.php?id=1712&cat= (doesn't feature him, but Cerny says a few things)
My game design document is currently about 20 pages long, and will probably double in size until the end of development. It's half text, half drawings. I only use loose sheets and pencil + eraser. It looks a bit drafty but I like how it is. Of course this document is mainly used by me. BTW: I may scan some drawings and put them somewhere in the game, might be funny.
Yes, because of the nature of the game it would be acceptable to make a change in one part without it affecting everything else. Most components are pretty independent. Also, alternatives are presented in the event that any component proves to be unfeasible. It's true that things hardly ever go as planned and flexibility is an important feature.
Biggest design doc I ever saw dropped on us was in the order of 550-600 pages. This was from a team of 10-12 "designers" who If I recall correctly had never designed a game before. The fun thing about it, is that when they delivered this epic tome, it still had a ton of holes in it regarding what was actually required to make the thing (lots of vague things like "he will be agressive" and "they will be able to jump"). Even funnier was that when I quizzed them, not a one of those designers had read the whole document, they just worked on thier own 50 pages. Any way you slice it, it is very unlikely for a designer to be able to foretell absolutely every eventuality for a game to suck. So in general, your doc should aim for the "essentials" and give enough detail to implement them. So for example, if youre designing a magic based game, be very clear about the mechanics of that system, be sure you explain how casting works, how timing of spells works, spell interruption etc. Include tables of values, variable names, formula's to use etc. The thing here, is not to expect those values to be fixed in stone, but to describe that there IS a value, so that your programmers can actually program exactly what it is you want. We know that things will change, but not knowing about the details of how a system should work is a sure fire way to get something else. Of course, if youre a programmer/designer, things get a little bit more fuzzy, as you have most of those kind of things in your head. But a pure designer MUST be able to logically decompose problems down to the notion of variables, formula's and the like. Actually, you just gave me an idea for a class!
Unless you are working on a game genre that you already master, it will be impossible for any designer (even the most talented one) to "feel" how the game will plays. Most of the time, writting lenghtly design doc is pointless. People need to play the game to see what is wrong/right with it and then act in consequences. So for "small" project like ours here, it is far better to get a working prototype working quickly and use it as a working base to test new ideas. Most of the time, new "clever" idea will come to you while playing your game over and over. So better to start playing it as early as possible. Obviously, if your game is based around an important story, you might not need to wait for the game and start working on the story. Most of time, I also notice that you need to play the game to think about cool stuff you could use in your story. There is the lenghty balancing/polishing stage that can only happen when you have all your game play element coded and most of your ressources done. This is the longuest (should be) phase in game developement and you can't write it down on paper before having the game to play with. Ok, so these are just example of why in "real life" design docs are not that usefull. Specially if they are completely done before you have a working prototype. A game need to be a little bit "organic" and your design need to evolve with the progression of your game. JC
I was once presented with a dozen feature changes that turned out to come from the designer's wife. She went onto his computer and added features to the bug/feature database that propagated to every developer, artist, producer, etc. on the project. I had implemented two of those features by the time a producer noticed features he hadn't approved. She assumed she could add features she thought were necessary without telling him, or anyone else, first.
That's sound like a lame excuse from the designer ;-) Boss: "Who wrote this c..p" Designer: "Not me boss, it's my wife!!!" JC
Since I do the one man development thing, the longest one that I've written has been a six page design treatment. What actually works for me, is a sturdy notebook with a plastic cover. That's where I brainstorm, create to-do lists of features, enumerate items, and what not. Those notes can run on from one to twenty pages depending on the complexity of the project. Sometimes I'll also spin off a one or two page spec sheet for file formats and the like. -- TAZ
I once wrote a design document as long as one page. The problems with design planning is that a game that is like another, but modified, is easy to define and hardly needs a design document. Concept art and level designs are problably essential for a complex game and a large team but I don't think those things are "game design"... that's content development. A doc for a game that is totally original is pointless because it needs a lot of prototyping and will inevitably evolve. After a few days you'll throw the doc out of the window. I don't think I've ever planned a game on paper then made that game, depsite making over 40 games and probably as many design documents! The two activities seem to be mutually exclusive, but maybe that's just my way of working. Mark
My official role at my current games company is games designer however my casual game doesn't have any design doc to date (and its about %60 complete). Being a casual game the mechanics are quite simple and intuitive so I never really considered writing everything out. Like Mark sais Which is very true in most cases. It's an evolving process from prototype through to the final product. The only reason I would document the game would be for publisher or investment purposes. I do see the need for a detailed design doc for larger games that involve larger teams. It is useful in that situation for a central point of vision/reference. Out of 10 commercial games I have worked on I think maybe 4 of them had complete design docs. The others were works in progress with the design and technical docs completed only for publisher reference.
I've written SEVERAL design documents over the years, averaging 125 pages in length. They've included practically every little bit of information needed to build a game from start to finish, without telling each individual how to do their job. I've gotten down to # of enemies, pixels per second on movement, etc...etc...etc... They've evolved over the years and have gotten to the point that on a couple of games, I can go back and whip them out and they are like strategy guides for the final product. They're 80% accurate on what came out. That said, design documents should be as much information as necessary. The smaller the team and the smaller the game, the smaller the document necessary. Over-documenting can be overkill. Under-documenting can get you into a time/money wasting situation where you're saying, "hmm... what do I do next?" Or the more idealistic thought of, "oh, my game is done when it's done," which really translates to; I don't have a clue, because I haven't thought the whole thing through.