COMPUTER-GAME ENEMY DESIGN

It's difficult to make a challenging enemy. Even if the enemies you make have huge health and firepower, the player always seems to figure out loopholes to defeat it. 

contents
  the loopholes
  the results
    preventing edging, splashing, picking, and wedging
    preventing memorizing
  let enemies use loopholes
    serializing
  conclusion
The Loopholes
One loophole is to hide around a corner and shoot the edge of the enemy. I call this "edging". Your enemy can't shoot back because vus (his/her) weapon is blocked by the corner. This works best on slow enemies.

A variation of edging is splashing. This is when the player hides completely out of your enemy's view and attacks it with a splash-damage weapon, such as a bouncing grenade or a rocket.

Sometimes the player hides behind a corner, jumps out and fires once, then jumps back behind cover. I call this "picking", since vu (he/she) picks away at your enemy. If your enemy has a slow weapon or takes too long to fire it, the player will never get hit.

If your enemy only has short-range weapons, the player might wedge it. This is when vu leads your enemy through a narrow passage and your enemy gets stuck. Vu then leisurely kills the enemy from just beyond the passage.

The worst loophole a player can use on your enemies is memorizing. This happens when vu has played the level enough that vu has learned the positioning of all your enemies. This lets vu surprise and trap your enemies instead of the other way around.

Notice that edging, splashing, picking, and memorizing use the walls and other solid objects as protection from your enemies. Another class of loopholes, predicting, results when a player figures out the patterns to your enemy's logic.

The Results
By using the loopholes above, a player can easily kill even the strongest enemy. It just takes a long time. Vu only gets hurt when vu messes up while doing a loophole. In short, the challenge is gone.

One bad way that enemy designers have fixed this problem is to make their enemies extremely powerful and puts them in large clusters. That way, one little slip up and half the players' health is gone. But, since the player couldn't possibly survive a direct confrontation with such an enemy, vu is forced to use the loopholes all the time. This, of course, becomes boring, unrealistic, and mechanical.

To make a challenging enemy, you should make it hard for the player to use loopholes on your enemy. At the same time, you should make it easy for your enemy to use the loopholes on the player.

Preventing Edging, Splashing, Picking, and Wedging
A simple way to prevent edging is to make your enemy strafe a lot, especially during fights. You can design your enemy to move its weapon to whichever edge is most vulnerable, so that less of its body is exposed without its weapon also being exposed. A less classy solution is to make your enemy rush the player very fast.

To prevent splashing, your enemy simply needs to be smart enough to get out of the way and figure out where the player must be. You could also make your enemy move around a lot, in a large area, and in a random pattern.

To prevent picking, give your enemy fast weapons and reflexes. Make it hide or move if a player is picking it, and make it shoot randomly, in case the player comes out. It could even call in other enemies to flank the player.

You can prevent wedging by making small and mobile enemies. Your enemy should be able to follow the player wherever vu goes. If it can't, it should back up and wait, forcing the player to come back out of vus trap.

Preventing Memorizing
Memorizing only works in a predictable environment. So, your enemies should appear with a certain probability and at a random place within a region. Then they should run to a strategic position and switch positions when the player isn't looking.

Another type of memorizing is when the player knows that every enemy behind vu in the level is dead, since vu killed them. To prevent this, some of your enemies should lie hidden. Then, once the player has moved past them, the enemies can converge on vu from all angles. This also helps prevent the other loopholes.

Memorizing a level's layout is bad too. It makes the good enemy attack positions too obvious. You should make the layout change as much as possible while still doing it in realistic ways.

Finally, predicting can be stopped by making your enemy's behavior partially random and imprecise. Also, your enemy should change its strategy if its current one isn't working.

Let Your Enemies Use the Loopholes
You should place your enemy where it has a positioning advantage over the player. It's positioning should allow it to use the loopholes on players.

A simple example is you could have a long, narrow hallway and instruct your enemy to stay at one end. Then, when a player comes in the other end, your enemy can start edging, picking, or splashing at the player.

You could wedge the player with a flying enemy of a small enemy that attacks and then hides out of range, where the player can't follow.

Serializing
Whether you place 10 or 100 enemies on a level, all that matters is how many the player can handle at once. This is because the player serializes them. Vu moves in just close enough to draw one out and then kills it. Then vu moves close enough for the next one and so on.

This can easily be prevented by having your enemy signal the other enemies when it spots a player. But even that won't work if you end up with 10 of your enemies in a cluster, tripping each other up while trying to shoot the player.

So, an additional solution is to give your enemies posts, allowing them to attack in parallel and protect each other.

Conclusion: Scaling Down Your Enemies
If you use the above ideas with your enemies, they will be very powerful because of their intelligence and strategy. To balance this effect, you will want to make their health and weapons the same as the player's. That way, the experience the player gets when fighting your enemy is more like when vu is playing against other real players. It again becomes a battle of brains and speed.

John LeFlohic
March 13, 1999