GOAP NPC Systems, Quest Design, and Goal-Oriented Quests
Sometimes, telling a story doesn’t require a story.
Introduction
This is really a reflection—or a discussion—prompted by a problem I encountered at work.
For various reasons, I came into contact with a system very similar to GOAP. My job was to design quests around the NPCs running under that system, for players to experience.
But quite a few people seemed… uncomfortable with these NPCs. On the design side, creating tightly sequenced, scripted situations often required additional features to strip away the NPCs’ GOAP behavior. On the system-development side, people weren’t sure how to give GOAP NPCs a richer role in the narrative either.
That’s what motivated this article. I’ll be talking quite a bit about relatively recent examples such as Escape from Tarkov, S.T.A.L.K.E.R., and Kingdom Come: Deliverance: how we understand these NPCs’ behavior, and how we design the player’s narrative environment and quests around it. For Tarkov, I’m only inferring that it uses GOAP, because the behavior looks quite similar. And since a discussion of Tarkov’s GOAP-like NPCs inevitably involves AI PMCs, assume I’m talking about PvE here.
GOAP NPCs
If you don’t know what GOAP is, let me describe an approach to NPC design.
Broadly speaking, NPC design tends to follow two approaches: NPCs driven by behavior trees, and NPCs driven by state machines.

A behavior tree is like a thought process that can loop. An AI executes behaviors by following nodes through a tree with multiple branches, from top to bottom. Those nodes can do all kinds of things: query the environment, move to a specified or random point, check a collision overlap event.

I really don’t know that much about state-machine design. Please excuse the crude example.
A state-machine-driven NPC, meanwhile, switches between states in response to events or other conditions. I won’t pretend to be an expert here—the only AI I’ve properly tinkered with is behavior trees. But you can think of it as the designer defining states such as attacking, taking a hit, or damage over time, with a corresponding response for each state.
Both approaches share a characteristic: they operate through some form of linear logic, or fragments of logic. For a traditionally linear game, or a boss in an action game or action RPG, that’s perfectly fine. Most of the player’s progression is controllable. Often, you can simply let a script take over the AI for a performance. Behavior trees and state machines also give you more control over finely tuned behavior, which suits the needs of a linear sequence.
But we all know what’s happening: game worlds are getting bigger, or games need more randomness within rules. Instead of a linear script, the game provides global rules and a goal you need to achieve. How you achieve it is up to you.
And that can make conventional behavior-tree or state-machine NPCs look a little… unintelligent.
So GOAP—Goal-Oriented Action Planning, the system originally used in F.E.A.R. back in 2004—has come back into the conversation.1 Whether it’s a game structured around individual raids, like Tarkov, or an open world like Kingdom Come: Deliverance II, these systems have been used to build NPCs with good results. Again, Tarkov hasn’t said that its AI uses GOAP; some of the AI behavior in the release version just looks very much like it. KCD2’s NPCs, on the other hand, are built using GOAP.

At GDC 2025, Warhorse discussed using GOAP to build NPCs in Kingdom Come: Deliverance II: Combining GOAP and MBTs to Create NPCs’ Behaviors.
That raises a problem. We know the advantage of GOAP NPCs: an NPC determines its current Goal from the World State, then executes the corresponding Actions. But it’s a little… too hard to control. With its own Goals and Actions, the AI decides what to do for itself. A designer can hardly guarantee that it will act exactly as intended. So in authored sequences, GOAP behavior is usually exposed only in limited ways, or reserved for combat AI and switched on when combat begins.
But a game built around GOAP is not incapable of narrative. Quite the opposite: because of its emphasis on rules and goals, it can communicate narrative through gameplay particularly well. We just need to change how we think. Step outside the traditional approach of controlling a quest’s sequence, and start designing around the player’s behavior and psychology.
Players play by instinct
If you’ve read Let Players Play by Instinct — A Murloc's Guide to Quest and Narrative Design, Part IV, you’ll know that I introduced a concept there: a quest model driven by player behavior.

The player-driven model
Establish the situation
- Give the player information about the current situation.
- Establish and verify the abilities available to them.
- Build their understanding of the situation.
Understand the current circumstances
- Design an event around the player’s existing abilities.
- As they use those abilities to respond, guide them toward new abilities—or a new understanding of what is happening.
Establish a goal
- Build a new goal around those new abilities.
- That goal might come from confidence gained through a new ability, or from a strategy for dealing with the situation after receiving new information.
Act / encounter a change
- Design a new event or situation around the goal.
- Let the player use what they have gained to explore this new situation, refine their abilities, or encounter another change.
Step outside quest design for a moment. Every time a player faces a challenge, enters unfamiliar surroundings, or encounters an event, they begin this thought process for themselves and use it to work out a solution.

