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 model | World model |
|---|---|
| You pick who to talk to | You pick where to go |
| Group chat = config | Group chat = “they were both in the cafeteria” |
| Character starts existing when summoned | Character was already there |
| Time = “now I’m in this conversation” | Time = “she’s at lunch right now, try later” |
| Absence = nothing | Absence = 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:
- Who replies first?
- How often does each character speak?
- What if one character would never speak in this context?
Spatial group chats answer all of these implicitly:
- Whoever notices you first speaks first (relationship-aware)
- Quieter characters speak less, by personality
- Characters who wouldn’t be in this space aren’t there
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:
- Who normally inhabits it (the regulars define the vibe)
- Physical access rules (locked, public, private)
- Social tone on entry (“you’re welcome here” vs “you’re an interruption”)
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?
- During her absence: zero LLM calls (she’s just not there)
- On reconnection: one LLM call to generate the catch-up message + souvenir image
What did this produce in narrative?
- A sense of loss during the gap
- The pleasure of return
- A naturally generated callback (“how was the trip?”)
- An item (the souvenir) that exists as a chat message — no inventory UI required
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.
- Kumiko notices first: “oh — over here!”
- Mao straightens slightly in her mentor’s presence
- Conversation runs Kumiko-led, Mao chimes in occasionally
- Mao slips into work mode mid-conversation: “by the way, the expense filings — end of next week is fine, right?”
- Kumiko keeps the room warm
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.
- Iroha: “the president? Is something wrong?” (guarded — visits are unusual)
- Mana: “perfect timing, actually.” (opportunistic — she’d been wanting something)
- Ayaha: doesn’t look up from her terminal, gives a small nod
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é.
- Airi is at the counter, drinking coffee alone
- Two male office workers and two strangers are at other tables
- A woman you’ve never seen — sitting with her legs crossed, talking to another woman — catches your eye briefly
- Airi notices you, her expression shifts slightly
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:
- Spatial schema. Spaces, schedules, social membranes, membership rules. This is design work.
- Migration of existing characters into the world. Each character needs a home space, a schedule, relationships to others.
- A spatial UI. Even a minimal one (something like a list of currently-occupied spaces with who’s there) is more UI than the current chat list.
The cheap parts (surprisingly):
- LLM cost. Goes down, because most of the world is offline most of the time. Only the spaces you visit need active context.
- Group conversation logic. Becomes simpler — emergent rather than configured.
- Absence handling. Free; it’s literally “do nothing for N days, then generate one message.”
The total architecture maps to roughly five subsystems:
spaces.md— taxonomy of spaces, their social properties, their default occupants- Schedules (YAML per character) — weekly rhythms with probabilistic variance
- NPC catalog — named regulars (5–10 simple personas) and unnamed extras (description-only)
- Absence engine — pattern catalog, trigger conditions, post-hoc message generation
- 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:
- One-on-one conversation quality. Still the core. World simulation makes it more meaningful, not less.
- NSFW handling. Already mode-switched; continues unchanged.
- Memory system. Still per-character, just augmented with spatial context.
- The character cast. Same characters, same personalities — they just gain locations and schedules.
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.