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:
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.