Project

NarraLeaf Project is an ecosystem for building visual novel experiences with a clear path from authoring to delivery. It brings together a zero-code studio, a desktop application toolchain, and a lightweight React player so teams can choose the right starting point without leaving the broader NarraLeaf Project model.

The project is designed around lightweight web technologies, structured content, and workflows that can grow from an individual prototype into a maintained software project. Authors can focus on scenes and narrative flow, while developers can keep access to TypeScript, version control, packaging, and application-level customization.

Project philosophy

NarraLeaf Project is not only a product list. It is a project structure for keeping visual novel work understandable as it grows.

The ecosystem favors:

• A clear separation between authoring tools, runtime behavior, rendering, and player integration.
• Web and TypeScript foundations that fit existing development workflows.
• Project files and tooling that can be reviewed, versioned, tested, and shipped like modern software.
• Multiple entry points that share the same direction instead of becoming unrelated products.

This lets a project begin with a visual workflow, move deeper into desktop delivery concerns when needed, or embed only the player layer inside an existing React product.

Main paths

NarraLeaf Studio

NarraLeaf Studio is the zero-code authoring and editing path. It is intended for creators and teams who want to build story structure, scenes, and production workflow through a guided visual environment.

Studio is the best starting point when the primary task is creating and maintaining content before dealing with application internals.

NarraLeaf Desktop

NarraLeaf Desktop is the desktop application toolchain. It covers the runtime, renderer, and CLI used to build and deliver NarraLeaf Desktop applications.

This path is intended for developers who need control over the full application, including local development, packaging, runtime integration, and delivery workflows.

NarraLeaf-React

NarraLeaf-React is the lightweight React player path. It is intended for teams that want to embed visual novel experiences in a web product or customize the player UI deeply.

This path keeps the player close to the React ecosystem, making it useful when the story experience is one part of a larger application.

Choosing where to start

Start with NarraLeaf Studio if your first goal is to create story content, manage scenes, and work through a visual production flow.

Start with NarraLeaf Desktop if you are building a complete desktop visual novel application and need access to the runtime, renderer, CLI, and delivery workflow.

Start with NarraLeaf-React if you already have a React application, need a lightweight player, or want to own the surrounding UI and product experience.

These paths are meant to be compatible parts of the same project ecosystem. A team can begin with one path and adopt another as the project becomes more technical, more collaborative, or closer to release.

Milestones

The project

• August 10, 2024. The NarraLeaf Project is founded.
• September 2024. NarraLeaf-React is published to npm, the first public release of the React player.
• February 2025. The NarraLeaf desktop toolchain is published, and a story ships as a desktop application.
• October 2025. The NarraLeaf command line interface is published, covering scaffolding, local development, and builds.
• May 2026. narraleaf.com opens, with documentation for the three paths in one place.
• August 2026. NarraLeaf Studio reaches its first public release, and a project builds for Windows, macOS, Android, iOS, and the web.

Before 0.1.0

Most of Studio was built in the ten months before the first version, while the project carried no version number.

• October 2025. The project starts: the window and process layer, the file system, the launcher, and the new-project wizard.
• November 2025. The workspace takes shape, with resizable panels, sidebars, a module and focus system, and the first asset library.
• December 2025. The character editor, with appearances, differentials and groups. The settings panel and remote assets follow.
• January 2026. Work begins on the UI editor. The asset library gains an icon view, copy and paste, and locking.
• February 2026. The UI editor becomes usable: surfaces, property editors, image cropping, and a color picker. Dev Mode appears.
• April 2026. The blueprint system: the node graph editor, diagnostics, the member panel, and variable management.
• June 2026. Work begins on the story editor. Blueprints gain surface scoping and history, and asset and window access is hardened.

Studio releases

