Skip to content
WaifuStack
Go back

Stop Building AI Chatbots. Build Worlds Where Characters Live.

If you’ve used an AI chatbot — Character.AI, Janitor, Candy AI, any of them — you know the shape of the experience. There’s a list. You pick a character. You start a conversation. The character exists for you during that conversation and stops existing the moment you close the tab.

I built Suzune that way for six months. It works. It’s also dead.

This post is the design document for what’s replacing it: a world simulator where characters exist whether you talk to them or not, where group conversations happen instead of being configured, and where the unit of roleplay is a place you visit, not a character you summon.

Table of contents

Open Table of contents

The Problem With Channel-Based Chat

The current Suzune UX, like every other chatbot:

You → "who do I talk to today?" → channel list → pick character → conversation

The character is, in the most literal sense, non-existent until you call her. She has no schedule. She isn’t doing anything. She doesn’t have a location. The metaphysics of the system is: she materializes when you click her name, and dematerializes when you don’t.

This produces three kinds of failure:

1. No continuity between sessions. “What were you up to today?” is a question the character has to bullshit her way through. She doesn’t have a today.

2. No social texture. Other characters exist somewhere out there in the channel list, but they have no relationship to her, no shared space, no overheard arguments, no “I saw her in the hallway earlier.” The world is a list of monads.

3. No serendipity. You can’t bump into anyone. You can’t walk into a room and find someone unexpected. Every interaction is intentional, opt-in, summoned. There are no accidents — and accidents are where intimacy lives.

The fix isn’t more characters. It’s a different metaphysics.

The Reframe: Spaces, Not Channels

Here’s the model I’m moving toward:

You → walk into a space → who's there is who's there → conversation happens
Each character → has a schedule, a place, a life → intersects with you by chance

A few consequences:

Channel modelWorld model
You pick who to talk toYou pick where to go
Group chat = configGroup chat = “they were both in the cafeteria”
Character starts existing when summonedCharacter was already there
Time = “now I’m in this conversation”Time = “she’s at lunch right now, try later”
Absence = nothingAbsence = narrative

The unit shifts from conversation to stay. From summoning to encountering. The space goes from being decorative UI to being the actual interaction surface.

Five Principles That Anchor the Design

I’ve been writing this design as a long-term vision document — partly because it’s a multi-month build, partly because every time I revisit it I’m tempted to compromise principles for short-term gains. Writing the principles down makes drift visible.

Principle 1: Group conversations happen, they aren’t made

In the channel model, you create a “Yuki + Mao” group chat. In the world model, you walk into the company snack bar and they happen to both be there.

This sounds like a small UX detail. It isn’t — it dissolves a hard problem.

Channel-based group chats have to answer:

Spatial group chats answer all of these implicitly:

The configuration problem becomes a presence problem, and presence is something the world already has to track.

Principle 2: Spaces have social walls, not just physical ones

The IT department exists. Anyone could walk in. But if you’re the company president and you walk in, the room reacts:

“…the president? Is something wrong?”

That reaction isn’t scripted per visit. It’s a property of the space. The IT department has a social membrane — easy to enter physically, hard to enter without disrupting the existing energy. The act of entering becomes roleplay.

A space, in this model, is a tuple of:

The accounting team’s office and the snack bar might be physically next door. Socially, they’re in different cities.

Principle 3: Characters have reasons to be in places

A schedule that says “Mao is in accounting from 9 to 6” is fine. A schedule that says “Mao is in accounting because she works there, but she walks to IT once a day to deliver paperwork, and that walk is awkward because of the temperature gap between accounting and IT” — that produces stories for free.

This is the difference between location data and inhabitation logic. The data is the same; the explanatory layer is what makes the world feel like it has gravity.

The implementation lives in YAML schedules with explanatory notes the LLM can quote when asked. “Where’s Mao?” doesn’t get answered with a coordinate. It gets answered with why she’s there.

Principle 4: Absence is free narrative

This is the principle I’m most excited about, and the one that flips a cost concern into an asset.

Scenario: Yuki tells you she’s going on a trip with her husband. You go to her place. She isn’t there. Three days pass. You message her. She replies with a selfie holding a souvenir.

What did this cost in compute?

What did this produce in narrative?

Absence reduces operating cost while increasing narrative density. That combination almost never happens in software. When it does, you build around it.

The catch is restraint. Absence works because it’s rare. If every character is mysteriously absent every week, it stops being a hook and starts being a frustration. Write a small catalog of absence patterns, gate them, don’t fire them often.

