Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411196 Posts in 69314 Topics- by 58380 Members - Latest Member: feakk

March 18, 2024, 10:44:26 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperDesignThe Designer's workshop: The design document
Pages: [1] 2
Print
Author Topic: The Designer's workshop: The design document  (Read 24934 times)
Guert
Level 10
*****



View Profile WWW
« on: June 01, 2008, 06:13:31 PM »

The designer's workshop: The design document

   Hello and welcome again to the designer's workshop! In this edition, we will talk about a subject that is somewhat taboo in the world of amateur and independant game development: the design document.

   Whenever someone mentions "design document", many developers shiver in disgust at the idea of documenting their work. At the same time, another bunch of designers will praise the idea publicly. This of course leads to many frictions between designers. One party yells out against the idea of confining the concepts within rigid documents and fastidious structure while the other side glorify the planification and cleansing the document brings to a design.

   Before we get into the midst of discussion, let's define what is this game design document. There are many conceptions of what it is but due to the fact that its roots lie in software design documents, we can easily get a
general definition of what it should do.  A game design document is a written outline of all the game's functionalities that will be featured throughout the gaming experience. Usualy written by game designers, these documents come in many shapes, structures and sizes but they all have the same goal : put on paper what the game will be in order to guide its development. These documents will tell the reader what the game is, how it plays and why it's like it is.

   A game designer in the industry will usualy produce more than one type of design document. The most common are the High Concept document, the Game treatment document and the Game Bible document. The high concept is an outline of the general concept or idea the designer has in mind. Commonly used to pitch ideas to producers or investors, this document is short, straight to the point and focuses only on key features. The game treatment is an elaborated high concept document. It features a lot more details by explaining the key features of the game and showing some mockups and character concepts. In some cases, it also features business-related information like schedules and competition analysis. The design bible contains all the details of all the concepts featured in the game. Usualy very big and, for most commercial games, seperated in many sub-documents, the design bible is the document that holds it all. In most companies, they use all of these documents during a project. But of course, what matters to us right now is not how big teams manage their
   

The most common high concept document: napkin scribbles
documentation. What truly interest us is how small independant teams can use design documents during the development of their games.

   When you run a small team or when you are alone working on a game, the use of a design document is a source of questions. Is it overkill to use a doc for a small game? Will it actualy help the game or just slow down the development? What about creativity? Would a document clog down the flow of creation or does it change a rivulet into a powerful river? So let's begin the discussion with these questions.

  • How do you, as an amateur or independant game developer, use design documents in your development process?
  • If you do use these documents, how important are they in your pipeline and what are their impact on your work? How do you create your design documents?
  • If you don't use design documents, why do you not use them and what is your development pipeline without a design document?

   I know that this subject is controversial in independant development so please, explain your point of view when posting, may it it be for or against the use of design docs. There are many philosophies regarding its use so please explain yours so that others may benefit from your point of view. 

DISCUSS

Related links
How to create a game deisgn document on Gamasutra.com
How to create a game design document article on Gamedev.net
Game design 101 on Sloperama
Game design document entry on Wikipedia
Logged

Lukas
Level 3
***



View Profile
« Reply #1 on: June 02, 2008, 03:30:14 PM »

Hi!
I'm a hobby game designer. I'm lead designer in my "own" project: "c0re", and have designed for some games which never came to be completed. I'm working on the Knytt-Stories-Level-series "Sohe and the rrokked" with a friend (the level is considered to be one of the best Knytt levels out there) and apart from that I've finished 2 "board-games" for VGNG- and PGC-compo and some adventure-games for Ti83+ calculators... to name one last thing: I'm thinking about all kinds of game-ideas all the time. And I have dozens of ideas every month. Just very few ideas make it far...

