Narrative Sim

sharing memories with NPCs

Sat, 29 Aug 2026 00:00:00 GMT

[interactive block — read it on the site]

A Budget of Consequence

Thu, 27 Aug 2026 00:00:00 GMT

A playtester spent a conversation needling an innkeeper. Third jab about her cooking, and she told them to sleep somewhere else tonight. For the rest of that in-game evening, the common room was actually closed to them.

I did not script that outcome. I also did not let the AI reach in and decide it on its own. The truth is in between.

The blank check problem

If a language model can change the world just by asserting it, eventually it will, and not always in ways you would sign off on. It will be inconsistent between runs, and players will learn to talk it into things. "Actually, you already gave me the key" is not a sentence you want to be load-bearing.

I have written about turning dialogue into real mechanics. This post is about the step before that: deciding what a character is even allowed to do to you in the first place.

The menu

Before a conversation, the engine works out a short list of consequences that would make sense right now. It weighs who this NPC is, how much authority they actually have, whose ground you are standing on, and how the encounter is going.

A field hand cannot bar you from anywhere. An innkeeper can close her own inn to you and nothing else. A guard can decide you are worth keeping an eye on.

The model receives that menu and a rough budget. It can spend nothing. It can pick one thing. It cannot invent a new option that was not on the list.

right now this NPC can:
  - refuse to serve you
  - ask you to leave for tonight
  - remember this as an insult

budget: enough for one real consequence

The engine still gets the last word

The model proposes; the engine checks the choice still makes sense in the half-second since the menu was drawn, and then applies it. There are caps on how far a single conversation can move things. Everything is written down. The innkeeper's ban lifts on its own after a while.

What it feels like to play

Conversations get weight. You can feel when one is load-bearing before it goes wrong.

And when it does go wrong, it is legible afterward. You know exactly which line cost you the room. Because the menu is short and hand-built, the world stays coherent in the other direction too: nobody signs over a title deed because you were charming for ninety seconds.

NPCs Who Remember That One Time

Thu, 20 Aug 2026 00:00:00 GMT

A playtester came back to a district they had not visited in a few in-game days. A guard who had waved them through before now stopped them, asked where they were headed, and looked in their bag.

The playtester sighed and said, "he is still mad about the gate thing." I had never told them a "gate thing" was being tracked. It just was.

No reputation bar

Most games hand you a meter and let you manage it. I do not show one, because a single number is not how people actually hold a grudge. Grudges are specific, they are personal, and they fade at different speeds depending on what caused them.

So instead of a global score, each NPC carries their own sense of you. The innkeeper's opinion and the guard's opinion are separate things, and neither of them is a slider you can watch move.

How it reaches the conversation

When you talk to someone, the engine gives the model a short read on where you stand with that person. Warm. Wary. Owes you a favor. Has not forgiven you yet. It does not replay your whole history; it just sets the temperature.

The model does the rest. The guard does not read your rap sheet aloud. He is simply short with you, and searches the bag he would have waved past a week ago.

It fades, and it spreads

Some of it cools off on its own. Some of it does not. And some of it travels: the guard mentions it to the other guard, and now you are dealing with two people who have heard a version of the same story. That second part deserves its own post.

What it feels like to play

You cannot grind reputation, because there is no bar to grind. You just end up with a history with people, the same way you do anywhere.

Walking back into a place you left on bad terms feels different, and you cannot un-feel it. The upside runs the same direction: sometimes someone you helped weeks ago greets you like an old friend before you have quite placed their face.

The Blacksmith Smelled the Mushroom

Thu, 13 Aug 2026 00:00:00 GMT

During a playtest last week, my blacksmith Garth stopped mid-swing, wrinkled his nose, and told the player to take "that glowing rot" outside before it ruined his steel.

I never wrote that line. I never wrote a rule that says "blacksmiths dislike mushrooms." What happened is smaller and, I think, more interesting.

What the NPC actually notices

