엘든 링의 단순한 AI 구조

The Low-Tech AI Of Elden Ring FROMSOFT has a reputation for diverse and punishing npc encounters across the entire Soulsborne extended series, but the implementation of the AI decision making itself is perhaps unexpectedly low-tech. Since the majority of the code is implemented in Havok Script (A games-oriented Lua implementation from Havok) it’s pretty easy to take a peek behind the fog wall to see how they’re implemented. Note that none of what follows is original research, I’m just reading the code that others have done the hard work of extracting, decompiling, and reversing. Goals The primary tool of the FROMSOFT AI approach is the Goal 1 , 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 would be to organize states into a Finite State Machine or maybe a Hierarchical Finite State Machine, but FROMSOFT go one step further and give the system a stack of states. This turns it from an FSM into Pushdown Automaton (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 2 . [ 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 and is popped from the stack. 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 3 ! In their APIs they refer to the root of this stack as the “Top Level Goal”, which I’ve made confusing by referring to the currently executing goal as the “top” of the stack. So keep in mind those are separate things. 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 target_distance = actor . target_distance ( Target :: Enemy ) ; let fate = actor . next_random ( ) ; // ApproachTarget itself being a goal defined in common code! if target_distance > 2.0 { 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 ) { todo ! ( ) ; } 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 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 { // If I start burning, attack! 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 ; } } // If somebody uses an item they might be in for it. UseItem => { let fate = actor . next_random ( ) ; if fate < 0.5 { goals . clear_sub_goals ( ) ; action_light_attack_combo ( goals , actor ) ; } } // Perform a ground slam if I get attacked from underneath. Damage { target , } => { if target == Target :: Self { let distance = actor . target_distance ( Target :: Enemy ) ; let fate