Level 4.0: Science of Design
Science of Design
How is a game designed? There are many methods.
Historically, the first design methodology was known as the waterfall method: first you design the entire game on paper, then you implement it (using programming in a video game, or creating the board and pieces for a non-digital game), then you test it to make sure the rules work properly, add some graphical polish to make it look nice, and then you ship it.
Waterfall is so named because, like water in a waterfall, you can only move in one direction. If you’re busy making the final art for the game and it occurs to you that one of the rules needs to change, too bad — the methodology does not include a way to go back to the design step once you are done.
At some point, someone figured out that it might be a good idea to at least have the option of going back and fixing things in earlier steps, and created what is sometimes known as the iterative approach. As with waterfall, you first design the game, then implement it, and then make sure it works. But after this you add an extra step of evaluating the game. Play it, decide what is good and what needs to change. And then, make a decision: are you done, or should you go back to the design step and make some changes? If you decide the game is good enough, then that is that. But if you identify some changes, you now go back to the design step, find ways to address the identified problems, implement those changes, and then evaluate again. Continue doing this until the game is ready.
If this sounds familiar, it is because this is more or less the Scientific Method Links to an external site.:
- Make an observation. (“My experience in playing/making games has shown me that certain types of mechanics are fun.”)
- Make a hypothesis. (“I think that this particular set of rules I am writing will make a fun game.”)
- Create an experiment to prove or disprove the hypothesis. (“Let’s organize a playtest of this game and see if it is fun or not.”)
- Perform the experiment. (“Let’s play!”)
- Interpret the results of the experiment, forming a new set of observations. Go back to the first step.
With non-digital (card and board) games, this process works fine, because it can be done quickly. With video games, there is still one problem: implementation (i.e. programming and debugging) is expensive and takes a long time. If it takes 18 months to code the game the first time and you only have two years, you will not get a lot of time to playtest and modify the game.
In general, the more times you iterate, the better your final game will be.
Therefore, any game design process should involve iterating (that is, going through an entire cycle of designing, implementing and evaluating) as much as possible, and anything you can do that lets you iterate faster will usually lead to a better game in the end. Because of this, video game designers will often prototype on paper first, and then only get the programmers involved when they are confident that the core rules are fun. We call this rapid prototyping.
