What Narratomi is

Narratomi is a studio for branching narrative games: stories the player steers, rendered live in the browser. One project is one game. You open a project, write in it, and press Publish, and readers get a link they can play. Nothing is installed, nothing is compiled by you, and no part of authoring involves writing code.

Three words

Almost every page in these docs uses the same three nouns. They nest.

Chapter. The top level inside a project, and the unit of collaborative sync. A chapter holds scenes. Chapters exist so a long story stays organized and so two people can work in different parts of it without stepping on each other. Story flow can cross chapters through a chapter's named entry points.

Scene. A node in the story graph. A scene is two things at once: a staging header (which environment, which cast member stands on which mark, which camera preset, what is playing in the background) and a script. Scenes are what the flow view draws as boxes. A scene is not a page or a screen: a single scene can carry a hundred lines of dialogue.

Beat. One typed step in a scene's script, top to bottom. Six kinds are writable in the editor:

So: a project holds chapters, a chapter holds scenes, and a scene is a script made of beats.

How the branching actually works

Two mechanisms move the player, and they are not the same thing.

An edge connects one scene to another. Edges are the only way flow leaves a scene, and an edge can carry a condition, so it is taken only when (say) trust is above 2. You draw edges in the flow view by dragging between scene nodes.

A choice beat presents options inside a scene. Each option routes one of two ways: down a graph edge to a different scene, or into an inline body, a short list of beats that plays and then rejoins the current scene. Inline bodies are for a reaction that does not need its own scene. Edges are for a real fork.

Options can carry a condition too. A locked option is either hidden or shown grayed out, which is your call per option.

The stage

Every scene plays on a virtual stage: a fixed stage line with named marks (far-left, left, center, right, far-right) where cast members stand, plus camera presets that aim at them. Environments are set dressing placed around that stage, so swapping a market for a rooftop does not move anybody. You stage a scene by picking marks and a camera, never by typing coordinates. The right dock renders the open scene live while you write, which is the closest thing here to a compile step, and it is instant.

Some stories barely use the stage at all. A cinematic story can play a video cutaway in every scene, with narration running over the frozen last frame.

No code

Conditions are built from pickers over variables you declared, not typed as expressions. Variables are declared with a type (flag, number, text, list, options, or a reference to a cast member or asset) and a required default, and every surface renders by that type. The HUD is configured, not scripted. There is no scripting language to learn and no place to put one.

What you end up with

When you publish, the compiler turns your story documents into a bundle: an immutable, versioned JSON file holding the graph, the scripts, the condition trees, and the asset manifest. That bundle is what players load. The compile is also the validation gate, so a story with a scene that just stops (no way onward and no ending named) fails to publish instead of stranding a reader.

Publishing gives you a share link, an unguessable URL that always serves the latest published version. There is no gallery and no player accounts by default: anyone with the link plays, and their progress pins to the bundle version they started on, so republishing does not break a save in progress.