Skip to content

Comments on Level Design Docs

May 5, 2009

We do not have Chicago Turabian style in the game industry. At best, we have a collection of practices that are culled from years of experience and the collective spreading of game design knowledge from person to person. Ultimately, this spreads company to company as people leave their jobs and join others elsewhere. What’s below is a general summary based upon the pile-o-docs I am reviewing today.

  • Proofread it. Proofread it. Proofread it. If you don’t have a good grasp on your language of choice, get it. Good language skills are a must. I have heard, “Yeah, my grammar’s not so great,” on a number of occasions. Then fix it. Can you imagine a programmer or an artist getting by with that line of reasoning? I once spent a year studying grammar, and I am glad that I did.
  • Include a cover page with date, copyright information and a note about the doc’s confidentiality.
  • If digital, integrate version control.
  • Provide an overview of the level: one or two paragraphs telling me in a general way about where and how the level fits in with the overall game. Does it come after the player completes the R14 Outpost level or before? Is it midgame, early game or end game? Do players come back to it multiple times?
    • I like the overview to be followed immediately by a general overhead of the level calling out major features. Visuals go a long, long way toward understanding.
    • Some people include a list of key NPCs, items and events in the level, too.
  • When designing the overall look of a level design document, consider its visual pattern. Instead of blocks of text, use indents, bullets and the like to differentiate and subordinate one kind of text to the other or to show relationships between text fields.
  • When we get to the main body of the level doc, I like to see an actual map of the level with numbers calling out locations. These numbers would then be matched in the sections that follow.
  • Missions or even just events need to have a reason to exist in the narrative. There are multiple parts to this:
    • The game’s motivation – you can say the character needs to leave 5 gp on the altar, but if there’s no reason to do it in terms of reward or conflict, who cares? I’ll do it because you made me do it, but I won’t like it. I will feel like you’re dragging  me through your world.
    • The player’s motivation – why do I want to leave the 5 gp on the altar? I’m hoping to get something I don’t have, improve something or not lose something I’ve already gained.
  • Some more mission stuff –
    • Remember Aristotle and the Deus Ex Machina.
    • Have logical outcomes. For instance, if you show up to give an item to someone and have that person spontaneously declare that you must fight their bravest combatant, this looks like bad design, not a challenge.
    • Give it out a little at a time. Tell the player that Travis in New City might have some idea what you need. Don’t tell the player that Travis in New City – who has been recently caught up in street battle with Jack and may need your help to resolve this – has what you need. Let Travis tell the player that. Better yet, let Jack tell the player that after he’s taken Travis for a sight-seeing tour of the cliffs.
    • Typically, we give missions names so that they can be easily referenced/discussed by the dev team and later by players.

See also:

Endless comments on level docs

Still more comments on level docs

More comments on level docs

Possibly the last set of comments on level docs

Advertisements
7 Comments leave one →
  1. May 5, 2009 9:50 am

    I found that Damion Schubert’s Power Point on writing design documents is very helpful as well. Hopefully that info adds rather than subtracts from the clarity of discussion. http://www.zenofdesign.com/Writing_Design_Docs_2008.ppt

  2. May 5, 2009 9:59 am

    Hi Seth,

    Definitely adds. Thank you.

    brenda

  3. Clemenstation permalink
    May 5, 2009 12:19 pm

    Hiya.

    Just wondering: how does this doc structure differ for games without clearly delineated levels or zones or areas? DOES it differ? I am thinking specifically about sandbox-style games, where quests can lead you from one side of the map to another and boundary lines are less apparent. Seems like it would be difficult to drill down into specific areas in this instance, at least without a bevy of cross-referencing.

    That would be one huge design doc.

    • May 5, 2009 12:54 pm

      Well, yes, sometimes they were huge docs and heavily cross referenced. It’s easier to do it digitally where a click will do it. All of the games I worked on were multi-linear, but it worked just fine. Ultimately, you need some kind of map that you can look at and a legend that tells you how all these things connect. I also tend to separate docs by levels within a game, and I show in the beginning of the level doc precisely what area I am talking about. In that section, I might also split the level out into zones for easier reference for those building it (if it is not me).

Trackbacks

  1. Comments on Level Docs - Take this book and flee! « Applied Game Design
  2. Endless Comments on Level Docs « Applied Game Design
  3. Possibly the Last Set of Comments on Level Docs « Applied Game Design

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: