Summary
AI experience management is the use of an AI system to monitor the player’s actions, infer something about their current experience, and then adjust the game so the experience stays within a desired range. In the interactive-narrative literature this is often called a drama manager or AI game master. The goal is not simply to win against the player, but to shape pacing, tension, challenge, surprise, or story progression in ways that improve the overall experience. (Bulitko et al., Game AI Pro 2, see source-game-ai-pro-2; Yannakakis and Togelius, Artificial Intelligence and Games, see source-ai-and-games)
Key ideas
- Player model first: The system needs some estimate of what the player is doing or feeling: skill, frustration, curiosity, preferred play style, or narrative appetite.
- Interventions second: Once the system has a model, it chooses an intervention: spawn different content, delay a story beat, move resources, alter encounter pressure, or surface a different branch.
- Experience targets: The adaptation is guided by target variables such as dramatic tension, challenge, pacing, or variety rather than by one mechanical metric alone.
- Local vs global adaptation: Some interventions are small and immediate (change the next encounter); others are long-horizon (change the campaign’s structure or future plot content).
- Authorial limits matter: Experience management works best when the set of allowed interventions is explicit. If the AI can change everything, it becomes opaque and difficult to debug.
Difficulty adjustment vs tension and pacing management
The two are often confused because both watch the player and change the game. The table below is a synthesis of this page and psychology-of-adaptive-play rather than a comparison taken from one source:
| Dynamic difficulty adjustment | Tension and pacing (drama) management | |
|---|---|---|
| Goal | Keep challenge matched to skill, so the player is neither bored nor overwhelmed (see flow) | Shape an emotional curve over time: build-up, peak, relief, surprise |
| What it measures | Performance: deaths, damage taken, accuracy, completion time | Inferred intensity or story state: recent pressure, time since the last peak, which beats the player has seen |
| Typical interventions | Enemy health or damage, aim assist, number of enemies, checkpoint spacing | When and where pressure arrives, recovery beats, resource placement, which story beat or branch comes next |
| Time scale | Usually local: the next fight or attempt | Often longer: the rhythm of a level or the shape of a campaign |
| Main risk | Feels rigged or patronising if noticed, and can punish players who improve | Feels arbitrary or manipulative if the pressure has no readable cause |
| Example | A racing game’s rubber-banding (a common genre convention) | The AI Director in left-4-dead, which varied special-infected spawns and item placement according to how the survivors were doing (Bycer, 20 Essential Games to Study, see source-20-essential-games-to-study) |
Arguably the clearest test is the target variable: if the system is trying to hold a success rate, it is difficulty adjustment; if it is trying to hold a shape over time, such as a relief beat after every peak, it is experience management. The ExperienceManager sketch below is the second kind, and one system can do both.
Emergence versus pacing
Designers who want emergent AI face an apparent contradiction. Emergent behaviour, where outcomes arise from agents following local rules rather than from a script (see emergent-design), produces surprise and replayability. Left alone, however, it can also produce long lulls, unfair pile-ons and deaths the player cannot read. Pacing wants the opposite: a designed shape of build-up, peak and relief.
The usual resolution is to put the emergence and the authorship at different levels: individual agents decide how to act from local rules, while a separate layer decides how much pressure the player faces, when, and where. The pacing layer does not puppet individual moves. It controls the inputs to the agents: how many there are, which of them may attack, and how long the gaps are.
What the evidence says
Booth’s account of the Left 4 Dead AI is the clearest worked example (Booth, The AI Systems of Left 4 Dead, Valve, 2009):
- Two of the game’s four stated AI goals are “Promote Replayability” and “Generate Dramatic Game Pacing”. Static enemy placement fails the first because “Players are good at memorizing all static locations”, which “Removes suspense of not knowing what will happen next”.
- Enemies and loot are therefore placed procedurally using what Booth calls “Structured Unpredictability”: the where varies, within structure taken from the navigation mesh, flow distance towards the exit, and what the survivors can see.
- The pacing layer is a small state machine driven by an estimate of each survivor’s “emotional intensity”, which rises with damage, incapacitation and nearby kills, and decays over time but not while infected are actively engaging. Build Up creates the full threat population until intensity crosses a peak threshold; Sustain Peak continues for 3–5 seconds; Peak Fade switches to a minimal population and waits for intensity to fall and for “a natural break in the action”; Relax holds the minimal population for 30–45 seconds, or until the survivors have travelled far enough, then Build Up resumes.
- Booth stresses that the “Algorithm adjusts pacing, not difficulty”: the “Amplitude (difficulty) is not changed, frequency (pacing) is”, and “timing and location of peaks will differ each time the game is played”. Boss encounters are explicitly exempt from the pacing system.
Booth’s framing differs from the one on left-4-dead, which, following Bycer, describes the Director as procedural difficulty scaling. Booth’s own slides say it changes the timing of pressure rather than its strength, which places it on the experience-management side of the table above.
The same split appears at the scale of a single fight. Token systems let every enemy behave freely while gating who may actually land a hit, or how many may attack at once (combat-coordinator-pattern); the Kung-Fu Circle used in Kingdoms of Amalur: Reckoning budgets attack capacity around the player in the same way (Straatman and Verweij, Game AI Pro 360: Guide to Tactics and Strategy, see source-game-ai-pro-360-tactics-strategy). Falstein’s rules for game AI pair “Add a small amount of randomness to AI calculations” with “Make the effects of the AI visible to the player” (Falstein, The 400 Project, see game-ai-agent-design), and npc-behaviour-readability adds that telegraphs need time, or the player reads an attack as unfair rather than intelligent.
Techniques
| Technique | What stays emergent | What the designer authors | Where to read more |
|---|---|---|---|
| Director or pacing state machine | Which threats appear, where, and how agents fight | When pressure arrives, how long peaks and relief last | Booth (above); the ExperienceManager sketch below |
| Attack tokens and slots | Positioning, flanking, which agent goes next | Maximum simultaneous attackers; minimum gap between hits | combat-coordinator-pattern |
| Telegraphs with a minimum duration | Which attack is chosen, and when | A floor on wind-up time, so every attack can be read | npc-behaviour-readability |
| Bounded randomness | The exact choice among good options | The range: pick among the top few scored actions, or jitter reaction times between a minimum and maximum, never uniformly over everything | utility-ai, game-ai-agent-design |
| Explicit limits on interventions | Everything not listed | The list of things the director may change, and the things it must not (Booth’s boss encounters) | “Authorial limits matter” above |
The bounded-randomness row is an interpretation of Falstein’s “small amount of randomness” rather than a technique taken from one source. The common thread, arguably, is that unpredictability is welcome at the level of individual actions, but pacing should be predictable in shape: the player cannot know where the next attack will come from, but can trust that a lull follows a peak.
A minimal pacing layer in the spirit of Booth’s state machine, with agents that ask for permission rather than being told what to do (values are illustrative, not Valve’s):
public enum PacingPhase { BuildUp, SustainPeak, PeakFade, Relax }
public class PacingDirector : MonoBehaviour
{
[SerializeField] private float peakIntensity = 0.8f, decayPerSecond = 0.05f;
[SerializeField] private float sustainSeconds = 4f, relaxSeconds = 35f;
[SerializeField] private int maxAttackers = 3; // the authored ceiling on simultaneous pressure
public PacingPhase Phase { get; private set; } = PacingPhase.BuildUp;
public float Intensity { get; private set; } // 0..1, raised by damage, near misses, nearby kills
private int attackers;
private float phaseTime;
public void AddIntensity(float amount) => Intensity = Mathf.Clamp01(Intensity + amount);
// Agents choose HOW to attack for themselves; the director only decides WHETHER pressure is allowed now.
public bool TryTakeAttackToken()
{
bool open = (Phase == PacingPhase.BuildUp || Phase == PacingPhase.SustainPeak) && attackers < maxAttackers;
if (open) attackers++;
return open;
}
public void ReturnAttackToken() => attackers = Mathf.Max(0, attackers - 1);
private void Update()
{
phaseTime += Time.deltaTime;
if (attackers == 0) Intensity = Mathf.Max(0f, Intensity - decayPerSecond * Time.deltaTime);
switch (Phase)
{
case PacingPhase.BuildUp: if (Intensity >= peakIntensity) Enter(PacingPhase.SustainPeak); break;
case PacingPhase.SustainPeak: if (phaseTime >= sustainSeconds) Enter(PacingPhase.PeakFade); break;
case PacingPhase.PeakFade: if (attackers == 0 && Intensity < peakIntensity) Enter(PacingPhase.Relax); break;
case PacingPhase.Relax: if (phaseTime >= relaxSeconds) Enter(PacingPhase.BuildUp); break;
}
}
private void Enter(PacingPhase next) { Phase = next; phaseTime = 0f; }
}Each enemy runs its own behaviour tree or utility AI, and its attack branch begins with director.TryTakeAttackToken(). In Build Up the enemies press the player in whatever way their rules produce; in Relax they still patrol, search and reposition, but no new attack starts, which gives the player a breather without the AI visibly freezing.
In practice
A simple experience-management loop looks like this:
- Record telemetry and current story/game state.
- Update a compact player model.
- Score the available interventions against the desired experience target.
- Apply the best-scoring intervention that does not violate design constraints.
Unity/C# sketch:
public class ExperienceManager : MonoBehaviour
{
[SerializeField] private float targetTension = 0.65f;
[SerializeField] private EncounterDirector director;
private PlayerModel model = new();
public void RecordCombatOutcome(float damageTaken, float completionTime)
{
model.UpdateFromCombat(damageTaken, completionTime);
}
public void EvaluateNextBeat()
{
float tensionGap = targetTension - model.CurrentTension;
if (tensionGap > 0.2f)
director.SchedulePressureBeat();
else if (tensionGap < -0.2f)
director.ScheduleRecoveryBeat();
else
director.ScheduleNeutralBeat();
}
}This is deliberately small-scale, but it captures the core idea: maintain a player-facing target state and select future content accordingly.
Evidence
- Bulitko and colleagues describe the AI game master as a bundled system that monitors player actions and modifies the story dynamically rather than treating the narrative as fully fixed. (Game AI Pro 2, see source-game-ai-pro-2)
- Artificial Intelligence and Games places experience management alongside player-modelling and procedural-content-generation-ai: the system needs a model of the player and a space of possible content adjustments in order to work.
- The approach is strongest in relatively constrained games because the intervention space is smaller and easier to author. Open worlds make the state space much harder to manage cleanly.
Implications
- Experience management connects programming/AI directly to narrative-design, player-modelling, game-analytics, and flow.
- It is best thought of as curation, not omniscient control. The AI should shape probabilities and sequencing, not completely replace authored structure.
- the course adds a psychological warning: players often accept adaptation when it feels responsive and fair, but not when it feels opaque or rigged. That makes readability and trust part of the implementation problem, not just tuning details. (course lecture series, see source-player-psychology-lectures)
- The ethical boundary matters. A system that adapts to improve readability or maintain flow is different from a system that adapts purely to maximise monetisation or retention at any cost.
Open questions
- How far can experience management scale beyond relatively linear or hub-based games into large open worlds?
- What is the smallest useful player model for a student project: skill only, or skill plus preference plus frustration?
- Which interventions are most legible to players without making the adaptation feel artificial?
Related
- source-player-psychology-lectures
- environmental-storytelling — World state that answers player choices
player-modelling · game-analytics · emergent-design · combat-coordinator-pattern · npc-behaviour-readability · left-4-dead · procedural-content-generation-ai · narrative-design · flow · psychology-of-adaptive-play · overview-artificial-intelligence-in-games · source-game-ai-pro-2