Testing Runtime

Runtime bugs are expensive when you find them late. The safest beta workflow is to split testing by what each environment can actually prove.

Preview is fast. Play mode is closer to the real game. Published test places are where saves get real.

Where to test

Preview

Use preview to check story flow, dialog timing, variables, conditions, choices, presentation nodes, synthetic text input, and simulated wait states.

Studio play

Use play mode to check runtime menus, story sessions, text input filtering behavior, player controls, teleporting, sprite activation, world waits, and installed assets.

Published test place

Use a published test place for save behavior, player rejoin behavior, and persistence across restarts.

Preview checklist

1. Compile the project.
2. Start preview from the scene you changed.
3. Step through the main path.
4. Choose each available Choice option.
5. Check locked choice text.
6. Use preview transport from important branch nodes.
7. Resolve warnings before moving to runtime testing.

Preview pathfinding has a limit of 4096 explored states. If preview cannot find a path to a node in a complicated scene, simplify the route, start from the scene, or preview a closer node.

Runtime checklist

1. Install or update the runtime.
2. Start a Studio play session.
3. Start a new game from the runtime menu.
4. Test Continue, Return to Menu, Settings, Log, Save, Load, and Chapter Select.
5. Submit text input and confirm filtered text reaches later dialog.
6. Test each world-facing node in the actual place.
7. Reinstall the runtime after changing story data, assets, styling, or extension settings.

Menus

New Game, Continue, Settings, Save, Load, Log, Chapter Select, Return, Close, and Open Menu all depend on runtime actions and player save data.

Timers

Waits, no-input dialog, title cards, and choice timeouts should pause while the runtime menu is open.

Text input

The runtime filters submitted text. Studio may warn and use local text if filtering is unavailable.

World nodes

Touch, click, teleport, roaming, and sprite activation all need the installed runtime.

Published-place checklist

Local Studio runtime saves are memory-only. A published test place is needed when the question involves real persistence.

1. Publish a private test place.
2. Enable runtime save access as your experience requires.
3. Start a story, make a manual save, and leave.
4. Rejoin and test Continue plus manual Load.
5. Change settings, leave, and confirm settings persist.
6. Test save/load from more than one route if your story branches heavily.

Failure signs

• Continue says no autosave is available after you expected one.
• A save slot loads but returns to the wrong chapter, scene, or node.
• A text input route works in preview but fails in play mode.
• A World Wait prompt appears forever because the target path does not resolve.
• Roaming does not restore controls after returning to normal story mode.
• Runtime menu timers continue while the menu is open.

These are not places to add delay hacks. They are signs to verify the authored fields, installed runtime, and place hierarchy.