Wir machen euer RPG Maker MZ-Spiel mehrsprachig!

Hallo auch!

Sicherlich gibt es unter euch auch jene, welche ihr Spiel gerne sowohl der internationalen Spielerschaft, wie auch dem deutschsprachigem Publikum möglichst zugänglich machen möchten.

Am einfachsten geht dies natürlich mit unterschiedlichen Lokalisierungen!

Für dieses kurze Tutorial verwenden wir folgendes Plugin von Open Digital World, dessen Einrichtung ich hier gerne im Detail erläutern möchte.

Außerdem brauchen wir noch einen Texteditor für den JSON-Teil des Tutorials. Ich verwende in diesem Beispiel Notepad++.

1. Das Plugin und den Projektordner vorbereiten

Zuerst wird das Plugin ganz normal in den Projekt-Ordner kopiert. Im RPG Maker MZ gehen wir in den Plugin Manager und aktivieren es dort. Hier fällt bei den Parametern sofort auf, dass dieses Plugin kein "Plug & Play" ist, sondern noch ein paar Vorbereitungen benötigt, um seine Funktion erfüllen zu können.

Hier kann man sehen, dass ich bereits (oben rechts) bei "Languages Option" (in der JSON) mit einem String arbeite, damit dieser Punkt ebenfalls berücksichtigt wird.

Im Projektordner eures Spieles erstellen wir einen neuen Ordner namens "languages" oder einen anderen beliebigen Namen, welcher dann aber auch in der 2. Parameter-Spalte des Plugins ("Languages Folder") angepasst werden muss. In diesem Ordner können wir uns nun Abkürzungen für die angestrebten Sprachen erstellen, welche als eigenständige Ordner in "languages" erstellt werden. In meinem Fall waren dies einmal "en" für die englische Sprachversion und einmal "ger" für die deutsche Version.

Hier lässt sich bereits (für Notepad++-Nutzer anhand der Icons) erahnen, was später in die Ordner kommen wird.

Nun werden wir auch nochmal im Plugin schauen, dass wir alles nach demselben Prinzip vorbereiten.

Hier sieht man, wie das Plugin in der 3. Parameter-Spalte einen Bezug zu den gerade erstellten Ordnern herstellt. Die 4. Spalte ist ebenso wichtig und wird im 2. Themenpunkt behandelt.

Sobald dies der Fall ist, öffnen wir nun den Texteditor unserer Wahl und erstellen in jedem Ordner (in dem Fall "en" und "ger") eine JSON-Datei, welche wir "main" nennen. Diese Datei ist ebenfalls bereits im Plugin vordefiniert (4. Spalte des obigen Bildes). Und genau mit diesen JSON-Dateien machen wir nun weiter!
Wichtig ist, dass alle Bezeichnungen (auch in Sachen Groß- und Kleinschreibung) 1:1 identisch sind.

2. JSON-Dateien erstellen und Strukturen aufbauen

Wir haben nun das Plugin eingestellt und im Projektordner die entsprechenden Vorbereitungen getroffen. Nun gehen wir dazu über zu definieren, welche Inhalte wir gerne im Spiel übersetzen möchten. Dafür öffnen wir eine der beiden mit "main" betitelten JSON-Dateien und bauen uns eine Struktur auf!

Hier zeige ich euch mal den Inhalt meiner exemplarischen "main"-JSON-Datei und erkläre euch die einzelnen Abschnitte.
Wichtig ist hervorzuheben, dass in einer JSON-Datei keine simplen Kommentare möglich sind, wie man es vom Programmieren in diversen Sprachen mit "#" oder "//" vor einem Text kennt, welcher für den Programmierer als Gedankenstütze dient und keinen vom Programm auszuführenden Code enthält. Die Leerzeilen dienen deswegen als thematische Trennzeichen zur Erleichterung des Lesens.
Auch muss aufgrund der Syntax (grob der "Grammatik" des Datenformats) hinter jeder Zeile ein "," stehen - außer in der letzten Zeile.

"Game.mainTitle":           "Das ultimative RPG-Deluxe-Pro-Mega-Edition",

