Before you can build a desk, you need to know what it’s supposed to look like. Before you can write an essay, you need to know what it’s about. Similarly, before you create a computer game you need to know what’s going in to it. This is where game design comes in to play; before you cut a single line of program code, you need to know why you’re doing it.
This is a huge topic, and I’ll be dealing with some of the aspects in more detail in future columns. This issue is only meant as a brief overview of some of what’s involved in designing the game.
A lot goes in to any well made computer game. In the now out of print book, The Art of Computer Game Design, Chris Crawford outlines some conceptual necessities:
[*]Choose a Goal and a Topic
[*]Research and Preparation
For now, let’s work with these, using our favourite game Diablo 2 as the sample space.
Goals and topics are not the same. In computer games, a goal is what you want the user to accomplish, while a topic is the environment in which you let them do it. The Fool’s Errand is one of the best puzzle games I’ve ever played. The goal is to solve almost a hundred puzzles, while the topic is a fantasy story set against tarot card lore. In Diablo 2, the goal is to murder monsters, zombies, demons, the undead, and eventually cows; the topics are the land of Sanctuary, medieval combat, and magic.
The goal and topic seem like obvious steps to take in game creation, but some games leave this step until the very end of creation. Indeed, their actual usefulness isn’t really evident until late in the game design stages. When you have a clearly defined goal and topic, you know precisely how the game should work; you can decide from there what features and ideas you want to include. When you get near the end of the design phase you will have to remove some really cool features, and a clearly defined goal and topic will make it much easier to decide what to cut.
Once you know what the game is about, you have to learn everything you can about your topic. If you’re setting a game in Camelot, read everything you can about Arthurian legends. If it’s a space combat game, study movement in space. I guarantee you’ll learn things you didn’t know, and you can use all of it in your game.
Take detailed notes on everything, no matter how trivial; it’s all potential game fodder. For the game my company is making, I personally researched hundreds of types of medieval armor and weaponry, for just this reason. Fullers are not blood channels.
In addition to studying, you should examine existing games that cover the same topic. Some very old games are really quite detailed, and have merely been forgotten in the high-graphics gaming world in which we now live. Look at how these other games handle the content; you might even get some ideas you can adapt for your own game. In a recent interview with, Bill Roper said “We?ve always believed that you can?t make great games unless you play games—probably incessantly.” He wasn’t just making this up.
Once you’ve learned everything you can about your topic, you get to start creating new material. You’re now designing the game itself, with the background research already completed. This is when your concept team sits down to decide what goes in the game, and whose ideas are total crack.
You filter through the research and ideas, and decide what to use or throw away. Then you start fleshing out anything you need to create. If you’re going to use a multi-tier magic system, you design it. If you’re going to use variable damage, you figure out the formulas. The folks at Blizzard North had to flesh out fifteen spell trees, dozens of creature types, create NPCs with which to interact, and figure out what special abilities some monsters should have, and some people think they still haven’t gotten it right.
Once you’ve decided what’s going in, you need to figure out what’s coming out. This is the I/O (Input/Output) Structure. The average computer communicates to a user in two distinct ways: images on the screen, and sound through the speakers. You need to make sure both of these are fully fleshed out.
It’s just not enough to know what will be in the game, you also need to know how it will all look and sound. You need to have conceptual art before even approaching a computer, and you need to know what type of music you want to hear, and what sound effects you’ll need. Take it from me, this isn’t as simple as I want to think it is.
Just as the game interacts with the user, the user needs to interact with the game. You need to decide which keystrokes will have what effect, whether to use mouselock, if you’ll include joystick support, etc. Also remember that the simpler the interface, the more likely people are to enjoy your game and continue to play. I don’t think Diablo 2 would have been so successful had you needed to learn fifty keystroke combinations, as opposed to two mouse buttons and a small number of hotkeys you can define yourself.
Game structure is how the game revolves around itself. Basically you pick a specific element of the game, and use that as the game’s focus. One aspect of the game will dictate how it’s designed and played. In Civilization, this aspect is movement: you move in to a city, and you occupy it. You move in to an enemy unit, and you attack it. The hard part is making sure you don’t neglect the other aspects of the game; after all, it’s not very good for a first person shooter to have masterful movement, but only one type of weapon.
Unfortunately, this isn’t as simple as it all sounds. It’s also not as linear as I’ve made it out to be. You will end up bouncing back and forth between these steps until the final day of game design, so don’t lose those reference materials; they’ll come in handy later.
Of course, once you’ve figured this all out you have to write it down somewhere. This collection of finalized ideas is called the Game Design Document, and will be the bible from which the programmers write their code. In a game like Everquest, it’s not unusual for the Design Document to be over five hundred pages. It’s all worth it in the long run, though, as having everything written out makes it easy for the programmers to write their code. I’ll cover their domain next time.
Disclaimer: Behind the Veil was written by Chris Marks and hosted by Diabloii.net. The opinions expressed in these columns are those of the author, and not necessarily those of Diii.net.