When you walk up to someone in one of my games, the engine assembles a small snapshot of the moment: a few things you are carrying, what the NPC was busy doing, roughly what time it is, and how they feel about you already.

The important word is small. It is not "here is everything true about the world." It is closer to "here are the four or five things a person in this spot would actually clock." Garth noticed the smell, noticed he had been interrupted, and noticed his patience was already thin that morning.

The engine decides, the model phrases

Garth did not choose to be annoyed. The engine did. The item crossed a line, his mood was low, and the result was a grumpy blacksmith.

The language model's entire job was to take "annoyed, interrupted, something here reeks" and turn it into something Garth would plausibly say. I have written before about treating the model like a renderer rather than a decision-maker, and this is that idea doing ordinary work.

Why not just script it

Because the branches do not exist to be written. Item times mood times current activity times relationship times location is not a dialogue tree, it is a fog. You cannot author your way through it. But you can describe a single moment accurately and let the wording be generated fresh each time.

What it feels like to play

The world feels like it is watching. Playtesters start doing things just to find out who reacts: walking into a shop soaking wet, showing up somewhere at three in the morning, wearing the wrong colors into the wrong tavern.

Most of those little reactions do not change the plot. They just make the place feel inhabited by people who have their own bad mornings.

Turning NPC conversation logs into readable devlog posts

Mon, 11 May 2026 00:00:00 GMT

Every conversation in the game gets logged as structured JSON: who was there, what each line was, and any context the engine fed the model. When something funny or revealing happens in a playtest, I want it on the devlog. The question was how, without it becoming a chore.

The options I did not take

A screenshot is the obvious move, and it is the worst one. You cannot read it on a phone, a screen reader gets nothing, and you cannot copy a line out of it to quote later.

Hand-formatting each transcript as Markdown blockquotes is the other obvious move. It works, but every post ends up slightly different, and you lose the visual difference between the player talking, an NPC talking, and the engine's internal notes.

MDX does the boring part

This site's posts are not Markdown files, they are MDX files. MDX is Markdown that can also import and render components. Astro's content collections are happy to treat an .mdx file as a blog entry, which means inside a post I can write normal prose and then drop a real component between two paragraphs.

So I wrote one component, <DevDiary>. It takes the export more or less as-is: a day label, and a list of conversations, each with its participants and a transcript. Player lines, NPC lines, and "context memory" notes each render in their own style.

Here is one, rendered from about a dozen lines of data pasted straight into this post:

[interactive block — read it on the site]

Why this shape is worth it

The export format and the component's props are nearly the same thing, so posting a clip is paste-and-wrap. Nothing gets retyped, so nothing drifts.

When I want a new kind of content in a post, a stat block, a schedule, a before-and-after, I write one small component and every future post can use it. The post itself stays plain text: it diffs cleanly in git, it degrades to something readable if the component ever breaks, and eventually it is the kind of thing I can paste into a browser CMS and publish without touching the repo.

That last part is the actual goal. This was the first thing I built on Astro, mostly to see if the idea held up. It did.

A social roguelike: NPCs who watch, remember, and gossip

Sun, 10 May 2026 00:00:00 GMT

If you played Gates and Gossip, you know I love deep, character-driven games.

Welcome to my new 2D systemic RPG—a "Social Roguelike."

Like Gates and Gossip the narrative emerges organically from the simulation itself. To do this, two highly dynamic, interconnected systems:

NPC Awareness & Memory: Characters in this 2D world actually observe their surroundings. They notice if you drop a strange item, remember if you helped them with a task, and form real mechanical opinions based on your actions. If you chase the farm's chickens they'll react, and even spread rumors.
A Living Dialogue System: Instead of the game picking from a pre-written list of responses for an NPC, responses are generated on the fly based on mechanical truths. When you talk to an NPC, the dialogue system reads the raw mechanical state of the game—what the NPC recently witnessed, their current mood, the time of day, and their relationship with you—to generate completely natural, unscripted conversations that reflect the physical reality of the world.

