Joel Burgess: A Level a Day Keeps the Docs Away

Bethesda Game Studios lead level designer Joel Burgess offers his thoughts on best documentation practices following an appearance on the “World of Design” panel at last month’s QuakeCon.

QuakeCon was awesome. Among other things, we got an amazing demo of Rage, walked around a BYOC that would make anybody believe in PC gaming, and heard the news that Arkane joined up with Zenimax. Which, believe me, is worth being excited about.

I think our World of Design panel went well, but I had a feeling that one of my remarks might raise some eyebrows. Sure enough, the next morning I had an email waiting for me from an astute SMU student, asking me to explain my thoughts on documentation for level design.

During the Q&A session, I advocated just getting into the editor and going after ideas rather than spending much time planning. This is looked upon poorly by some designers, and actively discouraged in a lot of school curricula. SMU students, specifically, write up an abstract and an LDD (level design document) before beginning work on a level. So why would I suggest this isn’t the best way to go?

Let me start by making clear that I am not against documentation. Honest! No, really! Documentation can serve an important role when used wisely. For many, it’s an important step in the creative process. When collaborating with others, it can be a vital communication tool. For students especially, it’s a great exercise to externalize thoughts and ideas by creating a document. This forces you to think through the implementation process before you begin, and keeps you from straying too far off-course once you have. Documentation has no art or code dependencies, either, and is sometimes the best possible way to use designer time early in a dev cycle when there isn’t much else to work with.

IMG_12349.jpg

The danger, I think, is when we spend time documenting at the expense of implementing content. Sometimes it’s easy to stay in a documentation phase long past the point of diminishing returns, or waste time maintaining a document that nobody needs. You are, as the saying goes, shipping a game, not a design document.

I should point out that I’m talking specifically about level planning docs here. There are certain jobs that call for more extensive documentation than others.  For example, when writing a feature request for tools, pitching a risky concept, or working on system design, the more detailed the documentation, the better. (Maybe.) When it comes to level design documentation, however, we’ve tried just about everything at Bethesda, and I’ve arrived at a “less is more” outlook.

Here are some things I keep in mind when approaching documention:

Audience

Always, always consider for whom you are writing a document. Here are some common considerations for different groups and people you may work with:

Yourself

For some designers, it’s important to get it down on paper. That may be the best way to crystallize and preserve an idea, keep your future self honest, or iterate in the moment. That’s fine, and if you are the only audience you should just do what works best for you and ignore what I or anybody else has to say.

QA

Documentation can be essential for testing. Off-site testers are common, so documentation may be the only communicative link between yourself and that team. Your document can inform them of your design intent, goals, supported (or unsupported) gameplay, known issues and potential problem areas where your level could use extra attention.

Production

When writing for the benefit of a producer, keep in mind things like any dependencies between your work and that of others, your best estimate of how long implementation will take, and the overall scope of the work. This information will help them design a schedule that doesn’t leave you in the lurch when the rubber hits the road.

Art

The relationship between art and level design is a little different at every studio. Depending on how things are where you’re at, you may need to generate whole asset request lists with relative priority or budgeting disk space for texture memory, or simply stating your high-level visual goals for a space. Talk to artists and find out what they’re looking for in your LDD.

Code

If you’re writing a design that depends on unimplemented tools or mechanics, be very specific about your intended use and desired workflow. I believe that face-to-face communication is vital here, but agreed-upon documentation can be an important supplement, as well.

Brevity

Nobody is reading your lovingly-crafted manifesto. Sorry. You’re wasting your time and putting everyone else to sleep. What’s worse is that anything of real quality in a long document is lost in the noise. Further, an expansive doc can be a bear to maintain. Pare down; focus on keeping things short and high on value.

Straightforwardness

