Comparação de Engines de RPG: RPG Maker, Godot, Unity, Unreal e Builders no Navegador

Escolher uma engine de RPG é, em grande parte, uma decisão sobre três coisas: como sua arte é produzida, quem precisa escrever código e onde o jogo final precisa rodar. As opções se dividem de forma clara. RPG Maker MV e MZ são editores 2D que já trazem os sistemas de RPG prontos. Godot, Unity, Unreal e Phaser são engines de uso geral que você programa. Ren'Py é uma engine voltada ao diálogo, que trata o jogo como um roteiro. Builders no navegador dispensam totalmente a instalação e a etapa de build.

Esta página compara esses caminhos pelos fatores que realmente decidem um projeto: custo e licenciamento, se você mexe com código, 2D ou 3D, o que você pode exportar e quanto tempo até algo ser jogável. Onde um número seria mero chute, descrevemos o mecanismo. Se você quer ver um mundo rodando antes de se comprometer com uma engine, a seção sem engine perto do fim é a que deve ler primeiro.

Resposta rápida

Se o jogo é um RPG 2D em visão de cima com atributos, itens e caixas de diálogo, RPG Maker MV ou MZ chega a uma cena jogável mais rápido, porque o banco de dados e o sistema de eventos já modelam esses sistemas. Se você quer controle sobre o renderizador e as regras sem pagar por nenhum dos dois, Godot é o caminho mais barato que não te prende a um formato. Unity e Unreal fazem sentido quando há uma equipe, uma submissão para console ou middleware envolvido. Phaser é a resposta quando o RPG é uma página web e você já escreve JavaScript. Ren'Py é a resposta quando o jogo é majoritariamente texto e escolhas ramificadas.

A tabela abaixo cobre sete caminhos: RPG Maker MV/MZ, Godot, Unity, Unreal, Phaser, Ren'Py e um builder no navegador, em que o resultado é uma página, e não um arquivo de build. As colunas são custo e licenciamento, código necessário, 2D ou 3D, plataforma-alvo e tempo até a primeira versão jogável. Leia essa última coluna como o tempo para colocar um personagem controlável na tela, com colisão e um objeto interativo, e não como o tempo para terminar um jogo. A maioria dos projetos de RPG fracassa nos sistemas, não na renderização, então trate a tabela como um filtro e as seções seguintes como a decisão.

A tabela comparativa

Duas células dessa tabela merecem um alerta. O destino de build Web da Unity funciona, mas um build WebAssembly até de um RPG 2D modesto costuma chegar a dezenas de megabytes antes da compressão de assets, e builds com threads exigem cabeçalhos de isolamento de origem cruzada (COOP e COEP) que muitos hosts estáticos não enviam por padrão. O sintoma é uma tela em branco e uma mensagem no console sobre SharedArrayBuffer, e não um erro claro. A exportação web com threads da Godot tem a mesma exigência de cabeçalhos, o que é o motivo mais comum de um projeto Godot rodar localmente e falhar em um host gratuito.

A exportação HTML5 da Unreal foi descontinuada na transição da versão 4.23 para a 4.24 e não há substituto com suporte, então um RPG feito na Unreal é distribuído como binário ou por meio de uma loja. Se a distribuição é feita por um link, isso tira a Unreal da lista antes mesmo de você escrever qualquer código.

A publicação do RPG Maker para navegador entrega toda a árvore de assets de uma vez. Isso é tranquilo para um projeto pequeno e sofrido para um com trilha sonora longa, porque o áudio domina o payload muito antes dos mapas. Trate o primeiro carregamento, e não a taxa de quadros, como seu primeiro problema de desempenho.

Engines de RPG 2D vs 3D

O renderizador é a parte barata. Godot e Unity renderizam 2D e 3D no mesmo download, e alternar uma câmera de perspectiva para ortográfica é uma única propriedade. O que muda entre um RPG 2D e um 3D é tudo o que vem antes do renderizador: como os assets são produzidos, quantas pessoas são necessárias e quanto tempo uma mudança leva para se tornar visível.