You aren't just clicking through a story anymore; your physical actions in the world constantly ripple through the social fabric of the town. It’s a massive technical leap, and I can't wait to share more about how it plays!

Structuring an LLM-driven NPC sim in ECS

Sun, 10 May 2026 00:00:00 GMT

If you’ve spent any time building games with an object-oriented mindset, you’ve probably hit the wall. Not immediately — OOP feels great at first. You have a `Player` class, an `Enemy` class, maybe a nice `Character` base class they both extend. Tidy. Logical. Until the moment you need a `FriendlyEnemyWhoIsAlsoAMerchant`, and suddenly your inheritance tree looks like a family reunion nobody wanted.

Entity Component System — ECS — is the architecture pattern that solves this, and once it clicks, it’s hard to go back.

The OOP Problem, Concretely

In object-oriented game design, a game object *is* a thing. A `Guard` has methods. It *knows* how to patrol. It *knows* how to detect intruders. Its behavior and its data are bundled together, which feels intuitive because that’s how we think about real objects.

But games are full of edge cases. What happens when:

A guard gets drunk and starts wandering randomly?
A merchant needs to react to threats like a guard would?
An NPC falls asleep and temporarily stops being *anything* useful?

You end up with either deep, fragile inheritance chains or a bloated base class that has a little bit of everything — the infamous “god object.” Neither scales well. Refactoring either one mid-project is painful.

The ECS Mental Shift

ECS flips the model:

**Entities** are just IDs. Empty vessels. A number.
**Components** are plain data attached to those IDs. No logic. Just state.
**Systems** are functions that operate on entities that have a specific set of components.

A guard isn’t a `Guard` object. It’s an entity with a `Position` component, a `PatrolRoute` component, a `Faction` component, and maybe a `Schedule` component. If you want that guard to also be a merchant during off-hours? Add a `MerchantInventory` component. No new class. No refactor. Just data.

The behavior emerges from which components are present, and systems only run on entities that qualify.

Why This Matters More Than It Sounds

The power isn’t just organizational tidiness — it’s *composability at runtime*.

In a recent project I’m building (a simulation-heavy RPG engine), NPCs needed to:

Follow patrol routes
Stick to daily schedules
React to things they witnessed — a theft, a fight, someone walking around smelling like mushrooms
Have their behavior temporarily overridden by status effects

In an OOP model, each of those features risks touching a central `NPC` class. In ECS, each is its own component. A status effect that makes an NPC avoid you? That’s just attaching a `StatusEffect` component with the right data. The avoidance system picks it up automatically. Remove the component when the effect wears off. Done.

What surprised me most was how *emergent* this gets. I didn’t script NPCs confronting the player about witnessed behavior — I just built an observation pipeline that writes to a knowledge component, and a reaction system that reads from it. The confrontations fall out naturally. The status effect humor? Completely unscripted. It’s a side effect of composable, data-driven logic.

The Practical Tradeoffs

ECS isn’t without friction.

**Debugging is different.** When behavior is spread across systems rather than encapsulated in objects, tracking down why an NPC is doing something weird means checking which components it has and which systems are touching it — rather than just setting a breakpoint on a method. Good tooling helps enormously here.

**The mental model takes time.** If you’ve spent years thinking in classes, ECS feels backwards at first. You keep wanting to put logic *on* the entity. Resist that impulse.

**Queries are your friend.** The real productivity unlock is fluent querying — asking the world “give me all entities with *these* components” and getting them back efficiently. This is where purpose-built ECS libraries pay for themselves over rolling your own.

Why Miniplex Specifically

For JavaScript/TypeScript game projects, Miniplex hits a sweet spot. It’s lightweight, has an elegant TypeScript-first API, and its query system feels natural once you’ve internalized the ECS mental model. Defining a query is as simple as describing what components you care about — and it handles the entity bookkeeping so you don’t have to.

