Enemies. Monsters. Sprites. AIs. NPCs. Creatures. Villains. What are they? More specifically, in computer games what are they? Hurdles that must be overcome in order to reach the exit to the level? Simulated opponents that try to kill the player or stop his progress? Beautifully rendered characters with interesting attack, fidget and death animations? Collections of stats?
All of the above, I suppose, but one of my pet peeves is that many game designers seem to have forgotten (or never learned) how to make interesting and distinctly different enemies. If a game has a line-up of creatures that look awesome but simply represent an ever-ascending set of numbers in several character attribute fields, then chances are that game will get boring quickly. At the very least, it will not be as exciting as it could have been, had the designer planned out the creature’s role in the game at an abstract level.
As with weapon differentiation, if each enemy has a particular function in the game world (and that function is obvious and/or something the player can learn about over time through observation), then the player can decide how to deal with each enemy. That enemy characteristic then becomes part of the game’s dynamics. Alternatively, if all enemies do basic variations of the same thing (such as race forward and inflict damage on the player), the player is apt to grow bored. The key, therefore, is to design game units that will make the game more interesting.
Case Study of Enemy Units: Defender
Let’s look at Williams Electronics classic arcade game, Defender, and examine three of the units in this game: the lander, the mutant and the bomber. By examining the ways in which these three units differ within the game’s framework of actions and mechanics, you can see some of the ingredients necessary for intriguing enemy behavior.
- The lander flew slowly and occasionally fired a shot at the player. Given the chance, the lander would descend to the surface below to pick up one of the humanoids that the player was supposed to be protecting. When a lander grabbed a humanoid, it would rise toward the upper levels of the atmosphere, suddenly firing like mad; when it reached the top of the screen, the humanoid was destroyed and the lander would become a mutant.
- The mutant was faster than the lander and much more aggressive – it always made a headlong attack when it spotted the player. The mutant also had an erratic flight pattern, making it’s movements less predictable and harder to evade.
- The bomber was slow and peaceful for the most part, but it left a trail of bombs that hung in space; if the player contacted one of the bombs, his ship was destroyed.
Discounting their appearances and fictional identities completely, think about how different these three units are. The behavioral attributes of three units that concern the player essentially are “movement rate”, “flight type”, “aggression level” and “special ability”. The “special abilities” (an arbitrary term) for these units were consume humanoids then change unit types (the lander), pursue the player aggressively (the mutant) and leave a trail of explosives (the bomber).
(Note: The lander’s ability to consume resources – the humanoids – is brilliant. The gameplay is made dynamic because the lander changes from a relatively weak enemy to really critical enemy as soon as it picks up a humanoid. The player must immediately switch gears and deal with the threat of the lander becoming a mutant, or suffer the consequences.)
In many games (old and new), the enemy design is nowhere near as interesting or distinct as in Defender. For example, in a certain game Creature One can move at a game speed of 50, does 37 points of damage in an attack and has 100 hit points, while Creature Two can move at a game speed of 75, does 12 points of damage in an attack and has 30 hit points. In some games, this is the extent of the enemy differentiation. The problem is that this sort of design does not cause the player to dynamically adjust his play. It does not force the player to make critical decisions about how to react to a game enemy; the reaction is generally always the same, since the enemies are fundamentally the same.
The Three Goals of the Game Designer
Game designers should:
- Present the player with a series of distinct and challenging situations.
- Give the player enough information so that he/she can decide how to react.
- Provide the player with a set of in-game actions that will allow him/her to execute their decisions, and provide appropriate consequences to those actions.
To illustrate these points, I’ll create an fictitious game enemy. Let’s make this enemy more relevant to modern game developers than my previous example, Defender, lest someone cry, “Games have changed; the old rules do not apply!” For this example the enemy will be a crocodile, and the setting will be a 3D world – an environment in which the player can run and swim. This is fairly standard stuff, and an area in which designers routinely short-change players by not making things interesting enough.
In designing this crocodile, one could just make it a big green lizard with lots of hit points, an appropriate movement speed and a large set of jaws that do damage to the player. To do so would not be horrible – after all, this creature would be somewhat different from the game’s other enemies simply because it is capable of chasing the player through water. (See Tomb Raider for examples – its crocodiles, bears, raptors and wolves.) But if this is the extent to which our example crocodile is unique, it is then essentially the same as a bear with a few different stats and the ability to swim. We can do better if we add just a few interesting and unique attributes. So our crocodile will have three more features.
First, let’s assume our player’s in-game character can hold his breath for a specific period. We’ll then say that when our crocodile succeeds in biting the character in the water, the player loses some of his precious “breath” (and of course when the player reaches zero, he drowns). Suddenly the player must rethink his strategies related to how long he can swim underwater, what distances he can reach, whether he needs to dispatch or distract enemies on land before entering the water, and so on. If the player did a great deal of swimming in the game before meeting his first crocodile (on previous levels for example, as he encountered water features such as current flows and other aquatic creatures such as small fish), he will now have to adjust the way he plays because the introduction of the crocodile has changed the game. Imparting our crocodile with this one attribute has made the game a dynamic experience.
Second, our crocodile, due to its tough leathery skin, is immune to the tranquilizer dart gun in our game that the player uses. With this aspect of the game introduced, the player cannot just shoot his way out of the encounter. Instead, he must react to the situation and make a decision (if only to switch weapons when fighting crocodiles).
Finally, let’s make our crocodile move fast in the water and on dry land (like a real crocodile), but let’s give him a really slow turning rate when on the land. This way, he will only be able to move fast in a straight line when chasing after the player on dry land. If the player zigzags as he runs, he can easily elude the crocodile.
So now the crocodile is different from the other enemies in the game in a number of recognizable ways. It is not just faster, tougher and more lethal – it also has some special attributes which will make it more interesting to encounter. The really good game designers have employed this philosophy for years, completely at odds with the “boss monster”style of enemy progression used in many games. This approach to design asks the question, “What does each unit represent on an abstract level?” It makes the game more interesting, because the player must decide and then react. It grants the game interesting dynamics, instead of creating tedious gameplay.
Also note that if the player never knows about any of the distinct enemy functions you generate, he will never get any enjoyment from them. Let’s see what kinds of feedback mechanisms we could employ in the crocodile example.
First, to give the player feedback about the crocodile’s tranquilizer dart immunity, the game could play a different “got hit” sound effect when the dart hits the crocodile; instead of a nice sticking sound (made when the dart “works” on a given creature), the game could make the dart “pa-ting!” and ricochet noise.
To inform the player of the crocodile’s interesting land movement features before the player actually encounters any crocodiles, the game designer could drop one or two of these creatures down on the beach, and allow the player to watch the crocodiles chase some small innocuous game creatures from a safe distance. The creatures that run from the crocodiles in straight lines always get eaten; the creatures that run in a zigzag pattern always escape. By affording the player time to study the crocodiles before encountering them, the player could learn something about consistent crocodile behavior as it is within the framework of the game. (Clearly, this sort of solution does not work if the game is nothing but a series of monster-filled rooms. Showing the next obstacle before the player actually has to deal with it can produce a much more interesting gameplay pace; the player has more information on which to base his actions.)
The “loss of breath” attack that the crocodile has against the player when fighting in the water is less complicated to communicate: it could be made obvious by subtracting a breath increment each time the crocodile bites, and the game could trigger a player gurgling sound.
Reverse Engineering Enemy Characters
An equally valid approach to designing game enemies – perhaps more valid – is to decide what function an enemy will provide within the game before you decide what the creature actually is. For instance, rather than asking, “How can we make our crocodile unique and interesting in terms of game mechanics?” you instead ask, “What do we want Enemy X to do or represent in the game?” In the latter practice, you would come up with an idea that you think would be interesting in your game, then retrofit the type of enemy to that idea.
For example, think about Quake 2’s “medic” enemy; its primary purpose is to heal wounded monsters. This was not executed particularly well since most players never had a chance to realize what was going on, and the guys at id, for some reason, did not focus this unit down to its essence. (Sadly, this creature is interpreted by many player as just another big beast with lots of hit points.) However, as a concept, the medic is quite cool. It works well as an example of how you might first decide what role a unit plays in the game, like “autonomously heal other enemy units so that they might live to antagonize the player anew,” then come up with an identity and a look for that unit. (Note: I have no idea which design phase came first in this case, abstract function or fictional/artistic identity.)
When you take this more abstract approach, it becomes obvious why so many games are set in “dark-magic land” or “alien dimension x”. If you are completely free to create the unit’s function first, you end up with some wild behaviors and actions, usually inappropriate for real-world mundane animals or those that are recognizable to the player. (Think Q*bert.) So inversely, setting a game in a completely realistic place restricts the designer a great deal.
Either way the creature is designed though, the end result is that when players encounter the crocodiles in our example, the function of the enemy unit is obvious, the game’s situation changes somewhat and the player is required to react to a new form of obstacle that behaves in unique and interesting ways. If the game designer accounts for these enemy design features by incorporating several potential methods of reacting, the player can, within the scope of the actions available to him within the game, make informed and useful decisions in response to the crocodile enemy. What’s more, those decisions will be completely different from the decisions made when facing a bear. Imagine if every game’s enemies were designed with such deep consideration?
During his hellish early years on the Texas Gulf Coast (surrounded by evil shrimpers and gloomy chemical plants), Harvey’s sanity was (narrowly) preserved through years of non-stop gaming and subcultural pursuits. Only through this massive assimilation of SF/Fantasy books, computer/video games, paper RPGs and mope rock did he manage to evolve into the fey being he is today. He makes his home in Austin, Texas because he has a lick of sense. He eats nothing but Tex-Mex and fried seafood, and he is a 6th generation Texan. Harvey can be reached at [email protected].