This is technical documentation, not creative writing 101. You generally want to keep an LDD very dry; forget the flavor. For many LDs, it’s easy to drift into scene-setting paragraphs, but you should excise this useless information in favor of direct statements about the assets you need, and how you’ll be using them. See the note on brevity: say what needs to be said so you can glean the important data when referring to this doc later.

Acknowledge Lies

The game is truth; the wiki (or whatever you use) is lies. Maintaining a document throughout development is tedious and often futile. Rather than agonize over keeping a doc current, be cognizant of when portions of the doc have fulfilled their purpose or become irrelevant. Those sections should be removed or clearly delineated as obsolete.

I’d rather be Implementing…

I always get pensive when doing heavy documentation, because I’d rather be doing something. So I always keep in mind where to put the metaphorical pen down and pick up the (equally metaphorical) shovel and get to work. Know your documentation goals, achieve them, and then get in the editor and start making some videogame magic.

So that’s my view, in a nutshell. I don’t pretend to know it all, but I’ve tried dozens of approaches to the LDD through my career. For me, it comes down to this: I love making levels, and there’s never enough time in the schedule to do everything you want for a game. The time I spend writing about levels is time I’m not making them. Documentation is one of those sometimes-necessary evils, but I like to keep it brief so I can get into doing what I really care about, and what the player will really see. After all, ideas are nothing – execution is everything.

Reader Comments

  1. Nice and actually makes sense. I remember when doing some level for UNREAL 2004 i planned it out all on paper because i just didnt trust myself like you were stating about keeping ones self honest. Still not planning things out so much on paper does keep one on a focused edge where one does things as quick as possible while they’re still fresh in the mind which cuts the down time in half leaving more time for other stuff or a quicker finished product.

    Thanks for the excellent read Mr.Burgess.

  2. Great article – gives me alot of peace of mind actually. 90% of the modding I have done so far is on level design in my attempt to first make a world, and then worry about the dialogue and even extra quests until the world was done and I had a “stage” to use for the quests/dialogue. Your method is exactly what I’ve been doing – making cells – though as an amateur still make alot of mistakes in trying to noodle it all out. Your commentary is definitely good food for thought.

    Cheers!

  3. Great article, you always keep a lot of these things back in your mind..yet it’s nice to see a full story in mind and there are definitely some things I’ll use for the future. I also recognize a lot in the types of audience. Coders can do a lot, but if you don’t explain too well a lot can go wrong resulting in a (huge) difference of aim and result. I like the Acknowledge Lies part, it’s something that’s often ignored but can cause a lot of trouble.

    Thanks for giving us an insight :).

  4. After reading this and Joel’s entry in the ‘On Inception’ series, I’m really impressed. It’s reassuring to know that Bethsoft games are in such good hands.

  5. Very true! I really enjoyed this one.

    However I must say that writing things down can be very important. Many a time in the TES:CS I’ve blown an hour or more messing with a part of the toolset (such as the Dagon shrine or Chargen architecture sets) thinking about what cool things I COULD do rather than go into what NEEDS to be done. What a battle >.<

  6. I’m trying to break into the industry myself, and in my 18+ years of gaming this has got to be the best time ever in being a gamer/modder (Arkane studios, of Arx fame, with Bioware N’ Beth!?..I feel giddy inside 8^D! ) So it comes as no great surprise to me that this information is the most invaluable tool for both gamers, and modders/Soon-to-be Devs alike!

    Thank you very much for sharing this with us, and Devvin’ the games that I have enjoyed very much!

  7. I can’t agree more. I actually went through the program for design at SMU and while the exposure to the documents was a good learning experience I found it not in alignment at all with how a level takes shape and is created in reality. I think much in an academic environment is designed to stave off chaos when in fact it has be included in the process, not exorcised. It all has to be quantifiable all the time. But, its not.

    I use no more than one or two page write ups here and there for levels at work and I use none for my side projects and personal work other than silhouette drawings and meaningfully named groupings of objects in the tool.

    Love the philosophy at work here. can’t wait to see more meanderings.