I think that the DesignDocument is absolutely necessary in my production pipeline.
Without any documentation I'd never be able to create anything.
I've worked out different ways of documenting my designs...
First I have the classic "Design-Bible for the team" approach which leads to very long, very structured documents. (25 pages just for the hacking-system-design in a sci-fi-stealth-action-game as an example)
I do this mostly to prevent any misunderstanding in the team aswell as trying to learn more about the design by writing it down really precisely.
After you've written many pages of well worked-out material about the design you will suddenly understand the game on a whole new level.
You can't make the right decisions about things you haven't thought about intensely before.
Second I have the "idea-sheet" model which isn't actually a "design-document" in its purest form...
I love to write on paper. I always need a pen and a stash of paper when thinking about something. I need paper to work out ideas. So I often start to scribble around, writing down some words and diagrams, some drawings and slowly I begin to shape the game's form on the paper. So I often end up with many pages of hand-written sheets of design. If I work by myself I always use such "documents". Before I write any electronic documents I begin to scribble. Sometimes I even scan in my sheets of paper and send them to members of the team.

For creating my recent game: "Faith, to a certain Degree" I wrote 15-20~ sheets full with concepts. These concepts often are flowcharts which allow me to keep my mind focused on the things I've stated already.

Sometimes I start design documents after having presented my ideas to others. That's why I have a (new) idea-blog: http://radiant-vision.livejournal.com/

Anyway... I keep 99% of my scribbles for myself so they are an extension of my mind. That's actually what (in my opinion) design documents have to be in the first place:
Extensions of the designer's mind. Design-Bibles for the team can be cluttered but every game needs an at least short one-document-overview of what is in the programme. This overview should be a personal designer-thing and free form. So if a game is mostly about the simulation of... cardriving... the designer can focus on the driving physics, for example. Things like complete lists of all game-modes etc. just need to be in design-bibles which make the concept understandable for others.


BaronCid
Logged

I make (60s/70s) rock music. Listen to my band's new album here: www.speicher.bandcamp.com
Robotacon
Pixelhead
Level 3
******


Story mode


View Profile
« Reply #2 on: June 02, 2008, 10:37:16 PM »

Design documentation is a two-edged sword.

If you're a lead designer it works as a means to force your will on the other project members and to keep everyones focus on where you're going. The Bible-approach sets guidelines on a architectural level with one document explaining how the game engine should work and another that explains what the world of the game should look like.

If you're making a game on your own with limited resources I'd say that a heavy design document might work against you. Your idea will grow faster on paper than you can implement it and if you don't look out your idea will have outgrown both your skill-set and your time limitation.

If you've got an idea, write it down and keep record of things, but don't brew on your ideas too much. Instead take advantage of the fact that a lot of games starts off with a simple level and gets increasingly more complex and let your game design grow with every level created. You can always go back at any time and tidy up those first crappy levels that you created.

Your biggest enemy will be NOT COMPLETING THE GAME!
« Last Edit: June 02, 2008, 10:49:15 PM by robotacon » Logged
mewse
Level 6
*



View Profile WWW
« Reply #3 on: June 03, 2008, 03:40:17 AM »

When I'm writing a game on my own, I generally don't write down any design documents at all (exception:  MMORPG Tycoon was complicated enough that I had to keep paper notes to so I could keep all the various simulation systems straight in my head).

Instead, I keep a log line, similar to the log lines that writers use to sell their screenplays.  It's a short, 25-word-or-less description of the core idea of the game.  I keep the log line written on paper, electronically, and in any other form I can manage, to keep it fresh in my mind at all times.  Then, whenever I want to add a feature to the game I'm making, I first compare the feature to the original log line, and see whether or not it helps further the game's core idea.

As an example, my log line for MMORPG Tycoon was:  "The player designs a complete WoW-style MMORPG, and must keep his users happy while still turning a profit."  Having that log line around made it easy to decide not to include (for example) letting the player have a character within the game;  while a cool feature, it wouldn't have advanced the core of the game.  In fact, the log line tells me that the most important facets to the game are the users, their happiness, and cash, and so any gameplay element which doesn't affect or reflect at least one of those factors probably doesn't belong in the game at all.
Logged
AdamAtomic
*BARF*
Level 9
*


hostess w/ the mostest


View Profile WWW
« Reply #4 on: June 03, 2008, 02:21:57 PM »

