To] A Primer for the Design Process,
Part 1: What to Do
The list of "Never":
The list of "Never" has evolved into a kind of Ten Commandments
for me. They've evolved over the years, usually noted and expanded upon
while playing games. They are things I've noticed, come to realize,
and things that are brought up in conversations with my peers. I've
also noted that some of these rules get repeated in game previews and
Like all good rules, however, they are ALWAYS made to be broken. And,
of course, you are allowed to break them. You just better make darn
sure you know what you're doing when you do break them.
Never overcomplicate a game if you can help it. Stated in the
obvious way it reads, "Keep It Simple, Stupid." Those of
us old enough to look back on what is considered the "classic"
era of video gaming remember it as being a time of very straight forward
gaming that could keep you glued to a monitor for hours. Games evolved
around a simple premise or method of controller input. Those games
were not limited by technology or the lack thereof, but were instead
solid concepts of experimentation. The KISS principle still holds
true today. Pac-Man had one joystick and one maze. Tetris had
a few simple shapes falling gently from the sky. Even Quake III
Arena follows the KISS ideal of not over-complicating the main
goal, which in this case happens to be blasting your opponent as many
times as you can till your hands fall off.
The context may change with player expectation or technology, but
the principle will always remain sound.
The arcade game designers from the good old days knew what they were
doing. The philosophy there was that they had 30 seconds to introduce
someone to a game and maintain that interest. People are willing to
drop 25 cents into a cabinet to see what it does. If they don't see
it immediately, they won't drop another 25 cents into the machine.
You have to grab them quickly. You do that by keeping it simple. The
next time you go to E3 or some such event, spend some time watching
not the game, but the people playing the game. See what's grabbing
their attention. Find the games that people won't put down then try
them yourself with an eye towards critical evaluation.
Never make the same mistake twice. Critical evaluation of your
competition means looking at what's been done and what's out there.
It means if you're doing a game in a similar genre, you should be
borrowing from the things that they do well, and avoiding the things
they don't do well. Don't re-invent the wheel unless you sincerely
have the time and wherewithal to come up with a better way.
3. Never take control from the player if you can help it. Don't
make the player sit through some animation, cut-scene, or musical
interlude if they don't have to. Metal Gear Solid did a great
job of using run-time transitions to keep you there and interested.
Valve's Half-Life was another excellent example of transitioning-taking
control from the player-but it didn't really feel like it. Revenant
by Cinimatix, on the other hand, is a frustrating example of waiting
for the developer's scripting engine to putter characters around the
screen while you mash the ESC key in frustration.
This rule also works for "in-game" events. A constant and
common failing of many fighting, action, or other titles where the
player is physically "fighting" an opponent happens when
the player gets "stuck" in a hit reaction loop. The animation
may have looked cool on the animator's screen, but while the hero
is writhing in pair from a vicious blow on the part of the attacker,
this same attacker has finished his animation and has initiated another
attack. (while the hero is still writhing) See where I'm going here?
The player ends up getting hit 3 or 4 times with no chance to defend
themselves. This is a very frustrating flaw.
4.Never forget the controller or I/O device you will be using to play
the game. Obvious problems are when PC games are converted to
consoles. It's hard to type from 16 different hot-keyed actions with
a Playstation controller. You've figured out what your character will
be doing in the game, at the same time you should have figured out
how the player is going to maneuver the character through your world.
This applies to navigating inventory screens and complex selection
schemes as well. You should always defer to the KISS philosophy here
unless you absolutely can't help it.
5. Never assume the player knows what you're thinking. Players
are usually bright people who can intuit a pre-existing puzzle or
situation rather quickly. Because of this, designers must think of
ways to challenge the player. Sometimes, we will challenge the player
by presenting to them something that makes sense to us while we were
working on it, and make sense to QA while they were testing it, but
doesn't translate for a player who hasn't spent the last 9 months
of their life working on the game.
Soul Reaver is a good example of maintaining this rule AND
breaking it at the same time. The tutorial portion of the game was
an excellent introduction to the game's world. At several points,
however, the game would tell you do something without any explanation.
Case in point: Directions were given in the form of a compass point
(go North, young man. . .) yet there is no compass in the game so,
just how am I supposed to know which way is North? Sound's easy, but
I lost 4 hours backtracking to figure this one out.
6. Never break the established rules unless you TELL the player.
There are a number of games out there that will teach the player certain
habits by NOT letting them manipulate their environment. That's OK,
but if at a later date you decide to allow the player to use these
objects in a way that's different from previous lessons, TELL THEM!
Metal Gear Solid was good about this. The game gives
you the information you need to accomplish your goal. It begs a little
suspension of belief when this happens, but it's far better that fumbling
around for several hours trying to unlearn something you've been doing
the entire game to this point. Withholding information from the player
should not be the extent of the puzzle. There's also the parallel
argument here about making your puzzles somewhat dependent on existing
logic. Return to Zork was a prime example of logic having nothing
to do with solving the puzzle and the players lost interest for that
7. Never assume technology can fix bad design. This is a BIG rule
that this industry is guilty of breaking repeatedly in the last few
years. We see a number of titles every year that claim to make certain
technological feats, usually in terms of pushing poly's or having
"the most realistic AI ever encountered!" You're answer
to marketing ploy's like this should be, "So, is it fun?"
Real-Time Lighting! If the game's not fun, no one is going to want
to play it.
There are cases where technology can ease bad design. Pushing more
poly's, thus raising the frame rate and smoothing out your visuals,
is a good thing. Some technologies, however, don't or won't filter
through to the average end-user. They generally don't know about or
care about technical specs, they just want to know if the game is
An example here is the PC product Nocturne by Terminal Reality.
The game has great "real-time lighting and shadows" FX that
lead to some truly creepy moments in the game, but anytime more than
two creature jumped on screen, the frame rate would bog to amazingly
bad rates, making combat near unplayable at certain points. Very frustrating.
8. Never assume the license is all you need. No association in
the world will help you sell an inferior product. There are some exceptions
to the rule but as above, players want to know if the game is fun.
9. Never cheat the player. The basic rule here is that if the
player can't do it, the CPU shouldn't be able to do it. It's AMAZINGLY
easy for a programmer to set up the AI to be perfect but it's a lot
harder to get that AI to act like a human would. The hand's-down winner
of cool creature AI would be Unreal because they do human player-type
things to get on you.
10. Never design morality. If players find a way to circumvent
a "feature" of your game by utilizing the save feature,
let them. You see this kind of problem in RPG's like Baldur's Gate
or Jagged Alliance II. I myself was guilty about sending guys
blindly into the fray just to see where the bad guys were coming from,
then re-loading the game and planning accordingly. Don't penalize
the player for re-loading a failed attempt at a room or hurdle. A
specific example of creaming the player in this manner would be the
expansion pack to Baldur's Gate-Tales of the Sword Coast. They
had a feature that, if you re-loaded a previously saved game, they
would throw MORE monsters at you or make some sprung trap hit you
even harder. This, quite simply, sucks. It's also a poor excuse for
problem solving. If the player wants to save his game, walk into a
room to see what jumps out, the re-load and re-configure his characters,
let him. So what? We don't design morality. If the player wants to
"cheat" let them but if you can come up with a solution
that DOESN'T screw the player, even better.
installment of this series (Need) will deal with some of the things
that you, as a designer, should have available to you within your development
environment. Did I happen to mention time . . ? There's also a small
section at the end called 'Expect.' This is more of a personal bit about
how I see the intrinsic philosophy of game-making and how it relates
(and rules) my life.
Huntsman has been with Acclaim Studios, SLC for over 4 years and is
the Lead Designer for Acclaim's next-gen wrestling title. He has worked
on the ECW wrestling franchise as well as the genre-defining WWF
Attitude for PSX and N64, projects that taught him more about professional
wrestling than he ever thought he'd know. When not working on games
and their design, he's playing guitar in experimental projects, writing
various forms of fiction, painting in the Sumi-E style, and fencing
(with swords, not wooden planks.) Questions, comments, atta-boy's, or
derisive snorts of laughter should be sent to email@example.com
Tim's always looking to learn from his peers.
this article in Gamasutra's discussion
[Back To] Asking Even More Questions