How to Build NPCs That Feel Like They've Lived a Life Before the Player Meets Them

A lot of AI NPC research is converging on the same idea: characters should not feel like chatbots that boot up the moment a player walks over. They should feel like they were already living when the player arrived.

The clearest recent example is Agentopia, a paper posted to arXiv in June 2026 by Xintao Wang and twelve co-authors, several of whom are publicly associated with Anuttacon, the AI company founded by miHoYo co-founder Cai Haoyu. It runs 100 agents through 10 simulated years, letting them pursue personal growth, build relationships, and chase their own needs, then trains the underlying model on a "life reward" that mirrors human well-being. It reports a 15.6% improvement on downstream role-playing benchmarks.

That is a research project, not a build target. You are not going to simulate a decade of village life before your vertical slice. But the direction it points is worth taking seriously, and the useful part of it is reproducible with a much smaller system: track memory, mood, relationships, and lore well enough that each NPC behaves like it had a life before the player showed up.

Who it's for: Game developers, narrative designers, and indie teams building RPGs, social sims, or persistent multiplayer worlds.

Step 1: Give every NPC a life before the player meets them

• Write a short pre-player timeline: where the NPC came from, what they care about, who they know, and what changed for them recently.
• Include a few unresolved goals or pressures so the NPC already has a point of view when the player walks into the scene.
• This is authored, not simulated, and that is the point. A page of history per character buys most of what a long simulation buys, for a fraction of the cost.

Step 2: Separate memory, mood, and relationship state

• Treat memory as what the NPC knows, mood as how they feel right now, and relationship state as how they feel about one specific player.
• Keep these systems independent. A bad interaction should be able to lower trust without instantly rewriting the character's personality.
• The separation also makes debugging possible. When an NPC behaves oddly you can look at three small pieces of state instead of one opaque blob.

Step 3: Store meaningful events, not raw chat logs

• Save the moments that matter: promises, betrayals, favors, preferences, shared discoveries, and topics that keep coming back.
• Summarize old interactions into durable facts so the NPC remembers the relationship without replaying every message verbatim.
• A transcript is not a memory. Nobody recalls a conversation word for word, and feeding one back into a prompt is expensive and vague at the same time.

Step 4: Make mood drift gradually instead of snapping

• Use a small ordered mood scale and move it one step at a time based on accumulated pressure, not on a single line of dialogue.
• This avoids the most recognisable AI NPC failure: cheerful one moment, hostile the next, with no believable transition in between.
• Keep mood separate from the immediate emotional colour of a single reply. A character can be irritated by one question without their baseline shifting.

Step 5: Ground dialogue in lore, memory, and character notes

• Before an NPC states something specific, check whether that specific actually came from memory, world lore, or the character brief.
• If the model reaches for a number, a name, a date, or a distance it cannot source, rewrite the line or have the character admit it does not know. "I never counted" is in character. Inventing a garrison size is not.
• Unsourced specifics are worse than vague answers, because players repeat them and they quietly become canon.

Step 6: Pass scene context in every time the NPC speaks

• Send location, time of day, weather, and nearby events so the character reacts to the world instead of sounding like it is floating in a void.
• For live responses inside a running game, use a streaming integration such as WebSocket so the character can speak while the scene continues.

Step 7: Use a cognition layer if you do not want to build all of this yourself

• Every step above is buildable. Together they are a subsystem with its own storage, its own failure modes, and its own maintenance cost, sitting next to the game you actually wanted to make.
• If you would rather not hand-roll it, MistScale is one way to get persistent per-player memory, gradual mood drift, claim checking against your lore, and WebSocket integration for Unity and other engines without owning the stack.
• Either way, prototype one character first. A single NPC that genuinely remembers you across two sessions tells you more than a design doc covering fifty.

Common mistakes

• Shipping a normal chatbot and calling it an NPC, which usually means the character forgets everything important the moment the session ends.
• Keeping one global relationship state, so every player gets treated identically no matter what they did.
• Letting mood change too fast, which produces emotional whiplash and kills believability faster than a flat character would.
• Letting the model invent lore that was never in your world documents.
• Stuffing raw transcripts into the prompt instead of storing a clean summary of what actually mattered.

FAQ

Do I need to simulate an entire life for every NPC?

No. Agentopia ran 100 agents for 10 simulated years because it was studying what emerges from that, not because a game needs it. You only need enough history to make the character feel continuous: a short pre-player timeline, a few core goals, and a memory system for the interactions that matter.

What is the minimum state an AI NPC should remember?

Key memories, current mood, and a per-player relationship record. That trio covers almost everything players read as "this character remembers me."

Can this work in Unity or another engine?

Yes. If your engine can talk over WebSocket you can stream NPC responses into the game loop. Unity is the common case, but the pattern is not Unity-specific.

Does any of this run while the game is closed?

Not in the setup described here. The state lives on a server so it survives scene unloads and quits, but the characters are not simulating a life in the background between sessions. What persists is what happened, not what is happening.