Author : Drew Sikora
Page : << Previous 2
2.7.2.2 Place.....................................17
2.7.2.3 Destruction...............................17
2.7.2.4 Time......................................17
2.7.3 Multiplay.......................................18
2.7.4 Difficulty Settings.............................18
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:
2. Gameplay
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.
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.
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.
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...
Gaiiden@hotmail.com
Creating a Great Design Document, Tvzi Freeman
Design Document Tips, Usenet compilation
Tom Sloper's Format for Game Design Specs, Tom Sloper
Page : << Previous 2