All I have to say on the topic of design documents, for now (and I apologize for its brevity) is this:

If I document something, it is a set in stone, indisputable guarantee that I will never ever even make it to the prototype stage, much less actually finish the project.

I had this problem in school, as well, and began using rough drafts instead of outlines for all my major writing assignments.  For me, this is really critical, I believe that it is almost impossible to really innovate and invent if you've already plotted the basic course of a thing.  By the time you sit down to prototype (the game's equivalent of the rough draft) you (and by you I mean me) are already bored with the project, because you know how it will turn out.

My design document, as it were, tends to be a Flash or other rapid-dev prototype!

EDIT - It should be made clear, if it was not obvious, that I am not advocating this approach, and it is likely some very real problem on my part.  However, I have not found any way around it!
« Last Edit: June 03, 2008, 05:11:05 PM by AdamAtomic » Logged

cup full of magic charisma
moi
Level 10
*****


DILF SANTA


View Profile WWW
« Reply #5 on: June 03, 2008, 05:00:13 PM »

I am currently coding games with a commercial oriented mindset (rather than an indie/artsy approach), so my approach is only coherent for this particular approach, people develloping more experimental games might have different needs...So here goes:
I am a lone designer and I use a limited design document  for the sole reason that it helps me prevent feature creep and procrastination.
When i have a good idea of what the game will be like, I sit down with a notebook and I start making lists of everything the game should have.
So during the devellopment of the game it helps me focus and yeah it's boring, but I know that when I have finished implementing all those things the game is finished, I am not tempted to add everything that goes through my head, or to start working on a totally new idea because I'm bored of working on ennemy#3
Generally I make a list of : ennemies, powers or weapons, levels (with vague schematics), etc,etc...
Then I add or remove items until the list is within a reasonable scale.

Then during devellopment itself I use the almighty Todo List but that is another subject...
Logged

subsystems   subsystems   subsystems
joshg
Level 4
****



View Profile WWW
« Reply #6 on: June 03, 2008, 08:50:30 PM »

There are two things a design document can do which can be useful to both a huge commercial team or a small indie group:

 - communicate and clarify ideas and goals
 - document your decisions so that people don't forget or screw them up later

If you're a lone indie, you may not have to communicate to anyone else, but I find that writing something down can help clarify what it is you have to decide.  eg. writing down a list of options on a decision, pros and cons. 

And if there's time enough for you or someone else to forget why a decision was made, you can go back to the doc and look over the decision making process again and remember why you thought it was a good idea.  (If you disagree now, then you should be able to look at the facts involved and see what's changed, or what you were wrong about then.)

Don't write more than you have to. 

It helps on larger projects to create separate small documents for specific features rather than one huge document.  That way you'll only have to look at one manageable chunk at a time when you're implementing that feature.  Plus, if you have multiple people making decisions about different features, separating things to their own docs means you aren't all trying to edit the same massive document at the same time.

When I worked on a very small team (2-3 people), I learned another lesson about design docs - the hard way.  As the coder implementing someone else's design, it was incredibly easy for my mental image of the game's design to slowly shift in ways that made my life easier.  Unfortunately, those shifts didn't actually make the game any better, and by the time I looked back at the original mockups and design doc I realized I had made some wrong technical decisions for what the game really should've looked like.  This is another reason to keep design docs small - so people actually read them.
Logged

these are from an actual radio shack in the ghetto
Guert
Level 10
*****



View Profile WWW
« Reply #7 on: June 18, 2008, 05:11:13 PM »

Sorry for the delay, I've been quite busy these last few days.

So, from what I read, design documents seem to be used rather as a guideline rather than fixed rules. For those using a design document, it is mostly used to get the rough ideas first before getting started.

Adam, I'm sure you are not alone in this situation. Smiley Anyone else has trouble using this kind of documentation? If so, what ticks you off when documenting?

And for those who use a document, how do you structure your documentation? What are the topics found in it? How do you tell when you've written too much or too little about an element of your game?

Logged

Don Andy
Level 10
*****


Andreas Kämper, Dandy, Tophat Andy