"Command.fight":            "Angreifen",
"Command.escape":           "Fliehen",
"Command.attack":           "Zuschlagen",
"Command.guard":            "Beschützen",
"Command.item":             "Rucksack",
"Command.skill":            "Fähigkeiten",
"Command.equipment":        "Ausrüstung",
"Command.status":           "Status",
"Command.formation":        "Anordnung",
"Command.options":          "Einstellungen",
"Command.save":             "Speichern",
"Command.gameEnd":          "Spiel beenden",
"Command.weapon":           "Waffen",
"Command.armor":            "Rüstungen",
"Command.keyItem":          "Wichtige Gegenstände",
"Command.equip":            "Ausrüsten",
"Command.optimize":         "Optimieren",
"Command.clear":            "Alles entfernen",
"Command.buy":              "Kaufen",
"Command.sell":             "Verkaufen",
"Command.newGame":          "Neues Spiel",
"Command.continue":         "Fortsetzen",
"Command.toTitle":          "Zum Startmenü",
"Command.cancel":           "Abbrechen",

"Message.language":         "Sprache",
"Message.alwaysDash":       "Immer Rennen",
"Message.commandRemember":  "Befehle merken",
"Message.touchUi":          "Benutze Touch UI",
"Message.bgmVolume":        "Hintergrund-Musik",
"Message.bgsVolume":        "Hintergrund-Geräusche",
"Message.meVolume":         "Musik-Effekte",
"Message.seVolume":         "Geräusch-Effekte"

Hierbei handelt es sich um folgende Gliederung, welche ich vom Plugin-Ersteller übernommen und (bislang) minimal erweitert habe.

1. Abschnitt:
Der Name des Projektes, welcher oben im Fenster des Spiels (und wenn aktiviert im Titelmenü) angezeigt wird.
Bei Bedarf lässt sich hier auch die Währung an die jeweilige Sprache des Spielers anpassen, indem man (beispielsweise) eine Spalte mit ""Game.currencyUnit":" und gemäß der grundlegenden Struktur mit einem in "Wert" auf der rechten Seite verwendet. Ebenso kann man im Falle eines Schrittzählers oder anderer Funktionen diese hier aufgreifen und entsprechend übersetzen.

2. Abschnitt:
Befehle aus diversen Menüpunkten, welche der Spieler auswählen kann.
Der Plugin-Ersteller hat hier mit "command." gearbeitet, um die Buttons beim Lesen besser hervorzuheben. Grundlegend kann man sich aber auch hier seine eigene Logik überlegen, da diese Werte auf der Linken Seite lediglich als Verknüpfung von Datenbank-Spalten und JSON-Übersetzung dienen. Je prägnanter diese Namen sind, desto leichter lässt sich damit arbeiten. Deswegen rate ich dazu, diese zu übernehmen und nach denselben Prinzipien neue Verknüpfungen zu erstellen - gerade wenn man das Spiel durch anpassbare Menüs und zusätzliche Funktionen weiter individualisiert.

3. Abschnitt
Informationen aus dem Optionen-Menü, welche nur dort gebündelt vorkommen.
Hier habe ich in der ersten Spalte "Message.language" hinzugefügt, damit im Optionsmenü auch der Menüpunkt für ausgewählte Sprachen in der jeweilig ausgewählten Sprache benannt wird. Darüber hinaus kann man auch hier die gegebene Logik konsequent weiterverfolgen, wenn man durch Plugins ein wesentlich umfassenderes Optionsmenü hat.

3. Im RPG Maker MZ alle gewünschten Texte durch Strings austauschen

Jetzt ist es an der Zeit, in die Datenbank des RPG Maker MZ zu gehen.
Dort "verlinken" wir nun mit

${beliebiger-Inhalt-der-linken-Spalte-der-JSON-Datei}

die Textausgabe des Spielprojektes mit den multiplen Möglichkeiten der unterschiedlichen Sprachvarianten. Da nach Auswahl der Sprache die jeweilige "main"-JSON-Datei verwendet wird, reicht der soeben genannte Befehl vollkommen aus, um mehrere Sprachen gleichzeitig zu verwalten.