Let’s assume you’ve played Escape from Tarkov. You’re a newcomer, and other players or AI bosses have already put you through the wringer a few times. You’ll naturally start developing a sense of which maps and areas are easier or harder.
- You might think the new area of Interchange isn’t too difficult because it only spawns Scavs—but head into “IKEA,” and you may have to face Killa, laughing like he owns the place.
- You might be doing fine on Ground Zero during the beginner stage, but have heard that bosses appear there once you reach level 21, and that they’re no joke.
- Or you might know that Factory has a simple layout, but it’s small. A lunatic with a sledgehammer could turn up at any moment to say hello.
Notice something? None of those impressions of places, bosses, or maps came from the game’s plot or quests. They came entirely from your own repeated visits.
In other words, this is a narrative arising from your instinctive responses while playing. You form an initial picture of the map, understand the current circumstances through your experience and present condition, set a goal before entering, and then go in and act.
Before the full release, Tarkov’s approach to opening up maps was downright merciless. Our beloved Tsar Nikita didn’t care whether your first trip as a beginner was to Factory or Customs. Everything except The Lab was thrown at you from the start.

The original map-selection screenshot labels The Lab, Woods, Factory, Interchange, Customs, Reserve, and Shoreline. Streets of Tarkov, Suburbs, Town, Lighthouse, and Terminal are marked as not yet available.
For the full release, though, Tsar Nikita changed that approach and put unlock conditions on the maps. You could call the new system well reasoned—or not. Beginners are limited to Ground Zero and Interchange. Both have relatively simple structures, but also bosses that present a challenge. Players can learn Tarkov’s basics there: AI behavior, factions, the areas within a map, loot locations, extraction, and so on.

The revised Interchange really does have a clear structure. Inside and outside the mall almost feel like two different games.
At the same time, if you think those two maps give you free rein, you can still run into Killa and Tagilla, the guy with the sledgehammer, in Interchange’s “IKEA.” Both are a lot for a beginner to handle. Nikita still makes sure Interchange shows you how brutal this game can be.
That forces players to learn the rules through the instinctive process I described, then play according to what they’ve learned. A quest narrative emerges naturally from their understanding of the rules. They set their own goals. They know why they’re entering a raid, what they’re trying to do, and which route they intend to take. Their experience then depends on whether the GOAP-like NPCs behave as their understanding of those rules predicts.
In other words, the player learns the game within this situation, and the process of learning creates a narrative of their own.
Sounds good. But awareness of the environment alone isn’t enough to create that self-generated narrative when a player enters a map. They may still lack a reason to go in at all.
And practically every game using this kind of GOAP system—Fallout 3, F.E.A.R., Tarkov, S.T.A.L.K.E.R., Kingdom Come: Deliverance—uses a particular combination in its quest design: goal-oriented quests, and narrative driven by an environment built through the GOAP system.
Environment-driven narrative
A quest is a simple structure. That’s a convention handed down from RPGs.

A request has an objective to carry out, information about that objective, and a reward.
As role-playing elements became richer, quests accumulated all kinds of additions. An NPC might tell you a vivid story, show you a performance, or give you more varied things to experience on the way to the objective.
Under those expectations, quests became more explicitly sequenced. And so we arrived at the idea of the quest step.
Designers habitually use the linear, staged nature of quests and steps to build controlled sequences. We divide a quest into macro and micro objectives. The micro objectives are the steps guiding you through what to do, one by one. The macro objective is the reason you set out on the journey in the first place.

In practice, a step often also marks the beginning of a scripted sequence. That makes it easier to replay the scripts when the player loads a save or reconnects.
Usually, the purpose is to use steps to create more controllable narrative content. It’s a little like the checkpoints in older Call of Duty games: reaching a checkpoint often means that the next stage of a performance is about to begin. When the trigger associated with a step fires, we might establish a situation in the environment, play a Sequence or Timeline, run NPC dialogue, or start a scripted scene.
All of this serves two purposes from the player-behavior model above: establish the situation and understand the current circumstances. By mandatory or partly mandatory means, it creates a goal that you believe you should pursue right now, nudging you into the next action.
So the game is effectively putting on a performance centered on the player, right? Everything is shoved right in your face. The scripts and behaviors only happen in front of you.

But in a world designed around GOAP, the AI can decide its own Actions. Designers can only constrain it more broadly through Goals and World State. It’s difficult to create that same experience of placing every beat directly in front of the player.
That also means, though, that the game is operating according to a set of rules. Those constraints include the game’s global rules, the design of its map regions, and the Goal lists of its GOAP AI.
The rules determine the relationships between NPCs, players, and the world. Through their actions, NPCs enact and confirm those larger relationships. The player then needs to be able to interact with them, or at least become part of the experience, in order to perceive them.
None of this depends on the quest or objective currently assigned to the player. It exists according to a World State. That state may come from another system, or from Actions the AI produces on its own in the scene. Two groups of AI fighting, for example, might draw in more AI and cause them to change their Goals.

