RPG Maker MV vs. MZ: Was sich für Übersetzer ändert

Aus Sicht eines Übersetzers sind RPG Maker MV und MZ zu 90 % dieselbe Engine. Beide speichern Dialoge, Auswahlmöglichkeiten, Gegenstände, Fähigkeiten und Begriffe als JSON. Beide verwenden dieselben Ereignisbefehlscodes (401 Dialog, 102 Auswahl, 320/324/325 Lauftext). Beide berücksichtigen dieselben Steuercodes (\C[1], \N[2], \V[3] usw.). Die verbleibenden 10 % — Ordnerstruktur, Format der Plugin-Parameter, eine Handvoll neuer Ereigniscodes — sind das, worüber Übersetzer stolpern, wenn sie zwischen beiden wechseln. Dieser Beitrag ist eine kurze Referenz.

Ordnerstruktur: der sichtbarste Unterschied

• MV speichert die Datendateien unter www/data/*.json. Spielinhalte, Plugins und die mit Node gebündelte Laufzeitumgebung liegen daneben.
• MZ lässt den www/-Wrapper weg und speichert die Daten direkt unter data/*.json. Die Laufzeitumgebung ist außerdem schlanker (standardmäßig kein mit Node gebündelter Wrapper; MZ wird als statische Web-App im NW.js-Stil ausgeliefert).

Für RuneTranslate ist das unsichtbar — die Engine-Erkennung prüft beide Pfade und wählt den, der vorhanden ist. Aber wenn du irgendetwas von Hand machst — eine Übersetzung von einem Spiel ins andere kopieren, eine Datei mit einem externen Editor prüfen —, denk an das Präfix.

Dialoge, Auswahl, Lauftext: identisch

Die Struktur der Ereignisbefehle ist in beiden Engines gleich, was bedeutet, dass die Übersetzungsfläche identisch ist:

• 401 — Dialogzeile in einem Show-Text-Befehl.
• 405 — Folgezeilen desselben Show-Text-Befehls (wenn Text über mehrere Anzeigefenster reicht).
• 102 — Text einer Auswahloption.
• 320, 324, 325 — Lauftext-Blöcke (verwendet für Abspann, Monolog-Szenen).

RuneTranslate verarbeitet alle fünf in MV und MZ identisch. Das Einzige, was variiert, ist, welcher Code tendenziell auftaucht: MZ-Skripte nutzen den Lauftext-Block in den Standardvorlagen häufiger, aber das ist Vorliebe des Autors, kein Engine-Unterschied.

Zeilenumbruch bei 46 Zeichen

Sowohl MV als auch MZ brechen Dialogzeilen am Rand des Nachrichtenfensters um. Das Standard-Nachrichtenfenster fasst bei der Standard-Schriftgröße etwa 46 Einzelbyte-Zeichen pro Zeile; längere Zeilen brechen in das nächste sichtbare Fenster um. RuneTranslate bricht Dialoge beim Export automatisch bei 46 Zeichen um — in beiden Engines, damit übersetzte Zeilen nicht aus der Sprechblase laufen.

Vorbehalt: Wenn das Spiel eine benutzerdefinierte Schriftart verwendet, die breiter oder schmaler ist, muss der Umbruch möglicherweise angepasst werden. Derzeit ist dies eine globale Konstante im RPG-Maker-Adapter; wenn du ein Spiel findest, bei dem es unsauber aussieht, besteht die Abhilfe darin, die langen Zeilen vor dem Export im Editor von Hand zu kürzen.

Plugin-Parameter-Strings: wo MZ abweicht

Beide Engines speichern die Plugin-Konfiguration in js/plugins.js (MV) bzw. js/plugins.js (MZ — derselbe Pfad, nur ohne das www/-Präfix). Die Struktur des Formats ist gleich: eine JS-Datei, die pro Plugin einen PluginManager.parameters-Block deklariert. Beide Engines speichern sichtbare Strings inline in diesem Block.

Der Unterschied liegt darin, welche Plugins standardmäßig ausgeliefert werden und wie sie ihre Parameter deklarieren. Die Standard-Plugins im Yanfly-Stil von MZ verwenden häufiger strukturierte, verschachtelte Parameter-Schemata, was JSON-codierte Strings innerhalb eines JSON-codierten Strings erzeugen kann. RuneTranslate bewältigt gängige Verschachtelungstiefen, aber wenn ein Plugin eine eigene Codierung verwendet (zum Beispiel Base64-verpacktes JSON), musst du die Strings dieses Plugins möglicherweise von Hand übersetzen.

Praktischer Rat: Wenn du im Projekt Strings siehst, die wie {"text":"こん..."} aussehen — das ist ein JSON-codierter innerer Block, den das Plugin zur Laufzeit parst. Das Japanische ist noch da, nur eingepackt. Nutze die Suchen-und-Ersetzen-Funktion des Editors, um nach der Übersetzung stichprobenartig zu prüfen.

Steuercodes: identisch, lass sie nie verloren gehen

Beide Engines unterstützen dieselbe Familie von Steuercodes:

• \C[n] — schaltet die Textfarbe auf Paletten-Index n um.
• \N[n] — gibt den Namen von Akteur n aus.
• \V[n] — gibt den Wert der Spielvariablen n aus.
• \., \|, \^ — Pause-/Warte-Modifikatoren.

Diese müssen die Übersetzung wortwörtlich überstehen. Wenn ein Anbieter \N[1] verschluckt oder verfälscht, gibt das Spiel rohen Backslash-Müll statt des Spielernamens aus. RuneTranslate maskiert jeden Steuercode vor dem Senden an den Anbieter mit einem undurchsichtigen Platzhalter und stellt sie danach exakt wieder her — und wenn ein Platzhalter den Rundlauf nicht übersteht, wird die Einheit als fehlgeschlagen markiert, sodass das ursprüngliche Japanisch erhalten bleibt.

Praktische Workflow-Tipps

• Bearbeite die JSON-Dateien nicht von Hand. Nutze für manuelle Korrekturen den eingebauten Editor von RuneTranslate. Der Editor verfolgt, welche Einheiten du bearbeitet hast, sodass ein erneuter Durchlauf des Übersetzers deine Arbeit bewahrt.
• Übersetze Plugin-Parameter zuletzt. Die meisten Plugin-Strings sind Konfigurations- / UI-Text, der kaum manuelle Nachbearbeitung braucht. Lass zuerst die Dialoge laufen, korrigiere die Zeilen von Hand, die es brauchen, und lass dann die Plugins in einem separaten Durchgang mit einem günstigen Anbieter laufen.
• Behalte Speicherstände über Neuübersetzungen hinweg. Die Engine-Player laden Speicherstände über den Datenzeilen-Index, nicht über Strings. Solange du keine Ereignisse umsortierst, können Spieler ihre Speicherdateien über eine englische Neuübersetzung hinweg behalten.

Die vollständige RPG-Maker-Anleitung findest du auf der RPG-Maker-Engine-Seite. Um Übersetzungsanbieter für RPG-Maker-Spiele zu vergleichen, siehe Die besten Anbieter zum Übersetzen japanischer Spiele.