Case Study: F.E.A.R.'s GOAP — Why a 2005 Shooter Still Has the Best AI

First Encounter Assault Recon shipped in October 2005. It was a supernatural horror shooter about a paranormal squad investigating a psychic child who could cause visions of torn-apart faces to appear in hallway mirrors. The horror was effective. The shooter was better than the horror.

Twenty years later, people still talk about the AI.

The reason is not that it was the first good AI in a shooter — it wasn't. Half-Life (1998) had the HECU marines. Halo: Combat Evolved (2001) had the elites and grunts. Half-Life 2 (2004), released one year before F.E.A.R., had the Combine and the G-Man. By 2005, first-person shooters had figured out AI — or at least, they had figured out how to make enemies feel like combatants rather than piñatas.

F.E.A.R. did something slightly different. It built its AI on an architecture called Goal-Oriented Action Planning, or GOAP, which Monolith's AI programmer Jeff Orkin described in a 2005 GDC talk and subsequent paper titled "Three States and a Plan: The AI of F.E.A.R." The paper is one of the most-read AI-programming documents in game-development history. It is still taught in university AI courses. Its influence, measured in direct descendants, is small — almost nobody shipped GOAP-based AI after F.E.A.R. — but its influence on how we talk about game AI is enormous.

The reason the talk became canonical is that F.E.A.R.'s enemies felt uncannily intelligent. Players reported moments that had never quite happened in shooters before: the enemy would go silent, the player would hear a creak from a different direction, and they would turn to find a Replica soldier climbing onto the catwalk behind them. It had flanked. Not because the level designer had scripted a flanker — because the AI had decided, in response to the firefight's dynamics, that flanking was the right move.

This case study walks through how Monolith built that decision-making, what emerged from it, and why nobody copied the approach.

The Problem Monolith Faced

Orkin started work on F.E.A.R. with a specific frustration: the AI in most 2004-era shooters felt scripted. The designer placed enemies, scripted their initial behavior (stand here, patrol to there, shoot at the player when spotted), and the enemy would execute that script reliably but rigidly. If the player did something unusual — attacked from behind, rushed, baited the enemy out — the script would visibly break down. The enemy would run in place, shoot at a wall, stand confused.

Behavior trees helped. Halo 2, released in 2004 just before F.E.A.R., used behavior trees to produce more context-adaptive behavior. But BTs still had a rigid shape — the designer had to anticipate, in the tree, which tactical options the AI should consider, and in what order.

Orkin wanted something different. He wanted the AI to figure out what to do, rather than execute pre-authored responses. Specifically, he wanted an AI that could plan — that could look at the situation, consider available actions, and synthesize a sequence that would achieve its goal.

The obvious reference was STRIPS and the classical AI planning literature. Orkin adapted STRIPS into GOAP, the real-time game version.

How GOAP Works

GOAP has three components:

World state. A small vector of facts about the current situation. In F.E.A.R., this included facts like: weapon_loaded, target_position_known, in_cover, at_flanking_position, has_grenade, ammo_low, and so on. Maybe 30-50 facts total, represented as booleans or small enums for fast comparison.

Actions. A library of things the AI can do. Each action has:

  • A precondition — the world-state facts that must be true for the action to be valid. Reload requires has_ammo = true and weapon_loaded = false.
  • An effect — the world-state facts that change when the action executes. Reload's effect is weapon_loaded = true.
  • A cost — a numeric weight used by the planner to prefer cheaper solutions.

The F.E.A.R. action library included things like: ReloadWeapon, TakeCover, FireAtTarget, MoveToCover, MoveToFlankPosition, ThrowGrenade, CallReinforcements, TauntPlayer, GoToSearchLocation, and others — roughly 50 actions in the shipping game.

Goals. A description of the desired end state, expressed as the world-state facts that must become true. The top-level goal for the Replica soldiers was target_neutralized = true. The goal for wounded soldiers was at_safe_location = true.

The planner runs a search — in practice a backward A* from the goal over the action graph — and finds a sequence of actions whose combined effects transition from the current world state to the goal state. That sequence is the plan. The AI executes the first action in the plan; on completion, it re-plans in case the world has changed.

