Chapters own scene order
Chapter select, story entry, and broad story progression depend on clear chapter structure.
Project Structure
Large stories get hard when everything is just a script and a folder of assets. VNC keeps the moving parts explicit so you can edit one concern without losing track of the rest.
The important idea is simple: a project is story data with clear ownership.
The story is the top-level project. It owns global settings such as Title, Dialog UI Preset, Dialog Mode, Chapter Title Cards, Typewriter Speed, No-Input Dialog Delay, Story Starts At, runtime menu fields, and sprite slots.
Project typewriter speed is clamped between 0.5 and 2. The default is 1. Dialog Mode resolves to adv unless you choose nvl.
Chapter
Section titled “Chapter”A chapter groups scenes. Chapters are useful for structure, chapter select, and larger projects. If your story has acts, days, routes, or major sections, chapters are usually where those belong.
Each chapter has a name, an ordered scene list, an optional Next Chapter, and title-card overrides. The runtime starts from the story’s entry chapter, then uses chapter scene order to find the first scene.
A scene contains nodes. It has a starting node and defines a playable segment of the story.
Scenes are a good place to separate changes in location, time, route, or save/load intent. They do not need to be tiny, but they should not become a whole game inside one scene either. The Scene Starts At field decides where playback enters the node graph.
A node is one story action: dialog, choice, condition, sprite update, background change, audio, jump, title card, or end.
Unlike script-first engines, a VNC node is structured story data. That means the editor can show it in the Explorer, place it on the Story Map, check its fields, copy it, reconnect it, and prepare it for runtime play.
Assets represent runtime resources such as backgrounds, covers, sprite images, portraits, audio, scroll sounds, menu media, and SFX. Presentation nodes point at assets by stable IDs, so visible names can change without rewriting every node.
Sprite assets are slightly richer than a single image. A sprite has poses, a default pose, and optional display scale fields on each pose.
Variable
Section titled “Variable”Variables store story state. Conditions and text can reference variables to branch or personalize the story.
Each variable has a stable Variable Key, a display Name, a Kind, a Default Value, and an optional description. Kinds are string, number, and boolean.
Character
Section titled “Character”Characters provide speaker identity for dialog. A character can use a normal name, a Name From Variable string variable, a default portrait, and a default scroll sound set.
Use Name From Variable for player names. The runtime uses the variable value when it is not empty, then falls back to the character’s normal name.
Why the structure matters
Section titled “Why the structure matters”The project structure is deliberately explicit:
Scenes own node graphs
A scene is where flow becomes playable. It has a start node and a connected set of story actions.
Nodes own one action
Dialog, choices, conditions, sprites, audio, waits, jumps, and endings stay easier to reason about when they are separate.
Assets use stable references
User-facing names can change without breaking saves or node references because stable IDs stay the same.
This separation makes larger projects easier to maintain. You can rename a chapter for players without changing the stable ID used by saves, or change a sprite pose without rewriting story flow.