A few months ago, my eight-year old goddaughter came to me asking if I would teach her how to make video games. She didn’t know C++, of course, nor were her Maya skills quite up to snuff yet, so I thought about it a bit and decided to approach the question from another angle.
Namely, what are the first steps of game design?
In “The Industry” (which outside of L.A. is more likely to mean the video game industry than the movie or porn industry) designers talk sometimes about “paper design”. In the same way that paper prototyping can be used by user interface and usability designers to probe the benefits and pitfalls of the human-to-computer interface, paper design can ferret out issues long before the expensive expenditures in software architecture and data entry need to be spent.
Computer science uses the term algorithm, meaning a step-by-step procedure, distinct from the actual code that processes said algorithm, in the same fashion, determining the logical process by which one gets from input to output.
The same thing happens in design:
There are inputs (player strategic decisions like character class, tactical decisions like which direction to execute a roll or what power to use, environmental determinations like random chances for debris to fall from a ceiling) and outputs (how much damage the mob takes from a player-initiated attack, or the visual effects that play when the debris falls from the ceiling).
Computers are amazing machines capable of incredibly fast calculations, and there are some game designs that work really, really well on a computer that in the absence of a human computer well, just plain suck. Conversely, there are designs that are damn fun without a computer (roleplaying games with, well, actual roleplaying) that are really hard to get right in an online environment.
That being said, there’s a lot of crossover, and more often than not, if a basic idea works well without a computer, it will usually work pretty well with a computer.
Traditionally, “paper design” refers to the design version of making an algorithm; as a designer, you put together the possible inputs, the basic rules to process those inputs, and the possible outputs arising out of all possible combinations of inputs + rules. In video game development, it’s most common to jump from paper design to prototyping, where you build a basic form of mechanic, system, or game on whatever game engine you are using to see how it feels.
This is, I think, actually kind of a shame, and I think it skips an important step that – for some kinds of designs, albeit not all – can be incredibly useful in fleshing out a design. Germanely to this article, it’s also a fantastic way of developing the skills of a designer.
Board and card game designers are very familiar with this process, as for them, such a “papered” prototype is a true prototype for a board or card game, but this process can also be used with an eye for many types of video game design (though, I should note, probably not all – it could work really well for character generation, level flows, trading systems, metagames like Vanguard‘s diplomacy system or Star Trek Online‘s duty officer system, but probably less well for things like Marvel Heroes combat or achievement systems).
So back to the question that started all of this – how to teach someone how to design a video game?
My answer? Chess. But without the rules.
- Pick up a chess board, dump out the pieces, lay out the board.
- Now, make a new game using at least some of the pieces. Spend twenty minutes or so and make some rules (I trust you – it’ll be brilliant, really).
- Dragoon someone into playing the new Not-Chess Game.
- Step away alone now, and spend another twenty minutes or whatever you want to dedicate to the exercise to rework the rules, learning what you did from playing with whatever poor sucker, er, friend, you convinced to play opposite to you.
- Play again.
Interesting, no? But we’re not even close to done yet.
Now that you’ve made one game with chess pieces…make a completely different game, still using those chess pieces. If you really want to maximize the effects of the exercise, let a day or so pass and try it again.
If you have the stubbornness and perseverance to be good at game design as a career, you’ll still be game – pun intended, of course – for more. The next step is to take chess and something else – maybe a standard pack of cards, or the pieces out of a Settlers of Catan game, or even something that isn’t even a game at all, like a pile of DVD cases – and make yet another game – or games.
When I was at Cryptic Studios, one of the high-level exercises that the Chief Creative Officer would have senior designers engage in was to come up with ten different solutions to whatever problem was at hand that day.
Why ten? Simple. The first solution will be obvious. The second and third, probably as well. The fourth is going to be getting desperate, and by the time you hit Idea #7 and #8 you’re going to seriously be going oddball just to come up with something different.
Most of these ideas are going to be dead on arrival for a lot of reasons, some technical, some philosophical, some for other reasons. Some, however, won’t, and this kind of exercise can generate some truly out of the box ideas. Now, you usually won’t use any of the ideas, particularly the later ones, as-is, but you can often hybridize two or three of the ideas, or graft on a part of an unconventional idea onto a conventional approach to give it a new spin, and that’s where things get really interesting.
So what about my goddaughter? She was, I think, more enamored of the idea of making games than quite yet prepared to actually sit down and make them, and I am not the kind of person to push someone before they’re ready, so when she lost interest and asked if she could play Marvel Heroes on my computer (true story) I didn’t fight it.
I’m still waiting for her to come back in a year or so and ask the question again, and this time I have a whole bunch of new ideas ready to suggest to her…