A typical plan in combat: the world state says target_position_known = true, weapon_loaded = false, in_cover = false, target_can_see_me = true. The goal is target_neutralized = true. The planner might produce:

  1. MoveToCover (effect: in_cover = true, target_can_see_me = false)
  2. Reload (effect: weapon_loaded = true)
  3. LeanOutOfCover (effect: target_can_see_me = true, has_shot = true)
  4. FireAtTarget (effect: target_neutralized = true — if shot succeeds)

The AI moves to cover, reloads, leans out, shoots. What the player sees is coherent behavior: not just "shoot," but "duck, reload, peek, shoot" — a sequence that looks like thinking.

The Emergence of Flanking

The flanking that F.E.A.R. became famous for was never written as a behavior. It emerged from the planner.

Here's how. The action set included:

  • MoveToFlankPosition — precondition: flanking_route_exists = true, weapon_loaded = true. Effect: at_flanking_position = true, target_can_see_me = false (during the move).
  • FireFromFlank — precondition: at_flanking_position = true, weapon_loaded = true. Effect: target_neutralized with high probability (flanking shot bypasses cover).

When the player was in cover such that direct fire was blocked, the planner's search would find direct-fire sequences failing (blocked by the cover effect), but the flanking sequence would succeed. The planner would select the flanking plan. The AI would execute: move to flank position, fire from flank.

Combined with the level design — Monolith's environments had plenty of flanking routes — and the barks ("I'm going around!" "He's pinned down!" "Flanking left!"), the effect was that the AI visibly went to solve the problem by flanking.

Players interpreted this as the AI planning its tactics. They were, technically, correct. The AI was planning. The planning wasn't deep — maybe 4-8 actions in a typical plan — but it was real, and it was responsive to the situation.

What made it feel intelligent wasn't the planning itself. It was three things together:

  1. The planner's output varied with situation — different plans in different contexts, so enemies never did the same thing twice in a row.
  2. The animations were crisp and unique per action. When the AI kicked over a desk for cover, it played a specific, recognizable animation. You saw the action and understood it.
  3. The barks narrated the plan. "Taking cover!" "Reloading!" "Flanking left!" The player heard the plan as it was executed.

Strip any of these and the AI would have been less impressive. The planning by itself would have been invisible. The barks by themselves would have been hollow.

Jeff Orkin on What He Was Going For

In the GDC paper, Orkin describes the design intent this way:

"Rather than hand-authoring a finite state machine, we wanted the AI characters to be able to figure out their actions on the fly. A planner is a state machine that writes itself." (Orkin, "Three States and a Plan," GDC 2005)

And, on the social layer:

"The appearance of coordination emerges not from actual coordination, but from the combination of individual planning with shared situational awareness via blackboards." (Orkin, GDC 2005)

This is the underrated insight. The Replica soldiers don't actually coordinate. Each soldier plans independently. What they share is a blackboard — a data structure containing facts about the group's situation (who's taking cover where, who called for reinforcements, who's wounded). Each soldier's planner reads the blackboard as part of world state and plans with that context.

So when one soldier plans to take cover on the left flank, the blackboard updates: "left flank covered." The next soldier planning sees that fact and, because its own plan would be redundant there, picks a different cover point. The result reads as coordinated defense. It is actually parallel individual planning over shared information.

This is a beautiful design. It decouples individual intelligence from group intelligence, and it scales — add a tenth soldier, no group-level logic changes.

What Made It Work Beyond The Architecture

The planner alone didn't make F.E.A.R. feel smart. Several non-planner elements carried as much weight:

Kickable objects. The levels were full of office furniture — desks, chairs, filing cabinets — and the AI could kick them over for dynamic cover. When a Replica soldier entered a room and kicked a desk into position, the player saw the AI react to its environment.

Audible communication. The barks were extensive, context-sensitive, and tied to blackboard events. If one soldier took damage, nearby soldiers would hear it on the blackboard and call out. The VO budget was huge.

Tight animation blending. The animations for each action were crisp and the blending was smooth. The AI never looked like it was in two animations at once, or snapping between states.

Level design for AI. The environments were designed with the AI's action set in mind. Every combat space had cover points, flanking routes, and escape paths. When you played F.E.A.R. and watched the AI exhibit behaviors, the levels were set up to allow those behaviors.