Da Bilder mehr sagen als Worte - hier ein Beispiel! Man kann sehr gut sehen, wieviel Arbeit noch vor einem liegen wird. Oben rechts lässt sich das Vorgehen am besten lesen/herleiten.

4. Optional: Weitere Überlegungen

Nun haben wir die Grundsteinlegung hinter uns. Doch die tatsächliche Arbeit wird darin bestehen, all die Dialoge des Spiels in die JSONs zu schreiben und diese Strings in Nachrichtenfenster, Auswahlfenster, Item Beschreibungen, etc zu setzen.

Neben diesem Zusatzschritt hat man nun natürlich auch mindestens die doppelte Arbeit, da der Maker keinen automatischen Zeilenumbruch in den Dialogfenstern nutzt und übersetzte Texte ohne sorgfältige Überprüfung abgeschnitten werden können.

Aber eigentlich möchte ich auf etwas anderes hinaus: Wie viele JSON-Dateien pro Sprache machen Sinn?

Wir wissen ja, dass wir derer einige im Plugin einstellen können. In welchen Situationen kann dies sinnvoll sein?

• Beispielsweise kann bei sehr dialoglastigen RPGs eine Aufteilung im Sinne der Kapitel/Akte/etc auf eigene JSON-Dateien sinnvoll sein. So lassen sich Übersetzungen und/oder Korrekturen schneller vornehmen, da man beim Öffnen der Datei sofort in einem Themenbereich steckt.
• Wenn man dies wünscht, kann man auch alle Formen von Gegenständen ("Items", "Ausrüstung", "Wichtige Gegenstände") in einer eigenen JSON-Datei bündeln, um sich im Workflow das viele Scrollen (trotz Einklappen der Elemente) etwas zu reduzieren.
• Ebenso könnte man Bereiche durch eigene JSON-Dateien "ausklammern", welche unter Umständen noch einer starken Überarbeitung unterliegen - wie beispielsweise ein selbst geschriebenes Plugin im WIP-Zustand. Dieses ließe sich bei Bedarf im Nachhinein leicht in eine größere Datei hinüber kopieren, wo man dann mit den Klammern arbeiten kann.

Als Dreingabe hänge ich euch die beschriebene Ordnerstruktur samt beispielhafter JSON-Dateien zur freien Verwendung an, welche bereits ein paar (aber bei Weitem nicht alle) Parameter aus der Datenbank und die Sprachoption im Spiel selbst übersetzen. Das erspart euch etwas Schreibarbeit.

Danke Dir!

Es scheint so zu sein, dass man nur den Weg über die JSON-Datei hat (\n), was entweder Try & Error oder über den Daumen gepeilt grob eine maximale Zeichenanzahl pro Zeile zur Folge hat (grob, da manche Zeichen trotzdem mehr Platz einnehmen und somit eine fixe Zahl nur eine Orientierung sein kann).

Gerade bin ich mit dem Ersteller wegen eines bereits ausgemerzten Bugs im Austausch. Ich könnte Mal nachfragen, ob sich die Zeilenumbrüche irgendwie automatisieren ließen, indem beispielsweise ein benutzerdefinierter Wert (Zeichen pro Zeile) als neuer Parameter in das Plugin aufgenommen wird. (Benutzerdefiniert, da man als Nutzer unter Umständen die Textbox modifiziert hat.)

Das wäre zwar keine komplette Lösung (aus oben genannten Gründen), aber dürfte zumindest in vielen Fällen ausreichen.

Dafür würde ich tatsächlich empfehlen, dass man mehrere JSON-Dateien verwendet (Struktur nach eigener Logik), sodass man beim "Abarbeiten der Übersetzung" fern der nativen Sprache einen möglichst schnellen und übersichtlichen Zugriff auf die entsprechenden Strings hat.

Wenn beispielsweise jedes Kapitel eine eigene JSON ist, kann man innerhalb dieser mit den Leerzeilen die Orte in chronologischer Reihenfolge unterteilen. Eine ausgelagerte Textdatei oder eine externe Excel-Tabelle könnte da als "Erinnerungs-Backup" herhalten.

