Companions That Help: Designing an AI Ally Players Don't Resent

The most common feedback a companion character gets in a playtest is not about its personality, its combat contribution or its dialogue. It is some version of "it kept blocking the doorway." A team can spend a month on a hand-authored follow animation set and a reactive bark system, and the thing the tester remembers is getting wedged behind an ally in a corridor.

That is the default outcome for AI allies, and the cause is structural. A companion is the only character sharing the player's space for hours, so every mistake lands at point-blank range; enemies get to be stupid in the distance. The good news: most companion failures are not AI research problems. They are design problems with known answers, specifiable in a document before anyone opens a behaviour tree.

Decide what the companion is for

Most broken companions are broken because nobody wrote the job down. "She follows you and helps in fights" is not a job; it is two jobs competing for the same navigation budget. Pick one primary role and at most one secondary. These five cover almost every shipped companion:

Role	What it does	Shipped example	Main risk
Combat support	Adds damage, stuns, heals, draws aggro	Atreus in God of War (2018)	Steals the player's kills or trivialises fights
Resource mule	Hands over ammo, health, currency	Elizabeth in BioShock Infinite	Becomes a vending machine with a face
Navigation guide	Points, leads, unlocks the route	Trico in The Last Guardian	Player follows blindly, stops exploring
Narrative presence	Reacts, comments, bonds	Ellie in The Last of Us	Repetition destroys the illusion
Puzzle actor	Stands on plates, boosts, carries	Yorda in Ico	Turns into a physics object to be shoved

Write the role down next to the companion's relationship map, because the role is a relationship: a resource mule is a subordinate, a navigation guide is an authority, a narrative presence is a peer. Players read that hierarchy from behaviour long before they read it from dialogue.

Rule one: never block, never get lost

Before anything clever, buy out the two failures that produce the loudest playtest complaints.

Never block. Either remove player-companion collision entirely, or make push-out resolve in favour of the player. Add a "get out of the way" behaviour that fires when the companion sits inside a doorway volume, on a ladder base, or within arm's reach of a player walking into it. What collision cannot solve, teleport can.

Never get lost. The leash is the single most important number in companion design. A starting set of values that tends to survive first contact:

• Comfort radius: 3–5 m. The companion idles here when the player is stationary, never directly in front of the camera.
• Follow trigger: 6 m. Beyond this it moves, matching player speed with a 10–15% overspeed cap so it can catch up without looking like it is racing.
• Hard leash: 20–25 m or two rooms. Beyond this, start recovery.
• Teleport window: 1.5–2 s off-camera. Recovery means teleporting to a navmesh point behind the player and out of view. If the player never sees it happen, it did not happen.

Teleporting a companion feels like cheating the first time you ship it. It is not. Companion-heavy games lean on it routinely, and the players who catch it are far outnumbered by those who would have caught the ally stuck on a crate.

Make the help legible — and capped

A companion that helps invisibly gets no credit; one that helps too much takes the player's win away. Both are tuning problems, so give them explicit budgets rather than letting them emerge from the behaviour tree. A workable combat-support budget for a single-player action game:

• Damage share: 10–20% of encounter damage. Enough to feel like a partner, not enough to clear a room.
• Kill rights: 0 on named enemies. The companion can stagger a boss; it cannot land the killing blow.
• Utility cooldowns: 8–20 s. Long enough that the player notices the help arriving, short enough to feel reliable.
• Revive or save: once per encounter, with a visible 3–5 s window the player can watch.

Then make each contribution readable: distinct audio cue, distinct hit colour, distinct animation silhouette. If a tester cannot tell you what the companion did after a fight, that budget bought nothing.

The invulnerability question

Three options, and only one is cheap:

1. Invulnerable. No fail states, no babysitting, no pathing into fire. Costs tension, and the fiction has to tolerate it.
2. Downed, not dead. The companion drops and needs a revive: a clean failure loop, at the cost of a revive mechanic and a "cannot be downed twice in ten seconds" rule.
3. Fully mortal, mission fails. Only pay this if protecting the companion is the game. Escort failure is the fastest way to turn a character into a liability players resent.

For a small team, option 1 for most of the game plus option 2 in a handful of authored encounters is the best value per week of work.

Stealth needs an explicit lie

Stealth is where companions break most visibly: honest simulation produces nonsense, with the ally walking through a guard's vision cone and the player punished for a decision they did not make.

So write the lie down. The usual and correct one is that companions are invisible to enemy perception until combat has already started. Add a second rule — the companion mirrors the player's stance, crouching or going prone within 0.3 s — so the lie is never contradicted by the animation. Players accept a world that behaves consistently; they notice the cheat only when the body language disagrees with it.

Say less than you think

Companion dialogue is the fastest-decaying content in your game: the trigger that fires once an hour in your head fires every ninety seconds in a real session. Rules worth enforcing in your dialogue trees:

• One hint line maximum per puzzle, gated behind 45–90 s of no progress, then silence.
• A 20–40 s global cooldown on all companion barks, so two systems never speak at once.
• At least four variants for any line that can trigger more than once per level, and no repeat until the pool is exhausted.
• Combat and ambient lines in separate priority bands, combat always winning.

Tune it as a system, not a character

The workflow that gets companions shipped:

1. Write the role card — one paragraph: job, secondary job, what it never does.
2. Build the leash and anti-block rules first. No combat, no dialogue. Walk a whole level with the companion only following, and fix pathing until that is boring.
3. Add one contribution — the one the role depends on — and tune it against the budget table.
4. Add barks last, once the behaviour reads correctly in silence.
5. Playtest with the sound off once. If the role is unclear without audio, the behaviour is not doing its job.

Keeping those numbers in a balance sheet beside your other tuning data — rather than buried in a behaviour tree — is what lets a designer change the follow distance on a Friday without filing a ticket. The role card belongs with your characters and mechanics documentation, so the writer, the animator and the programmer all read the same definition of what this character is allowed to do.

The playtest checklist

Run these eight checks every milestone. Each maps to a complaint that recurs in real sessions:

• Walk into the companion in a doorway, on stairs, and at a ladder base. Can the player always pass?
• Sprint away for 60 s through three rooms. Does it recover off-camera, without a visible pop?
• Stand still for 60 s. Does it settle, or circle you forever?
• Enter a stealth section. Does it ever break your cover?
• Clear a fight. Can the tester name what the companion did?
• Fail a puzzle for two minutes. How many times does it repeat the hint?
• Save and reload mid-encounter. Does it return to a sane position and state?
• Play a full hour. Which line do you now hate?

That last question is the one that matters. A companion is the only character the player cannot walk away from, and the difference between a beloved ally and a punchline is rarely the AI. It is whether someone decided, in writing, what the character was for — and then protected the player from everything else it might do.