Comments on Level Design Docs
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.