Portabilidade
Importar e exportar: sua história deve continuar sendo sua
Esta é mais uma história sobre por que gosto tanto dos navegadores e da web. Graças à evolução deles, em 2026 a mesma história pode rodar no navegador, em um arquivo autônomo e como aplicativo para Windows ou macOS sem manter vários motores de jogo independentes.
Antes do lançamento da importação e exportação em agosto de 2026, o Romergo teve por muito tempo um problema de vendor lock-in: era possível criar dentro do sistema, mas quase impossível levar o resultado para outro lugar. Isso não é mais verdade. Hoje, o proprietário pode baixar um arquivo .romergo documentado ou preparar um jogo autônomo para web, Windows, macOS e Microsoft Store. O projeto deve pertencer ao autor, mesmo que ele decida sair do Romergo.
Por isso comecei a trabalhar em importação e exportação.
Como a web reduziu o tamanho do problema
O Romergo já tinha um Player runtime compartilhado para cenas, ramificações, imagens, música, vídeo, traduções, idiomas RTL e saves locais. Normalmente ele carrega uma publicação do serviço, mas também pode ser empacotado com a história e funcionar sem rede.
A versão web coloca index.html na raiz do ZIP. Windows e macOS envolvem o mesmo Player em uma camada Electron protegida. A Microsoft Store recebe o mesmo jogo em um MSIXUpload. A lógica da história não é reescrita quatro vezes; apenas o pacote em torno do runtime muda.
Assinaturas, certificados, notarization e regras das lojas continuam existindo. Mas a parte mais cara deixa de ser duplicada: criar e manter um cliente diferente em cada plataforma.
Como funciona a exportação
O Romergo usa um rascunho salvo no estado Saved ou uma versão específica da publicação. Runtime e assets são fixados por revisão. Se o projeto mudar durante o build, a tarefa recomeça em vez de misturar cenas antigas e arquivos novos.
O primeiro resultado é sempre .romergo: um ZIP documentado com manifest, projeto, capítulos, cenas, grafo, variáveis, apresentação, mídia, créditos e checksums SHA-256. Ele mantém nomes visíveis e funções dos colaboradores, mas não emails nem IDs internos.
rascunho salvo ou publicação
↓
runtime e assets consistentes
↓
arquivo .romergo documentado
↓
builder de plataforma isolado
↓
ZIP ou MSIXUpload privado por 7 diasCada asset é lido, recebe hash e é verificado novamente. O arquivo é transmitido diretamente para o R2 privado, sem manter um projeto enorme na memória de um Worker.
Para gerar o jogo, um container Linux sem Internet valida .romergo, adiciona o Player autônomo e produz Web/itch.io, Windows x64, aplicativos macOS separados para Apple Silicon e Intel ou MSIXUpload. O Romergo nunca pede credenciais Steam, Apple Developer ID, certificados ou senhas. Assinatura e publicação continuam nas contas do autor.
O preço também me surpreendeu. “A Nevasca” tem 101 arquivos de mídia e cerca de 30 MB. Mesmo depois dos recursos Cloudflare incluídos, o build custa apenas alguns centavos. O maior gasto não era R2 nem tráfego, e sim o tempo em que o container continuava ativo após terminar.
Você pode jogar a versão publicada de “A Nevasca” no navegador: é o mesmo projeto usado neste cálculo.
A importação era mais difícil
Já existem mais de dez editores e motores. Alguns autores vêm de Twine, ink, Yarn Spinner ou Ren’Py; outros trabalham em cadernos, Obsidian ou Notion. Também chegam PDF, Markdown, planilhas, gravações de voz, links de vídeo e pastas de imagens.
São milhares de formatos que mudam todos os anos. Um importador nativo para cada um viraria um cemitério de parsers que entendem apenas uma versão de outro produto.
A resposta já estava por perto: agentes de IA.
Um agente pode receber HTML, Markdown, PDF, áudio, imagens e links, reconstruir a ordem, reconhecer personagens, indicar ramificações ambíguas e fazer perguntas. A pessoa orienta o processo e revisa o resultado.
O Romergo já tinha suporte a MCP. Em vez de ensinar todos os formatos do mundo ao produto, mantive um destino estável: ferramentas com as quais o agente cria e verifica um projeto Romergo normal.
O fluxo de importação com agente
arquivos e links de origem
↓
agente MCP do usuário
↓
inventário, preview, perguntas e avisos
↓
ferramentas MCP de autoria do Romergo
↓
leitura persistida e validação
↓
revisão final no BuilderO agente lista capítulos, cenas, personagens, locais, mídia e idiomas. Para HTML, Markdown, TXT e PDF de texto, romergo_inspect_story_source e romergo_import_story_source fazem uma transferência literal e linear sem inventar novas ramificações.
Em Twine, ink, Yarn Spinner e Ren’Py, passages, knots, nodes, diálogos, escolhas e variáveis básicas normalmente viram capítulos, cenas e conexões. Macros, Python, comandos Unity, screens, CSS/JS e funções externas viram avisos que exigem uma decisão humana.
Depois do preview, o agente cria um novo projeto, importa anexos em lote, grava o grafo e as cenas. Mídias grandes vão diretamente para o R2. Em seguida ele relê com romergo_get_chapter, executa romergo_validate_project e só termina após romergo_verify_quest_change.
IA não elimina a revisão
Um agente entende significado, mas uma inferência não vira fato. Áudio pode exigir transcrição externa, um link não concede direitos e uma macro pode ser um programa inteiro. Por isso o fluxo mostra preview e avisos e pede confirmação dos direitos.
O importador nativo aceita apenas .romergo. Isso é intencional: nosso formato deve entrar de modo determinístico e seguro; fontes externas precisam de uma ferramenta capaz de raciocinar e perguntar.
Uma aposta nos próximos cinco anos
Formatos e agentes mudarão, mas a fronteira pode permanecer: qualquer material humano de um lado, .romergo documentado e ferramentas MCP do outro.
Se um novo editor se tornar popular, um agente poderá estudar seus arquivos, mostrar o que entendeu e escrever o resultado pelo mesmo contrato. E se um autor sair do Romergo, continuará com um arquivo aberto e um jogo autônomo.
O Romergo deve ser um lugar conveniente para criar histórias, não uma gaiola que impeça levá-las embora.