CHAPTER 12 ■ VIDEO GAMES
- A timer that ends the game after some amount of time – perhaps settable by the
player - A target score (the game ends when the player reaches a certain score – don't
forget to show the elapsed time) – perhaps settable by the player - A fixed number of targets (either total or for each row – the game ends when the
targets run out) – perhaps settable by the player - A fixed number of bullets (which makes the game a bit more of a thinking game,
since unaimed shots get punished) – perhaps settable by the player - Bullet or laser beam animation
A Note about Limitations
Larry Niven, a great science fiction author, in a collection of short stories entitled Limits, wrote that
“Often enough, it's the limits that make [emphasis in original] the story.”
That excellent observation very much applies to software development as well. No program can do
everything, so we have to choose what each program will and won't do. In addition to design
considerations, we often also have to battle performance and hardware constraints. For example, I am
currently working as a member of a team attempting to re-engineer content delivery for a major web site
(it's a household name and one that you'd recognize instantly). The site gets 80 million visits a month
(on average – during the holiday shopping season, that number goes up substantially). We have to
ensure that each page request (each click a user makes on the web site, in other words) gets a response
in less than two seconds. Otherwise, the user might take their business elsewhere, and our company
wouldn't make all the money it can. That two-second limit is a huge factor in every decision we make.
And we can't just throw hardware (more and bigger servers) at the problem, even though the company
makes computers, including extremely high-end web servers. At some point, we run out of address
space for servers (each computer on the Internet has to have a unique address, known as its IP address).
So there's yet another limitation.
So why tell you all this here? Because games, even more than software, rely on limitations. In a very
real sense, a game is a collection of limitations. Each rule in a game is a limitation, and a game is nothing
without its rules. If you could put a card wherever you want when you play solitaire, would it still be a
game? If you could shoot multiple times a second, wouldn't ShootingGallery be less challenging (and so
less fun)?
In that same essay (the introduction to Limits), Mr. Niven also states that “puzzles require [emphasis
in original] rules.” All games are puzzles. The player always asks, even if only subconsciously, “What is
the proper set of steps that I need to follow in order to beat this game?” Thus, all games require rules,
and all rules are limitations. As you design your own games, remember to make a set of limitations that
make the game fun. If the limitations are too many or too severe, they will make the game frustrating. If
the limitations are too few or too loose, the game is such a poor challenge that it's not worth playing.Game Design Resources
I anticipate that many of the people who read this book are doing so because they want to create their
own games. To that end, here's a short list of resources that I've found useful when thinking about
games and how to design good ones. Note that these resources apply to designing games in general, not
just computer games.