next »

[ChevyRay]

Good article, Guert!

I write lots of design docs, because I come up with so many ideas and I have to do something to keep them from getting me distracted from what I'm working on.

Seriously. I have nearly a hundred full design docs for games just sitting around. It's retarded.

[neon]

I have nearly a hundred full design docs for games just sitting around. It's very impressive, and I should be proud of my accomplishment.

small non-destructive edit

[cynical duck, the]

I use a sketchbook: ie: I write down a lot of ideas quickly, so that I can remember them later.  These range from level ideas to high level ideas to the newest (conceptual) version of the melee system to power up concepts, and some can get complex, although rarely does any single idea use up more than a page or two (handwritten) and the entire thing is too disorganized to serve anyone but me.  Not sure if that counts as a design doc, but thats what I do (it should also be kept in mind that this is my first serious project and is being done on my own, so probably my system will change over time.)

[RobHaines]

I've just drafted my first design doc, so this thread was enlightening. As far as I'm concerned, it has two main functions: first, to help standardise assets between myself and the artist on the game (sprite dimensions, animation, levels, etc.) and perhaps more importantly to lock down at an early stage exactly what needs to be in the game to consider it finished. Otherwise, I think I'll probably feature-creep myself into oblivion.

[SundownKid]

I think that the larger the team (and to that extent, the project) is, the more important the GDD is. Writing a GDD when you are designing and programming the game seems superfluous in my eyes, but if you are trying to manage a group of people planning is essential.

[Konidias]

I create design documents using Google Docs. I just open op a new document whenever I get a new game idea, and I start writing stuff down as I think it. If I read over what I wrote and I really like the idea, I'll start cleaning it up and fleshing it out more.

It's at that point that I might try to prototype something. If the prototype turns out to be enjoyable, then I'll proceed to keep fleshing out the design doc, adding on to it, taking away from it, until eventually it holds everything about the game there is to know.

I also use the design doc as a dump for any links of sites I visit while researching for the game, or links to inspiration or articles or whatever...

Along with all of that, I also write my to-do list in the design doc, I can check off things as I complete them, I can set deadlines, I can do some redesigns and then change my to-do list around...

This all works really well for me. But I work solo and I'm doing it in my spare time right now, so I'm not sure if it would work well in a team or a full-time project. Though I think Google Docs would still be rather handy for that, as you can share the document so that others can read/modify it. So that way your team could modify/read it right there on the fly, remotely. If you mark off something on the to-do list, everyone sees it get marked off right away. While they are reading it.

So yeah, that's how I work right now.

[RobHaines]

I've done the same; Google Docs is great for that kind of collaboration.

[Tiderion]

I write everything out as I become satisfied with the idea. Things I am not sure about I prefer to let stew in my head. If I don't have time to stew on it, I'll list the options I have come up with thus far.

Regardless, I tend to write game bibles because I am already used to writing production bibles for everything else. I start with a general premise and usually a list of similar games for reference. As the document expands, I edit it to split it into appropriate sections such as setting, a list of characters, player abilities, enemy types, etc.

None of this should be a surprise however because I am a writer.

One thought I have for other people: I tend to keep a folder of game design documents but with that folder I also keep an idea dump file. It is literally a single document that has a list of scenarios or character ideas or whatever that sound interesting. That way no idea is lost because there is not enough other information accompanying it. For example, one thing on my list is "haunted monastery." Whenever I get around to it or come up with something brilliant to go along with it, I move that off the list and that idea gets its own design document.

[thedaemon]

I also have a dump text file, where I quickly jot down all my game ideas.

[Kurai]

We use the 37Signals Suite for documentation.
It's pretty smart, and usually we are going like this:
- I've got on paper or just inside my Simplenote account all the small ideas, concepts and such. I carry a moleskine where I'm trying to write a game idea (even if just a small mechanic) every day.
- We use backpack for detailed concepts and to elaborate the smallest projects
- And then, for the bigger ones, we use writeboards on Basecamp. Is really good, because you can divide the documentation and put an index, change it over time, discuss it with the team.

But we tend to fast-prototype, so prototype has always a priority over documentation. We want to stay agile.

[Theophilus]

I just documented a nice game idea yesterday for the first time. Not really the first time, just the first time I did it organized. It helps a lot.

[Muz]

It varies. I think design documents are essential. But treating them as well, some bible is just pushing it too far.

In reality, your game will change greatly from its design. People will find exploits you didn't expect. Something you suggested may turn out to be a bad idea. You could add in some things that screw with the balance of everything else.

But.. design documents help a LOT in the game development process. If you have a complex enough idea, you'll have a huge headache keeping it in your head while trying to code it. That's what design docs are for. They give you a plan to follow and so you don't have to think about 4 different things at once.

Personally, I think that formatting etc doesn't matter. What you really want is a full description of what to do. The big difference between documentations for a game made by 200 people and a game made by 1 person is that how easily understood they are. With a single person document, you'll still describe things from start to finish. But the one for less people will have minimal formatting and minimal descriptions.

Anyone who thinks that it takes too long and you'll accomplish nothing.. well, you just need practice! Not practice writing down random junk; practice in trying to create a document while making the game. Make lots of small games until documentation becomes second nature.


My best design documents are normally just a bunch of notes scribbled together. I'll get a heap of ideas, I toss them onto a txt doc. If I'm working with someone else on it, I paste logs of conversations with her, copy images/vids/links for possible concept art.

There's a part on a short description of the game - what it is, what it intends to achieve, the big picture. This helps in making sure you don't go off track from your original idea when you'll have to make changes.

Then I work on the core design of one "demo" level, which is supposed to capture the heart and soul of the game. This is what attracts the other people I want to collaborate with as well as the players.

After that, I branch out to working on the loose details of it. How many hit points? How much speed.. don't give a number, just something like Monster A can outrun Hero, but can't jump as high. Fine tune it to numbers later.

Then with the demo level complete, I use it as a prototype. Get the game and the feel right, and work outwards from there, until I can describe everything I want to do.

[turgoz]

I agree with JoshG, GDDs are about communication. A Designer needs to communicate to people in what ever way they can get the info the best. For instance I write a GDD mostly for the client, because not only is it repository of what a game IS but it also acts as a contract supplement. For artists, I make lots of asset lists, because they tend to only need to know what to make.

Hell, I'd pantomime if it gets the point across to people

So use a wiki, use a big document, a series of documents, whatever you need to communicate the vision, design, and tasks.

[ஒழுக்கின்மை (Paul Eres)]

that isn't really true. not everyone creates the design document before they create the game, and then makes the game and never changes the design document. i create the design document of my games *as* i make them, and i alter the design document when i have a new idea for what would work better than what's currently in the design. i think people who don't use design documents have this illusion that they are these unchangeable bibles that you can't deviate from once you write them, when in reality most games' design documents are in wiki format and changed daily as the design for the game is changed during the development process

[08--n7.r6-79.84]

Design document is very important and necessary thing for me. Too many ideas and thoughts in my head about current game project. So i need to order and summarize that ideas in one place.
But i'm  not supporter of design document in "web-page" or "wiki" format, because it's not esthetic! :D Design document must be stylish and conform to my esthetic requirements. Or i won't work with it! Or my inspiration will be gone!! For this reason i always make design document as picture, like this:



...it gives me complete control over visual aspect.

[rivon]

You should probably stick to using only one language in the design doc.