View Profile
« Reply #8 on: June 19, 2008, 03:14:06 AM »

Adam, I'm sure you are not alone in this situation. Smiley Anyone else has trouble using this kind of documentation? If so, what ticks you off when documenting?

I just can't document stuff, maybe sketch around the basic outline of the game, but the rest I gotta keep in my head. Basically, the outline is just for reminding purposes.
I always have billions of ideas about a game, but as soon as I try to write any of them down, they're gone. I think it's because I'm thinking faster than I can write. By writing down just one thing, I have to focus so much on it that I basically forget the other ideas.

The disadvantage of this is, of course, that it's hard to stick with a basic principle for the game. The idea that was awesome today may sound less awesome than the idea I'm going to have tomorrow, resulting in trying to do something different again, instead of sticking with the first thing.
Logged
team_q
Level 10
*****


Divide by everything is fine and nothing is wrong.


View Profile WWW
« Reply #9 on: June 19, 2008, 06:50:02 AM »

My favorite approach is to do the design document in a Wiki format, it makes it much more dynamic and easier to cross reference. Though I only document when I'm working with others as I don't tend to write things down for myself.
Logged

Dirty Rectangles

_PRINCE OF ARCADE_
Arne
The Pantymaster
Level 6
******



View Profile WWW
« Reply #10 on: June 19, 2008, 07:52:12 AM »

I use design docs are an external augmentation of my structural thinking (problem solving). Also, they're incredibly fun to make.

One thing which I should do more is to also write down my thought process for arriving at a conclusion. I sometimes find old docs with just conclusions and I don't understand anything and think it's shit. It's also important to illustrate structures if you want to sell the concept to someone.

I generally try to stay away from fluff like names early in the process. It's a bit like a mosaic reveal, the big picture comes first. I also try to draw first, feel my way around... position the elements in the design space, nudge them around, and then decide on the visual design fluff.

This is a lot harder to do when someone else has already written down their 'mental image' of a design. Then you have to spend a lot of time chasing that, maybe venturing too far outside your comfort zone, ending up with a stale design. Quite often this 'mental image' is already an arbitrarily placed point inside a space with a lot of tolerance, so it would've worked to just draw something cool (within the tolerance) and then decide it's the right choice.

However, when I make designs based on old games, I have to stay close to the original. That's where the fun lies, dancing around in design space to see how close I can get to certain areas, and seeing what kind of structure I can come up with within those restrictions.

I find that if I write a really accurate design doc it is essentially pseudocode and at some point I might just start coding the thing. For me a design doc can be anything between loose idea and pseudocode. Since I code a bit I think a lot about the code when I come up with structures.

I never finish anything that I design doc though, but I get offers from people who are interested in working on my stuff. Unfortunately since most of my stuff is based on licenses / copyrights owned by others, I can't really do anything with the stuff.

Logged
Lord Ash
Level 0
**



View Profile
« Reply #11 on: June 24, 2008, 04:48:07 PM »

as a pen & paper rpg player and designer, I get pretty detailed, covering battle mechanics, item descriptions, locations, everything I can think of. I am starting to get more script oriented lately, covering dialog and such. I think that there has to be a point where you put away the design doc, and start developing something. Without a clear roadmap, there is a lot of room to get lost in the project.

Logged
PenguinHat
Level 1
*


Hi everyone! Nice to meet you all!


View Profile
« Reply #12 on: June 25, 2008, 05:35:45 AM »

I tend to make very short things, but what I do is write (or draw) a quick outline of what I want the game to end up like on a piece of paper, with ideas randomly thrown around the piece of paper. I then crack open something and make a very quick prototype. I then realise that parts of the design are no good, or only get in the way of the great bits and I remove them. Or trash the whole idea and scribble down a  new one.

I personally find that if you don't start working on what you are designing soon, you never do. So the design doc serves only to focus the mental image of the final thing.

If you are interested, I could scan in the type of scribble I make. They aren't much to look at, but you might find it interesting.
Logged
marshmonkey
Level 2
**


