Design Documents – Yes, you need them!

Hallsofvallhalla started a conversation on Friday questioning the value of design documents. I think he is mostly wrong and partially right. I’ll start with why I agree because that is easiest. Most design documents that I have seen are not terribly valuable because they focus solely on the color of the bike shed. They discuss things like level layout, class abilities, races, etc. and ignore the deep decisions about the physics of the world; how it actually works. The design doc should be useful to all team members; not just artists and designers. Now the other side of the argument:

Architecture Matters

Persistent worlds are certainly complex enough to require serious planning. Part of preproduction – and an important part of the design document – is figuring out how to do the hard problems. How will inventory work? How can it be implemented? Etc. Etc. Unless you want to constantly be throwing your work and starting over again, these things need to be worked out before you write a single line of code. All too often, I see freshly started projects publishing screenshots, which hints that they have skipped preproduction entirely.

While writing the Angela interpreter engine for Memotica, I’m reaching the point where I’ve got the core of the interpreter to the point where I’m writing the brokering mechanisms for actions and stimuli. I designed the overall, high level architecture of the engine over a year ago and looking back on it now allows me to continue without flailing about and redesigning the whole choreography. In short, the time spent then is saving me considerable time now.

The ship needs a rudder

Where is the project going? Is it still going in the same direction as six months ago? Or is it adrift and rudderless, buffeted by whatever is being talked about on the project’s forums?

A dirty secret about community/indy teams

One of halls’ argumenents against design documents is that it acts as a straightjacket that restricts creativity and makes the project less interesting to portential team members. One of the dirty secrets is that half of the people who show an interest in helping out a project are useless. They have neither the work ethic, nor the patience and tenacity to stick with the project and be productive. They will happily shoot the breeze on your forums and pontificate endlessly. Do you really want these people setting – and changing – the direction of your project? 90% of the other half are only valuable if they were recruited at the right time and there is consensus on vision; two things that are only possible after the valley of tears phase.

The valley of tears

Every PW project goes through the valley of tears. This is the phase in the project when the interesting theoretical discussions have been had and it is clear that it won’t take weeks to realize the world, but months and years. It will seem that “nothing is happening and the project is going nowhere” for long stretches as the foundations are laid. This is a time when no flashy screenshots are created, but instead the plumbing is laid in. In the worst case scenario, you will be the only person sticking with the project during this time. Projects whose leads allowed them to turn into designed by committee, vampire/puppy/rainbow monstrosities tend to die tragic and lonely deaths in the valley of tears; identified only by the lonely husks of once active forums that will one day disappear into the great 404. You didn’t let it turn into something that you are not entirely happy with during the pontification phase did you? Because it is your passion and drive that will see the project through to the promised land on the other side.

Please tell me that you are recruiting your team at the end of prepreproduction!

You have a prototype. It may be butt ugly. It may not be very performant and will need the attention of better programmers than yourself. The important thing is that the project is past the valley of tears phase, is picking up speed and has direction. The people you recruit at this phase will be attracted to:

• The fact that it has direction. Hey, we have all been on teams with no rudder or team stuck in perpetual pontification mode. Being on a team that is on the move has its own attraction and for years has been one that Luca Pancallo (Talad) of Planeshift has used in dev team recruiting drives.
• The vision. In the pontification (a.k.a. early design) phase, you will inevitably find that others want your goth-vampire world to be about puppies. Perhaps those puppies could have a vampire option as a compromise, but rainbows are much more important. The kinds of people who join because they read your design doc are true believers.

The live team that runs the PW won’t be the same as the one that initially works on it

I don’t say “built” or “delivered” as community worlds are never finished and are always works in progress. People come and go on the project and over time the composition of the dev crew will change. The people coming in will need to sign onto that vision. When a player (always a self identified “ideas” person) starts pontificating about how you need to change your world, you can point him to the vision. Not having a clearly defined vision contributed to Etilica’s death spiral. From the perspective of the leads, I was probably a rogue developer. If there was a design doc to refer back to, we probably would not have been in the habit of surprising each other with changes.

A final caveat. The document need not be set in stone

A design document needs to be a living document. You’ll want to prevent the pontificators from rewriting your design document, but you’ll also want the committed team members to effect change as long as they earn the right. As these committed team members get their ideas accepted, the design doc should be updated to reflect the new status quo.

Prepreproduction

