Juuso Hietalahti


  1. It seems that when there’s more than 1 guy doing the thing, it becomes almost a necessity to have some sort of Design Doc to aid the process.

    @Tobias: how do you categorize things in your tree structure? How you keep it all together?

    I also use some sort of “todo & design doc” alongside with “crazy/fun/cool ideas” section. I think putting some things in writing is a must. But I want to keep my design doc simple & clean.

  2. I use it so that important ideas (be it game design or art style details) stay more or less unchanged. To have a clear picture of what I’m doing, why, and what I need to achieve.
    Because without DD I often found myself starting something only to end up with something completely different once finished.

    Plus, when the time comes to use a team or outsource, the DD should help.

  3. Instead of a (linear) design doc I keep a todo-list in a tool. This is because working on a side-project takes a long time, so this way I won’t forget things. The tree structure (with priorities and estimates) also helps me in constantly re-arranging priorities and change ideas on the fly. Estimates help me learning to make better estimates, and get some feeling of how many hours of work I have put into this since I started.

    At work, we have requirement documents and design documents, but with all the changes in meetings, protocols and everything it becomes difficult to find specific things and details. Which is also the reason I don’t write design documents for my own games.

  4. We use it for stuff that needs to remain clear and consistent throughout a long process, such as the controls in the level editor. We also use it to test ideas more thoroughly in our head to catch issues early, and in general to just keep stuff remembered during long Archetype meetings.

  5. I use design docs because once you have an idea in your head, writing it down helps to generate related ideas and to work out any problems with the design + you can show the doc to other people. Oh and then you can de-scope the entire design and assign time estimates to make sure your project is realistic. All this saves time because if you being coding before you have a decent design you’ll waste a lot of code later on (or stubbornly keep the code and make an inferior game – I’ve seen that before).

Comments are closed.