It also plays well with Phaser, which has its own scene/game object model. The trick is treating Phaser’s rendering objects as *one component* among many, rather than the center of gravity. Your simulation logic lives in ECS; Phaser just draws what the simulation says.

When to Reach for It

ECS shines when:

You have many entities with overlapping but non-identical behavior
You need to add or remove capabilities from entities at runtime
Emergent behavior from system interactions is a feature, not a bug
You want your simulation logic decoupled from your rendering

It’s probably overkill for a simple platformer with five enemy types. But if your game world has NPCs with schedules, knowledge, relationships, and dynamic status — ECS stops being a nice-to-have and starts feeling like the only sane choice.

The shift from “objects that do things” to “data that systems act on” is subtle on paper and profound in practice. Once your guard becomes an entity with components instead of a `Guard` class, a whole class of design problems quietly disappears — and a whole class of emergent surprises quietly appears.

That trade feels worth it.

Multi-provider LLM routing in a live game

Sun, 10 May 2026 00:00:00 GMT

In the last post, I talked about why Entity Component System architecture is worth the mental shift — how thinking in *data* instead of *objects* makes your game world composable in ways inheritance never could.

But there’s a follow-on problem ECS doesn’t automatically solve: once your world is a sea of components spread across thousands of entities, how do any of your systems make sense of it cleanly?

The answer, at least in my engine, turned out to be a single pattern I kept reaching for without fully naming it: **providers**.

The Problem: Systems Are Hungry

A game simulation has a lot of mouths to feed. At any given moment:

A dialogue system needs to know everything relevant about the current conversation — who the NPC is, what they’ve witnessed, what they think of the player, what the player is carrying
A behavior AI needs to evaluate dozens of potential actions and score them against the current world state
A world history pipeline needs to know what factions exist, what they believe, and what events they’ve witnessed

Each of these systems needs *contextual information*, and that information is scattered across your ECS. You could hardcode queries into each system — but then you’ve just rebuilt the spaghetti you were trying to escape.

Providers are the cleaner answer.

What a Provider Actually Is

A provider is a small, focused object with one job: look at the current world state and return a slice of relevant information in a standardized form.

It doesn’t act on anything. It doesn’t own anything. It just observes and reports.

In practice, a provider might:

Query the ECS for components on a specific entity
Check a knowledge ledger for what an NPC has witnessed
Read a relationship table and return a tension score
Inspect the player’s inventory for items with relevant properties

Each provider is narrow — it knows about one thing. But because they share a common interface, any system that needs context can simply ask: *“Run all relevant providers and give me what they find.”*

The Composability Payoff

What makes this pattern powerful isn’t any individual provider. It’s that you can compose them.

When my dialogue system builds context before handing off to the LLM, it doesn’t have one monolithic “gather everything” function. It runs a stack of providers — personality, relationship state, current activity, witnessed events, carried items — each contributing its slice. Add a new provider and every system that consumes the stack gets richer context automatically. Remove one and nothing breaks.

The same pattern feeds my behavior AI. Instead of dialogue hints, providers return scored inputs — considerations that the system uses to evaluate which action an NPC should take. The mechanism is identical; only the output shape differs.

Further out, the world history pipeline uses the same idea at a larger scale — providers that look at faction relationships, accumulated events, and cultural context to seed NPC memories and beliefs before the simulation even starts.

Same pattern. Three very different systems. Zero special-casing.

Why This Pairs With ECS

If ECS is about making your *entities* composable — snapping capabilities on and off at runtime — providers are about making your *information flow* composable. They’re the read layer that sits above the raw component data and gives systems a coherent view of what’s happening.

Together, the two patterns push in the same direction: keep data flat and decoupled, let systems compose it into meaning at the moment they need it. Neither pattern is complicated in isolation. The leverage comes from applying them consistently.

What This Unlocks

The practical benefits are less about elegance and more about velocity.

