Why Open Worlds Need NPCs, Not Just Quest Markers

The argument for why open worlds need NPCs is not an argument about behaviour trees. It is an argument about information. A quest marker is a compressed instruction: a position, an icon, a distance, a state flag. It answers where and how far. It cannot answer who, why, or what happens if you don't go. Those three questions are what separate a map from a place, and markers are structurally incapable of carrying them.

This is a design argument, but it has to be paid for in engineering. So it is also about budgets: what a marker costs, what a character costs, and where the exchange rate stops being worth it.

A marker is an index entry, not a place

A marker is a transform with an icon projected to screen space, plus a radius trigger, plus a flag. That is the entire object. When we build one in the 3D game builder, it is a scene node with a position, a label, and a completion boolean. It has no presence in the world when the UI layer is off.

That matters because the player spends most of their time with the UI layer on. The mental model they build is not "there is a village north of the ridge." It is "there is a dot north of the ridge, and the dot has a number next to it." You have replaced geography with a spreadsheet column.

Then the optimisation follows. Players route between dots. They fast-travel when the game allows it, walk in straight lines when it doesn't, and ignore everything between the origin dot and the destination dot. This is not a player failure. It is the correct response to the information you gave them. You told them the interesting part is at the dot.

What a marker cannot carry: why open worlds need NPCs for tone, consequence and relationship

There are three channels a character has and a marker does not. They are not cosmetic. Each one is a design capability you lose entirely if you only ship markers.

Tone

A marker is delivered in exactly one voice: the UI's. Every entry in the log has the same typeface, the same weight, the same cadence. The urgency of a quest is encoded as a colour or an icon shape, and the player learns to read those as grammar, not as feeling.

A character's tone is delivered by performance. Whether they stop walking when they talk to you. Whether they turn to face you or keep working. How long they pause before answering. Whether they make you follow them across a room to finish the sentence.

Those are engine decisions, not writing decisions. "Stop and face" is a state with an entry condition — player within 3 m, line of sight true, agent not in a scripted route step — and an exit condition. It costs a handful of nodes and one animation slot. It changes how the identical sentence lands. You cannot ship that through a tooltip.

Consequence

A quest flag is a boolean. A marker with a false boolean is a greyed-out icon. A marker with a true boolean is a checkmark. The world geometry is identical in both cases.

A character can leave. Can stop walking a route. Can be gone when you come back, and the absence is visible, because the route they walked is now empty and the shop they ran is now shut. The player perceives that without being told, and without opening a menu.

Consequence that only exists inside a dialogue box is a statistic on a save file. Consequence that changes what is in the scene graph is something the player sees from across the street.

Relationship

Recognition is cheap to build. One flag, one alternate greeting line, one different idle animation when the player is inside the notice radius. What makes it read as a relationship rather than a variable is that it is attached to a body that has a place in the world.

Players form attachments to routine. A courier who takes the same road at the same time every day becomes a landmark. When that courier is not there, the player notices. No amount of marker customisation produces that, because markers are not in the world. They are on top of it.

The first schedule system we shipped stored elapsed time per agent. Everything worked until a scene reload, at which point every character's clock reset to zero mid-route and the whole town walked to work at once. Fix: one world clock, absolute time, agents query it rather than accumulating their own. Schedules became reload-safe and the save file got smaller, because we were serialising one number instead of one number per agent.

The cost trade-off: N markers versus M characters

Markers are close to free. Authoring one is a position and a label. Runtime is one screen-space projection per visible marker per frame, and you can cull the projection pass by frustum and distance without anyone noticing. This is why teams add them: the marginal cost of the hundredth marker is near zero, so the hundredth marker always gets added.

Characters are not free, and the cost is not where people expect it. The expensive parts are not the model or the texture. They are the navmesh area they require, the decision tick they consume, the avoidance queries they generate when two of them meet in a doorway, the save state they serialise, and the authoring hours per character once they have a schedule and dialogue.

The mistake is treating this as a straight substitution. It is not. Markers are the addressing layer; characters are the content layer. Markers point at things. If nothing is there, you have built an index for an empty shelf, and the player will find that out at the first dot.

The practical framing we use: spend markers like they are cheap, because they are, and spend characters like they are expensive, because they are. Then make sure the ratio is not inverted. A world with two hundred markers and four characters is a checklist with four exceptions. A world with twenty markers and twelve characters is a place.

Why open worlds need NPCs to make markers mean anything

A marker is a pointer. Pointers are only as good as what they point at, and a pointer that resolves to "a chest containing a sword" is honest — the marker was never pretending to be more than a delivery address. A marker that resolves to an empty plaza is a lie of omission, and players feel it even when they cannot name it.

The stronger version of the argument is about what a marker becomes once characters exist. In a marker-only world, the marker's job is: this is where the content is. In a world with characters, the marker's job changes to: someone told you to go here, and that someone is standing behind you. The dot is now a record of a conversation rather than a piece of level geometry with an icon on it.

Same UI element. Same code. Completely different object. That is the cheapest upgrade available to an open world, and it costs nothing but the characters.

Low detail plus consistent behaviour beats high detail with none

The counter-intuitive part: fidelity and aliveness are not the same axis, and past a low threshold, fidelity actively works against you.

