Product & game
Core loop, world and narrative systems, feature priorities, pricing, and the decisions that turned an experiment into a playable product.
Live product case · 2026Choose a world. Write what you do.Live with what it remembers.
Hallu is an AI-driven multi-world text RPG. Enter an official world or define your own, act through choices or free text, and keep living with the relationships, abilities, and consequences that your save carries forward. I founded it and built the product with a two-person team.
Titus Lai · Founder & AI-native Product Builder
What players actually do
Start with a character. End up inside a history only this save could produce.
The loop is closer to role-playing inside a living novel than using a chat window. The model narrates, but the player chooses the life—and the product preserves what that life changes.
- 01
Choose a life
Enter one of six official worlds or define a world with its own era, laws, powers, and central conflict.
- 02
Act beyond the menu
Follow a suggested choice or type any reasonable action. Skills, items, companions, relationships, and world state shape the next scene.
- 03
Carry the consequences
Promises, injuries, grudges, allies, major turns, and Dream Traces give one save a real before and after.
- 04
Cross into other players’ stories
Bring what you built into co-play, co-writing, duels, squad campaigns, or a persistent shared world.
Playable scope on the official site
- Solo story
- Create a world
- Co-play
- Co-write
- Duels
- Squad campaigns
- Persistent world
Product proof
A live product, not a concept.
- Registered players
- 400+Cumulative registrations
- Paid subscribers
- Reached 12Paid subscriptions at the milestone
- Cumulative gross payments
- US$1K+Rounded through the milestone snapshot
- From public beta
- 4 monthsTime to the milestone snapshot
Built and operated with a two-person team. These are rounded milestones, not a claim about current recurring revenue.
Founder scope
I owned the product end to end. We built the platform as a team.
I made the product decisions that connect what players imagine, what the model narrates, and what the world is allowed to remember.
AI & narrative
Prompt authority, persistent-world behavior, failure boundaries, evaluation, and the rules that decide when generated prose may alter state.
Experience & brand
Frontend flows, visual direction, official-site direction, positioning, launch material, and the language players meet before entering a world.
Community & operations
Discord, player feedback, release gates, incident response, monetization decisions, and the daily judgment required to keep the product trustworthy after launch.
System map
A player turn crosses six trust boundaries.
The model is only one component. The product has to decide what may be shown, what becomes canonical, what can trigger an effect, and what happens when any step fails.
The world is still becoming…validatedThe world remembers.
- 01Player intentInput plus current world state
- 02Model streamUseful, but not yet world truth
- 03Unit validationCompleted narrative units only
- 04Canonical saveVisible story and state move together
- 05World effectsOnly after the commit is valid
- 06ObserversMetrics and cleanup cannot rewrite history
Operating principleA generated sentence becomes world history only after the matching state is safely saved.
Engineering case 01 · Turn transaction
What if the player saw it, but the save failed?
A player can read a new scene before several background steps have finished. If the save then fails, the player has seen a future that the world no longer remembers.
The failure is temporal
The visible story, saved world, usage credit, and undo snapshot must agree on which turn actually happened. A retry must also recognize work it has already settled.
I treated each turn as a transaction: validate the scene, save one identified result, and only then let analytics or cleanup run. A later observer failure can be recorded, but it cannot erase an accepted turn.
The invariants
Validate before visibility
Rejected narrative never becomes visible or canonical.
Save before observers
Analytics and cleanup run only after the world has been saved.
Recover once
The same failed turn can be compensated only once, even when retries overlap.
Undo only with a complete snapshot
If the previous state is incomplete, the system refuses to guess.
Synthetic fault-injection model
Inject a failure into one turn
This small model was written for the case study. It shows the same ordering rules without product source, player data, pricing, or service configuration.
Visible storyNone
Canonical storyNone
Save version0
Recovered credit0
ObserverIdle
Safe next actionNo recovery required.
Transaction trace
- received
Public evidence boundary
The decisions are inspectable. The live product stays private.
The engineering claims trace back to frozen product code and failure tests. The public demos reproduce only the relevant behavior, without exposing players or the system that serves them.
What is shown
State transitions, failure ordering, recovery limits, design tradeoffs, and fixed synthetic tests.
What stays private
Product source, player and payment data, prompts, defensive rules, service configuration, and production identifiers.
What this does not claim
The demos are not the live game, and frozen evidence is not presented as proof of current external state.