RPG Maker MV vs MZ: o que muda para os tradutores

Do ponto de vista de um tradutor, RPG Maker MV e MZ são 90% o mesmo motor. Ambos armazenam diálogos, opções, itens, habilidades e termos como JSON. Ambos usam os mesmos códigos de comando de evento (401 diálogo, 102 opções, 320/324/325 texto rolante). Ambos respeitam os mesmos códigos de controle (\C[1], \N[2], \V[3], etc.). Os 10% restantes — a estrutura de pastas, o formato dos parâmetros de plugins, um punhado de novos códigos de evento — é o que faz os tradutores tropeçarem quando migram de um para o outro. Este post é uma referência rápida.

Estrutura de pastas: a diferença mais visível

• MV armazena os arquivos de dados em www/data/*.json. Os recursos do jogo, os plugins e o runtime empacotado com Node ficam ao lado.
• MZ abandona o invólucro www/ e guarda os dados diretamente em data/*.json. O runtime também é mais enxuto (sem invólucro do Node por padrão; o MZ é distribuído como um aplicativo web estático no estilo NW.js).

Para o RuneTranslate isso é invisível — a detecção do motor examina os dois caminhos e escolhe o que existir. Mas se você fizer algo manualmente — copiar uma tradução entre jogos, verificar um arquivo com um editor externo — lembre-se do prefixo.

Diálogos, opções, texto rolante: idênticos

A estrutura dos comandos de evento é a mesma nos dois motores, o que significa que a superfície de tradução é idêntica:

• 401 — linha de diálogo em um comando Mostrar Texto.
• 405 — linhas de continuação do mesmo comando Mostrar Texto (quando o texto se estende por várias janelas de exibição).
• 102 — texto de uma opção de escolha.
• 320, 324, 325 — blocos de texto rolante (usados em créditos, cenas de monólogo).

O RuneTranslate analisa os cinco de forma idêntica em MV e MZ. A única coisa que varia é qual código costuma aparecer: os scripts do MZ usam mais o bloco de texto rolante nos modelos padrão, mas isso é preferência do autor, não diferença do motor.

Quebra de linha em 46 caracteres

Tanto o MV quanto o MZ quebram as linhas de diálogo na borda da janela de mensagens. A janela de mensagens padrão comporta cerca de 46 caracteres de um byte por linha no tamanho de fonte padrão; as linhas mais longas passam para a próxima janela visível. O RuneTranslate quebra automaticamente o diálogo em 46 caracteres na exportação nos dois motores, para que as linhas traduzidas não transbordem da caixa de fala.

Ressalva: se o jogo usar uma fonte personalizada mais larga ou mais estreita, a quebra pode precisar de ajuste. Por enquanto, isso é uma constante global no adaptador do RPG Maker; se você encontrar um jogo em que fique estranho, a solução é encurtar as linhas longas manualmente no editor antes de exportar.

Cadeias de parâmetros de plugins: onde o MZ diverge

Ambos os motores armazenam a configuração dos plugins em js/plugins.js (MV) ou js/plugins.js (MZ — o mesmo caminho, só que sem o prefixo www/). A estrutura do formato é a mesma: um arquivo JS que declara um bloco PluginManager.parameters por plugin. Os dois motores guardam as cadeias visíveis inline dentro desse bloco.

A diferença está em quais plugins vêm por padrão e em como eles declaram seus parâmetros. Os plugins no estilo Yanfly que o MZ traz por padrão usam com mais frequência esquemas de parâmetros aninhados e estruturados, o que pode produzir cadeias codificadas em JSON dentro de outra cadeia codificada em JSON. O RuneTranslate lida com as profundidades de aninhamento comuns, mas se um plugin usar uma codificação personalizada (JSON envolto em Base64, por exemplo), talvez você precise traduzir manualmente as cadeias desse plugin.

Conselho prático: se você vir no projeto cadeias parecidas com {"text":"こん..."} — é um bloco interno codificado em JSON que o plugin analisa em tempo de execução. O japonês ainda está lá, apenas envolto. Use o localizar e substituir do editor para conferir após a tradução.

Códigos de controle: idênticos, nunca deixe que se percam

Ambos os motores oferecem suporte à mesma família de códigos de controle:

• \C[n] — muda a cor do texto para o índice n da paleta.
• \N[n] — imprime o nome do ator n.
• \V[n] — imprime o valor da variável de jogo n.
• \., \|, \^ — modificadores de pausa / espera.

Esses precisam sobreviver à tradução exatamente como estão. Se um provedor descartar ou corromper \N[1], o jogo imprime lixo de barras invertidas em vez do nome do jogador. O RuneTranslate mascara cada código de controle com um marcador opaco antes de enviar ao provedor e depois os restaura com exatidão — e se algum marcador não voltar corretamente, a unidade é marcada como falha para que o japonês original permaneça.

Dicas práticas de fluxo de trabalho

• Não edite os arquivos JSON manualmente. Use o editor integrado do RuneTranslate para correções manuais. O editor registra quais unidades você editou, de modo que reexecutar o tradutor preserva o seu trabalho.
• Traduza os parâmetros de plugins por último. A maioria das cadeias de plugins é texto de configuração ou de interface que não exige muita edição manual. Rode primeiro os diálogos, corrija manualmente as linhas necessárias e depois processe os plugins em uma passagem separada com um provedor barato.
• Mantenha os saves entre retraduções. Os players do motor carregam os saves pelo índice da linha de dados, não pela cadeia. Desde que você não reordene os eventos, os jogadores podem manter seus arquivos de save após uma retradução para o inglês.

Para o passo a passo completo de RPG Maker, veja a página do motor RPG Maker. Para comparar provedores de tradução para jogos de RPG Maker, veja Os melhores provedores para traduzir jogos japoneses.