Real-time battles, part 3: party AI

My last post about real-time battle systems looked at requirements for enemy AI. This third (and final) installment will deal with party AI.

To me one of the most significant differences between a turn- or time-based battle system and a real-time system is how the other members of your party behave. Old-fashioned time-based systems like Final Fantasy VII usually have random battles that take place in a temporary battle area. The advantage here is that the player can easily give orders to every member of the party during the battle, since only one party member or enemy can execute a move at any given time.

In a real-time system, things happen too fast to give explicit orders to each party member throughout an entire encounter. One obvious solution to this problem is not to have a party. But if you don't take the easy way out, you have to prevent the rest of the party from being a liability.

The common approach to party AI is, first, to give the player a way to switch control between active party members at any time during a battle and, second, to provide a short list of general behaviors for AI-controlled party members. These often give you three choices along the lines of aggressive, defensive, and support (healing and ranged attacks).

Unfortunately, these limited options usually result in party members that seem to get themselves killed (but only after using up all your items), and there is no way to customize their behavior any further.

Final Fantasy XII's gambit system finally offered a better and more fun option for party AI. By giving the player access to the if-then structure (e.g., if an ally's health drops below 50%, cast cure on that ally) of the party AI system (and by making it a part of the character leveling scheme), party AI became not only useful, but fun. Creating just the right combination of gambits became almost a game in itself.

One criticism of FFXII's gambit system, of course, is that the more gambit combinations are available, the less you have to pay attention during battles. You can literally run up to a group of enemies and go get a snack while your party defeats them. In some ways this is quite nice, but could be quite annoying for players who like finer control. Turning gambits off is always an option, though.

I haven't yet designed the party AI system for my game, and I don't know how I'll approach it. Some amount of control over party members' decisions is essential, but a more robust system would need to be carefully integrated into the gameplay and could distract from the primary character leveling system (which is going to be very cool, but I don't want to give it away just yet).

But until it's time to program party AI, I will turn my attention back to modeling buildings and other inanimate objects.

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.

Real-time battles, part 1: timing

Ok, so my last post wasn't exactly about real-time battle systems like I said it would be. This one is.

As I mentioned previously, there are advantages to a real-time battle system (like World of Warcraft or most other MMOs). For one, you don't need to whisk the player off to a "battle mode" that exists in some parallel universe. Another big advantage is that battles can be more realistic. Enemies and party members can attack and be attacked at any time, and there doesn't need to be any god-of-the-battle AI that dictates when each character or enemy is allowed to execute a move.

As you might expect, these advantages come with their share of tricky design decisions. This is the first in a series of posts that will discuss some of the common ones. Where to start?

Timing

Attack speed -- At first glance, timing seems easy. Each character or enemy has an attack speed, probably determined by some stat or the awesomeness of your weapon.

Cooldown -- Ok, that might be enough if all you do is flail about, but what if you want to give your player a special "extended flail" skill? You wouldn't want him to be able to string these together endlessly (it just wouldn't be fair), so you need a cooldown time for each ability or skill.

Charge time -- So now you can't eliminate your target with an endless string of "extened flail," but couldn't you just string together every skill in your arsenal and gank your unsuspecting target that way? (Indeed, this is the method used by every god-forsaken rogue in World of Warcraft.) This wouldn't be too challenging, either (yes, I played a mage), so you also need to implement some system where abilities require time to execute. Then you need to decide whether the charging process can be slowed or interrupted.

Down time -- This is similar to cooldown, but instead of affecting a single ability, down time affects your ability to do anything at all. After executing your supremely powerful "nuclear meltdown" ability, there might be a period of time when you can't execute any new moves, which leaves you vulnerable to the giant cockroach monster that survived the meltdown. Final Fantasy XII used down time instead of cooldown; WoW imposes a uniform down time of about a second after each move, in addition to skill-specific cooldown.

Easy enough, right? Part 2 will cover the intricacies of enemy AI.

A sneak peek

One of the coolest things about Unity is its Web player plugin. It's the same idea as the Flash Player, but it renders amazing 3D graphics instead. Pretty cool.

As a way to test out how well I will be able to embed builds of my game into this blog, I'm posting here some of the progress on my battle system. It's not much at first glance, but there really is quite a lot of depth to it. Here are some nuances to look out for:

• The way blue box man's left leg twitches when he runs.
• The fireworks that go off when he lands a Super Attack (press "2" to execute one--you'll love it).
• The way he runs forward while moving backward.
• The glorious piece of weaponry that blue box man and red box man are both carrying.
• The way the camera gets stuck above blue box man's head when you zoom in too far (using the scroll wheel).

Here are the controls. (You need to download the Unity Web player to play the game.)

• Right mouse to enter full screen mode (highly recommended--some of the controls don't work too well otherwise).
• Click on an object to target it.
• Left mouse: look around
• Right mouse (in full screen mode): turn
• Scroll wheel: zoom in and out
• w, s: forward and backward
• a, d: turn left and right
• q, e: strafe left and right
• 1: attack
• 2: super attack
• 3: cure
• 4: spell

Fun with blended animation

In this post I'm going to dig into a particular topic a little bit: animation. First, a little setup.

When I switched to Unity from Torque, I also decided to change the nature of my battle system. I had been working toward a time-based battle system in Torque, which meant that each character or enemy in the battle had a timer that would reset after each move and then refill over a period of time. When the timer filled, that character/enemy would enter its desired move into a queue that would execute one move at a time.

One big advantage of this system is that it's easier to input moves for multiple characters (since only one character/enemy is doing anything at any given time). Unfortunately, it's also a bit dated (think Final Fantasy VII) and works best with a separate battle screen.

So, in Unity I'm working on a more "real-time" system like World of Warcraft or Final Fantasy XII where enemies are visible all the time, have an aggro range, etc. This type of system is much more realistic and helps maintain the illusion of the game world, which is something I want to do as much as possible.

So what about animations?
Time-based systems make animations a little easier to handle, since each animation occurs in sequence and involves the entire skeleton. A basic move might go something like this.

1. "Idle" animation playing before the move.
2. Play a "run" animation and move toward the target.
3. Once the character reaches the target, transition to an action animation (like swinging a sword).
4. Play a "run back" animation and move back to the starting location.
5. Transition back to the "idle" animation.
   

A real-time battle system isn't quite so neat. At any time, your characters can be running in any direction while attacking, being attacked, casting a spell, etc. So your animation setup needs to be pretty flexible. This kind of thing is usually handled through the concept of animation blending. Here's Unity's discussion of the subject. To use blended animations, it's often a good idea to create separate upper and lower body animations that are combined at runtime. So your animation setup might look something like this:

• Full body
• Standing
• Walking
• Running
• Strafing
• Walking/running backwards
  
• Upper body only
  
• Swinging weapon
• Spell casting
• Blocking an attack
  
• Taking damage

With a blended animation system, you can give the upper body animations control over the affected joints in the skeleton when necessary, without interrupting whatever is happening in the lower body. This way you swing a weapon while standing, running, or whatever. Also, with a layering system like Unity's you can blend multiple upper body animations at once. This means you can run, swing a weapon, and take damage all at the same time.

Learning to animate
Animation is a very complex subject and an art in itself. I don't claim to be very good at it, but there are a lot of good basic tutorials out there. I'm particularly fond of this one, which explains the process of animating a run cycle.