When a new system needs world context, you don’t write a new data pipeline. You write or reuse providers. When an existing provider needs to return richer data, every system consuming it benefits immediately. When you want to understand why an NPC made a decision, you can inspect exactly which providers fired and what they returned — the information flow is traceable by design.

Testing also becomes surprisingly smooth. Because each provider is a pure, narrow function — world state in, data slice out — you can test them in complete isolation. Feed it a mock ECS world with two components and assert what it returns. No scene setup, no running game loop, no trying to simulate the conditions that triggered a bug. This isn’t something I planned for upfront; it’s just a natural consequence of the pattern’s shape. Narrow inputs, predictable outputs, no side effects.

For a solo developer juggling simulation, dialogue, behavior AI, and world history in the same codebase, that combination of traceability and testability is less of a nice-to-have and more of a survival mechanism.

In future posts, I’ll go deeper on each of the systems this feeds: how providers slot into the dialogue context pipeline, how they drive NAAS behavior scoring, and how the world history enrichment pipeline uses the same idea at generation time. Each of those is its own rabbit hole — but they all share this same quiet foundation.

The pattern isn’t glamorous. It doesn’t have a dramatic origin story. It just kept being the right answer, system after system, until it became the connective tissue of the whole engine.

That tends to be how the good patterns go.

The Chatbot Trap: Why I Stopped Letting AI Run the Game

Wed, 29 Apr 2026 00:00:00 GMT

Remember the first time you saw a video of an RPG NPC hooked up to ChatGPT? It was intoxicating. You could type anything, and the blacksmith would respond. You could ask him about his childhood, his favorite color, or his philosophical views on the monarchy.

But then the illusion broke. You asked him for a million gold pieces, and because LLMs are inherently designed to "yes-and" the user, he said, "Of course, traveler! Here you go." Except... your inventory didn't change. The game engine had no idea what the LLM just promised. And five minutes later, the blacksmith forgot your name.

When I set out to build Narrative Sim, I looked at the current landscape of "AI in Games" and realized the industry is falling into a trap. Developers are treating Large Language Models as state machines. They are asking the AI to be the Game Director.

The Problem with LLM Game Directors

While outright hallucinations are getting rarer with better models, the fundamental drawbacks of LLMs remain:

They are stateless: They have context windows, not true memory.
They are people-pleasers: They struggle to hold firm boundaries against a player's inputs.
They don't know math: They don't know the player's true X/Y coordinates, their actual gold count, or the pathfinding navmesh.

The Narrative Sim Philosophy

I decided to flip the architecture on its head. In my engine, the LLM makes zero behavioral decisions. Instead, the system splits into two distinct halves:

The LLM as a Text Renderer: The game's Entity Component System (ECS) and my deterministic Utility AI (NAAS) calculate the rigid, mathematical truth of the world. The LLM is simply handed that truth and asked to "render" it into natural language.
Semantic Meaning Turned Mechanical: When a dialogue scene concludes, the LLM doesn't just output text. It outputs strict, schema-validated JSON commands that hook directly back into the game engine's physics, economy, and scheduling.

Over the next two posts, I'm going to dive into the exact data structures and pipelines that make this work. I'll look at how I generate infinite dialogue without ever breaking the simulation, and how I turn a simple menu-click into a physical, systemic consequence.

Treating the LLM as a Semantic Text Renderer

Tue, 28 Apr 2026 00:00:00 GMT

In traditional RPGs, if a player tries to talk to a blacksmith while holding a smelly, toxic item, you have two choices: write a hardcoded if (player.hasItem('smelly_mushroom')) dialogue branch, or let the NPC ignore it entirely.

Yesterday during a playtest, my blacksmith, Garth, abruptly stopped hammering, pinched his nose, and told the player to get out of his shop. I didn't script a single line of that dialogue. But more importantly, the LLM didn't decide to make Garth angry. The game engine did.

