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.
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:
Always, always consider for whom you are writing a document. Here are some common considerations for different groups and people you may work with:
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.
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.
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.
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.
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.
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.
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.
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.