Friday, September 10, 2010

The Myth of the LDD

QuakeCon was awesome.  We, among other things, 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 the World of Design panel went well, but I had a feeling that one remark in particular 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.  Sometime 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.  When writing a feature request for tools, pitching a risky concept or working on system design, for example, 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.
  • Be Straightforward
    • This is technical documentation, not creative writing 101.  You, in general, 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.


Forrest said...

As nutty as this may sound, at my current gig I generate multiple docs for each level, for different audiences. Design gets to look in the editor, or a simple story points wiki page to build from. Production gets a word doc that looks like a spreadsheet; it's a long series of tables detailing content needs of story beats. Art gets some poster sized printouts that illustrate key locations & their function.

I plan on retiring all but the level itself as it comes to fruition and it can speak for itself.

Brandon said...

At SMU I do think we do go a little overboard on documentation. For DFSII (Direct Focus Studies II) I am doing a Gears of War level. The LDD for this class was 30% so I spent almost 30 hours writing it when I could have been whiteboxing and actually seeing if my ideas work.

On the other hand, I also feel by fleshing this document out so fully, I do not have to fear feature creep and I know the project is in scope with meeting my milestones. I think it comes down to experience. With more experience gained, I think what I get from the documentation process will be inherently known.

Tim Flemming said...

Joel, your post has been making the rounds here at SMU. Thanks for taking the time to elaborate.

I feel like the LDDs we do here can get pretty bloated and unwieldy. I think you and Forrest have pretty much identified the problem though in that the LDDs we do here are really intended to be for pretty much all of the above audiences simultaneously.

We also add overview sections intended for executives or people who aren't well acquainted with the project. However, it seems like from your post that they are an audience who would probably not be reading that kind of documentation.

Anyway, thanks again for the read. It had never even occurred to me that QA would need some kind of documentation to know what was going on.

JBurgess said...

@Forrest - Considering your project, it certainly makes sense that you would do more documentation per level. It just goes to show that there's no blanket approach to documentation: every project, studio culture, and individual's preference will influence what sort of documentation is called for. I tend to minimize documentation to cover the essentials, but the "essentials" can be very circumstantial.

@Brandon, Tim & SMU at large - First of all, the collective experience of the folks who developed the Guildhall curriculum far outweighs my own. I've never had to write documentation for executives, for example, but at some studios an LD may be called upon to do that. It's certainly better to run the gamut now and be prepared for those eventualities later.

Second; I think it's a wise practice to over-document a bit as a student. I don't advocate minimal documentation because it's dull compared to implementation (that's just a bonus), but because I think it's easy to become wasteful in a live dev cycle. When you're in school you are hopefully able to take some time to be deeply introspective about your process, and focusing on that paper phase can shake out some problems you would have hit hours into implementation otherwise.

It's certainly an interesting topic to discuss, as there are no right answers!

Wade-Hahn said...

Joel, what do you feel about revising documentation throughout the project? It seems more important for things like asset lists, but what about LDDs?

Anthony Paul said...

I just stumbled upon this. Great Article.

After leaving a job at a social games studio I thought to myself, I can create a social game in nearly the same amount of time as their entire team does. It's not to be arrogant (Okay, maybe a little) but on my own project, I'm finding this to ring true.

The time it takes me to program, design and create (poor) art is offset by the time it took me to write documents, have meetings about the features in those documents (to some who may or may not know English), and communicate the information to everyone on staff. To bypass that all and go straight to implementation, at least more frequently than is currently done, perhaps needs to be considered more often.