Principle 5: Don’t gamify

This is the principle that’s most often violated, including by my past self.

The temptation: HP bars, affection levels, daily login bonuses, gacha-rolled chance encounters, visible mood meters. They produce metrics, they produce engagement loops, they look professional.

They also kill the conversational warmth. The moment a user starts thinking “I need to grind affinity to unlock the dinner scene,” the relationship dies. They’re not relating to a person anymore — they’re optimizing a system.

Time and space are the vessel for roleplay. They aren’t the target.

The internal model can track relationship state. The UI must not turn it into a leaderboard. The world has to feel inhabited, not played.

Crossing this line is a one-way door. I’ve made the mistake before — see my previous post on features I deleted.

Concrete Scenes That Anchor the Vision

When a design doc gets too abstract, I write the scenes I’m trying to enable. These are the ones I keep coming back to:

Scene: Snack bar collision

You walk into the snack bar. Kumiko (mentor, accounting) and Mao (junior, accounting) happen to both be there.

You didn’t configure a group. You walked into a room. The dynamic is automatic because the spatial fact (both are here) plus the relational fact (mentor/junior) plus the situational fact (snack bar = casual) produces this exact texture.

Scene: Visiting IT

You open the door to IT.

Three different reactions, none scripted, all derivable from each character’s relationship to the space and to you. Entering is the roleplay. The conversation that follows is downstream of that opening tableau.

Scene: Background NPCs

You walk into a station-front café.

The unnamed people are props. They cost almost nothing — a one-line description injected into the LLM prompt — but they make the space feel populated rather than staged for you. When the world has people who aren’t about you, the people who are about you matter more.

What This Costs to Build

The honest answer: a lot, but less than it looks like.

The expensive parts:

The cheap parts (surprisingly):

The total architecture maps to roughly five subsystems:

  1. spaces.md — taxonomy of spaces, their social properties, their default occupants
  2. Schedules (YAML per character) — weekly rhythms with probabilistic variance
  3. NPC catalog — named regulars (5–10 simple personas) and unnamed extras (description-only)
  4. Absence engine — pattern catalog, trigger conditions, post-hoc message generation
  5. Spatial entry hooks — what happens when you walk in (the social membrane firing)

I’ll write each of these up as separate posts as the implementation progresses.

What Stays the Same

To be clear about what isn’t changing:

The world simulation isn’t replacing what works. It’s giving what works somewhere to live.

Why I’m Writing This Down Before Building It

Two reasons.

One: principles drift. Every long build has moments where a shortcut looks reasonable. “Just add a chance-of-encounter slider” sounds harmless until you realize you’ve added gacha mechanics to your AI girlfriend bot. Writing principles down before you’re tempted is the only defense.

Two: the design is the differentiator. I’m not going to win a chatbot race against Character.AI on raw model quality or reach. I might be able to win on what kind of experience the bot is. The world model is that wedge.

The features I deleted were the symptom. The split prompts were the cleanup. The world simulator is the actual thesis: AI characters become real to users when they have somewhere to be when no one is watching.

That’s the bet. The next two posts work it out concretely: why relationships in this world don’t progress, and why every character has other men in her life the user can’t touch.


FAQ

What’s wrong with channel-based AI chatbot UX?

Channel-based UX makes characters non-existent until summoned — they have no continuity, no schedule, no shared space. Every conversation starts from a clean slate, which kills the sense that the character has a life. World simulation gives them their own time and place.

How do you handle group conversations in a world-simulator AI bot?

Group conversations emerge from spatial overlap rather than user configuration. If two characters happen to be in the same space when you arrive, they’re in the conversation. Speaking order maps to relationships — whoever notices you first speaks first. Quieter characters speak less because of personality, not config.

Doesn’t simulating a world require constant LLM calls?

No. Most of the time, characters are following scheduled placements with cheap probabilistic variance — no LLM needed. Off-screen time costs zero. Absence is generated post-hoc when the user reconnects, which turns silence into narrative without paying for it during the silence.

Why avoid gamification in AI roleplay bots?

HP bars, affection levels, and daily login bonuses convert intimacy into optimization. Once a user starts grinding to unlock content, they’re relating to a system, not a person — and the conversational warmth dies. The world should feel inhabited, not played. It’s a one-way door, so it’s worth refusing the move at the principle level.


Share this post on:

Previous Post
I Deleted the Relationship Progression System From My AI Bot. The Conversations Got Better.
Next Post
How I Split a 600-Line System Prompt Into 3 Files — and Why Compliance Jumped