As with weapon differentiation, if each enemy has a particular function in the game world (and it is obvious and/or something the player can learn over time) then the player can make informed decisions about how to deal with each enemy (which becomes a game dynamic). The alternative (in which all enemies do basic variations of the same thing–race forward and inflict damage) is boring.Enemy Differentiation and Available Responses
Enemies. Monsters. Sprites. AI’s. NPC’s. 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? Cool renders 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 have never learned) how to make interesting and distinctly different enemies. Or even what that really means.
If a game has a line-up of creatures that look awesome but simply represent an ever-ascending set of numbers in several fields, then chances are that game will get boring quickly. Or at 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.
Think about Defender (and Stargate), the classic arcade games by Williams Electronics. Let’s choose three of their units, the Lander, the Mutant and the Bomber.
The Lander flew slowly and occasionally fired a shot at the player. If 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–always making a headlong attack when it spotted the player. The Mutant also had an erratic flight pattern, making it less predictable 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… Think about the ways in which they are different within the game’s framework of actions and mechanics. In these three units you have essentially Movement Rate, Flight Type, Aggression Level and Special Ability. The special abilities (an arbitrary term) for these units were respectively: L) consume humanoids then change unit types, M) pursue the player aggressively and B) leave a trail of explosives. (Note: The Lander’s ability to consume resources–the humanoids–is doubly brilliant. The game-play 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 was nowhere near as interesting and distinct. To use two hypothetical examples: Creature One can move at a game speed of 50, does 37 points of damage in an attack and has 100 hit points. Creature Two can move at a game speed of 75, does 12 points of damage in an attack and has 30 hit points. And so on. In some games, this is all you get. 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 any critical decisions about how to react to a game enemy; the reaction is generally always the same, since the enemies are fundamentally the same.
Game designers should want to 1) present players with a series of distinct and challenging situations, 2) give them enough information so that they can decide how to react and 3) provide they with a set of in-game actions that will allow them to execute on their decisions, with consequences.
To illustrate my points, I’ll create an example game enemy. And let’s make an enemy relevant to more modern games than Defender, lest someone cry, “Games have changed; the old rules do not apply!” For our example, I will use a crocodile, set in a 3d world-an environment in which we’ll state that the player can run and swim. Fairly standard stuff, and an area in which designers routinely short-change players by not making things interesting enough.
Now, for the crocodile we’re discussing, you 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 such examples in 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, etc. If the player did much swimming in the game before meeting his first crocodile (on previous ‘levels’ or whatever, encountering other types of water features such as current flows and small fish), he will now have to adjust the way he plays because the game has changed. Imparting our crocodile with this one attribute has made the game a dynamic experience. (Now imagine if we applied this thinking to every enemy or friendly AI unit in our make-believe game…)
Second, our crocodile, due to its tough leathery skin, is immune to the tranquilizer dart gun in our game. If we do this, the player cannot just shoot his way out of the encounter. He must instead, react to the situation and make a decision (if only to switch weapons when fighting crocodiles).
And lastly, 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, 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. So 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 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 active. It makes the player decide and react. It grants the game interesting dynamics, instead of creating tedious game-play.
It is also important to note that if the player never *knows* about any of the distinct enemy functions you generate, he will never get any enjoyment from them. So, as feedback mechanisms for to our example croc, we could do something like this:
Related to the crocodile’s tranquilizer dart immunity, we 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), we could make the dart “pa-ting!” and ricochet.
Also–to inform the player of the croc’s interesting land movement features before the player actually encounters any crocodiles–we could drop one or two down on the beach, chasing some small innocuous game creatures. The creatures that run from the crocodiles in straight lines always get eaten; the creatures that run in a zigzag pattern always escape. By studying the crocodiles before encountering them, the player could learn something about consistent crocodile behavior as it is within the framework of our game. (Clearly, this sort of thing 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 number of more interesting game dynamics; the player has more information with which to act.)
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 croc bites and triggering a player gurgling sound.
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 saying, “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. As an example, think about Quake 2’s “medic” enemy; its primary purpose was 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, seemingly, did not have the discipline to focus this unit down to its essence. (Sadly, it comes across in Quake 2 mostly as another big beast with lots of hit points) However, as a concept, it is quite cool. It really works 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 approach, it becomes obvious as to 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.)
Either way, 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. And if we account 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. And those decisions will be completely different from the decisions made when facing a bear…