Margit the Fell Omen raises his staff and holds it in the air for one and a half seconds.
You’re already rolling. Your thumb hit the B button before your conscious mind caught up, because eight deaths have taught you one thing: Margit’s windup contains two completely different combos, distinguishable only by the subtle shake of the staff tip. But this time you didn’t have time to read it — you rolled before you saw the tip move. Margit’s delayed strike lands precisely on the frame your i-frames end. YOU DIED.
Ninth death. You stare at the screen and start noticing something uncanny: the more you die, the more “readable” Margit’s behavior becomes. Not because he’s getting weaker — boss data doesn’t change between deaths — but because your brain is compiling Margit’s move set into a rulebook: staff tip tilts forward = three-hit lunging combo; staff tip lifts up = holy hammer slam; distance beyond one body-length = dagger throw. The rules are few, each is clearly identifiable, and each corresponds to a definite response window.
This is the most counterintuitive thing about FromSoftware’s game AI: the simpler it is, the smarter it feels.
Not AI — PDA
In June 2026, a technical reverse-engineering article published on nega.tv blew up across Hacker News and Lobsters. The content boils down to a surprising discovery: FromSoftware’s enemy AI system — used from Demon’s Souls all the way through Elden Ring — is not a behavior tree (BT), not a GOAP planner, and certainly has nothing to do with deep learning. At its core, it’s a Pushdown Automaton (PDA), written in Havok Script (a discontinued, game-oriented Lua variant), with a data structure more primitive than most AAA game AI systems.
FromSoftware internally calls the basic unit of its AI a “Goal.” A Goal is an immutable function table containing three core callbacks: activate (triggered on first execution or when sub-goals are exhausted), update (called every frame, returning Continue/Success/Failure), and interrupt (responding to external events). Each Actor (i.e., an NPC or boss) maintains a Goal stack — not a simple finite state machine, but a PDA with stack structure.
The runtime logic is almost embarrassingly simple: every frame, update the Goal at the top of the stack. If the current Goal needs to expand into sub-behaviors, push a stack of Sub-Goals onto the stack; the next frame automatically starts executing the topmost one. When a Goal completes, it pops off the stack. If a Goal fails, the entire sub-goal chain pops together and control returns to the parent Goal.
Take CoolBossBattle as an example. The boss’s activate function contains a set of weighted action candidates: at long range, Death Ray weight 15, Jump Attack weight 65; at mid range, Ground Slam weight 5, Light Combo weight 60, Heavy Combo weight 35. Weights are dynamic — moves on cooldown have their weight zeroed out, and as the boss’s HP decreases, certain high-risk moves get higher weight. Each decision cycle is just a weighted random draw, then push the corresponding attack Goal onto the stack.
There is no “planning” here. The boss doesn’t predict where you’ll be three seconds from now. It doesn’t build a world model. It doesn’t do Monte Carlo tree search. It just draws a card from the action table each decision cycle based on a few well-defined conditions (distance, cooldown, HP, random number).
Then Why Is It So Hard?
This is the central paradox of FromSoftware’s design philosophy: making enemy behavior predictable actually makes combat harder.
A common misconception is “hard = smart.” But if you think back to the game moments that truly made you throw your controller, the most frustrating deaths usually weren’t because the enemy was too smart — they were because you couldn’t understand what the enemy was doing. When NPC behavior seems random, inconsistent, or “cheap,” players instantly switch from “I need to improve” to “this game is screwing me.” The learning process terminates. Frustration takes over.
FromSoftware does the opposite. Every boss’s move set is a closed set. Every attack’s windup animation, active hit frames, and recovery frames are fixed. The boss doesn’t “learn” your playstyle — it just draws from the same weighted random pool over and over. But that’s exactly what lets you learn the boss. The difference between death nine and death one isn’t that the boss got weaker; it’s that your brain completed a reverse-engineering of a deterministic system.
Lobsters user icefox said something honest in the comments: “Being smarter than the enemy AI is one of the few advantages you have in Elden Ring.” The reverse reading is more accurate: FromSoftware designed the AI to be something the player can outsmart, and that’s the precondition for this series’ combat to work at all.
The engineering statement of this design philosophy: predictability = playability. Emergent behavior doesn’t come from complex decision algorithms — it comes from the combinatorial explosion of simple rules under different player behaviors. The delayed strike is iconic not because it uses some advanced AI — it’s literally just extra waiting frames inserted into the Attack Goal’s animation playback. But from the player’s perspective, it translates to: “You need to learn to count frames.”
Why AAA Games Chasing ML AI Keep Tripping
Put FromSoftware’s approach next to the current AAA game AI trends, and the contrast is almost comical.
For the past decade, the main theme in game AI has been “make NPCs smarter.” Behavior Trees became the de facto standard — Halo 2 was the first major use of BTs for combat AI in 2004, and subsequent Halo titles pushed BTs to their limit. GOAP (Goal Oriented Action Planning) was mythologized because of the enemies in 2005’s F.E.A.R. that flanked, vaulted cover, and shouted “he’s reloading!” Utility AI proved itself in The Sims for driving complex daily life simulations. Every approach is more complex than FromSoftware’s PDA — BTs have sequence nodes, selector nodes, parallel nodes, decorator nodes; GOAP requires A* search over the action space; Utility AI scores every option.
But complexity has an underappreciated cost: loss of control. The more designers rely on general-purpose planners to automatically concatenate behavior sequences, the harder it becomes to predict what an NPC will do in a specific situation. The classic GOAP problem is “the planner occasionally decides to hit a door with a ladder instead of opening it.” BT scaling usually comes with the curse of “the tree is too deep for any human to understand” — over a decade ago, Bungie’s Damian Isla warned at GDC that Halo 3’s BT complexity had reached the point where designers could no longer fully comprehend behavior causal chains.
For FromSoftware, this isn’t a problem — because they don’t give the AI the ability to “plan for itself.” Every boss behavior is hand-authored frame by frame. Animators decide the startup frames and active frames of each attack. Combat designers decide cooldown times and weight distributions. The “intelligence” the player feels comes from the emergent effect of these three layers of handcrafted detail layered together, not from some algorithm acting on its own.
This is the fault line in engineering philosophy. One side: “give the AI a general intelligence framework and let it decide what to do.” The other: “give designers a simple enough, composable enough infrastructure to hand-control every AI decision.” FromSoftware bet on the latter, and won.
The Interrupt System: The Hidden Difficulty Dial
Beyond the Goal stack and weighted random selection, FromSoftware’s AI system has a third leg: interrupts.
Every Goal can register an interrupt callback. When a specific event fires — the player uses an item, casts a spell, stands in a specific spatial zone behind the boss — the interrupt event bubbles up the Goal stack until some Goal’s interrupt callback returns true, signaling “I handled this event.” Handling logic can include: clearing the current Goal stack, immediately pushing a new attack Goal, or modifying the parent Goal’s state.
This is why the Bell Bearing Hunter almost always charges when you drink a flask — its interrupt system has a rule: detect UseItem event + 85% probability → clear current action, immediately lunge. You think the boss is “input reading.” It’s just responding to a hardcoded event callback.
The cleverness of this system: it lets designers precisely control the boss’s reaction intensity to player actions without tangling that logic into the base decision loop. The boss’s routine behavior (mid-range → randomly draw from move pool) and reactive behavior (you’re healing → immediately punish you) are two independent logic channels.
Someone on HN asked: can this system handle scenarios more complex than Soulsborne boss fights? The nega.tv author’s answer: “it can go quite far.” The reasoning is simple: the complexity of the PDA framework depends on the number and quality of Goals, not the framework itself. Want an open world where every NPC in a village has daily routines and social networks? You might need thousands of Goals and a complex orchestration system. Want to make an unforgettable boss fight? A dozen Goals and two hundred lines of Havok Script will do it.
The Low-Tech Victory
Back to the opening question: why do FromSoftware’s state machines outperform most AAA game AI?
The answer isn’t in the technology — it’s in the design philosophy. FromSoftware never treated AI as a tool for “simulating intelligence.” They treated AI as a communication medium for combat design. A boss’s behavior is a language the designer writes for the player. Every attack, every recovery window, every “you can squeeze in one hit here” hint — all intentional. When AI becomes too complex and too unpredictable, that language breaks. The player is no longer “learning the fight” — they’re “tanking RNG.”
There are also some more pragmatic engineering advantages. PDA execution efficiency far exceeds BT — it typically only needs to update one Goal at the top of the stack per frame, rather than re-traversing the entire tree from the root. FromSoftware’s Goal system writes control flow in imperative code, with an extremely lean data model — each Actor has a float array, and Goals read and write by index. No Blackboard, no event bus, no complex condition/sequence/selector node trees. The author’s article update specifically emphasizes: in most AAA games, you’d see “behavior trees with tens of thousands of nodes, plus hundreds of individual nodes implementing control flow and actions,” while FromSoftware’s single boss behavior is typically “quite small.”
Of course, this doesn’t mean PDA is a cost-free silver bullet. Writing AI in Havok Script means basically saying goodbye to visual behavior editing tools — designers have to write code. Debugging the interrupt system scales exponentially with Goal stack depth. No general-purpose planner means every boss behavior is hand-crafted, non-reusable — but for FromSoftware, that’s not a bug, it’s a feature.
The correctness of a technical choice is ultimately not determined by how advanced it is, but by whether it fits the problem being solved. FromSoftware’s problem isn’t “make smarter AI” — it’s “make more readable, more learnable, fairer enemies.” Using a PDA instead of GOAP, using state machines instead of deep learning — not because they’re behind the times, but because what they want is exactly what low-tech can deliver.
This article draws on publicly available information and community discussions. If you have deeper first-hand experience with this topic, corrections and additions are welcome.