Portability

Import and export: your story should remain yours

Here is another story about why I love browsers and the web so much. By 2026, their rapid development means that the same story can run in a browser, a standalone archive, a Windows app, and a macOS app without maintaining several independent game engines.

Before import and export launched in August 2026, Romergo had a long-standing vendor lock-in problem: a user could create something inside the system but had almost no way to take the result elsewhere. That is no longer the case. Today, the project owner can download a documented .romergo archive or prepare a standalone game for the web, Windows, macOS, and Microsoft Store. I think that ownership matters: a creator's project should belong to the creator, even if they eventually decide to leave Romergo.

That is why I started working on import and export.

Why the web made this task much smaller

Romergo already had one shared Player runtime. It knows how to play scenes, branches, images, music, video, translations, RTL languages, and local saves. It normally loads a published story from the service, but it can also be packaged with the story itself and run with all network access disabled.

That became the foundation of every game export. The web build places index.html at the root of a ZIP. Windows and macOS wrap the same Player in a hardened Electron shell. Microsoft Store receives the same game inside an MSIXUpload. Story logic is not rewritten four times; only the package around one runtime changes.

This does not make platform development a single button. Windows and Apple still have signing, certificates, notarization, store rules, and developer accounts. But the most expensive part is no longer duplicated: building a separate game client with different story behavior for every platform.

How export works

An export does not begin by copying an arbitrary editor state. Romergo takes either a saved draft after it reaches Saved, or a specific retained publication version. Runtime and assets are pinned by revision. If the project changes during the build, the job retries instead of mixing old scenes with new files.

The first result is always .romergo: a regular ZIP with a documented structure. It contains a manifest, project, chapters, scenes, flow graph, variables, presentation, media, credits, and SHA-256 checksums. The archive keeps the display names and roles of contributors but not email addresses or internal identifiers.

Saved draft or publication
        ↓
consistent runtime + asset revisions
        ↓
documented .romergo archive
        ↓
isolated platform builder
        ↓
private ZIP or MSIXUpload for 7 days

Every asset is read and hashed, then checked again before it is written. The archive is assembled as a stream directly into private R2 storage, so a Worker never tries to keep a multi-gigabyte project in memory.

If the creator only needs an editable project, the process ends there. For a game, .romergo is sent to an isolated Linux container with no internet access. The container validates the archive, adds the standalone Player, and produces one of these packages:

Romergo never asks for Steam credentials, an Apple Developer ID, certificates, or passwords. Publishing and signing stay in the creator's own accounts. The service prepares a build ready to upload, keeps it private for seven days, and gives the owner a short-lived download link.

The price surprised me too. The production project “The Blizzard” contains 101 media files and is about 30 MB. Even after the included Cloudflare resources are exhausted, building it currently costs only a few cents. The largest cost was not bandwidth or R2 storage, but how long the build container stayed alive after packaging finished.

You can play the production version of “The Blizzard” in the browser and see the same project that was used for this measurement.

Import was a harder problem

There are already more than a dozen visual novel builders and game engines. Some creators arrive from Twine, ink, Yarn Spinner, or Ren'Py. Others keep a story in a notebook, Obsidian, or Notion. Someone else may bring a PDF, a folder of Markdown files, a spreadsheet, voice notes, video links, and a directory of images.

There are thousands of formats, and they will appear and disappear every year. Writing a native importer for each one would produce a graveyard of parsers within five years, each understanding only one version of somebody else's product.

The answer was already close at hand: AI agents.

An agent can receive a collection of HTML, Markdown, PDF, audio, images, and links. It does not need to reduce everything to one syntax. It can read the material, reconstruct its order, find recurring characters, identify ambiguous branches, and ask the person a question. The creator only needs to guide the process and review the result.

Romergo already supported MCP, so the foundation of an import system effectively existed. Instead of teaching Romergo every format in the world, I kept one stable target: tools through which an agent creates and verifies a normal Romergo project.

What agent-assisted import looks like

source files and links
        ↓
user's MCP-capable agent
        ↓
inventory, preview, questions and warnings
        ↓
Romergo MCP authoring tools
        ↓
persisted readback + project validation
        ↓
creator reviews the result in Builder

First, the user connects their MCP-capable agent to Romergo and gives it the source material. The agent builds an inventory of chapters, scenes, characters, locations, media, languages, and discovered links. HTML, Markdown, TXT, and text-based PDFs already have romergo_inspect_story_source and romergo_import_story_source. They can prepare a literal linear transfer without inventing new branches.

For Twine, ink, Yarn Spinner, and Ren'Py, the agent interprets the source's native structure without pretending that every piece of code can move automatically. Passages, knots, nodes, dialogue, choices, and basic variables usually become chapters, scenes, and branches. Macros, Python, Unity commands, screens, CSS/JS, and external functions become warnings that require a human decision.

After the preview, the agent creates a new project through MCP. It can use a declarative manifest, import attachments in batches, create chapter entities, and write the graph and scene content. Large media is uploaded directly to R2 through a one-time upload rather than passing through a model response.

Writing is not the end of the flow. The agent reads the persisted chapter back with romergo_get_chapter, runs romergo_validate_project, and only finishes after romergo_verify_quest_change. The creator then opens the result in Builder, plays through it, and fixes places where the source format or human intention could not be reconstructed unambiguously.

AI does not remove the need for review

An agent can understand meaning well, but it cannot turn an inference into a fact. A voice recording may require an external transcription tool. A video link does not grant permission to copy the video into a game. Complex Ren'Py code or a Twine macro may be a separate program rather than story content. That is why the import flow presents a preview and warnings, and asks the creator to confirm rights before creating the project.

Romergo's native uploader accepts only .romergo. That limitation is deliberate: our own format should be imported deterministically and safely, while the open world of third-party sources is better handled by a tool that can reason and ask questions.

A bet on the next five years

Formats will change. Models and agents will change too. But the boundary can remain stable: arbitrary human work on one side, and a documented .romergo format plus project-authoring MCP tools on the other.

If a new editor becomes popular in a few years, Romergo does not necessarily have to wait for a dedicated importer. An agent can inspect its files, show what it understood, and write the result through the same contract. And if a creator decides to leave Romergo, they keep an open archive and a standalone game.

That is the direction that feels right to me: Romergo should be a place where stories are convenient to create, not a cage that prevents people from taking them away.

Back to dev blog