This blog has moved. Visit Groundswell Games for the latest. Remember to update your bookmarks and RSS feeds.

Wednesday, September 26, 2007

Real-time battles, part 2: enemy AI

My first post about real-time battles dealt with timing -- how to pace a battle so it's fast-paced but leaves just enough time to make decisions. Part 2 deals with a considerably more complicated topic: enemy artificial intelligence (AI).

Before I begin, a disclaimer. I don't know anything about AI -- at least not about programming it (yet). These thoughts are just that: reflections on what's required to simulate an intelligent adversary. The way I see it, the problem of enemy AI can be divided into two parts (at least in terms of RPG games like the one I'm making):

Basic movement

In a real-time battle system, enemies exist in a world filled with obstacles -- rocks, trees, buildings, other creepy monsters -- so enemies need the ability to move around the world without doing silly things like trying to walk through a wall or wandering into the ocean.

Basic movement, then, requires that enemies have the ability to move around in a normal fashion (when nothing is in the way), and to avoid obstacles when they arise. Normal movement, of course, can take several forms. One enemy might patrol between a series of fixed points while another might wander aimlessly in a particular area.

Neither of these possibilities is very convincing, however. It would make much more sense for enemies to move about the world with a purpose. Not only would they lead happier and more fulfilling lives, they would seem more realistic. An evil imperial soldier might indeed patrol between fixed points, but a giant cave bat wouldn't spend all its time wandering within five meters of the place it was born.

Higher brain function (deciding what to do)
Wandering is fine, but what if a player (or group of players) invades the cave bat's cave? It would protect its turf by attacking the intruders. The first order of business is to decide who to attack. This decision is easy enough when there is one player-controlled character, but in a party-based or multiplayer game it obviously becomes more difficult.

Many games solve this issue with the concept of aggro. An enemy might attack the first player it sees, but if another player comes in and deals twice as much damage, he will draw the enemy's attention. Aggro, then, can be thought of as a function of damage or healing. Whichever player in range has offended the enemy the most becomes the object of its raging cave bat wrath.

Once the enemy has decided who to attack, it must then choose the manner of attacking. The conventional way to approach this problem is to build a decision tree. Given its set of possible moves, the enemy will survey its situation and choose a move, often with a healthy dose of randomness built in. For example, a monster with access to a healing spell and a basic attack might go through this sort of thought process:

  • If my health is less than 60%, heal myself.
  • Otherwise, attack the player with the most aggro.
The options in the decision tree get priority based on their order. As you might imagine, these trees can get pretty complicated. It's not the most sophisticated way for enemies to make decisions (they can't learn), but it is the most straightforward.

A similar approach is also useful for party AI, which I'll discuss in part 3. I know you can't wait.

No comments:

Post a Comment