Players read agency from contingency — the agent's state depends on the player's state. A character who pauses because you are standing in the doorway is alive, regardless of polygon count. A photoreal character standing on the same spot for forty hours of play is furniture, and the higher the fidelity, the more obviously it is furniture, because a detailed character doing nothing invites closer inspection.

So the design move is to buy consistency with the fidelity you would have spent. Cheap agents can afford to always run. If an agent costs a few milliseconds of CPU per frame, you cap the simultaneous count low, and the natural next step is to only tick the ones near the player. That destroys the illusion, because the player sees the town freeze the moment they walk out of the activation radius and unfreeze when they come back.

Our defaults, which are deliberately boring:

• Agent decision ticks at 4–8 Hz, decoupled from the render rate. Interpolate positions at render rate so movement stays smooth.
• Full pathfinding only on route change, not per frame. Route changes are rare by design — that is what a schedule is for.
• Beyond roughly 40 m, agents drop to position-only updates: no animation evaluation, no avoidance queries, no navmesh re-path. They still move. They still arrive on time.
• Animation LOD past about 15 m: blend tree collapses to a single loop per state instead of a layered set.
• Off-screen agents keep simulating. That is the whole point. A town that stops existing behind you is not a town.

We shipped an early build where agents only ticked inside a 25 m radius. The playtest note that killed the feature was not about performance. It was a player saying the town felt like a set that got built when they walked in. They had walked a loop around the square out of curiosity and watched the blacksmith disappear and reappear in a different pose each time.

The isometric and miniature case: Mini World and The Cyclops' Island

The miniature camera makes the argument visible, because it removes occlusion entirely. An overhead or isometric view shows the player everything in frame at once. There is nowhere to hide an empty space.

In Mini World, an empty plaza reads as empty. Not "quiet", not "between events" — empty. Add two characters crossing it on fixed routes at different speeds, and the same geometry changes category. It stops being a level and becomes a scene. Nothing about the art changed. The clock changed.

The Cyclops' Island runs the same test at a different scale: a small island where the read distance is short and every character is visible most of the time. That makes consistency brutal to fake. Every agent has to be somewhere plausible at every moment, because the player can see the whole board. A schedule with gaps shows up immediately as a character standing in a field for no reason.

Agent Sprite Forge sits at the opposite end of the fidelity budget from a fully rigged character: sprites with a small direction set and a short animation list, no facial rig, no layered blend tree. That is exactly the tier this argument is about. A sprite courier with eight directions and one walk cycle will out-read a detailed character with no behaviour, every time, because the player is reading the route and the timing, not the model.

Where markers still win

Markers are the correct tool for two jobs and you should not feel bad about using them.

Large-scale navigation. You cannot place a character at every fork in a four-kilometre map, and you should not try. Markers are a UI layer over distance. They cut through terrain, they work in fog, they persist when the destination is outside the loaded scene. Characters cannot do any of that.

Repeated objectives. Forty collectibles do not want forty conversations. Nobody is served by making a player listen to a monologue before picking up the eleventh shard. Markers respect the player's time on chores specifically because they carry no tone.

There are a few smaller wins too: markers do not depend on audio, they do not move, they are readable at a glance on a small screen, and their state is a boolean, which makes them trivial to test and snapshot. An NPC's state is a running simulation, and debugging a simulation is a different kind of work.

The rule we use:

Markers for where. Characters for why. If a marker is answering a why question, it is answering it badly and the player will notice by about the fourth dot.

A collectible hunt we built shipped with markers only, and the completion rate was fine. What was not fine was that players described the island as "a map" in feedback. Not bad, not boring — a map. The fix was not more markers or better markers. It was three characters with routes that passed near the collectible clusters, so the island had someone standing on it.

Practical rules we use in the 3D game builder

1. Every marker should have an author. If a dot appeared in the log, some character should have been the reason. If no character gave it, the marker is a UI event pretending to be a quest.
2. Budget characters before markers. Decide your concurrent agent cap and your authoring hours first. Markers will fill whatever room is left. They always do.
3. Schedule first, dialogue second. A character with a route and no lines reads as alive. A character with lines and no route reads as a vending machine. Build the route first and see if you still need the dialogue.
4. Write the off-screen state explicitly. What does this character do when the player is not in the scene? If the answer is "nothing", you have a prop, not an NPC, and you should stop paying agent cost for it.
5. Test with the player standing still. Most NPC bugs only appear when the player stops moving and the agent has to react to a stationary obstacle. Walk into a doorway and wait. Watch what happens to the traffic behind you.
6. Two agents, one route, different timing. This is the cheapest possible test of whether a scene reads as alive. If it does not, the problem is your clock, not your art.

The test we run before shipping a world

Turn the UI layer off and walk the scene for sixty seconds. If nothing is moving, or if the only things moving are wind and water shaders, the world is a level. If something crosses your path that you did not trigger, the world is a world.

That is the whole argument for why open worlds need NPCs. Not because characters are more sophisticated than markers, but because markers are a compression format, and compression only works when there is something underneath to decompress. Put the characters in first. Then let the markers point at them.

Keep going

• what a non-player character is
• what NPCs are
• NPCs in video games
• NPC behaviour explained
• The Cyclops' Island
• Little Ritual

Build the world it walks in

A character, a tile or a model is a material with nowhere to stand. Every world on the 3D game builder was made from one written description and published as a page you can play — including Mini World and The Cyclops' Island.

Open the 3D Game Builder →