Goals

The primary tool of the FROMSOFT AI approach is the Goal¹, which is their own terminology for a unique state that the AI can be in. Goals can be parametized when instanciated, and can access data stored on the Actor itself, but are otherwise really just an immutable table of functions.

Now the simplest option here would be to have states form a Finite State Machine or maybe a Hierarchical Finite State Machine, but FROMSOFT go one step up from that and give the system a stack of states. This turns it from an FSM into pushdown automata (PDA).

That’s an entirely abstract definition, so after you get back from wikipedia let’s talk about it concretely from the top down.

Each frame Actors will update the Goal on top of their stack of Goals. When the Goal updates, it can then push more Goals as Sub-Goals onto the stack, the topmost of which will execute next frame. The Goal’s update function returns a value indicating either Continue, Success, or Failure. Continue will leave the stack unchanged, the other two will cause the Goal to be popped from the stack. Failure will additionally cause all other unexecuted Goals to be popped from the stack up to the parent Goal (The Goal which pushed this sub-goal).

For example, we might define a Goal called CoolBossBattle, during the course of its execution it might then push a series of Attack Sub-Goals. Those attack Goals can be parametized by various means, but the main one is the animation id².

[ GOAL STACK ]

3: Attack (R2, Combo)           <<<<-- Currently Updating
2: Attack (R2, Repeat)
1: Attack (R2, Finisher)
0: CoolBossBattle

After a few seconds the first attack lands, and that Goal completes with success. However the next fails, causing the stack to unwind to its parent.

[ GOAL STACK ]

2: Attack (R2, Repeat)          <<<<-- Failed, will be popped from the stack.
1: Attack (R2, Finisher)        <<<<-- Will be removed as well.
0: CoolBossBattle

Readying it to chose its next action now that the attempted combo of attacks has ended.

[ GOAL STACK ]

2: Attack(L1)
1: Attack(L1)
0: CoolBossBattle               <<<<-- Updating, pushes 1, and 2 for the next frame.

Not too complex³!

Activate

Goals are defined by a few functions used as callbacks, and the one which contains the most AI logic is usually activate. This is called the first time that a Goal is updated, and then every subsequent time that the Goal exhausts its Sub-Goals and starts executing again.

For boss and regular npc Goals the code in Activate is responsible for choosing the next action that the Actor will take using a mix of context from the world and Actor, and randomness (which also comes from the Actor itself).

The most widely used approach uses common code to perform a weighted random selection between a number of Actions (which are just functions), calling the winner.

To return to our CoolBossBattle, this time in some Rusty pseudocode…

fn action_giga_death_ray(goals: &Goals, actor: &Actor) {
    todo!();
}

fn action_leap_attack(goals: &Goals, actor: &Actor) {
    todo!();
}

fn action_ground_slam(goals: &Goals, actor: &Actor) {
    todo!();
}

fn action_light_attack_combo(goals: &Goals, actor: &Actor) {
    let fate = actor.next_random();

    // ApproachTarget itself being a goal defined in common code!
    goals.push_sub_goal(Goal::ApproachTarget, Target::Enemy);

    goals.push_sub_goal(Goal::Attack, AnimId::R1, Combo::Initial);
    goals.push_sub_goal(Goal::Attack, AnimId::R1, Combo::Repeat);

    // Unlucky buster! It's the long combo.
    if fate < 0.2 {
        goals.push_sub_goal(Goal::Attack, AnimId::R1, Combo::Repeat);
    }

    goals.push_sub_goal(Goal::Attack, AnimId::R1, Combo::Finisher);
}

