Skip to content

Search String: “How large should a game design doc be?”

December 27, 2007

Another post in my continuing series of google search strings that bring people to my site.

How long does a game design doc need to be? As long as as necessary, but not a word more.

I know that sounds like I’m completely blowing off the question, but it’s an accurate answer. I’ve had design docs in the 150+ page range for hardcore RPGs that included all the item lists, monster lists, NPC listings and so on. I’ve also written design docs that are as short as 30 pages for an adventure game.

Here are some numbers to the best of my recollection from my actual experience:

  • Story mode system for Def Jam Icon: 110 pages
  • One level doc for Wizardry 8: 60 pages, including all narrative content
  • Serious game design doc [confidential game]: 70 pages
  • Design proposal for an upcoming RTS [confidential client]: 10 pages

Rather than shooting for a specific number of pages, here are some suggestions.

Be Precise

Newly minted game designers have a tendency to say things like this in their design docs: “After the player gains a level, the game raises the character’s statistics.” Can someone actually program what was just written there? No. What statistics? How are they selected? How are they raised? How do you notify the player that they have been raised? Do you take them to the character review screen automatically? When do they actually level? On the spot or when the encounter is fully ended? When a stat is raised, is there any specific effect on the stat (i.e. it turns blue for a sec and then fades back to the default color)? As a game designer, precision is your job. You need to answer every question before it’s even asked. The more experienced you are, the better you’ll get. Experienced game designers can spot a lack of precision in a junior designer’s doc at 12 feet. I run a class at SCAD called Applied Game Design (surprising, no?). In that class, I mimic the industry, act exactly like a lead under pressure would, and demand students step up to industry level. Provided they’re not working in agile, you can see dramatic growth in the precision in their docs as they advance from draft to alpha to beta and then to gold.

Be succinct.

The most important audience for your design doc is the programmer at 3am. It’s that man or woman who’s going to be coding what you’ve written in that doc. Think not of that joyful co-worker you see during the day. Rather, think of the person who’s unbelievably tired and hoping to stave off crunch. If it’s not precise or goes on for ten pages about why you decided to do something or another or – way, way worse – includes rambling story reflections or marketing-esque text about how this feature is going to revolutionize the world of gaming as we know it, you’re creating one irritated person. They’re programming the game, not buying it. Get to the point, and don’t make them hunt for it. In fact, consider using bullet points in your docs. I do. Here’s a fictional set to illustrate the point:

  • Increment STR by one if the player’s avatar is a fighter
  • Increment the LVL by one
  • Check for any level-based skill awards
    • If there are level based skill awards…
    • If there are no level based skill awards…

I started using bullets in docs where appropriate quite a long time ago. At 3am, it’s really easy to lose a point in the middle of a big fat paragraph of text. By using bullet points, programmers can cross them out as they’re finished or move down a line if the doc is a part of a wiki. It just makes it easier for them.

Be respectful

Don’t tell the programmer how to code what needs to be coded in the doc. If you knew best, you’d be doing their job. Also, be open to feedback from programmers. Good programmers are trained to find the most efficient way to get something done. Let’s say that it would take 10 hours to do what you’ve asked the programmer to code. After reading your doc over, she tells you that she can give you something very close to what you’ve asked for in just 2 hours for a small compromise. It might be worth it. This brings me to the next point:

Be cost conscious

Think of everything in terms of the amount of programming and art time it’s going to take. People tend to think about this past alpha, but it matters even more in the early days.

Be open to change

The way we make games is changing. Designers aren’t writing sitting down to write long docs all the time. We’re using scrum and agile, and the designer’s job is much more hands on than it was in the late 1990’s. Stay on top of those trends and learn by application however you can, especially if it involves creating your own game with a team of like-minded individuals.

Advertisements
3 Comments leave one →
  1. December 27, 2007 11:02 pm

    I’ve found this template a long time ago that I’d like to share to help those that are interested in creating a design document, but are not sure where to start. This template is from Chris Taylor’s Dungeon Siege design, so it’s more directed toward an RPG, but it can easily be modified to fit whatever you need.

    Download Document

    Feel free to look at this and recommend it or provide another way to get started, Brenda. Thought I’d add my two cents.

  2. Nat permalink
    December 28, 2007 1:46 am

    http://www.gamedevblog.com/2007/12/manager-in-a-st.html#comments
    Jamie Fristrom has a good post on game development planning.

    One line from the comments…

    “The more you can iterate, the less you need to plan. Conversely, the less you can iterate, the more you need to plan.”

    Which I totally agree with. If you can iterate, the best thing to do is to have an idea, iterate, see if it’s fun. In 5 iterations (Cerny method) you’ll have something much much better than a 100 page doc that most people will most likely not read. Team members included. During development, things like

    # Increment STR by one if the player’s avatar is a fighter
    # Increment the LVL by one
    # Check for any level-based skill awards

    will often change so taking the time to write down each case can often… I hate to be negative but be a waste of time. HOWEVER when you are unable to iterate, I would recommend more general planning and avoid details. I’d consider 20-30 pages the sweet spot. It’s a readable length and it’s enough to get all the most important ideas down.

  3. December 28, 2007 8:41 am

    @Nat – Totally agreed on stuff changing. It depends on the studio, too. The studios that I’ve worked for opened up those variables so that designers could tweak them as necessary. Sometimes, designers don’t have a choice about writing a doc. It depends on the studio or publisher policies. One group I worked for required a complete game design document before entering preproduction.

    @David – That’s one way to do it. In my docs, I like to write them in the order that the player encounters stuff. For instance: UI, intro menu, character creation, main game world view, exploration, NPCs, combat, etc.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: