What Do we Mean by "Design"?
There are two types of design we can talk about:Game design - designing the gameplay elements, what the players do, and what their experience is like
Software - two parts:
Requirements - Formal description of what the program will do
Design - Technical notes about the implementation details (in very low-level detail: function names, variable names, etc.)
This post focuses on the benefits of game design and software requirements, but not so much about the process itself. Much of this is written in response to IainPeregrine's Functional Specifications article. All quotes are from that article.
Iain's article proposes that programming without a design is like running a marathon without a finish line. He asks:
> How will you know when you're finished? How will everyone know when to get together, fill their glasses, and toast your success?
Is that really the problem?
I don't like the marathon metaphor because saying that you'll run a marathon defines the task. You want to run ~26 miles. You'll know you're done when you've run 26 miles. You might not have exact ways of measuring but you can use landmarks and your knowledge of how fast you run to estimate - but that's not the problem. The problem isn't that programmers need a finish line so they know when to stop. What happens if they don't stop and they run to Kansas, what's the programming equivalent of that? They added too many features to a game? The game is too polished?
The article also focuses a lot on what a design document is without explaining why they are helpful. I think it also misses the mark on why they're helpful.
> You need a functional spec, because it is your game.
My point exactly.
What Are We Designing?
When designing a game you know what the goal is (ex: make an RPG) and you might know some details (ex: it will be set in outer space), just like when you're running a marathon you know that you're going to run ~26 miles. The problem is that you don't know how to get there, how to make an RPG. There are lots of features your game could have, but which ones do you want it to have? Here is a better metaphor:Suppose you want to go to Wichita, Kansas. You go to google maps, search for "Wichita, KS", see where it is, then run out the door and hop in your car. You have identified your goal (Wichita) but you don't know how you're going to get there. You'll have a lot of options (roads you can turn onto), how do you know what turns to make? If you don't plan your route you might make a lot of wrong turns and waste a lot of time.
Planning a route is the equivalent of designing a program. You might have requirements for your trip to Wichita. You might want to stop in certain towns to see museums or eat at certain restaurants. Similarly you might have requirements for your space RPG: you want it to feature both ship-to-ship combat and crew-to-crew combat by boarding another ship. Design is a way to specify and formalize these requirements for the program.
How Does Design Help?
Design has one big purpose that manifests itself in two ways. The big purpose is that you don't want to waste time. The first way that design works to achieve this is by forcing you to make decisions and stick with them. Ideas are easier to work with when they're in your head or on paper - it's easy to change your mind. If you've already written code to implement a feature and you change your mind about how it should work, you might have to re-write a lot of code.Design also saves time because you can work through problems before encountering them. This is similar to the first point. You might think about two features for a while, decide on how you want them to work, implement them, and then realize that they conflict and you need to re-work them both. The design phase gives you a chance to see this problem and work on a solution so you don't waste time and have to throw away work.
Back to the Metaphor
The driving metaphor also handles these concepts. Suppose you're driving from Las Vegas to Wichita (link). You can take I-70 or I-40, they're about the same. You believe I-70 to be the more scenic route so you decide to take it. If you waited until you were driving to make that decision you might already be on your way to I-40 and need to turn around.Suppose that you decide to take I-70 and you also decide to stop in Lubbock, TX. If you're going to take I-70, Lubbock is ~700 miles out of the way. If you take I-40 it's only ~200 miles out of the way. If you make both of these decisions before you start driving you can see the potential problem and resolve it in a way that doesn't involve driving 500 more miles.
Back to Programming
There are two kinds of problems: big ones and little ones. The big problems are the ones you want to catch in the design phase, the little ones can be dealt with as they come up.> Now consider that a malicious user joins your game, double clicks one of your players, waits until it's his turn in battle, and then logs out. Now your regular player is stuck in battle unable to do anything.
This is a little problem. Implementing a solution won't require that you un-do existing work. This problem won't waste your time. A metaphorical note: a little problem would be finding a place to stop for lunch on your way to Wichita. The highway will have signs about local places to eat. You don't need to plan the stop in advance, you can look for a place when you get hungry.
You need to expect to deal with the little problems as they come up. There's no way to anticipate them all. You'll spend more time trying to anticipate little problems than you would spend dealing with them as they occur. Here's why:
> Once we take into consideration all input available to the player at every state in the program, then our programming job will be much easier, and we won't be sabotaging ourselves in the future.
Assuming the player can move in four directions and perform a single action, there are 510 = 9,765,625 different sequences of 10 actions that can be performed. Try verifying that none of those sequences lead to a problematic outcome! Think about how much harder this problem gets as we increase the complexity of the game. All we can do is hope for the best that the problems that result from the nearly-endless possible sequences of actions are all little problems, not big ones.
If this is coming from a fellow who's dabbled a bit in game design, that's a valid perspective, but something I'd regard differently than a fellow who's done professional software design for years.
It's the difference between, "sure, that's a good way of looking at it, but who's to say what's really odd about ideas of design" and "oh, well he's done this kind of thing a lot, and probably tried the alternative, so I guess he'd know what it takes."