[size="5"]Recap

In the last article, we discussed a wide range of topics in order for you to weed out any malicious bugs in your game before they grew jaws and began to bite. Hopefully we extracted them all, realistically, we didn't come close. Oh well - we tried. However it was time not wasted, because defeating them is just like defeating cancer - you have to treat them in their early stages. Fortunately, most of the obvious and most important ones were covered and hopefully squashed underfoot. Of course, come development, new ones will always crop up in the most unlikely places but - we'll hold off those gloomy thoughts till part four hmm?

In this installment, we will discuss the Design Spec and the Pitch. Both are needed in order to get things rolling along. The Design Spec is the long, detailed, technical document that you use to guide you through development. The Pitch (as I like to call it) is a shortened version (very short for those poor, poor management people on the receiving end) of the Design Spec that you present to publishers and (if you're a freelance designer) developers alike. Since I have no example game to give you, we'll instead construct a simple template and set of guidelines to get you started.

Shall we?


[size="5"]Why Do We Need A Design Spec?

A good question. Back in the days of old, it took about three people to make a game at the very most - artist, designer, and programmer. Usually though all these were rolled into one person. Since games were relatively simple and didn't have too much depth (again, relatively) and since the designer didn't really have to worry about anyone but himself in most cases, wasting time on a design spec was, well, a waste of time.

Today, however, the one-man development team has grown considerably. Now it takes well over a few dozen people to get the job done right. This means that the designer has to have a way to communicate to the rest of the team what he wants the game to be like. Enter the Design Spec to a raging applause. Unless you, the designer, want to be on call 24/7 with a phone built into your ear so you can answer any questions, or hold meetings everyday explaining what the next step is, then you need a design spec. There's just no two ways about it. Without a good design spec, team members won't know what to do. Then they'll waste development time doing one of two things:

• Hunting you down and asking you: how you want this feature implemented? How you want this to look? Where you want this feature included? Why did we drop this idea? Tell me, could that get annoying? Yes!
• Even worse, the programmer, artist, whatever, might just say "heck with it" and fill in the gaps with what he thinks should go there. You, however, have a different idea. So when it comes time to inspect the game progress, you find these features that clash horribly. Now time is wasted going in and cleaning up the mess.

So there are two things to remember here. One is that you need a design spec. Two is that you need a good design spec. First I'll talk about making the design spec (structure) then I'll discuss how to make it a good design spec. Onward!


[size="5"]The Pitch

This will be your first move out of the design phase. Mission number one is to construct a nice, flashy presentation to show to your prospective clients. Depending on your role as a designer, these clients can be either a developer and a publisher, or just a publisher. Either way, they'll be expecting a good show in order to convince them that the game you want to make is going to be The Next Best Thing. It's your job to give it to them.

The Pitch is a short, short, short version of your design spec. The idea is to focus on the features that will make the game unique in the upcoming market. If you're wondering why I said upcoming market, then you haven't read well enough! Go back to part two. If you understand, then you can see why a publisher would not be interested in things that could be outdated when the game is released. The Pitch should not delve into technicalities, but just skim the surface. Remember whom you're dealing with - managers and directors who don't have the need to get their hands dirty. If you start providing them with information they will never use nor care about (or even understand), the value of your presentation will quickly degrade in their eyes.

The Pitch is where you get to have fun designing colorful charts and graphs - even a PowerPoint presentation if you like. You have to get your message across in a very short amount of time, since a lot of people don't like to sit around at meetings and listen, and listen, and listen some more until they are ready to fall out of their chairs with boredom. You have a small window in the beginning with which you will have their optimum attention. If you do not manage to capture their interest within this window, it will get harder and harder as the presentation drags on. It's nothing but common fact that most people, try as they might, do not have long attention spans.


[size="5"]Priming the Pages

It's show time. The publisher has agreed to fund your project by providing you the money you need to pay your staff and equipment and get the job done. Now it's time to turn to...(drum roll, please) the Design Spec! (Cymbal crash). Of course, this should already be completed so you can jump right in to development, but we'll assume in this case that it's not, and we have to write it - quick! So let's get the basics down.

You don't need anything fancy to write a design spec - a simple word processor will do. Now, the first step is to gather together all the information that you have written down, drawn, whatever. The pile of paper in from of you will magically coalesce into a single, neat stack of paper that we will call the design spec. Oooooh. Now we can really begin. Please note that the topics discussed from here on are my own personal opinions. This is the way I structure my own design specs. If you do not wish to follow my examples exactly (which you are welcome to do) then hopefully they will give you ideas on how to do it your own way.


[size="5"]First Things First - The Title Page

Nothing too complex, all you need are a few things on the title page to start you off:

• Name of the game (or code name)
• Company name
• Your name if you prefer (why not?) as Lead Designer
• Date
• Copyright information or something that denotes it as the property of the company
• Version number

Try not to clutter up the page with all this information. Prioritize. The name of the game, of course, should be in nice big, bold letters smack dab in the center. But make sure you space everything else out so that it looks neat and professional.


[size="5"]The Table of Contents

Time to brainstorm. Start by going through all your ideas, features, and whatnot and start getting a general idea of where each thing belongs. Make up broad sections such as Gameplay, Control, Graphics, Internet, etc. Group all the items together into those categories. Now go through each category and start to break it down into more and more individual features and ideas. For example, the Control category would have subsidiaries of Joystick, Keyboard, etc. Keep going until you have everything written down.

Next you need a way to identify all the related parts while thumbing through the spec. The most popular way to do this (and the way I use myself) is a numbering system that uses periods to separate each delineation. Here's what it looks like and how it works:

1. - the main topic

1. - subtopic related to the main topic
2. - another subtopic related to the main topic
   1. - a subtopic of the above subtopic

2. - a whole new topic

Get the gist of it? I'm sure many of you have used it before, and since my explanation of it is rather pathetic, I have an example for you. Here is an excerpt from the table of contents from a game I'm designing called Traction Control:
Here I used a monospaced font in order to get the number to line up on the right. Sue me; I don't know how to use Word TOCs ok? J Notice the way I separate each subsection and new topic. The main topics are in bold and each subtopic alternates between regular and italic text. In the actual body, I use varying types of listings to help point out certain subsections. For example:

[size="4"] 2. Gameplay

[size="2"] 2.7 Play Modes

2.7.1 Tour

2.7.1.1 Stats/Rankings

Of course, you are free to use any means necessary, this just happens to work for me.


[size="5"]Filling In the Blanks

Now comes the hard part where you actually have to work. As I said earlier, your design spec has to be good. In this sense, good means detailed. A detailed design spec is the only way to go. If you do not detail enough, you will encounter at least one of the scenarios I mentioned earlier. Both will extend development time. I really can't give you any advice on how best to detail your design spec. The most important thing to remember is that as you are writing about each individual topic (as outlined in your table of contents) be sure to keep an open mind. Check back every now and then to make sure what you are saying does not go against anything you stated earlier. This is a great way to confuse your team and have them show up at your door asking you questions.

Make sure that you think up everything that may pass through the minds of your team members. This is where it is a plus to have a handle on coding, art techniques, etc. If you can detail enough information so that the artist, programmer, etc can at least safely derive what you want, then you are on the right track.


[size="5"]Designers Notes

Now here's the kicker. You create a unit that uses silver resources to build, but not gold. This is because the gold is first spent in the Smyth shop when his weapons are forged. So you list the unit with the rest as requiring no gold to construct. Now, later on you are overseeing the unit development and a programmer asks why this unit doesn't have a gold cost when the rest in its class do. You can't remember any reason for not assigning a gold cost, so you okay the change. Months later, during play testing, you find that the unit is never used. You ask the play testers why they don't use the unit and they respond that it is too expensive in comparison to the others. You are confused, why is it more expensive than the others? Then you smack your head, remembering that you have to spend gold to forge the swords, so you are effectively doubling the cost of the unit. Doh!

How could this scenario have been avoided? Well, a good memory would definitely have helped, but we all can't admit to that. This is where the designer's notes come into play. While the design spec should be detailed, it's not really necessary to tell programmers why, but how. The same applies for the other members of the team. They don't need to question why the game designer included this feature, but how best to implement it. That's the purpose of the design spec - it tells the team how to implement items and features. The designer's notes, however, is like the backdrop to the design spec. Your designers notes don't need to be neat and organized - they can consist of scraps on which you wrote your ideas, napkin drawings, anything that explains the why of the feature or item. Keep these all together so that if you ever come up against a question posed by the team about why or why not, you can flip through them and come up with an answer.


[size="5"]Conclusion

Well, there isn't much more I can tell you without either repeating myself or other people. I tried to give you a general idea of what you need rather than plunge into detail, mostly because others have done that for me already. Below is a list of links (mainly on this site) that I would suggest as further reading on the subject of designing game specs. In part four we will discuss the way of development, as well as how to use the design spec every step of the way.

Questions? Comments? That's what email's for...

[email="drew@gamedev.net"]drew@gamedev.net[/email]

Creating a Great Design Document, Tvzi Freeman

Design Document Tips, Usenet compilation

Tom Sloper's Format for Game Design Specs, Tom Sloper