Was man auch ausprobieren könnte wäre, wenn man in der JSON Zeilen hinzufügt, welche nie abgerufen werden. Das wären keine klassischen Kommentare, aber könnte dieselbe Funktion erfüllen. Das habe ich bislang noch nicht ausprobiert, da ich "sauber" arbeiten wollte.

Ich kann Dich da sehr gut verstehen!

Zu Beginn eines Projektes würde ich (und praktisch ist das bei Misty Hollow auch so) das Plugin schon Mal einbauen, um mit einer Hauptsprache zu arbeiten und überall im Projekt bereits die Verknüpfungen für die Strings zu platzieren, damit ich später nichts übersehe, was dann partout in der Hauptsprache bleibt, da ich genau DAS Event nicht mehr angepasst habe.

Die Idee die Map- und Event-ID festzuhalten ist an sich schon sehr präzise und sollte dies verhindern - sehr cool!

Von Anfang an multilingual zu arbeiten erscheint mir auch nicht sonderlich sinnvoll. Da sind die ständigen Überarbeitungen nichts, was ich mir in 2-5 Sprachen (Zahlen jetzt aus'm Bauch heraus - wahrscheinlich sind die Klassiker Deutsch, Englisch, Spanisch, Französisch, & vllt einfaches Mandarin) antun möchte - davon abgesehen ob man dies maschinell versucht oder tatsächlich noch andere Menschen ins Boot holt, welche dann ebenso betroffen sind.

Wenn jemand masochistische Tendenzen hat und sehr sprachbegabt ist, kann die Person das natürlich gerne Mal als Selbstversuch mit der eigenen Leidensfähigkeit angehen.

Auf jeden Fall - es ist natürlich Aufwand, aber als deutschsprachiger Entwickler wäre mir schon daran gelegen, nicht "nur" die englische Sprache zu bieten. Natürlich spielen da auch ab einem gewissen Punkt Fragen der Wirtschaftlichkeit mit hinein, aber ich sehe die Projekte welche ich habe nicht als potenzielle Haupteinkommensquelle für meinen Lebensunterhalt, dieser ist ja anderweitig abgedeckt. Ich wage sogar zu behaupten, dass es ohne eine starke Nische ("Erotik" scheint meist verhältnismäßig gut zu laufen) generell sehr schwierig sein kann, sich denselben Lebensstandard zu sichern, als wenn man angestellt ist. Da sehe ich im Spielemarkt einfach eine zu starke Übersättigung. Natürlich gibt es immer Phänomene (beispielsweise neues Spielgenre-Crossover) und den Einfluss der Influencer, aber das sind selten(er) Dinge welche man selbst in der Hand hat.

Davon abgesehen ist es aber natürlich super, wenn man möglichst viele Menschen erreicht, was sich nicht nur in potenziellen Verkäufen (im Falle eines kommerziellen Projektes), sondern auch potenziell mehr Reviews und einem entsprechenden Ruf/Sichtbarkeit für Folgeprojekte widerspiegelt. Aber gut - ich drifte leicht ab.

Was Übersetzungen betrifft, so bin ich echt mal gespannt, was da maschinell künftig noch alles weiter verbessert wird - inzwischen haben wir ja stellenweise schon echt einen guten Stand erreicht. RPGs stellen hier aber natürlich nochmal eine andere Herausforderung dar, als Spiele mit mehr Action, wo Dialoge eher eine Nebensächlichkeit sind und man im Zweifel lediglich das UI übersetzen muss.

Danke übrigens für den Einblick, was das professionell so kosten kann (in Deinem Fall eine günstige Variante - wahrscheinlich vor (starker) (Kern-)Inflation und anderen Wirtschaftsfaktoren)!
Es ist immer hilfreich, wenn man da möglichst früh weiss was gängiger(e) Standard(s) sind - gerade damit Freelancer nicht mit völlig utopischen Preisvorstellungen der Kunden konfrontiert werden, von welchen man einfach nicht leben kann. Denn leider vergessen manche schnell, dass Menschen welche sowas beruflich machen rein nach erbrachter Leistung bezahlt werden und da der Zeitfaktor stark mit hinein spielt. Es ist halt kein Hobby, in dem man endlos Zeit versenken könnte.