【ACADEMY】日本産ゲームのローカライズにおける技術的課題とその解決方法

[2021/09/08 07:00]

CodeglueのThomas Jongman氏が，日本のゲームを英語にローカライズする際に遭遇する一般的な問題について詳しく説明する。

　Stranger of Sword City Revisited（SoSCR：剣の街の異邦人～黒の宮殿～）とSaviors of Sapphire Wings（SoSW：蒼き翼のシュバリエ/新釈・剣の街の異邦人）は，それぞれ2016年と2019年にPlayStation Vita向けに先行発売された2つのダンジョン・クローリングJRPGだ。

　2019年末，NIS Americaから，この2作品をNintendo SwitchとPCに移植することについて相談を受けた。この記事では，この2つのゲームに見られたローカライズの技術的な課題と，それを解決するために我々がどのようにアプローチしたかについて概説する。なお，この記事では，NIS Americaが担当したテキストの翻訳については触れていない。

当初の状況

　Playstation VITAで発売されたSoSCRは，すでに英語版が発売されていた。そのため，新しいプラットフォームでの英語ローカライズ版の制作にはどのような苦労があったのと思う人もいるだろう。

　本作は日本版と英語版が別々のSKUとなっており，日本語または英語のテキストのみが表示され，ゲーム内で2つの言語を切り替えるオプションはなかった。このオプションはグローバルで発売するには必要なものだった。

　SoSWについては，オリジナルのゲームは「蒼き翼のシュバリエ」という名前で日本語版のみが発売されており，英語版のテキストやリリースは一切なかった。

日本語テキストのエンコーディング

　日本のゲームに共通して言えることだが，テキストやソースコードのエンコーディングは，ソフトウェアで一般的に使用されているUTF-8ではなく，Shift-JISで行われることが多い。これは，コンパイラがソースコードを別のエンコーディングとして解釈し，予期しない文字に遭遇したときにシンタックスエラーを引き起こす可能性がある。この問題を解決するために，ソースコードをUTF-8に変換するスクリプトを作成した。

　しかし，この方法には問題がある。ソースコードにハードコードされた文字列が含まれていると，それらも変換されてしまい，これらの文字列がまだShift-JISエンコーディングを期待しているシステムに渡されると，大混乱に陥ってしまうだろう。幸運なことに，SoSCRとSoSWにはそれがなかった。

誤って解釈されたテキストは，一見するとランダムな文字として表示される。なお，ラテン文字については，2つのエンコーディングで同一なため，同じ文字が表示される

アセットのテキストデータ

　どちらのゲームも，プレイヤーに表示されるテキストは，複数の異なるファイルやファイルタイプに分かれている。これは，ゲーム内でどの機能や画面にテキストが表示されるかを決定するコンテンツ制作ツールによって分けられている。

　そのため，ゲームの移植作業を行う際には，テキストデータを含む最大のファイルを見つけた時点で，すべてのテキストを見つけたと考えてはいけない。ベストプラクティスは，テキストエディタやカスタムスクリプトですべてのファイルを検索し，共通の単語やフレーズをチェックすることだ。これにより，プロジェクト内のテキストを含むすべてのファイルを発見できる。ただし，バイナリファイルも必ずチェックしてほしい。

テキストデータを含む最大のファイルを発見した時点で，すべてのテキストを発見したと考えてはいけない

　今回のプロジェクトでは，テキストを以下のように分割した。

UIでのみ表示されるテキスト
キャラクターが話すテキスト
オブジェクトに関連するテキスト（通常「タイプデータ」と呼ばれる）（アイテム，スペル，クエストなど）
ゲーム内のマニュアルに記載されているテキスト

　このようなさまざまな種類のテキストの元となるのがExcelのスプレッドシートだ。これらのExcelスプレッドシートは，一連のカスタムツールの入力として使用され，C++ヘッダー，プレーンテキストファイル，カスタムバイナリフォーマットなど，さまざまなファイルを出力する。ゲームを移植するためのローカライズシステムを構築する際には，これらの異なるテキストデータのソースを考慮する必要があった。

2つのゲームのチュートリアルテキストは別のファイルに含まれている

SoSCRのローカライズソリューション

