Coming From SVNE

Visual Novel Creator is designed for authors who like the kind of visual novel SVNE can produce, but do not want every story change to become a code change.

The goal is visual and functional familiarity, not architectural compatibility. A VNC project can look and behave like an SVNE visual novel, but the underlying model is different: VNC stores story flow as structured project data, checks it, previews it, compiles it, and runs it through the installed runtime.

The short version

Recreate the player experience, not the SVNE script structure. If the menu, dialog, choices, saves, and sprite behavior feel right to the player, VNC can own the new structure.

Familiar output, different model

SVNE mindset

A scene is a Luau function. You call APIs like vnm.dialog() and vnm.promptChoice() in the order the story should run.

This is flexible, but the branch graph, dependencies, and save behavior are mostly hidden inside code.

VNC mindset

A scene is a graph of explicit nodes. Dialog, choices, conditions, sprites, backgrounds, audio, waits, jumps, and ending behavior are editable data.

The editor can check, preview, map, compile, and install that data into a runtime.

What should feel familiar

Runtime shell

Menu, save, load, log, settings, chapter select, and return-to-menu concepts.

Story presentation

Dialog-driven scenes with sprites, backgrounds, portraits, audio, and title cards.

Branching flow

Choices, locked choices, conditions, variables, and shared branch merges.

SVNE-style output

Use SVNE-like visual presentation as a starting point, then modernize without copying SVNE’s source structure.

What is different

• Story flow is authored with nodes instead of hand-written story code.
• Missing setup appears as warnings instead of hidden runtime failures.
• Runtime behavior is structured and checked during play.
• Custom logic uses documented extension points instead of editing core scripts.

The migration mindset

Do not try to port one SVNE function call at a time. Translate the story structure instead:

1. Convert chapters and scenes first.
2. Convert each scene function into a sequence of nodes.
3. Convert if statements into condition nodes.
4. Convert promptChoice branches into choice options and node links.
5. Convert sprite/background/audio calls into presentation nodes.
6. Only use extensions for behavior that is truly custom.

This keeps the VNC project maintainable and avoids recreating the brittle parts of SVNE inside a node editor.

Migration approach

Start by recreating one scene. Match the backgrounds, sprite slots, dialog UI, and menu assets first. Then rebuild branches with choice and condition nodes.

Do not migrate custom Luau first. When you start with the visible story path, you quickly learn which behavior VNC already covers with nodes and which behavior truly needs an extension.

Recommended next pages

How SVNE Works

Understand SVNE’s runtime model before rebuilding it in VNC. Read the breakdown.

Why VNC Is Different

See why VNC uses structured data, project checks, compilation, and runtime rules. Compare the models.

Concept Mapping

Translate common SVNE APIs into VNC nodes and properties. Open the mapping guide.

Migration Checklist

Follow a practical order for rebuilding an SVNE project. Use the checklist.