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

Імпорт та експорт: історія має залишатися вашою

Це ще одна розповідь про те, чому я так люблю браузери й 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.

Підписи, сертифікати, notarization і правила магазинів нікуди не зникають. Але найдорожчу частину більше не потрібно дублювати: окремий клієнт із різною поведінкою історії на кожній платформі.

Як працює експорт

Romergo бере збережену чернетку у стані Saved або конкретну версію публікації. Runtime й асети фіксуються за ревізіями. Якщо проєкт змінився під час збірки, завдання повторюється, а не змішує старі сцени з новими файлами.

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

збережена чернетка або публікація
        ↓
узгоджені runtime та асети
        ↓
документований архів .romergo
        ↓
ізольований платформний builder
        ↓
приватний ZIP або MSIXUpload на 7 днів

Кожен асет читається, хешується та перевіряється вдруге. Архів потоково записується у приватне R2, тому Worker не тримає багатогігабайтний проєкт у пам’яті.

Для гри Linux-контейнер без доступу до інтернету перевіряє .romergo, додає автономний Player і створює Web/itch.io, Windows x64, окремі macOS-застосунки для Apple Silicon та Intel або MSIXUpload. Romergo не просить Steam credentials, Apple Developer ID, сертифікати чи паролі. Підпис і публікація залишаються в акаунтах автора.

Мене здивувала й ціна. «Заметіль» має 101 медіафайл обсягом близько 30 MB. Навіть після вичерпання включених ресурсів Cloudflare її збірка коштує лише кілька центів. Основною витратою виявився не R2 і не трафік, а час життя контейнера після пакування.

Можна зіграти в опубліковану версію «Заметілі» просто в браузері: це той самий проєкт, який використовувався для розрахунку.

З імпортом було складніше

Існує понад десяток редакторів і рушіїв. Автори приходять із Twine, ink, Yarn Spinner, Ren’Py, блокнотів, Obsidian чи Notion. Вони приносять PDF, Markdown, таблиці, голосові записи, відеопосилання та папки зображень.

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

Відповідь уже була поруч: AI-агенти.

Агент може отримати HTML, Markdown, PDF, аудіо, зображення й посилання, відновити послідовність, знайти персонажів, позначити неоднозначні розгалуження та поставити запитання. Людина спрямовує процес і перевіряє результат.

Romergo вже підтримував MCP. Замість навчати продукт усім форматам світу я залишив стабільну ціль: інструменти, якими агент створює та перевіряє звичайний проєкт Romergo.

Потік імпорту через агента

вихідні файли та посилання
        ↓
MCP-агент користувача
        ↓
інвентар, preview, запитання й warnings
        ↓
авторські MCP-інструменти Romergo
        ↓
повторне читання та валідація
        ↓
остаточна перевірка у Builder

Для HTML, Markdown, TXT і текстових PDF інструменти romergo_inspect_story_source та romergo_import_story_source роблять буквальне лінійне перенесення без вигаданих гілок.

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

Після preview агент створює новий проєкт, пакетно імпортує вкладення, записує граф і сцени. Великі медіа йдуть прямо в R2. Потім агент читає результат через romergo_get_chapter, запускає romergo_validate_project і завершує роботу лише після romergo_verify_quest_change.

AI не скасовує перевірку

Агент розуміє зміст, але припущення не стає фактом. Аудіо може вимагати зовнішньої транскрипції, посилання не надає прав, а macro може бути окремою програмою. Тому flow показує preview і warnings та просить підтвердити права на матеріали.

Нативний імпортер приймає лише .romergo. Це навмисно: власний формат має імпортуватися детерміновано й безпечно, а відкритий світ сторонніх джерел краще довірити інструменту, здатному міркувати й запитувати.

Ставка на наступні п’ять років

Формати й агенти змінюватимуться, але межа може залишатися сталою: будь-які людські напрацювання з одного боку, документований .romergo та MCP-інструменти з іншого.

Якщо з’явиться новий редактор, агент зможе вивчити його файли, показати, що зрозумів, і записати результат через той самий контракт. А якщо автор піде з Romergo, у нього залишаться відкритий архів та автономна гра.

Romergo має бути місцем, де зручно створювати історії, а не кліткою, з якої їх неможливо забрати.

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