this is personal


View Profile WWW
« Reply #13 on: June 25, 2008, 04:39:34 PM »

I don't use design documents, becuase while I generally have a pretty good idea in my head of what I want the game to be ( and I communicate those ideas constantly ) I don't like to define things until they are in the game and the ramifications of those decisions can be seen. I am most partial to the type of iterative game design that branches off in new directions that couldn't have been anticipated by the thought exercise of writing a design doc.
Logged

LuisAnton
Level 1
*


View Profile WWW
« Reply #14 on: June 27, 2008, 01:29:35 AM »

By the time you sit down to prototype (the game's equivalent of the rough draft) you (and by you I mean me) are already bored with the project, because you know how it will turn out.

And that's the story of my game programming attempts. But even worse, I don't even write down anything. Whenever I get the basic game mechanic working, I feel I know how it will turn out and I get bored.
Logged

Eeriepanda
Level 0
**


View Profile
« Reply #15 on: July 07, 2008, 10:35:26 AM »

I usually create a very brief and unorganized Design Doc to start work off of. With this in hand, I go haphazardly creating rubish in whatever language I have chosen. After doing that for a bit I see what I have and then flesh out the Design Doc as to what I think is feasible and what would work good. I then haphazardly go at it again and look at what I have....

Anyhow, I highly suggests doing iterations. Start with a really basic idea, build the basis of that and see where you want to go with it.

Eventually the Design Document will overflow into a Design Bible :D
Logged
DjangoDurango
Level 1
*



View Profile WWW
« Reply #16 on: August 07, 2008, 04:42:14 AM »

I work both on an high profile game development company and a small indie game (2 man team) and I've experienced wiki to be ideal tool for design documentation. Not only is it neat, tidy and easy -- you'll be able to chop it up to specific hotlinks and chunks. I'm in the midst of outlining a prototype game and seeing the flexibility of a wiki-system for documentation is great. Information is usually maintained and updated.

Are any of these wikis accessible so that I might see how your organization system works? Like for a game that's already been completed or something? I like the idea of using a wiki to organize, and while I don't necessarily need to do a fullout design doc for anything yet, I'd like to see this in action should I ever need to work with other people.
Logged
diwil
Level 2
**


View Profile WWW
« Reply #17 on: October 08, 2008, 01:48:28 AM »

I use design documentation in a very liberal way; mostly consisting of a bunch of text fils in a folder, streams of consciousness and ideas that I refine into well defined concepts.

Usually after I've processed each of these notes, I delete it from the folder, so I don't actually leave much documentation behind; I have a big brain with lots of memory space for that stuff! Wink

The weirdest thing? I can't remember anyone's birthday for the death of me, but I can still remember each sector code in Duke Nukem 3D's build, as well as the bounding boxes of every item in Quake. Talk about filling my head with trivial knowledge!
Logged
Hajo
Level 5
*****

Dream Mechanic


View Profile
« Reply #18 on: October 08, 2008, 01:54:37 AM »

Once I had a full-fledged design doc, starting with a vision chapter, then some specification of the features, down to specifications of implementation details.

In hindsight, it was the complete overkill. And it was difficult to maintain.

Currently I'm using a wiki, to keep things like the vision chapter, also much of the specification. It's not that much different to the doc I had before, but due to the wiki nature, much more accessible, and easier the keep up to date.

For the smaller things popping up during development I keep a todo list.

Design docs are more important for teams, and for bigger projects. There they really help to keep everything on track.
Logged

Per aspera ad astra
diwil
Level 2
**


View Profile WWW
« Reply #19 on: October 08, 2008, 01:58:54 AM »

One of my spare time hobby-programming projects is a SCRUM time management system, embedded with a Wiki for feature documentation.

I loved the way SCRUM made development of small teams much, much more efficient, but we used an Excel sheet for managing our hours and tasks. An integrated system with documentation was something I kept wishing we had, so I figured to write my own. I'll probably use that to manage all of my projects in the future.
Logged
Pages: [1] 2
Print
Jump to:  

Theme orange-lt created by panic