fn action_heavy_attack_combo(goals: &Goals, actor: &Actor) {
    let fate = actor.next_random();

    goals.push_sub_goal(Goal::ApproachTarget, Target::Enemy);

    goals.push_sub_goal(Goal::Attack, AnimId::R2, Combo::Initial);
    goals.push_sub_goal(Goal::Attack, AnimId::R2, Combo::Repeat);

    // Unlucky buster! It's the long combo.
    if fate < 0.2 {
        goals.push_sub_goal(Goal::Attack, AnimId::R2, Combo::Repeat);
    }

    goals.push_sub_goal(Goal::Attack, AnimId::R2, Combo::Finisher);
}

fn activate(&self, goals: &Goals, actor: &Actor) {
    let target_distance = actor.target_distance(Target::Enemy);

    let mut weights = if target_distance > 6.0 {
        [
            15.0,
            65.0,
            0.0,
            10.0,
            10.0,
        ]
    } else if target_distance > 1.5 {
        [
            0.0,
            0.0,
            5.0,
            60.0,
            35.0,
        ]
    } else {
        [
            0.0,
            0.0,
            20.0,
            40.0,
            40.0,
        ]
    };

    // This doesn't exactly work this way in the Lua code, and these cooldowns
    // don't make sense here either, but hopefully it gives the rough idea.
    //
    // The helper function is checking last played data for the animation on the
    // Actor itself, and then modifying the weights before they go into the
    // common battle randomized selection.
    weights[3] = if common::is_cooldown(goals, actor, AnimId::R1, 8.0) { 0.0 } else { weights[3]; };
    weights[4] = if common::is_cooldown(goals, actor, AnimId::R2, 10.0) { 0.0 } else { weights[4]; };

    let actions = [
        action_giga_death_ray,
        action_leap_attack,
        action_ground_slam,
        action_light_attack_combo,
        action_heavy_attack_combo,
    ];

    // Does some common setup for the number of actions and then rolls the dice
    // and chooses which function to call.
    common::battle_activate(goals, actor, weights, actions);
}

Modifying the weights dynamically is handled in many different ways, but the most common are simple rng rolls from the actor and hp thresholding.

Other, simpler, goals than the top level battle Goal for an Actor may simply push a few sub-goals, perhaps reading some data from the Goal parameters. The nesting means that it’s possible to compose quite complex behavior from simple building blocks.

Interrupts

The other major callback defined for goals is the Interrupt. As the name suggests, this allows Goals to respond immediately to external events which are mostly configured on the Actor itself.

My understanding is that interrupts bubble up, that is, it will run the interrupt on the currently executing Goal and then its parents recursively, until it runs out of Goals or one of the interrupt callbacks returns true to indicate it has consumed the interrupt.

For example, if I wanted CoolBoss to move into a furious rage of attacks as soon as I set it on fire, then I might implement something like the following.

fn interrupt(&self, goals: &Goals, actor: &Actor, interrupt: Interrupt) {
    match interrupt {
        SpecialEffectActivate {
            target,
            special_effect,
        } => {
            if target == Target::Self && special_effect == SpecialEffect::Fire {
                // Since there might still be other things running when
                // interrupt is called we need to unwind so we're on top again.
                goals.clear_sub_goals();

                goals.push_sub_goal(Goal::Attack, AnimId::R1);
                goals.push_sub_goal(Goal::Attack, AnimId::R2);
                goals.push_sub_goal(Goal::Attack, AnimId::R1);
                goals.push_sub_goal(Goal::Attack, AnimId::R2);

                return true;
            }
        }
        _ => {}
    }

    false
}

This is used to implement some truly evil features, for example the Bell Bearing Hunter will detect you spell casting or using an item and from there has an 85% chance to immediately abort its current action and launch into an attack.

They also make use of dynamic spatial watch regions configured on Actors, which trigger interrupts. For example you might add a watch for the area behind or under a boss, and use that to adapt their behavior immediately when the player tries to get clever.

Timeouts

Goals, in addition to their individual state, also carry a lifetime value in seconds. This is used to break out of states which become stuck for whatever reason. Mostly this seems to be used purely as a bug containment mechanism.

It’s also possible to modify the lifetime of a parent goal during execution, to indicate continued forward progress.

