Переносимость

Импорт и экспорт: история должна оставаться вашей

Ещё один рассказ о том, почему я так люблю браузеры и web в целом. Благодаря их бурному развитию к 2026 году одна и та же история может работать в браузере, автономном архиве и приложениях для Windows и macOS без нескольких независимых игровых движков.

До запуска импорта и экспорта в августе 2026 года в Romergo долго оставалась проблема vendor lock-in: пользователь мог создавать что-то внутри системы, но почти не мог забрать результат с собой. Теперь это не так. Владелец проекта может скачать документированный архив .romergo или подготовить автономную игру для web, Windows, macOS и Microsoft Store. Проект автора должен принадлежать автору, даже если однажды он решит уйти из Romergo.

Поэтому я занялся импортом и экспортом.

Почему web сделал эту задачу заметно меньше

Внутри Romergo уже был общий Player runtime. Он умеет показывать сцены, ветвления, изображения, музыку, видео, переводы, RTL-языки и локальные сохранения. Обычно он загружает опубликованную историю из сервиса, но его можно собрать вместе с самой историей и полностью отключить сеть.

Это и стало основой всех игровых экспортов. Web-версия кладёт index.html в корень ZIP. Windows и macOS упаковывают тот же Player в защищённую оболочку Electron. Microsoft Store получает ту же игру внутри MSIXUpload. Логика истории не переписывается четыре раза: меняется упаковка вокруг одного runtime.

Это не превращает платформенную разработку в одну кнопку. У Windows и Apple остаются подписи, сертификаты, notarization, правила магазинов и собственные кабинеты разработчика. Но больше не дублируется самая дорогая часть: отдельный игровой клиент и отдельное поведение истории на каждой платформе.

Как устроен экспорт

Экспорт начинается не с копирования случайного состояния редактора. Romergo берёт либо сохранённый черновик после состояния Saved, либо конкретную сохранённую версию публикации. Runtime и ассеты фиксируются по ревизиям. Если проект изменился во время сборки, задание повторяется вместо того, чтобы смешать старые сцены с новыми файлами.

Первым результатом всегда становится .romergo: обычный ZIP с документированной структурой. Внутри находятся manifest, проект, главы, сцены, граф переходов, переменные, оформление, медиа, credits и SHA-256 checksums. Архив хранит отображаемые имена и роли участников, но не email и внутренние идентификаторы.

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

Каждый ассет читается и хэшируется, затем проверяется ещё раз перед записью. Архив собирается потоково и сразу уходит в приватное R2-хранилище, поэтому Worker не пытается держать многогигабайтный проект в памяти.

Если пользователю нужен только редактируемый проект, процесс на этом заканчивается. Для игры .romergo передаётся в изолированный Linux-контейнер без доступа в интернет. Контейнер проверяет архив, добавляет автономный Player и выпускает один из вариантов:

Romergo не просит Steam credentials, Apple Developer ID, сертификаты или пароли. Публикация и подпись остаются в аккаунтах автора. Сервис готовит сборку для загрузки, сохраняет её приватно на семь дней и выдаёт владельцу короткоживущую ссылку.

Меня отдельно удивила цена. «Метель» в production содержит 101 медиафайл объёмом около 30 MB. Даже после исчерпания включённых ресурсов её платформенная сборка по текущим тарифам Cloudflare стоит примерно несколько центов. Основным расходом оказался не трафик и не R2, а время жизни контейнера после завершения упаковки.

Можно поиграть в production-версию «Метели» прямо в браузере: это тот же проект, который использовался для расчёта.

С импортом всё оказалось сложнее

Конструкторов визуальных новелл и игровых движков уже больше десятка. Одни авторы приходят с Twine, ink, Yarn Spinner или Ren’Py. Другие ведут историю в блокноте, Obsidian или Notion. Кто-то приносит PDF, набор Markdown-файлов, таблицу, диктофонные записи, ссылки на видео и папку с изображениями.

Форматов тысячи, и они будут появляться и исчезать из года в год. Если писать отдельный нативный импортёр для каждого, через пять лет получится кладбище парсеров, каждый из которых понимает только определённую версию чужого продукта.

Ответ уже был у меня под рукой: AI-агенты.

Агенту можно передать пачку HTML, Markdown, PDF, аудио, изображений и ссылок. Он не обязан сводить всё к одному синтаксису. Он может прочитать материалы, восстановить последовательность, найти повторяющихся персонажей, увидеть места, где ветвление неоднозначно, и задать человеку вопрос. Автору остаётся направить этот поток и проверить результат.

В Romergo уже была поддержка MCP, поэтому базовая система импорта фактически существовала. Вместо того чтобы учить Romergo всем форматам мира, я оставил стабильную цель: инструменты, которыми агент создаёт и проверяет обычный проект Romergo.

Как выглядит импорт через агента

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

Сначала пользователь подключает к Romergo своего MCP-совместимого агента и передаёт ему исходники. Агент составляет инвентарь: главы, сцены, персонажи, локации, медиа, языки и найденные связи. Для HTML, Markdown, TXT и текстовых PDF уже есть инструменты romergo_inspect_story_source и romergo_import_story_source. Они умеют подготовить буквальный линейный перенос без выдуманных веток.

Для Twine, ink, Yarn Spinner и Ren’Py агент разбирает родную структуру источника, но не притворяется, что любой код переносится автоматически. Passages, knots, nodes, dialogue, choices и базовые переменные обычно превращаются в главы, сцены и переходы. Macros, Python, Unity-команды, screens, CSS/JS и внешние функции попадают в warnings и требуют решения человека.

После preview агент создаёт новый проект через MCP. Он может использовать декларативный manifest, пакетно загрузить вложения, создать сущности глав, записать граф и содержимое сцен. Большие медиа идут напрямую в R2 по одноразовой загрузке, а не проходят через ответ модели.

Записью флоу не заканчивается. Агент снова читает сохранённую главу через romergo_get_chapter, запускает romergo_validate_project и завершает перенос только после romergo_verify_quest_change. Затем автор открывает результат в Builder, проходит историю и исправляет места, где исходный формат или человеческий замысел нельзя было восстановить однозначно.

AI не отменяет проверку

Агент хорошо понимает смысл, но не превращает догадку в факт. Аудиозапись может потребовать внешней расшифровки. Ссылка на ролик не означает право перенести его в игру. Сложный Ren’Py-код или Twine macro может быть отдельной программой, а не частью сюжета. Именно поэтому import flow показывает preview, warnings и просит подтвердить права на материалы до создания проекта.

Нативный загрузчик Romergo принимает только .romergo. Это намеренное ограничение: собственный формат должен импортироваться детерминированно и безопасно, а открытый мир чужих источников лучше разбирать инструментом, который умеет рассуждать и задавать вопросы.

Ставка на следующие пять лет

Форматы будут меняться. Модели и агенты тоже будут меняться. Но граница может оставаться стабильной: с одной стороны любые человеческие наработки, с другой находятся документированный формат .romergo и MCP-инструменты создания проекта.

Если через несколько лет появится новый популярный редактор, Romergo не обязательно ждать отдельного импортёра. Агент сможет изучить его файлы, показать, что он понял, и записать результат через тот же контракт. А если автор решит уйти из Romergo, у него останется открытый архив и автономная игра.

Для меня это и есть правильное направление: Romergo должен быть местом, где истории удобно создавать, а не клеткой, из которой их нельзя забрать.

Назад в dev-блог