[B]Don’t Start Vast Projects with Half-Vast Ideas[/B]
Aren’t the old adages always the ones you learn to respect? “Measure twice, cut once.” “Look both ways before crossing the street.” “Don’t stick a fork in the light socket.”
Nowhere is the first one more applicable than in computer game design. Well, maybe in construction, but that’s beyond the scope of this column. Since it takes a complete team to create a computer game, including people with a variety of skills, everyone’s input is required to finish the Design Documents.
“But wait,” I hear you cry, “didn’t you say concept and coding should be kept separate?” Yes, they absolutely should. Concept creates the Game Design Document, but because they’re so generous they show it to everyone else before finalizing it.
As much as we would like to think the concept team just makes the document and spits it out for the coders to deal with, it’s not quite that simple. It’s basically a five step process to create any Design Document, and each step has its own little nuances. Let’s break it down:
[B]Initial Creation:[/B] This is where the concept design team sits down and hammers out the first draft of the document. A completely formed document, as I said in column 4, could be a few hundred pages long; it’s no small task. Don’t be surprised if you end up having fifteen people on the concept crew by the end of it, because getting everything created and written down on time is an awful lot of work.
This is also, in my humble opinion, the most enjoyable part of the design process. I’ve heard some pretty off-the-wall suggestions in these meetings, and I’ve made some myself. The length of time and the manpower required for this step will vary based on what type of game you’re making, but don’t be surprised if this process takes over a year for a massive-sized game.
[B]First Review:[/B] Remember those six people you singled out in the Sell Document? This is where they get to shine. After you have what you think is a completely finished Design Document, you call these people your friends and share it with them. Photocopy or print six copies, and distribute them to the project manager and department heads.
They will all read the document, and make comments on it. If you don’t have anything in your document that relates to one of your heads, then you’re not finished with it yet and need to keep working on it.
You should expect each copy of this document to come back covered in red marker. The readers will find things that just can’t be done, things they’d rather see done a different way, come up with suggestions for new content that the concept team hadn’t thought of, and colour in the letters. This all leads up to what’s probably the least enjoyable part of the design process:
[B]Rewrite: [/B]You’ve spread the word, and the word came back to you, and you’ve never seen it so messy. At this point you’ve got six different copies of the Design Document, with six different sets of comments, suggestions, and criticisms. Now you need to sift through all of these, and recreate the document with the other heads’ notes in mind.
Believe me, this is no small task. Here’s an exercise for you: Write a one page essay about something; about anything. Now give six copies of it to six friends, and ask them to make comments and suggestions about the writing style and content you used. When you have them all back, try to edit your essay to conform to all of their suggestions. Now imagine doing this for a 300 page document.
There’s really not much I can say here, other than to be patient; it will probably take more than a month to go through this phase of the document creation process. It will also benefit you to invite each head to a meeting for the sole purpose of going over their specific comments. This will be your chance to ask them questions, discuss their ideas, and hit them with wiffle bats.
[B]Second Review: [/B]After you’ve rewritten your Design Document, and you think it’s finished, you make six more copies of it and spread them around again. Despite having already received and incorporated their input, your document’s not actually finished yet. There will undoubtedly be some things they missed, or some new issues caused by your rewrite.
Don’t get discouraged by this; instead, treat it as what it is: a sign that you’re doing something right. It’s far better to catch issues and mistakes now than it is to find out about them six months in to programming. This is why steps 3 and 4 are repeated as often as necessary until all six copies come back in the same condition they left in.
One good thing about the second review, and all subsequent reviews, is that they aren’t as productive as the previous ones. Since you’ve already dealt with many of the issues they have, there shouldn’t be many left to find, which also means subsequent rewrites will take less time. If you did the first rewrite properly, you’ll actually have no new notes, and be able to go straight to the next and last step:
[B]Final Polish:[/B] This is the final rewrite of the Design Document. All the notes have been made and dealt with, and all the coffee’s been devoured. This is when you take a final look at the document and correct any speeling or mistakes grammer, to make sure it looks professional.
This is the version of the Design Document that your coders, musicians, artists and administrators actually use to create the game. It’s done, it’s been shipped off, and if all goes well you’ll never have to look at it again.
And that’s a brief summary of a process that could easily span a chapter or more in a comprehensive book. You should also realize that both the Game Design Document and the Technical Design Document need to go through this process, for exactly the same reasons. Now, I’ll go a little bit more in-depth on the Design Document Reviews (DDRs), to give you a slightly better understanding of what’s involved in them.
As you’ve probably already gathered, this whole process is really a sanity check. Each person on the DDR team is there to make sure you’re not trying to do anything that’s unreasonable. Additionally, they bring perspectives to the document that the concept team just doesn’t have. Since the concept team is very close to the initial document, they’ll be more reluctant to notice flaws and holes in it; it’s just human nature.
It’s quite likely that you’ll have more than six copies of each draft going around. In addition to the ones you’re already printing, you’ll probably want to give copies to another programmer who’s not actually working on this particular game, programmers who are working on the individual parts of the game (client, server, database access, etc), someone from Marketing and/or Press Relations if the company’s progressed that far already, various Tech Support people and Player/Community Relations people, and one or two other managers. If you don’t have a publisher lined up, you’ll probably want to contract someone with experience in such things to help you out as well, as they’ll undoubtedly spot things that everyone else on the DDR team missed.
After the DDR team has done their dirty-work, and before sitting concept down to work on the document, you’ll want to have some all-day meetings between concept and the DDR team. This gives everyone a chance to air their opinions for all to hear. Be warned: THESE MEETINGS WILL GET HEATED. People will have different ideas of what the best way to solve a problem is, and some solutions may cause other problems you only catch in this sort of meeting. At this point, everyone at the table thinks of the game as their own, and they will treat it as such; nobody likes having flaws pointed out.
These review sessions are also where you’ll start to get an idea of what features need to be cut. Odds are there are too many cool features in the Design Document for the game to be released on time or on budget, and some of them will need to be trimmed. It’s truly amazing how “feature creep” can take over a project. This is why, as Behind the Veil continues, I will keep telling you to prioritize your features. If something needs to be cut due to time or budget constraints, it comes straight from the bottom of the list. Like Bill Roper said a month ago, don’t cling to the document when something just doesn’t fit.
This is a phase of development that you really don’t want to rush. Developers want to get to developing, coders want to get to coding, and artists want to get to …arting. Despite everyone’s enthusiasm, the document needs to be gone over line by line to make sure all comments are taken in to account. As I said above, if you get this right, then your second review will return no comments and you’ll be able to put the final polish on immediately. A little time now will save a lot later, as tends to be the case in most things.
One more thing I must say: Make sure you print the document out – don’t just give them a file on a floppy disk. This is for the same reason that you send important letters by mail and not email; an email can be ignored, but a letter is a physical ‘thing’ that must be opened and dealt with. Similarly, a floppy disk can be set aside and forgotten, but a printed 300 page document is much more difficult to ignore.
In addition, it’s much easier to make notes on a paper copy of the document than on a digital copy. It’s also much easier to read notes made on paper copies, as you don’t have to go hunting through them counting lines on pages; you can just look at where the comment is. Yes, this kills trees, and yes, this will cost a fair amount of money for the electricity, toner and paper. Just trust me on this, it is worth the expense.
So now we’ve gone over what’s involved in creating the Design Documents, but what about their contents? In installments 4 and 5 of this column I gave brief overviews of the kinds of things you should be looking to include, but I didn’t really give you any specifics. Over the next several issues, I’ll be discussing some of the items you’ll want to consider when creating the Game Design Document, and I’ll get to the Technical Design Document some time after that.
[B]Disclaimer:[/B] Behind the Veil was written by Chris Marks and hosted by Diabloii.net. The opinions expressed in these columns are those of the author, and not necessarily those of Diii.net.