RPG Maker MV と MZ の翻訳: 翻訳者にとって何が変わるか

翻訳者の視点から見ると、RPG Maker MV と MZ は 90% 同じエンジンです。どちらもセリフ、選択肢、アイテム、スキル、用語を JSON として保存します。どちらも同じイベントコマンドコード(401 セリフ、102 選択肢、320/324/325 スクロールテキスト)を使います。どちらも同じ制御コード(\C[1]、\N[2]、\V[3] など)に従います。残る 10% — フォルダ構成、プラグインのパラメータ形式、いくつかの新しいイベントコード — こそが、両者を行き来する翻訳者をつまずかせる部分です。この記事は手早い参考資料です。

フォルダ構成: 最も目に見える違い

• MV はデータファイルを www/data/*.json に保存します。ゲームのアセット、プラグイン、Node に同梱されたランタイムがその隣に並びます。
• MZ は www/ ラッパーを取り払い、データを直接 data/*.json に保存します。ランタイムもより軽量です(デフォルトでは Node 同梱のラッパーがなく、MZ は NW.js スタイルの静的ウェブアプリとして出荷されます)。

RuneTranslate ではこれは見えません — エンジン検出が両方のパスを調べ、存在する方を選びます。ただし手作業で何かをするなら — ゲーム間で翻訳をコピーしたり、外部エディタでファイルを確認したり — 接頭辞を忘れないでください。

セリフ、選択肢、スクロールテキスト: 同一

イベントコマンドの構造は両エンジンで同じであり、つまり翻訳対象領域は同一です:

• 401 — 文章の表示コマンド内のセリフ行。
• 405 — 同じ文章の表示コマンドの継続行(テキストが複数の表示ウィンドウにまたがる場合)。
• 102 — 選択肢のテキスト。
• 320、324、325 — スクロールテキストのブロック(クレジットや独白シーンに使われます)。

RuneTranslate はこの 5 つを MV と MZ で同一に解析します。唯一異なるのは、どのコードが出やすいかです。MZ のスクリプトはデフォルトのテンプレートでスクロールテキストのブロックをより多く使いますが、それは作者の好みであってエンジンの違いではありません。

46 文字での折り返し

MV も MZ もメッセージウィンドウの端でセリフ行を折り返します。デフォルトのメッセージウィンドウは、デフォルトのフォントサイズで 1 行あたりおよそ 46 個の半角文字が収まり、それより長い行は次の表示ウィンドウへ折り返されます。RuneTranslate はエクスポート時に両エンジンでセリフを 46 文字で自動折り返しし、翻訳された行が吹き出しからあふれないようにします。

注意点: ゲームが幅の広い、または狭いカスタムフォントを使っている場合、折り返しの調整が必要になることがあります。今のところこれは RPG Maker アダプタ内のグローバル定数です。表示が崩れて見えるゲームを見つけたら、回避策としてエクスポート前にエディタで長い行を手作業で短くしてください。

プラグインのパラメータ文字列: MZ が分かれるところ

両エンジンともプラグインの設定を js/plugins.js(MV)または js/plugins.js(MZ — 同じパスで、www/ 接頭辞がないだけ)に保存します。形式の構造は同じで、プラグインごとに PluginManager.parameters ブロックを宣言する JS ファイルです。両エンジンとも表示される文字列をそのブロック内にインラインで保存します。

違いは、どのプラグインがデフォルトで出荷されるかと、それらがパラメータをどう宣言するかにあります。MZ のデフォルトの Yanfly スタイルのプラグインは、構造化されたネスト型のパラメータスキーマをより頻繁に使うため、JSON エンコードされた文字列の中にさらに JSON エンコードされた文字列が入ることがあります。RuneTranslate は一般的なネストの深さを処理しますが、プラグインが独自のエンコード(例えば Base64 で包まれた JSON)を使っている場合は、そのプラグインの文字列を手作業で翻訳する必要があるかもしれません。

実践的なアドバイス: プロジェクト内に {"text":"こん..."} のように見える文字列があれば — それはプラグインが実行時に解析する JSON エンコードされた内側のブロックです。日本語はまだそこにあり、包まれているだけです。翻訳後はエディタの検索・置換で抜き取り確認をしてください。

制御コード: 同一、決して失わせないこと

両エンジンは同じ系統の制御コードをサポートします:

• \C[n] — テキストの色をパレットのインデックス n に切り替えます。
• \N[n] — アクター n の名前を表示します。
• \V[n] — ゲーム変数 n の値を表示します。
• \.、\|、\^ — 一時停止 / 待機の修飾子。

これらは翻訳を経ても必ずそのまま残らなければなりません。プロバイダが \N[1] を落としたり壊したりすると、ゲームはプレイヤーの名前の代わりに生のバックスラッシュのゴミを表示します。RuneTranslate はプロバイダへ送る前にすべての制御コードを不透明なプレースホルダで覆い、その後で正確に復元します — そしていずれかのプレースホルダが往復に失敗した場合、そのユニットは失敗としてマークされ、元の日本語が残ります。

実践的なワークフローのヒント

• JSON ファイルを手作業で編集しないこと。 手作業の修正には RuneTranslate の組み込みエディタを使ってください。エディタはどのユニットを編集したかを追跡するので、翻訳を再実行しても作業が保持されます。
• プラグインのパラメータは最後に翻訳すること。 ほとんどのプラグイン文字列は、手作業の編集をあまり必要としない設定 / UI テキストです。まずセリフを実行し、必要な行を手作業で修正してから、安価なプロバイダで別のパスとしてプラグインを実行してください。
• 再翻訳をまたいでセーブを保持すること。 エンジンのプレイヤーはセーブを文字列ではなくデータ行のインデックスで読み込みます。イベントの順序を入れ替えない限り、プレイヤーは英語への再翻訳をまたいでセーブファイルを保持できます。

RPG Maker の完全な手順については、RPG Maker エンジンのページをご覧ください。RPG Maker ゲーム向けの翻訳プロバイダを比較するには、日本語ゲームの翻訳に最適なプロバイダをご覧ください。