Skip to content
Journal

Build notes / Family Adventure

Family Adventure: building an AI RPG for the whole family

A private browser game where a parent and children shape one fantasy campaign together — and where the AI is deliberately never in charge of the rules.

Family Adventure parent game view showing a fantasy scene, player sheets, story narration and turn choices
The parent game view keeps the shared scene, party state, current turn and available actions visible together.
01

The idea was a shared game, not an AI storyteller

Family Adventure began with a fairly ordinary family problem. A parent and two children wanted the freedom of a tabletop role-playing game, but not the preparation, rulebooks or pressure on one person to improvise an entire campaign. A browser could remove that friction, and generative AI could keep a story responsive, but only if the result still felt like a game the family owned together.

That distinction shaped the product. Family Adventure is a private role-playing game for a parent and up to two young adventurers, played in separate browser sessions. Each person has a character, traits, inventory and a special move. They see the same evolving world, take turns in a fixed order and make the decisions that move the campaign. The Storyweaver responds to those decisions; it does not replace them.

The most tempting version would have been a large chat box with a fantasy skin. It would also have been the weakest. Open chat gives the model too much authority, makes turn-taking vague and asks children to understand what the system can safely do. The game instead gives every participant a clear role, visible state and one meaningful action at a time.

Family Adventure welcome screen asking whether the player is a parent or a young adventurer
The first decision is a role, not a login method: parent controls and the young adventurer experience separate immediately.
02

One campaign has to feel live on every screen

The multiplayer part matters because the game is meant to create a conversation in the room. Dad might play on a laptop while Finn joins on a phone and another child uses a tablet. When one player acts, the result needs to appear everywhere, the next person needs to know it is their turn, and nobody should be able to race ahead from a second tab.

Every selected adventurer must therefore be online before a campaign begins. Presence is kept alive with short leases, turns rotate through the chosen party, and the game pauses safely if somebody drops out. A submitted action is claimed once, so a retry or double tap cannot accidentally advance the story twice. Reloading a device restores the exact shared campaign rather than beginning a slightly different version of events.

These details are not glamorous, but they are what turn generated narration into multiplayer play. The handoff is the heartbeat of the experience: one person makes a choice, the shared world changes, and the invitation moves visibly to somebody else.

A real two-browser session: Dad submits an action, both views receive the result, and Finn becomes the active player.
03

The model proposes; the game decides

A role-playing game needs surprise, but surprise is not the same as arbitrariness. In Family Adventure the Storyweaver produces narration and proposes structured changes to the world. Trusted server code owns the dice, difficulty bands, permissions, inventory limits, turn order and the final state transition. The model never receives a blank cheque to edit the campaign.

Each action travels through a narrow path. The server verifies the player and active turn, screens the action, loads the relevant world and memory, and asks the narrative model for a response in a strict typed shape. Any requested roll is generated on the server. The returned world changes are validated before one transaction commits the narration, state, memories and next player together. If the response is invalid, refused or interrupted, the existing campaign remains intact.

That architecture produces a more useful creative boundary. The Storyweaver can invent a suspicious lighthouse keeper, remember a promise made three scenes earlier or turn a failed agility check into a funny complication. It cannot grant an impossible object, alter a hidden rule, invent an extra player turn or expose private campaign notes to the browser.

  • The family decides what their characters attempt.
  • The server decides whether the action is allowed and how the dice resolve it.
  • The model turns that authorised result into story, atmosphere and possible next actions.
  • A deterministic reducer decides what becomes canonical game state.
04

Parent controls belong inside the fiction

Designing for a family audience is not solved by putting a cheerful interface around a general-purpose model. The parent needs practical authority over the experience, and the young adventurer should not have to negotiate safety settings or understand moderation systems in order to play.

The parent creates the family space, adds child profiles and chooses the campaign premise. A young player joins with a family code, PIN and adventure name; no child email, exact birthday, photo, school, location or voice recording is required. Story controls set the level of spookiness, action and language, while permanent character death is off by default. The game excludes sexual content, graphic gore and strong language from its family setting.

Those controls are deliberately expressed as tone and play decisions. A parent chooses cosy, mysterious or spooky; puzzles, cinematic action or heroic action. That is easier to reason about than a technical moderation label and keeps the boundary connected to the story the family actually wants to share. A rewind is available to the parent when a turn simply lands badly, because correction matters as much as prevention.

Family Adventure campaign arranged for a tablet with story, party state and actions remaining legible
The interface treats tablet as a shared-table format rather than a reduced desktop layout.
05

Memory should reward attention, not collect a child

A continuing campaign needs memory. Without it, a character forgets the rescued fox, a promise becomes disposable and every chapter feels like a reset. But a family game should remember the fiction without quietly building a profile of the child behind it.

Family Adventure separates memory into layers: the current canonical world, recent turns, compact chapter summaries and retrieved story facts. Positive feedback can also create an abstract family-private pattern, such as a preference for puzzle-led discoveries or comic complications. It does not need to preserve copied narration or infer personal facts about a young player to make the next chapter feel better shaped.

The same boundary applies operationally. Campaign data is isolated by family, raw narration is kept out of application logs, model training and cross-family retrieval are disabled, and a parent can export or delete the campaign. The aim is continuity with an end point, not an indefinite behavioural record disguised as personalisation.

06

The child view needs less, not smaller

Responsive design here is partly an information-permission problem. The parent may need tone controls, rewind, player presence and campaign management. A child on a phone needs to see the current scene, understand what changed and know exactly when an action belongs to them. Shrinking the parent interface would preserve the pixels and lose the product.

The mobile view therefore concentrates on the active young adventurer. The story remains shared, but the action area becomes immediate, suggestions are easy to scan and the current turn is unambiguous. Larger layouts can hold the party sheets, quest information, illustration and narration alongside one another because the screen has room to support that wider awareness.

The generated scene art follows the same principle. It can establish a new chapter and mood, but play never waits for an image. Text remains the canonical route through the adventure, with ambient effects, soundtrack and spoken narration available as layers rather than requirements. A slow media job or unavailable speech service should reduce decoration, not stop the family playing.

Family Adventure child view on a phone during Finn's active turn
Finn's phone view gives the active young adventurer one clear decision at a time.
07

The prototype proves a more useful role for AI

Family Adventure is still a private prototype. That status is important. Before anything like this became a public children's product it would need sustained family play-testing, accessibility work, moderation operations, verifiable parental-consent design and legal review against the UK Children's Code and relevant privacy law. A technically careful build is evidence of direction, not permission to skip those steps.

What the prototype does prove is a product pattern. Generative AI becomes more useful when it is given a specific creative job inside a system whose rules, permissions and failure states remain legible. Here, its job is to keep an original fantasy world responsive to a family's choices. Authentication, presence, dice, state, safety boundaries and deletion stay outside its authority.

That balance is the reason the game can feel open without becoming shapeless. The model supplies variation. The product supplies trust. The family supplies the adventure.

Topics

  • AI game design
  • Multiplayer web apps
  • Family technology
  • Child-safe design

Next step

Have something to make?

See the work, then tell me what your website, app or prototype needs to make possible.

Selected work