Something like the effect of A-Life in S.T.A.L.K.E.R.
I call this environment-driven narrative. It isn’t created through a quest’s authored narrative or sequence. It is narrative behavior that emerges from rules and the GOAP system. It doesn’t rely on the designer explicitly specifying that a particular step or trigger must spawn a particular unit in a particular place and make it perform a particular action. Instead, the behavior arises naturally from the rules.
The randomness has limits. Its main effect is on how the player judges the situation and their current circumstances. It might arise while they’re pursuing a goal, as they first enter an area, or even just in stories passed between players.
Usually, this is a matter of doing the work up front. Design the faction relationships, the regions of the map and the factions distributed through them, and the GOAP behavior of each faction’s NPCs. Then let them run. The aim is to give players an impression of the area—and encourage them to pass that impression on to others.
Once you’ve done that, you only need one fairly simple thing: put a quest into this situation whose goal is clear, but whose means of completion are open. A goal-oriented quest.
Goal-oriented quests
Designing these quests is fairly straightforward. Use your game’s factions, the narrative you want players to experience, or something you want to teach them to create a motive for entering the map.
These quests have a characteristic in common: their objectives are clear and sparse. Usually, they ask the player to kill something, enter or leave an area, obtain an item, or interact with something. In other genres, that might extend to talking to an NPC, taking a photograph, and so on.
Through environment-driven narrative, we’ve established a situation and given players an existing impression of that area. When we offer them the quest, they naturally evaluate its objective against the complexity of the place it sends them to.
Tarkov has plenty of quests notorious within its community, such as A Shooter Born in Heaven and Farming — Part 1. They take a fairly ordinary-looking challenge and place it in a dangerous environment, or add a difficult condition on top of that environment.

Imagine a player going to Factory for Farming — Part 1, which requires repairing control panels. They know Tagilla has a high chance of spawning there, and that the panels are right near him. They may reassess the difficulty of the task and rethink how to approach it.
That strengthens their impression of Factory and of Tagilla’s behavior there, which changes how they actually carry out the quest. They might kill Tagilla first, then do the repairs. Or they might gamble on him not spawning and rush straight to the panels. And once they’re in the raid, emergent NPC behavior may change the experience again. Perhaps AI PMCs attack some Scavs, cause a commotion, and draw Tagilla away. There’s your opening.
In traditional quest design, we consider Rational Level Design (RLD): using quantitative measures to evaluate a quest’s difficulty, complexity, and intensity within the flow experience. In a sequence produced by goal-oriented quests and environment-driven narrative, the flow curve instead depends on the situation emerging from the environment, and the actions the player takes after evaluating that situation against their own goal.
Of course, designers can still control the overall difficulty. We just have to look at it more broadly. We can no longer consider only the quest route and the challenges along it. We have to consider the whole map, AI behavior, and how terrain affects both the player and the AI.
At suitable moments, the quest can also deliberately create points of attraction for GOAP AI. A quest script might forcibly reposition certain NPCs, for example, or create a takeover area in which entering NPCs have their Goal priorities adjusted to produce a particular behavior.
You can also work through the rules governing Actions. Suppose you want two sides fighting in a quest area, but don’t want the GOAP AI there to attack the player of its own accord. You could put the player on a separate layer within the AI’s alertness Action, then have the quest script exclude that layer for AI in the specified area.
The AI would no longer acquire the player as a target while on alert. But if the player attacks, GOAP switches the AI into Combat, where the player becomes a valid target again. That keeps the AI from looking particularly stupid.
So what you’re really designing in this kind of quest is the pacing of objective delivery, the complexity of the corresponding environment, and the ways you can help that environment change. That’s why I mentioned Tarkov’s elaborate map locks and quest-based map unlocks in the full release. Ground Zero and the new Interchange area give beginners two relatively low-risk, structurally simple maps where they can still perceive the game’s faction relationships. Customs, Shoreline, and Woods, which act as progression gates, give them long-term challenges in more complex environments. Players have to reassess their circumstances, reconsider their equipment, and find their own ways to complete quests.
You can see a similar approach in Kingdom Come: Deliverance II, even though it isn’t an extraction game. When you first properly start exploring its world, the game strips you bare, gives you a broad goal, and leaves you to explore. Through exploration and the threat of death, you discover how to make money, what dangers are nearby, what opportunities might improve your fortunes, and which rules govern the region.
So, to sum up, one workable approach to quest design under a GOAP system is:
- Establish clear relationships between NPCs and factions through GOAP.
- Create an environment that puts enough pressure on the player to make them take the first step.
- Offer quests with clear goals and open means of completion, unlocking them according to the pacing of your content and the player’s progress through the world.
Once quests move beyond the traditional workshop model of handcrafting linear or scripted narratives, this approach can still provide a narrative experience for the player. It avoids forcing GOAP into a conventional scripted sequence, only to discover that the system doesn’t fit and the experience doesn’t work either.
The Chinese original gives 2004. F.E.A.R. was released in 2005; Jeff Orkin presented its AI at GDC 2006. See the GDC retrospective.↩