Actor Data Access

In many AI decision systems you might have heard of fancy systems for data storage like “blackboards”. In the Souls games there’s a list of floats on each Actor which are set and read arbitraily from Goals by index. Good enough I suppose!

A callback I didn’t mention before, Initialise, is commonly used to reset this data when an Actor is assigned a new top level Goal.

Goals have access to a range of queries about the world through the Actor. As far as I can tell most of these are pretty “low cost” from a performance perspective. Aggro and Targeting seems to be handled outside, so it should be possible to keep the Goals very lean even considering it’s all interpreted Lua.

Actual Doing Stuff

Something I’ve entirely skipped over is how the Goals actually Do things. For the most part everything like this in FROMSOFT games is animation driven.

The Goal says “play this attack animation”, and then the animation events carry hitbox information and timings, special effect triggers, projectile creation events, and whatnot. They also have a variety of “combo” features which seem to boil down to choosing a different set of events in the animations to enable faster linking of chained animation during a combo attack.

Misc Stuff

They seem to split AI scripting into a “logic” script, and a “battle” script, where the logic script is far more sharable, and the battle scripts are often bespoke. This seems super smart, it’s common to run into issues jamming both these things into singular hierarchies.

You seem to be able to configure the top level Goal for an Actor in the level itself, so you can place some dudes down with a passive Goal instead of their usual combat Goal, and they would just chill whilst otherwise functioning the same.

Most of the common code here is relatively compact bits of Lua, but I believe the load bearing Goals like Attack or MoveToSomewhere are implemented in C++ which gives you a pretty nice balance of scriptability and performance sanity.

The update function itself is sometimes used to check conditions, I kinda expect this must have caused problems occasionally. But so long as the interface for Actors in scripting is thin I guess you can keep it under control. (Don’t add a pathfind function call…)

I’ve entirely skipped over the event scripting system used to do high level encounter logic and level scripting. Unlike the AI it seems to be entirely custom, with a very restricted VM. That said, since it’s not Lua it’s hard to see how they’re actually authored. If anyone knows of primary sources for info about their tooling that would be super cool!

Conclusion

There’s a lot of enduring hype for complicated AI systems, GOAL springs to mind, but I think the success of putting a lot of control in the hands of your designers and animators really speaks for itself here. The system is also fundamentally quite fast; behavior trees often require deep re-evaluation of complex trees (defined in scripts…) during planning, where this is almost always executing a single Goal from the top of the stack, and planners have an expensive search phase in the middle of everything.

Compared to FSMs the flexibility makes it easier to avoid state explosion, which enables much more composable behaviors.

Plus of course it’s dramatically more legible than planner based solutions where individual actions are moved out of the hands of combat designers.

Is it going to handle more complex scenarios than the typical Soulsborne NPC or boss fight? I think it could go quite far, so long as you aren’t building a sim game.

References

Most of the info in this post comes from eladidu readable ds lua it’s fantastic and you can find many interesting definitions as well as a little tutorial.

If you want to get even more excited there’s a bunch of tools for extracting data from the game packages, as well as nice modding tools for patching things here and there.

1. This is not to be confused with the concept of a goal which you might know from advanced planning systems like STRIPS, GOAP (Goal Oriented Action Planning) or HTN (Hierarchical Task Networks). Those systems use a search algorithm in order to dynamically find a sequence of Actions which move the world into a Goal State. There’s nothing remotely so complex happening here!↩

2. Anim Ids are largely based on playstation controller inputs which are then offset by a per-actor value in the npc definition! Moveset swaps can be performed by changing the offset dynamically from scripts!↩

3. I’m glossing over a small problem here… You want to be able to write your scripts so that sub-goals function as a queue, not a stack, so they are executed in the order they’re pushed. Unfortunately that slightly complicates the implementation and explanation so I’ve left it as an exercise for the reader.↩