Synzza Star - Designing Combat AI

 I’d like to discuss the design behind Synzza Star’s combat AI agents, which will be used for both friendly party members as well as enemies and other NPCs. The following discussion will be somewhat complex and technical. If you’re interested in the philosophy behind these designs, check out this post here.

A Brief Clarification

Before going into detail about what it is I’m going to do, I should clarify what I’m not going to do. Again, if you’re interested in a more philosophical discussion, check out the post linked above.

In Synzza Star’s combat I seek to avoid a situation I call “AI slapfighting”, which is when two AI combatants within melee range of each other simply begin wailing away until one of them drops.

To be sure, it’s an effective formula for games to employ, even if it is a bit simple. Many well-respected, tactical, strategic games use combat like this as a base to build more complex abilities and satisfying mechanics atop of. Players intuitively understand it, and an ambitious designer can always introduce cool skills and status effects to make things more interesting for seasoned players with a more refined palette.

All that being said, it’s not what I want for my game. I’d like combat for every party member to feel more intentional than this, for a variety of reasons. That unavoidably means the AI agents I create will need to have more complexity, and so without further ado let’s get into the details of what I have in mind.

Continuous States

The term “continuous state” is what I use to refer to a pre-defined set of rules a battler AI agent in Synzza Star will follow when it is presented with either an enemy AI agent in melee range or a distant target to hit a melee-range ability with. (Anything in the game to do with ranged abilities is considered to be a higher-order executive thinking problem which the player can deal with on their own.)

I’ll grant you there may be a better or more established term for this concept, but if there is I don’t know it. If you’d like, leave a comment with a link if such a thing exists. In any case, let’s break down what each of these states mean.

Auto Block

This will be the state many battlers will spend most of their time in, and its purpose should be pretty self-explanatory. The agent will enter into a blocking state when in melee range of an enemy, assuming the enemy is within the agent’s line of sight. Agents in a blocking state have reduced mobility, but will take reduced damage from attacks, and the effectiveness of the block depends on the agent’s equipment and the type of incoming attack.

I’ll take a moment here to reiterate that when I use terms like “enemy” in these explanations, I’m speaking from the perspective of the agent, not necessarily the player. Hostile NPCs will use these same continuous states, and to them the player’s party members may be “enemies”. Just something to keep in mind as we move forward.

Auto Attack

This state is available to the player, and NPCs would rarely use it unless provoked into doing so by some kind of status effect. Its purpose is also self-explanatory – the agent will continuously attempt to attack the target when it is in melee range.

Wait, isn’t this the exact behavior I said I wanted to avoid? It is, and the fact that NPCs will rarely choose to be in this state should serve as a hint that this won’t be an effective strategy in Synzza Star, most of the time. In order to understand why, let’s take a quick look into how attacks in Synzza Star are designed.

The Anatomy of an Attack

Attacks are split into three phases: the wind-up phase, the effect phase, and the wind-down phase. The effect phase is likely what the player would think of as the “actual attack”, as this is the part where a hitbox is spawned, damage is dealt, status effects are applied, etc. The wind-up and wind-down phases are periods of vulnerability before and after the attack, respectively.

What this means is that attacks in Synzza Star are commitments, which require at least a couple seconds of safety in order to properly execute. If an enemy staggers the attacker with a faster parry of their own, or if the attack is successfully blocked, the attacker can suffer consequences ranging from simply losing their action to getting hit with follow-up attacks from their target.

Back to Continuous States

With the additional information about how attacks work in Synzza Star, the trade-off inherent to the Auto Attack continuous state is hopefully clearer: it is the state most efficient at exploiting a vulnerable target, at the cost of making the attacking agent more vulnerable to counterplay.

The other two continuous states, Auto Counter and Opportune Attack, are designed to be tools to help the player find advantageous attacking opportunities without being as all-in as Auto Attack. As previously mentioned, many battlers in the game will start in the Auto Block state, and so players will need such tools to effectively guide their party in battle without being forced to have total control of every time-sensitive input.

Auto Counter

