Menu flow
Main menu, new game, continue, return-to-menu, settings, log, chapter select, and story-authored runtime pages.
The runtime is the playable system installed into your Roblox game. It is what players see when they start the visual novel, open the menu, save, load, change settings, and advance through the story.
The plugin is for creators. The runtime is for players.
If you have not installed it yet, start with Install the Runtime. Use this page when you want to understand what that installed bundle is responsible for.
Menu flow
Main menu, new game, continue, return-to-menu, settings, log, chapter select, and story-authored runtime pages.
Save flow
Save slots, load slots, autosave, continue, chapter unlocks, completed stories, and player settings.
Story presentation
Dialog, choices, text input, sprites, image and parallax backgrounds, overlays, audio, title cards, transitions, and player input.
Runtime rules
The installed runtime keeps story state, text filtering, saves, purchase prompts, and world-facing actions consistent during play.
Story backgrounds, sprites, and overlays keep their authored 16:9 composition. Menus, dialog, choices, and text input adapt to the available screen space. Long choice lists scroll, and Save/Load uses one, two, or three columns as space increases.
The title screen separates Continue (resume your autosave) from Load game. While reading, Auto, Log, and Menu stay at the top of the screen. Menu pauses the story and opens Save game, Load game, Settings, and Chapters. Use Return to story to resume reading. Existing SVNE, Episode, and custom styles remain available, with smaller layouts keeping controls within the usable screen area.
Use the screen-size checklist to review your story before sharing it.
The runtime tracks the active story session, save data, text input filtering, and actions that affect the experience world.
The player sees dialog rendering, sprites, audio playback, menu windows, settings UI, logs, and input prompts.
Player actions are accepted only when the story is waiting for them. For example, Choose only matters while a Choice node is active.
The runtime supports click/tap controls plus Roblox’s newer Input Action system for story advance, opening the menu, and back/close commands.
On touch screens, the dialog text itself follows the same reveal-first behavior as the other advance controls. When a skippable line is still typing, the first tap completes it. A later tap advances once the story is waiting. An unskippable no-input line ignores advance controls and continues only after its typewriter and No-Input Delay finish. Dragging the text to scroll a long line does not count as a tap, so players can read without skipping ahead.
The project Runtime Menu > Startup Mode controls the first screen players see. Main Menu keeps the normal menu-first flow and remains the default for existing projects. Start Story enters a new story immediately when no autosave exists. If an autosave exists, players must choose between continuing and starting over; an outdated save is explained and is never resumed or overwritten silently.
Allow Return to Main Menu separately controls whether players can leave an active story for the main menu. Turn it off to hide the in-story Menu button and disable the M key and Y gamepad button for opening the menu. Save, Load, Auto, Log, and Settings stay available. Startup and recovery menus also stay available, so a failed story start never leaves the player on an unusable screen. Combine Start Story with Allow Return to Main Menu turned off for a story-only flow.
Allow Story Data Reset controls whether the destructive Delete Story Data action appears in Settings. The runtime also rejects reset requests when this setting is off, so hiding the button is not the only protection. When enabled, a reset clears progress, saves, and runtime settings. Most projects return to the main menu afterward. A Start Story project with Allow Return to Main Menu turned off instead starts a clean story immediately, preserving its story-only flow.
Inherit Active Style Preset applies compatible colors, typography, borders, and corner radii across the main menu, Save, Load, Settings, confirmations, and logs. The main menu uses the project preset, while pages opened during a story use the active scene preset and fall back to the project preset. It is disabled by default in 0.6.0-beta.11; the unpublished 0.7.0-beta.1 preview enables it for new Empty Projects. Existing projects retain their setting. Explicit Runtime Menu color fields override their inherited counterparts.
An Open Runtime Page node can open Save, Load, Log, Chapters, or Settings over the active story, even when the main menu is disabled. The story waits for the page to close; loading a save replaces the current session instead of returning to the node.
Starting a new game creates a session from the story’s Story Starts At chapter and that chapter’s first scene. If chapter title cards are enabled and the entry scene starts a chapter, the runtime queues the title card before advancing into nodes.
Runtime requests are state-aware:
When a route moves into a purchase prompt or another interactive wait without showing new dialog, the completed line stays in place while that wait updates. If a later Dialog node intentionally repeats the same speaker and text, VNC still treats it as a new line.
This is why runtime testing matters. Preview can show the authored path, but the installed runtime proves the real play rules.
The runtime keeps player-facing save actions responsive while preserving the current story checkpoint. Save and load entries display authored chapter and scene names when available, while stable IDs remain behind the scenes.
VNC saves runtime checkpoints. A checkpoint can include the current chapter, scene, node, variables, render state, effect sequence, wait flags, world trigger fields, timer duration, log entries, and end state. This is more precise than saving only a scene number.
New checkpoints also record which story created them. Continue and Load refuse an identified save from a different story even when both projects reuse the same chapter, scene, or node IDs. Older saves without a story identity keep their target-based compatibility and can still load when those targets remain valid.
The default player save document contains:
version = 3autoAdvanceEnabled = false, textSpeed = 1, bgmVolume = 1, sfxVolume = 1Settings are normalized before use. Text speed is clamped from 0.5 to 2; BGM and SFX volume are clamped from 0 to 1.
Manual saves cannot overwrite the autosave slot. Save summaries include the slot ID, save time, chapter, scene, node, display title, and current background when that data exists. The save/load menu shows up to 100 slots, with 6 slots per page.
VNC does not save an unresolved Prompt Purchase midpoint. While a purchase prompt or Developer Product receipt is pending, autosave keeps the last playable checkpoint and manual save requests leave the selected slot unchanged. After leaving and rejoining, Continue therefore returns to that earlier playable point instead of reopening stale MarketplaceService state.
If a save points to a scene, node, or chapter that no longer exists, VNC marks the slot as an outdated save. Players cannot load that slot, but they can overwrite it from the Save page.
When a story ends, VNC records completed-story progress separately from loadable checkpoints. Continue keeps the last playable autosave instead of replacing it with the ended screen.
In published places, VNC stores player save documents through profile storage backed by ProfileStore. If a player’s save profile is still being released by another server, the runtime asks them to wait instead of opening stale data.
The runtime log records dialog and choice entries, including prompt text and whether a timed choice resolved through timeout. The log keeps up to 200 entries.
Continue restores the autosave checkpoint when one exists. Loading a manual slot restores that slot’s checkpoint with the current player settings.
Use Testing Runtime for the beta checklist before shipping a route.