From source to scene: why a generated visual novel needs a director
How text, HTML, or PDF becomes a coherent visual novel through scene contracts, continuity bibles, two composition modes, MCP assembly, and render review.
Inside Romergo
How an interactive story platform is built.
A development journal about the product decisions, experiments, failures, and systems behind Romergo, explained through what they make possible for creators and players.
The big picture
One story, one shared foundation
Creators work in Builder, changes become a checked publication, and the same quest runtime carries that story into every supported way to play.
Development notes
Stories from behind the product
No scripts, still logic: how nodes and variables work in Romergo
Romergo does not run arbitrary code inside a quest. Authors build behavior from nodes, variables, conditions, and effects, while HTML and CSS remain a safe presentation layer.
Release chapters when they are ready — without making players lose their place
How to release a story in parts, update chapters that are already published, and continue play safely after a new version.
Why the Romergo Player runs on the ordinary DOM
How separating a simple scene from a smart runtime brought preview, browser play, mobile screens, and synchronized Discord play together.
Import and export: your story should remain yours
Why Romergo chose an open project archive, offline game builds, and agent-assisted migration instead of locking creators into one editor.
I invited my AI agent into Romergo, and I don’t know what this is or what to call it.
How Romergo lets a personal AI agent join a live Builder session, receive context and commands, use MCP tools, and return verified results without hosting the model.
A visual novel is a set of pictures. Why did the builder become so complex?
How a small prototype called Fibber grew into a distributed platform with collaboration, versioned publishing, and one shared story runtime.