RPG Maker MV vs MZ: qué cambia para los traductores

Desde el punto de vista de un traductor, RPG Maker MV y MZ son en un 90% el mismo motor. Ambos almacenan diálogos, opciones, objetos, habilidades y términos como JSON. Ambos usan los mismos códigos de comando de evento (401 diálogo, 102 opciones, 320/324/325 texto con desplazamiento). Ambos respetan los mismos códigos de control (\C[1], \N[2], \V[3], etc.). El 10% restante —la estructura de carpetas, el formato de los parámetros de plugins, un puñado de nuevos códigos de evento— es lo que hace tropezar a los traductores cuando pasan de uno a otro. Esta entrada es una referencia rápida.

Estructura de carpetas: la diferencia más visible

• MV almacena los archivos de datos en www/data/*.json. Los recursos del juego, los plugins y el runtime empaquetado con Node están junto a ellos.
• MZ elimina el envoltorio www/ y guarda los datos directamente en data/*.json. El runtime también es más ligero (sin envoltorio de Node por defecto; MZ se distribuye como una aplicación web estática al estilo NW.js).

Para RuneTranslate esto es invisible: la detección del motor examina ambas rutas y elige la que exista. Pero si haces algo a mano —copiar una traducción entre juegos, revisar un archivo con un editor externo— recuerda el prefijo.

Diálogos, opciones, texto con desplazamiento: idénticos

La estructura de los comandos de evento es la misma en ambos motores, lo que significa que la superficie de traducción es idéntica:

• 401 — línea de diálogo en un comando Mostrar texto.
• 405 — líneas de continuación del mismo comando Mostrar texto (cuando el texto abarca varias ventanas de visualización).
• 102 — texto de una opción de elección.
• 320, 324, 325 — bloques de texto con desplazamiento (usados para créditos, escenas de monólogo).

RuneTranslate analiza los cinco de forma idéntica en MV y MZ. Lo único que varía es qué código suele aparecer: los scripts de MZ usan más el bloque de texto con desplazamiento en las plantillas por defecto, pero eso es preferencia del autor, no diferencia del motor.

Ajuste de línea a 46 caracteres

Tanto MV como MZ cortan las líneas de diálogo en el borde de la ventana de mensajes. La ventana de mensajes por defecto admite aproximadamente 46 caracteres de un byte por línea con el tamaño de fuente predeterminado; las líneas más largas pasan a la siguiente ventana visible. RuneTranslate ajusta automáticamente el diálogo a 46 caracteres al exportar en ambos motores para que las líneas traducidas no desborden el cuadro de diálogo.

Advertencia: si el juego usa una fuente personalizada más ancha o más estrecha, es posible que el ajuste necesite modificarse. Por ahora se trata de una constante global en el adaptador de RPG Maker; si encuentras un juego donde se vea mal, la solución es acortar a mano las líneas largas en el editor antes de exportar.

Cadenas de parámetros de plugins: donde MZ diverge

Ambos motores almacenan la configuración de los plugins en js/plugins.js (MV) o js/plugins.js (MZ, la misma ruta, solo que sin el prefijo www/). La estructura del formato es la misma: un archivo JS que declara un bloque PluginManager.parameters por plugin. Ambos motores guardan las cadenas visibles en línea dentro de ese bloque.

La diferencia está en qué plugins vienen por defecto y cómo declaran sus parámetros. Los plugins de estilo Yanfly que trae MZ por defecto usan con más frecuencia esquemas de parámetros anidados y estructurados, lo que puede producir cadenas codificadas en JSON dentro de otra cadena codificada en JSON. RuneTranslate maneja las profundidades de anidamiento habituales, pero si un plugin usa una codificación personalizada (por ejemplo, JSON envuelto en Base64), es posible que tengas que traducir a mano las cadenas de ese plugin.

Consejo práctico: si ves en el proyecto cadenas con aspecto de {"text":"こん..."} —es un bloque interno codificado en JSON que el plugin analiza en tiempo de ejecución. El japonés sigue ahí, solo que envuelto. Usa la función buscar y reemplazar del editor para comprobarlo tras la traducción.

Códigos de control: idénticos, no dejes que se pierdan nunca

Ambos motores admiten la misma familia de códigos de control:

• \C[n] — cambia el color del texto al índice n de la paleta.
• \N[n] — imprime el nombre del actor n.
• \V[n] — imprime el valor de la variable de juego n.
• \., \|, \^ — modificadores de pausa / espera.

Estos deben sobrevivir a la traducción tal cual. Si un proveedor elimina o corrompe \N[1], el juego imprime basura con barras invertidas en lugar del nombre del jugador. RuneTranslate enmascara cada código de control con un marcador opaco antes de enviarlo al proveedor y luego los restaura exactamente; y si algún marcador no logra volver a su sitio, la unidad se marca como fallida para que se conserve el japonés original.

Consejos prácticos de flujo de trabajo

• No edites a mano los archivos JSON. Usa el editor integrado de RuneTranslate para los ajustes manuales. El editor registra qué unidades has editado, de modo que volver a ejecutar el traductor conserva tu trabajo.
• Traduce los parámetros de plugins al final. La mayoría de las cadenas de plugins son texto de configuración o de interfaz que no necesita mucha edición manual. Ejecuta primero los diálogos, corrige a mano las líneas que lo requieran y luego procesa los plugins en una pasada aparte con un proveedor barato.
• Conserva las partidas guardadas entre retraducciones. Los reproductores del motor cargan las partidas por índice de fila de datos, no por cadena. Mientras no reordenes los eventos, los jugadores pueden conservar sus archivos de guardado tras una retraducción al inglés.

Para el tutorial completo de RPG Maker, consulta la página del motor RPG Maker. Para comparar proveedores de traducción para juegos de RPG Maker, consulta Los mejores proveedores para traducir juegos japoneses.