The "Brain" vs. The "Mouth"

In my architecture, the Narrative Affordance & Agency System (NAAS) is the brain. It evaluates the world state on a staggered tick. It knows exactly who the player is, what time it is, and whether the NPC likes them.

When the player clicks the "Interact" menu, my Dialogue Director v2 (DDv2) steps in. DDv2 gathers "Hints" from the ECS and compiles them into a rigid context payload.

I treat the LLM exactly like a GPU. You don't ask a GPU to calculate gravity; you calculate gravity in the physics engine and say, "Render this box here." I calculate the social physics, pass it to the LLM, and say, "Render an angry greeting."

The Data (Show, Don't Tell)

Here is a sanitized look at the exact JSON payload my HintProviders inject into the LLM context when the player approaches Garth:

{
  "actor_profile": {
    "name": "Garth",
    "occupation": "Blacksmith",
    "personality": ["gruff", "proud", "easily_annoyed"]
  },
  "current_state": {
    "activity": "working_anvil",
    "interrupted_by": "Player"
  },
  "awareness_hints": [
    "Player is currently holding: [Item: Smelly Glowing Mushroom]"
  ],
  "relationship_context": {
    "tension_level": 0.8,
    "archetype": "annoyed_acquaintance"
  }
}

The LLM is given strict instructions: Translate this mechanical state into a response. Because the LLM is constrained by the mathematical reality of the ECS, it doesn't hallucinate a quest about a dragon. It simply renders the data:

"Are you out of your mind bringing that glowing rot in here? Put that away or get out before the stench ruins my steel!"

I get the infinite variance and natural phrasing of an LLM, but the rigid, unbreaking stability of a systemic simulation. The engine owns the logic; the AI just owns the prose.

Closing the Loop: Turning Semantics into Mechanics

Mon, 27 Apr 2026 00:00:00 GMT

Talk is cheap. In a systemic RPG, if I insult a guard, I don't just want a dynamically generated, angry response. I want him to physically arrest me, or at least kick me out of the tavern.

The biggest challenge with AI dialogue is giving it "teeth." If the AI generates text but the game world doesn't change, the illusion shatters.

The Menu-Driven Player

In Narrative Sim, the player does not type free-text to NPCs. Player agency is menu-driven.

When an event happens—say, the player is caught stealing—my IActionProvider dynamically populates the player's UI with contextual choices: [Apologize], [Bribe (50g)], or [Flee].

This grounds the player's inputs in the mechanical reality of the game. But what happens after the player clicks a choice?

The Semantic Command Registry

When the player clicks [Bribe (50g)], DDv2 evaluates the interaction against the NPC's traits (e.g., is this guard corrupt or honorable?).

I force the LLM to output its response not just as text, but as strict JSON containing an array of commands.

{
  "internal_thought": "The player is offering gold. I am underpaid and my 'corrupt' tag is active. I will accept the bribe.",
  "actorID": "npc-kael",
  "dialogueLine": "Just this once. But if I catch your hands near the merchant's cart again, you're going in the cage.",
  "topic_uris": [],
  "commands": [
    {
      "command": "transfer_gold",
      "amount": 50,
      "from": "player",
      "to": "npc-kael"
    },
    {
      "command": "modify_tension",
      "amount": -0.2
    },
    {
      "command": "clear_active_situation"
    }
  ]
}

The Physics of Conversation

My CommandRegistry catches that JSON object. Because these commands are strongly typed, the engine executes them flawlessly.

50 gold is mechanically deducted from the player and added to Kael's inventory.
The RelationshipManager lowers the tension between them.
The SituationDirector clears the "Confrontation" override.

Instantly, Kael's underlying NAAS evaluation changes. Because the confrontation is cleared and his tension dropped, his controller stops targeting the player, he turns around, and he physically walks back to his patrol route.

I have completely bridged the gap between dialogue and mechanics. The LLM translates the social consequence, and the ECS turns it back into physics.