　SoSCRでは，英語版と日本語版のテキストがすでに存在していた。2つの言語を同時にサポートするためには，2つの言語用にコンパイルされたアセットを作成し，言語設定に応じて適切なファイルを読み込むようにする必要があった。たとえば，以前は「dialog.dat」というファイルが1つだったが，その後は「dialog_en.dat」と「dialog_jp.dat」という2つのファイルを作成するといった感じだ。

　この問題に対する解決策はこれだけではなかった。両言語を同じファイルにインターリーブするというオプションもあった。このオプションは，ファイルが1つだけなので，結果的にハードドライブの容量を減らすことができるが，変更するファイルとそれを読み込むコードを生成するツールが必要だ。しかし，SoSCRのようなJRPGには多くの種類の型データがあるため，この方法は理想的ではないことが分かった。最終的には，最初の解決策を採用した。

　このスプリットファイル方式がうまくいかなかったのが，ダイアログ用のカスタムスクリプトファイルだった。このファイルには，キャラクターが話すテキストのほか，パーティにキーアイテムを与えたり，新しいクエストを開始するなどのゲーム固有のコマンドが含まれていた。そのため，ゲーム中にこのファイルをリロードすることができなかったのだ。リロードすると，内部のデータ構造への参照が無効になり，ゲームがクラッシュしてしまうからだ。このカスタムスクリプトファイルを作成するツールでは，生成されるファイルに英語と日本語のどちらのテキストを使用するかを選択できる。そして，スクリプトソースファイルのテキストIDを使って，出力ファイルに挿入するテキストの行を指定する。

　ここでの解決策は，スクリプトツールがテキストファイルに対して行う言語置換を切り離すことだった。これにより，カスタムスクリプトファイルはテキストIDを含むだけで，最終的なテキストは挿入されず，代わりにゲームは言語設定に基づいて英語または日本語のダイアログテキストを検索する。

RPGで最も一般的なタイプデータの形式の1つは，アイテムだ

SoSWのローカライズソリューション

　SoSWの場合，2か国語版を作るのはもっと複雑だった。このゲームもSoSCRと同様にカスタムスクリプトファイルを持っているが，1作めのようにカスタムスクリプトファイルを生成するツールがテキストIDを使ったテキスト置換を行わないのだ。音声テキストはすべてカスタムスクリプトファイルのソースファイルに直接存在する。

　このようなファイルには，必要なテキストを選択するためのコードが含まれているため，当然ながらローカライズチームに渡すことはできない。そこで我々が直面した問題は，どうやってこれらの文字列をExcelシートに抽出し，SoSCRと同様のワークフローを実現するかだった。

　これを行うために，Pythonスクリプトを作成し，カスタムスクリプトファイルを繰り返して，すべてのテキストを収集し，同時にテキストをIDに置き換え，実行時に英語または日本語の文字列を検索できるようにした。

一般的に英語のテキストは日本語よりも大きなスペースを占めるため，いくつかのUI要素のサイズを変更する必要があった

　問題となったもう1つのテキストソースは，タイプデータのテキストだ。
これらのデータは，日本語では識別のための名称が短くなる傾向がある。日本語ではこれらの単語に必要な文字数が少ないため，関連する型データ構造のメンバーは，英語のテキストが収まるほど長くはなかったのだ。

　最初は，ゲームとタイプデータをコンパイルするツールの両方で，これらのフィールドのバイトサイズを大きくしようとした。しかし，このツールは非常に脆弱であることが分かった。そこで最終的には，英語のタイプデータのテキストをまったく新しいファイルにエクスポートし，言語が英語に設定されている場合にのみゲームから参照することで，この問題を回避した。これは理想的な解決策ではないが，ゲーム自体には欠点がないので，満足している。

　最後の課題は，一般的に英語のテキストは日本語よりも大きなスペースを占めるため，一部のUI要素のサイズを変更する必要があったことだ。テキストを縮小することもできるが，とくにリストなど同じ種類のテキストが複数表示されている場合は，見栄えが悪くなりがちだ。

　最後に，テキスト付きの画像やテキスト付きの動画もあった。ここでも複数のファイルを用意し，言語に応じて読み込ませることで解決した。