• 0.1.0 (July 2026). The first version. The command palette, keybinding customization, the notification center, the plugin system, and the gallery arrive with it, and a project builds for desktop, mobile, and the web.
• 0.1.1. An About entry in the Help menu.
• 0.2.0. Layered character sprites imported from PSD, a dialog avatar per differential, one master icon baked for all six targets, and plugin sidecars with a capability-gated runtime API.
• 0.3.0 (August 2026). The first release published for download. Live2D and Spine models through a guided import, an audio mixer with a bus per character, project lint, code signing and notarization, and rotating auto-saves.
• 0.4.0. One command vocabulary in the story editor, a committed row that reads back as the line that wrote it, documentation inside Studio, and a localization export in the format a translator's tool speaks.
• 0.5.0. An installer, updates from GitHub Releases, playability checks and conversion on import, blueprint breakpoints with a Dev Mode debugger, and a project palette a color can point at.
• 0.6.0. Build variants: a variant states what its package contains and where its story ends, and the build reports what it dropped. Blueprint editors open in windows of their own, and a project keeps its own dictionary.
• 0.7.0. Asset sets: one library entry standing for a family of files, resolved by language at runtime or by release at build time. Patches an author produces and a shipped game reads, weather, and skipping with an auto-forward wait.
• 0.8.0. Blueprints authored as text against a catalog, a canvas toolbar with a graph overview, builds from the command line, DLC built into its own file, and a report of what each build carried.
• 0.9.0. Live sessions: a host opens a room, and the files it carries travel over the session's own connection. Compression per track, protected builds that compile their codec for the title they protect, and plugin sidecars for every target a build produces.
• 0.9.1. Project export handles packaged builds, and large packages are written and read a chunk at a time.
• 0.9.2. A save opens in the story it was written in, a scene hands the screen back to a page, transform presets travel as files, and the translation and voice tables can be searched.
• 0.10.0 (September 2026). A script is a blueprint layer backed by a TypeScript file the author edits in their own editor, a project Studio does not know waits to be trusted before it builds or runs, characters draw at their own pixel size, and --test and --lint join --build on the command line.
• 1.0.0 (October 2026). The first stable release: the projects of 0.10.0 on engine 1.0, with the plugin types package published under Studio's own version number.
• 1.1.0. A Blueprint Overview of every blueprint in the project, a template library for layers, hover and click sounds as element properties, and a text's words taken from its own text, a translation key, or a Blueprint Value.
• 1.2.0. Story actions from plugins, video that comes on stage through /play, macOS and Linux packages built on Windows, and a wire that names its far end on hover.
• 1.3.0. Every text on a page has one source of words, read the same way by the canvas, the game, translation and search, and project checks run in the background and list in a Problems panel.
• 1.4.0. Page params, struct types on blueprint pins, gamepad bindings for input actions, a grid in the interface editor, and abbreviations of the author's own for story commands.
• 1.4.1. A component's root can be changed in its editor, and a child is inserted into the row the command was opened on.
• 1.4.2. The live preview shows a saved variable's value at the previewed row, Studio's own words in a game follow the game's language, and a component parameter can hold an audio track.
• 1.4.3. Updates download and prepare themselves in the background, an update button in the title bar shows how far they have got, and the names a /rename row gives are translatable.
• 1.4.4. Every release is copied to GitCode, so downloads and updates reach mainland China, and the Windows installer is back to its usual size.
• 1.4.5. A failed update download is tried again, from the other source when there is one, and the update panel says what went wrong.
• 1.5.0. An author's own AI agent can build the open project; games can be played with the keyboard or a gamepad alone; a scene's layers are placed by their distance from the camera; a redone story motion editor; a minor warning level in the project check.
• 1.6.0. Related blueprint nodes browse as one row in the add-node menu, and a placed card switches to another of them from its title; Equal and Not Equal compare by value; each add-node category has its own icon; node type ids show only with developer options on.
• 1.6.1. AI agents that connect over stdio reach Studio on Windows, the access token in Settings can be copied, / and # start a story command with an input method on, and a blueprint layer opens already framed.
• 1.6.2. Agents in Claude Code read scenes, pages and guide chapters in full; the size and colour an agent gives a UI element show on the page; a .story file's short /if and a speaker named by a nickname work as they do in the editor; Settings has an endpoint port field again, and a port that is taken is reported rather than swapped for another.

Ecosystem direction

NarraLeaf Project is also growing around supporting tools for asset packaging, audio, UI composition, scripting, and production workflows. These tools are intended to support the three main paths rather than create separate product silos.

The long-term goal is a coherent toolset for visual novel projects: approachable for creators, practical for developers, and structured enough for teams that need to maintain and ship real applications.