Author : Drew Sikora
Page : 1 Next >>
Part 3: The Document
by Drew Sikora
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?
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!
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.
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.
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.
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
– subtopic related to the main topic
- another subtopic related to the main topic
– 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:
2. Gameplay................................................8
2.1 Racing/Tracks..........................................8
2.2 Points and Scoring.....................................9
2.3 Cars...................................................9
2.4 Drivers...............................................11
2.4.1 Skills and Traits...............................11
2.4.2 Autonomous Mind.................................12
2.5 Weapons and Special Objects...........................12
2.6 Physics...............................................13
2.7 Play Modes............................................14
2.7.1 Tour............................................14
2.7.1.1 Stats/Rankings............................14
2.7.1.2 Money/Scoring.............................15
2.7.1.3 Upgrading/Damage..........................15
2.7.2 Rally...........................................16
2.7.2.1 Points....................................17
Page : 1 Next >>