Um caminho 2D significa sprite sheets e tilesets. Um personagem que anda em quatro direções normalmente precisa de três quadros por direção, doze quadros no total, desenhados em 16x16, 32x32 ou 48x48 pixels. As configurações de importação importam mais do que a arte em si: defina o Filter Mode como Point (sem filtro) e a Compression como None para pixel art, ou a filtragem bilinear padrão do editor desfoca cada tile e você passa uma noite culpando o artista. A iteração é rápida, porque um novo tile é desenhado e jogado na pasta. Um mapa de 100x100 a 32 pixels por tile é uma imagem de 3200x3200 pixels, o que é um custo de memória real, mas administrável.

Um caminho 3D significa malhas, rigs, pesos de pele e clipes de animação. Um personagem precisa de uma malha, um esqueleto e, no mínimo, clipes de parado, andar e atacar. Se você não está licenciando uma biblioteca, isso é tempo de modelagem antes de existir qualquer gameplay. A iteração é mais lenta nos dois sentidos: iluminação, malhas de nível de detalhe e formas de colisão precisam ser rechecadas quando uma malha muda. O retorno é uma câmera que faz coisas que uma grade de tiles não faz, e um pipeline que aceita ambientes escaneados ou montados a partir de kits.

A pergunta prática não é qual parece melhor. É quantas mudanças de assets você espera fazer depois da primeira hora jogável. Um projeto 2D absorve dezenas de mudanças a baixo custo. Um projeto 3D absorve uma dúzia e depois começa a custar uma semana cada.

O RPG Maker te prende ao 2D, e isso é um recurso: o editor de mapas, os autotiles e os character sets pressupõem uma grade de tiles, então um tileset é o único tipo de asset que você precisa produzir. A Unreal te empurra para o 3D — o Paper2D consegue renderizar sprites, mas as ferramentas de iluminação, física e animação são construídas em torno de malhas, então um jogo 2D ali briga com a engine.

Godot e Unity são as duas que te deixam decidir depois, mas só a um custo. Trocar um protótipo de sprites para malhas significa reconstruir a colisão, reajustar a distância da câmera e refazer cada animação, porque a contagem de quadros de um sprite sheet e a duração do clipe de um rig não têm nada em comum. Escolha a dimensão antes de construir o primeiro encontro de combate, não depois.

Você precisa programar?

Não, até o momento em que você quer algo que a ferramenta ainda não modela. O sistema de eventos do RPG Maker é uma lista de comandos com condições, switches e variáveis, e você consegue construir uma cadeia de missões, uma loja e uma batalha por turnos sem digitar uma linha de código. O obstáculo surge com layouts de menu personalizados e fórmulas de batalha que o banco de dados não consegue expressar; nesse ponto você está editando arquivos de plugin JavaScript e registrando-os na lista de plugins, o que é trabalho de autor de plugin, e não de iniciante.

Os Blueprints da Unreal são o mais próximo de uma engine de uso geral com uma camada completa de programação visual. Você pode construir toda a lógica de um RPG como grafos de nós, e a diferença de desempenho em relação ao C++ só se torna visível em código que roda a cada quadro e por ator, como grandes loops de multidão ou de projéteis. A programação visual da Unity é um pacote mais assets de terceiros, e a maioria dos tutoriais e respostas de fórum pressupõe C#. A Godot não tem nenhum grafo de nós de gameplay integrado; o caminho é o GDScript, e ele é deliberadamente próximo do Python na sintaxe. O Phaser é código desde a primeira linha. O formato de script do Ren'Py se parece mais com um roteiro de cinema do que com um programa, com Python disponível para casos específicos.

Há uma quarta opção que não se encaixa na divisão entre grafo de nós e linguagem: descrever o jogo e deixar a ferramenta construí-lo. O 3D game builder da Neta Studio recebe uma descrição escrita e produz um mundo Three.js que roda na aba. Você faz mudanças descrevendo-as, em vez de abrir um arquivo de cena e caçar o painel de inspetor certo. Isso é um substituto ruim para um grafo de nós quando você precisa de controle exato por quadro sobre uma fórmula de dano, e um ótimo substituto para as duas semanas que a maioria dos projetos perde com configuração.

