If you're building a game companion or story NPC that needs to remember players, change mood over time, and react differently from one run to the next, you do not need to hard-code thousands of one-off behavior rules. The easier path is to design a compact memory-and-state system that drives the character like a living relationship instead of a giant dialogue tree.
Who it's for: This guide is for indie devs and small teams building RPG companions, social NPCs, or persistent game worlds who want richer behavior without hand-authoring an enormous behavior database.
Step 1: Start with state, not dialogue
- Define the NPC as a collection of state variables first: memory, mood, trust, relationship score, current goal, and location context.
- Treat dialogue as the output of those states, not the source of truth. The same line should change depending on who the player is, what happened last time, and how the NPC feels right now.
Step 2: Separate memory into a few practical buckets
- Use a small number of memory types instead of dumping everything into one log: player identity, recent interactions, long-term relationship events, world facts, and quest-relevant facts.
- Decide what should persist forever, what should decay over time, and what should be summarized after a while. This keeps the system from becoming huge and unmanageable.
Step 3: Give the NPC a simple emotional model
- Use a limited mood range such as hostile, wary, neutral, friendly, warm, or delighted rather than trying to simulate every possible emotion.
- Change mood gradually based on accumulated events. Small insults, gifts, promises, and repeated visits should move the state one step at a time, not cause instant personality whiplash.
Step 4: Make relationships per-player, not global
- A companion should not treat every player the same. Keep a separate relationship record for each player so trust, familiarity, and tone can drift independently.
- Track relationship-changing events such as betrayals, help given, quest completion, repeated conversations, or time since the last interaction.
Step 5: Ground responses in lore and known facts
- Before generating a response, check it against a small source of truth: world lore, character backstory, recent memory, and scene context.
- If the NPC does not know something, let it say so. It is better for the character to refuse, hedge, or ask a follow-up question than to invent false facts that break immersion.
Step 6: Test for persistence across sessions and edge cases
- Test the NPC after relaunching the game, reloading a save, returning after a long gap, and interacting from multiple players or save files.
- Look for failure modes like mood resetting too often, memory drifting out of sync, or the NPC recalling the wrong player. These bugs destroy the illusion of a living character fast.
Common mistakes
- Storing every possible behavior as hand-written content instead of using a smaller state system that can combine memory, mood, and context dynamically.
- Making mood change too quickly, which turns the character into a switch-flipping chatbot instead of a believable companion.
- Using one shared relationship state for all players, which makes the NPC feel generic and breaks multiplayer continuity.
- Letting the NPC invent facts when it lacks information, which weakens trust and can contradict your lore.
- Trying to build the whole system inside the game code without a clean external data layer for memory and state.
FAQ
Do I need an LLM to make a persistent NPC companion?
Not necessarily. You can build persistence with rules, memory, mood, and relationship state alone. An LLM can help with phrasing and variation, but the core design problem is usually state management, not sentence generation.
How much content do I actually need?
Usually far less than you think. A few well-defined memory buckets, a mood scale, and a relationship model can create the feeling of depth without thousands of manually authored behavior lines.
Can this work in engines like Unity or GameMaker?
Yes. The important part is having a reliable way to send context in and receive responses back. Unity can integrate directly, and any engine that can talk over WebSocket can connect to an external NPC cognition layer.
A practical next step
If you want the outcome rather than the infrastructure work, this is the layer MistScale provides. Persistent memory, a gradual mood baseline, and per-player relationships, without maintaining a giant custom behavior database of your own.
You author who the character is and upload your world documents. Everything above (per-player trust and mood, memory across sessions, and grounding responses against your lore) is handled server side. It connects over a single WebSocket, with a Unity SDK if you are in Unity.
Start free, define one companion, and test the thing that matters: close the editor, come back tomorrow, and see whether the second conversation knows who you are.