There are certain things that I’ve done and that I’ve seen done that can contribute to a world imploding during development. As I’d mentioned in earlier installments of the Etilica postmortem and as Phil had also mentioned in the comments, Etilica needed to be “clean” when it left beta. How might have this been accomplished? You need solid preproduction. Professional game developers tend to use terminology derived from the entertainment industry. Thus, instead of requirements, specification, design, development and testing phases, they have preproduction, production, rollout and operation. There is a pretty clean overview of this process, written by Richard Bartle in his book, Designing Virtual Worlds. Some of these bullet points are not entirely applicable to small teams and hobbyists, but the basic idea holds. I can say from experience that you should not skimp on the preproduction phase. I can’t guarantee that having one will be the magic bullet of your success, but not having one will give you grief.

At the end of “preproduction”, you want to have to following two things:

A design document that you can always refer back to - There are excellent write-ups here and here on Gamasutra for writing design documents. “Real” designers may have better things to do than write documentation when they really want to build, but that document will encapsulate your vision for everyone on the team. If your team always remains one or two guys, you can get away with not doing this. This document will entail how the subsystems (of the prototype below) function, how gameplay works, special shticks if the world has any, and basic, bullet pointed lore.

A working prototype with all of the core systems in place - A barebones world with all of the core systems in place should be playable. It may not be recognizable as the one you are planning to build; in fact, it is better if it is not. It does need to have all of your complex custom subsystems in place. Do you have a unique faction system? Do you have a custom dynamic encounter system, loot systems, crafting, character advancement, death, scripted AI, etc? These should all be in place.

A professional team would probably just have something minimal to show case gameplay ideas and leave their implementation up to the programming team during production. For a world build by volunteer hobbyists and indies, you’ll need more. The industry term for a pre-alpha, yet vaguely playable level mockup is a hull. A hull has no visual details and probably only has a plain texture thrown on the geometry to be able to see it in a game engine. It is just for testing concepts at this point.

You’ll need a keel (yes, a play on hull) for your world. You and the team you recruit will be extending it from there, but the foundation remains the same.

What you should avoid:

Resist the allure of “agile methods” during preproduction– Many amateur worldsmiths have probably never heard of agile methods, such as SCRUM. It can be an alluring idea. The central concept behind agile methods involves creating a deliverable every 30 days (or 20 days, or 6 weeks, etc.). The opposing approach, known as waterfall development, is currently out of fashion among software developers. Its premise was first you clearly define your requirements (qualitatively what the software will need to accomplish), then you clearly specify a set of key performance indicators (KPI’s) in a specification document (quantitatively what the software will need to accomplish), then you design it from soup to nuts and finally you sit down to write the code. The idea is that the code will flow and be relatively (not completely) bug free. Waterfall development often suffers from the problem that requirements are not completely known initially, or change, or that a proposed design element is not as completely and utterly awesome as envisioned once coded.

Agile development came into fashion because it addresses this. Taking your development in bite sized chunks has great merit. Ensuring that you have a deliverable every 30 days is a great way to keep moral up (after all, milestones are clearly being reached). A protracted design phase – as happens with waterfall development methods – can give people the feeling that nothing is happening and cause them to leave. I’ve seen this firsthand more than once. Often, there is some guy insisting on doing iterative development from day one. If you follow his advice, your group will quickly make progress and will be passing around its first screenshots in no time. In fact, I’ve seen more than one group on MMORPGMAKER use screenshots as the evaluator of progress. Then sometime down the road, you’ll run into a wall where your world is of undocumented complexity or there is no clear consensus about a particular design point.

Having a design document to refer back to prevents this. Save the SCRUM for production. In fact, you will be practicing waterfall development where preproduction is the requirements/specification/design phases all rolled into one and production is the implementation phase. Learn to love it.

Don’t recruit your team until after preproduction – Remember what I said about members feeling that nothing is happening? During preproduction, there will be a phase where it seems this way. After the initial brainstorming phase, there comes a period when you have to flesh these ideas out and come up with a design document and perhaps some code design to do with it for the prototype. That modeler you recruited from deviant art on the second week? He won’t have anything playable to put his models into. That lore writer you found? At this point, she’ll either start rewriting your cannon or will get bored and go back to whatever forum you found her on. That programmer you found on sourceforge? Programmers have a habit of measuring their productivity by code written. This is especially so for undergrads looking for a project to burnish their resume with. Once you have a design document in hand, have chosen an engine and prototyped your main gameplay elements, your project will look much more attractive and will give a greater feeling of progress. It will be much easier to recruit and hold onto people.

Lastly, having a design document handy when recruiting allows you to recruit them into the vision. I can’t stress enough the need for all of the team to drink the kool aid; even if nobody else in the universe does. This allows your world to have direction and not turn into a herd of cats.