Remove any of these and GOAP would have been much less effective. The architecture and the production effort were inseparable.

Why Nobody Copied It

If F.E.A.R.'s AI was so great, why did the industry not standardize on GOAP?

Several reasons, already outlined in the chapter but worth expanding here.

Development cost. GOAP required an action library, a precondition/effect DSL, a planner with good heuristics, and extensive tuning. For F.E.A.R., this was months of Orkin's work plus tools and tuning time. Most studios don't have a specialist AI programmer who can commit to that architecture. Most studios reach for a library (behavior tree editors shipped with Unreal, Unity, or middleware like Behavior Machine) and get 80% of the feel at 20% of the cost.

Debugging difficulty. "Why did the AI do that?" is hard to answer in a GOAP system. The answer is "given the world state at that moment, the planner found this sequence as lowest-cost." Tracing through a planner's decisions is harder than tracing a behavior tree or an FSM. Shipping teams need AI they can debug on a Friday before a milestone demo.

Scripting difficulty. Level designers want to script specific moments. "In this room, I want the enemies to rush the player, then fall back to the far corner." GOAP resists scripting. The planner doesn't want to be told what to do; it wants to figure it out. The compromise — adding hooks and overrides — ends up looking like a behavior tree on top of a planner, at which point you've doubled your architectural complexity.

Behavior trees caught up. By 2010, behavior trees with enough conditional logic could produce most of what GOAP offered. The F.E.A.R. feel — dynamic, varied, coordinated — was mostly reproducible in BTs with good blackboards and good VO. The architectural overhead of GOAP stopped being worth it.

The barks did most of the work. Post-hoc analysis of F.E.A.R. AI has argued — with some justification — that much of the "intelligence" players perceived came from the barks and animation telegraphs rather than from the planner itself. Strip the barks and the animations; play F.E.A.R. silently; the AI is still good, but it's not obviously good. Subsequent shooters learned to invest heavily in barks and telegraphs without investing in planners. They got most of the F.E.A.R. feel for a fraction of the cost.

The Legacy

F.E.A.R.'s AI legacy is not the planner. It is the lessons around the planner:

  • Dynamic, varied behavior reads as intelligence more than scripted-but-sophisticated behavior does.
  • The legibility of the AI — barks, animations, telegraphs — matters more than the sophistication of the decision-making.
  • Apparent coordination can emerge from parallel individual decisions over shared information.
  • Level design is inseparable from AI design — the environment must afford the behaviors you want to see.

These lessons show up everywhere in modern shooter AI. The Destiny games, the Far Cry games, the Halo sequels, DOOM Eternal, Titanfall — all of them exhibit F.E.A.R.-descended design sensibilities even when none of them ship a planner.

Suggested Playthrough

If you have not played F.E.A.R., find a copy (the original is available on GOG and various storefronts). Play the opening two chapters. Pay attention to:

  • How the Replica soldiers enter a room — they do not all rush, they spread out.
  • The barks — count how many different lines you hear in a single combat.
  • What happens when you retreat: the soldiers pursue, but not all in a line. Some circle.
  • What happens when you throw a grenade: they scatter, and specific soldiers call "grenade!"
  • The kicked furniture moments — they appear in most firefights.

Then, after playing, come back to Orkin's paper (linked in further-reading.md). Read it with the experience fresh. You will see the architecture in the behavior.

Takeaways

  • GOAP is an architecture that produces plans — sequences of actions that transition world state toward a goal — at runtime.
  • The F.E.A.R. flanking behavior emerged from the planner finding sequences involving the MoveToFlankPosition and FireFromFlank actions, not from scripted behavior.
  • Apparent group coordination came from shared blackboards and parallel individual planning.
  • The perceived intelligence of the AI depended as heavily on the barks, animations, and level design as on the planner itself.
  • The architecture didn't catch on because behavior trees with good authoring tools reproduced most of the feel at much lower cost, and because GOAP is harder to debug and script.
  • The lessons around F.E.A.R.'s AI — dynamism, legibility, emergent coordination — are the lasting legacy, and they shape shooter AI twenty years later.