This state is quite similar to Auto Block, with the exception that after an attack is successfully blocked, the agent will automatically respond with an attack of their own. This is taking direct advantage of the staggering mechanic described previously, with the idea that the opening created by the block’s stagger should be enough to offset the counterattack’s wind-up.

Opportune Attack

Finally, this state is Auto Counter’s more proactive (or alternatively, Auto Attack’s more conservative) relative. Rather than waiting for an enemy’s attack to connect, Opportune Attack eschews blocking entirely by attacking as soon as the target becomes “vulnerable”. In this case, vulnerable means either that the enemy does not have the agent in their line of sight (perhaps by being distracted or snuck up on) or that the enemy has entered into a stagger, wind-down, or wind-up animation of any sort.

Of course, if “vulnerable” includes wind-up animations, then that could mean our agent is in fact about to be attacked by its own target! Care needs to be taken when using this state, though even this scenario can be planned to the player’s advantage.

With that, we’re done describing what the continuous states are. Now let’s move onto how the player will actually use these states in the game.

Input Using the Pause System – How and When?

When the battle is paused to allow for input, players will select any of their party who have no input (and optionally any party members who are in the middle of “interruptible” actions such as walking to a location), and select an attack for that party member to use. After the attack is selected, a target enemy or area is chosen, and then once each party member has things to do, the battle resumes playing out until it ends or until a party member needs input again.

So, where are the continuous states?

By default, continuous states are automatically selected, depending on the character and the kind of attack selected. Generally, a melee-range attack being selected by the player will be automatically given Auto Counter, and a long-distance attack will be given Auto Block as the agent is in transit to where the player wants them to attack (remember that continuous states only govern melee-range interactions).

The player can also manually set the continuous state of any attack with nothing more than the press of a button (this would be something like a left or right trigger using a gamepad, or something like the Shift key on a keyboard). Setting the continuous state like this once will be maintained for the rest of the battle – in other words, manually setting the continuous state of an attack to Opportune Attack, for example, will have all other attacks adopt that same setting automatically until changed again.

Choosing Locations

Determining where a party member moves before attacking is similar to choosing a continuous state in that there is an automatic option and a mechanism for manual input.

If the attack is melee-range, the agent by default will aim for whatever location is closest to their target. If the player uses the same button for manual continuous state selection (again, something like a left or right trigger, or the Shift key), they can instead specify a waypoint on the melee target.

These waypoints correspond to the eight cardinal and intermediate directions. If one of these is selected, the battler will aim for that waypoint and conduct their attack from there.

For long-distance attacks, by default the agent will simply fire their attack from wherever they happen to be standing at the time. Using the manual input button can allow the user to specify if they’d like to move closer or further from the target before attacking.

If a long-distance skill has an area-of-effect, a single target will still be specified; however, like with melee attacks, the player can specify a positional offset from the target, in order to hit a group of enemies or to account for the enemy’s movement during the wind-up phase.

Interrupting Previous Commands

As previously stated, once each party member has a command the battle will resume from its paused state and will play out the inputs from the player and enemy AI. The battle will pause again on its own once a party member needs input, but the player always has the ability to manually pause whenever they want – they just may not have the ability to change every party member’s commands. It depends on whether that character is in an interruptible or uninterruptible state.

The wind-up animation for any attack always leaves that battler in an uninterruptible state. Not every attack has a corresponding wind-down animation, but those that do are also uninterruptible for the entire duration of the attack. For the player, that means when their battler begins that attack, that battler is committed to that action and will not be able to change until after completion. Status effects can also render the afflicted battler uninterruptible until the effect is removed.

Final Notes

If the battler loses their action due to being staggered in the middle of an animation or due to being blocked, the costs for that action would still have been paid and are simply lost; however, this does also mean the battler no longer has input, so if a party member is staggered this way the player will immediately be able to give new input as soon as that character recovers from being staggered.

There still is much to talk about with Synzza Star’s design, but those will be covered in future blog posts. I’ve glossed over some of the finer details of the battler AI system in order to cover the broader strokes, and there’s entire systems that we still have only barely touched. Stay tuned for more design and technical discussions, and until then take care.