O Ren'Py é o caso mais claro. Um projeto é uma pasta de arquivos de script em texto simples; você pode escrevê-lo e executá-lo a partir de qualquer editor de texto mais o launcher, e a única função obrigatória do launcher é iniciar o jogo. O Phaser é o segundo caso: um projeto é uma pasta de JavaScript e um arquivo HTML, e o navegador é o editor. Nenhum dos dois caminhos oferece um editor visual de mapas, mas nenhum exige que você instale um formato de projeto que não pode ler em um editor de texto.

O RPG Maker não se qualifica, porque o banco de dados, os mapas e as páginas de eventos vivem no formato de projeto do editor. Um builder no navegador segue o caminho oposto: a descrição é o projeto, e o editor é um campo de texto que você já está olhando. Se o seu motivo para evitar um editor é não querer aprender um, essa distinção importa mais do que a lista de recursos.

Exportação e publicação

O que você exporta decide o que seu jogador precisa fazer antes de poder jogar. O RPG Maker publica builds para Windows e macOS via NW.js, com a publicação para navegador e celular dependendo da versão e de ferramentas da comunidade. Uma publicação para navegador é um arquivo HTML, um runtime JavaScript e os diretórios de imagens e áudio do projeto — hospedável em qualquer servidor estático, mas os assets são baixados antes de a tela de título aparecer.

A Godot exporta por meio de presets armazenados em export_presets.cfg. Uma exportação web produz um shell HTML, um binário .wasm e um arquivo .pck com os dados do seu projeto. A exportação web com threads da Godot 4 precisa de SharedArrayBuffer, o que exige que o host envie os cabeçalhos COOP e COEP. Sem eles, ou você publica o build de thread única, ou a página nunca inicia. O build Web da Unity passa pelo IL2CPP e produz WebAssembly mais um pacote de dados, com a mesma exigência de cabeçalhos para threading e a mesma consequência por ignorá-la.

Os dois problemas práticos da Unity na web são o carregamento inicial e a memória. Uma cena que carrega tudo na inicialização trava no primeiro quadro; assets endereçáveis e cenas divididas são a solução, não um build menor. A Unreal exporta binários nativos para desktop e console e não tem destino de navegador com suporte. O Phaser não exporta nada, porque os arquivos já são arquivos web — publicar é copiar uma pasta. O Ren'Py produz distribuições por plataforma a partir de suas configurações de build, incluindo um build web, e empacota os assets junto com o runtime.

Se você vai publicar em um host estático, teste os cabeçalhos antes de testar o jogo. Um servidor local que define COOP e COEP vai esconder um problema de hospedagem que só aparece em produção.

A opção sem engine

Há um caminho em que nada do que foi dito acima se aplica, porque não há engine para instalar, nem pasta de projeto, nem preset de exportação para configurar. O 3D game builder da Neta Studio recebe uma descrição escrita e produz um mundo renderizado com Three.js na aba do navegador. O resultado é uma página. Você envia um link para alguém e o mundo abre; a pessoa não baixa um arquivo, nem roda um instalador, nem decide se confia em um executável.

Isso muda o formato do trabalho. Não há etapa de build para rodar de novo após uma edição nem exportação específica de plataforma para manter. Você descreve o terreno, o ângulo da câmera, a iluminação, os personagens que existem e o que o jogador pode fazer; o builder monta o grafo de cena e o Three.js o desenha. O Agent Sprite Forge cobre o caso em que um personagem ou objeto é necessário antes de existir um artista, e o Mini World e The Cyclops' Island são mundos jogáveis que você pode abrir para ver a câmera, o chão e o movimento já funcionando.

Isso não substitui a Godot ou a Unity em um RPG grande. Sistemas com exigências numéricas exatas — uma fórmula de dano, um formato de save que precisa permanecer compatível entre versões, uma máquina de estados de batalha com uma dúzia de status que interagem — ainda querem uma camada de script de verdade. O que isso elimina é a fase anterior, em que o mundo ainda não existe e você não consegue dizer se a câmera funciona ou se a escala parece errada.

Como escolher em dez minutos

Percorra estes itens na ordem e pare na primeira linha que decidir. A maioria dos projetos se resolve nos dois primeiros.

Entre no mundo a que ele pertence

Uma comparação de engines é uma tabela até uma linha estar rodando. A linha do navegador é a que você pode testar sem instalar nada: abra um mundo que foi descrito em uma frase e exportado como página. É assim que a última linha da tabela realmente se sente.