ビデオゲームの国際化は、ゲームのローカリゼーションをシームレスに行うことを可能にするプロセスです。ローカリゼーションを成功させるには、実際のローカリゼーション プロセスを開始する前に、国際化された製品が必要です。
ゲーム開発者は、ローカリゼーションが「正当な」翻訳であると仮定する典型的な間違いを犯します。彼らは、最初の計画段階でローカリゼーションの準備に失敗し、完全に母国語でゲームを開発するのを待ちます。
最初の設計段階から始まるビデオゲームの国際化のベストプラクティスに従えば、ビデオゲームのローカライズは簡単になります。
ビデオゲームの国際化とは何か、なぜベストプラクティスに従うべきか?
ビデオゲームの国際化は、ローカリゼーションのためにゲームを「準備」するプロセスです。ゲームを国際化することで、コード、アーキテクチャ、ユーザーインターフェイスを活用して、複数の言語でゲームコンテンツを処理およびレンダリングできます。
ビデオゲームの国際化の主な目的は、「ロケール」によって異なるコードベース内のコンポーネントの存在を排除することです。
プレイヤーは、ローカライズされたユーザーインターフェイスがインタラクティブで、ゲームがオリジナルと同じように魅力的であることを期待しています。同じインタラクティブで魅力的なエクスペリエンスを実現するには、ゲーム プログラマはゲームの設計と開発の初期段階でベスト プラクティスを採用する必要があります。
ビデオゲームの国際化のためのベストプラクティスは何ですか?
あなたがデザインに取り組んでいるゲーム開発者であれば、ビデオゲームの国際化のベストプラクティスについて知っておくことをお考えください。推奨されるビデオゲーム開発方法論を採用する必要があります。ビデオゲームの国際化のベストプラクティスは、次の 2 つのカテゴリに分類されます。
- ローカリゼーションに優しいアーキテクチャ:ファイル構造、アセットの整理、文字エンコーディング、メモリの問題、命名規則
- ローカリゼーションに優しいプログラミング:開発者に推奨されるプログラミング方法 (UI、地域設定、テキスト) を扱う
この資料では、推奨されるベスト プラクティスについて説明します。 ローカリゼーションに優しいアーキテクチャ.プログラミング方法論のためのビデオゲームの国際化の実践は、別のポストで彼らの完全な焦点に値する。
ローカリゼーションに優しいアーキテクチャ
ローカリゼーションに優しい構造を設計すると、ゲームを簡単に、迅速かつ正確にローカライズできます。ローカリゼーションに適したゲーム アーキテクチャを使用するには、次の方法を国際化する必要があります。
- ファイル構造
- ゲームアセット
- テキストアセット
- アートアセット
- ナレーション
- メモリ
- 命名規則
1. ファイル構造の国際化
ゲーム コードからすべてのローカライズ可能なゲームアセットを外部化し、別々の言語固有のフォルダに配置するのが一標準的な方法です。これにより、LSP (言語サービス プロバイダ) にローカライズ可能なコンテンツを簡単に渡すことができ、翻訳されたアセットをゲームに簡単に統合できます。これは、シンプルでありながら強力な重要なビデオゲームの国際化プラクティスです。
この例では、ゲーム コードとアセットを整理するためのサンプル ディレクトリ構造を示します。 ゲームのローカリゼーション.開発フレームワークは、特定のビデオゲームの国際化ディレクトリ構造を提供する場合があります。詳細については、ドキュメントを参照してください。
コード フォルダ ("ゲーム コード") には、ゲームのローカライズされたマスターを作成できる必要があるすべてのコード ファイルが含まれています。アセット フォルダ (「ゲームアセット」) には、ローカライズするすべてのテキスト、アート、オーディオ、映画、その他のアセットが含まれます。
2. ゲームアセットの国際化
テキストアセット、アートアセット、ナレーションは、国際化の要件に対応するゲームの重要なコンポーネントです。
2.1 テキスト資産の国際化
ゲーム内のテキストと UI テキストが主要なローカリゼーション ターゲットです。理想的なシナリオでは、実際のゲーム コードとは別のファイル内のすべてのローカライズ可能なテキスト (ゲーム内テキスト、UI テキスト、コンソール エラー メッセージなど) を外部化する必要があります。また、PC バージョンのすべてのインストーラ文字列を一元的な場所に整理することも忘れないでください。
外部文字列テーブルを使用してローカライズ可能なテキストを格納すると、翻訳の整理と統合が容易になります。すべての文字列に固有の文字列 ID を使用することで、開発中に文字列に対する変更を追跡する方法をさらに簡単にすることができます。
2.1.1 文字列テーブルの定義
最も簡単で一般的な方法は、すべてのテキストをプレーン テキスト ファイル (ソース言語) に格納することです。このテキスト ファイルは、ローカリゼーション用に簡単に渡すことができます。プレーンテキスト ファイルを使用している場合は、UTF-8 などのローカリゼーションに優しいエンコーディングに従います。
サンプル テキスト ファイル
文字列の格納方法にかかわらず、すべてのテキストに対して一意の文字列識別子を割り当て、この文字列 ID を使用してコード内のテキストを参照すると非常に便利です。
外部テキスト ファイルの例 (MissionDD と呼ばれるミッションのすべての元のテキストが含まれています)
en-US/テキスト/アセット/ミッションDD/文字列.txt DDSTRING_T1 ハイジスト!良いことをしていますか? DDSTRING_T2 はい、私は大丈夫です。 DDSTRING_T3 さようなら!じゃあ、また。
このファイルの日本語 (翻訳済み) バージョンの例
ja-JP/テキスト/アセット/ミッションDD/ストリングス.txt DDSTRING_T 1 の日に、ヘス・ヘス・ヘス・ヘス・ス・ヘス・ス・ヘス・ス・ヘス・ス・ DDSTRING_T2 の使用を指定します。 DDSTRING_T3の準備!
2.1.2 すでにあなたのゲームを開発しましたか?
ローカリゼーションを考えずにゲームを開発している場合は、いくつかのツールを使用してゲームファイルからすべてのテキストを抽出します。文字列テーブルに移動し、一意の「識別子」を持つすべての「テキスト」を割り当てます。識別子は、ゲーム コード内のすべてのテキストの発生を置き換えます。
2.1.3 テキストを大量に含むゲームを開発していますか?
大規模な RPG ゲームやアドベンチャー ゲームなど、膨大な量のテキストを含むゲームでは、データベースの使用を検討できます。理想的には、データベースには次の情報が含まれている必要があります。
- Id
- テキスト
- メモ (テキストのコンテキストを提供する)
- テキストの順序
- 最大文字列の長さ
- すべてのテキストのローカライズされたエントリ (使用可能な場合)
2.1.4 コードでの文字列テーブルの使用
ゲーム エンジンは文字列テーブルをメモリに読み込みます。ハッシュ テーブルは、一般的に使用されるデータ構造です。C++ でゲームを開発する場合は、STL マップ コンテナーを使用します。文字列テーブルをすべてのテキストを保持するクラスにカプセル化し、識別子を受け入れて翻訳されたテキストを返す静的メソッドを定義します。
次の例では、 GameDDStringTable は、文字列テーブルをカプセル化するクラスです。API getDDString(StringID) は、文字列のテキストを呼び出して取得することです (コードで使用する前に)。
国際化のないコード
DDCHARACTER1.トーク(こんにちはジスト!良いことをする?) DDCHARACTER2.トーク(はい、私は大丈夫です。; DDCHARACTER3.トーク(さようなら!また後でお会いしましょう。
国際化されたコード
DDCHARACTER1.トーク(GameDDStringTable::getDDString("DDSTRING_T1");
DDCHARACTER2.トーク(GameDDStringTable::getDDString("DDSTRING_T2");
DDCHARACTER3.トーク(GameDDStringTable::getDDString("DDSTRING_T3");
2.1.5 読みやすさの維持
ゲーム内のすべてのテキストを外部化する欠点の 1 つは、コードを見ている間に読みやすさが失われたことです。したがって、スクリプトの変更は少し難しくなる場合があります。
例えば DDCHARACTER1.Talk(GameDDStringTable::getDDString("DDSTRING_T1")); 文字が読み上げられた実際のテキストがないため、読み取りできません。
一部のゲーム開発チームは、コード内の元のテキストを保持 (および一意の文字列 ID を使用) することで、この問題を克服しようとします。これらは、次の例に示すように、事前に定義された明確な構文に従います。
DDCHARACTER1.トーク(GameDDStringTable::getDDString("DDSTRING_T1]こんにちはジスト、あなたはどうですか?")。
DDCHARACTER2.トーク(GameDDStringTable::getDDString("DDSTRING_T2]はい、私は大丈夫です。)。
DDCHARACTER3.トーク(GameDDStringTable::getDDString("DDSTRING_T3]さようなら！また後でお会いしましょう。)。
上記の例では、スクリプトにはテキストと識別子の両方が書式に含まれています。
“STRING ID | original text”.
静的メソッド getDDString() ID (パイプ文字の左側) を読み取り、翻訳されたテキストを返します。翻訳されたテキストが見つからない場合は、元のテキストが (パイプ文字の右側) に返されます。
この方法を使用すると、スクリプトを読みやすくします。また、文字列テーブルがない場合は、フォールバックするオプションがあるため、ゲームの実行は失敗しません。パイプ文字の右側に元のテキストが表示されます。
2.1.4 翻訳に関する注意事項
翻訳プロセスをさらに合理化する場合は、ローカライズ可能なすべての文字列に関する十分な情報を提供する必要があります。これらを外部文字列テーブルにコメント形式で指定できます。また、特定のドキュメント フォルダに含まれる個別のメモとして提供することもできます。これは、ビデオゲームの国際化のベストプラクティスを強くお勧めします。
メモは翻訳者が理解するのに役立ちます:
- テキストの順序
- ゲーム内のテキストのコンテキスト
- エンジンが引き続きサポートする文字列の最大長 (変換後)
- ゲームに固有のその他の文字列ルール
ビデオゲームの国際化 –テキストアセットの開発者チェックリスト
2.2 アートアセットの国際化
アートアセットのローカライズに費やす時間を短縮し、アートに表示されるテキストの量を最小限に抑えます。アーティアートでテキストを使用している場合は、次のベスト プラクティスに従ってください。
2.2.1 テキスト用の個別レイヤー
イメージ ファイルで、テキストを別のレイヤーに定義します。このような階層化されたアート ファイルは、翻訳をすばやく統合できるため、簡単にローカライズできます。
2.2.2 テキストをプログラムでレンダリングする (ランタイム)
もう 1 つの方法は、フォント (プログラム) を使用してイメージ内のテキストをレンダリングすることです。アートアセットに表示されるすべてのテキストを、簡単にローカライズできる別のテキスト ファイルに外部化します。ゲーム エンジンは、適切なテキストをプルし、実行時に必要に応じて画像に表示できます。
2.2.3 アセットフォルダの整理
前のセクションで説明したように、すべてのローカライズ可能なアートアセットを適切なフォルダに配置する必要があります。
2.2.4 翻訳に関する注意事項
テキストアセットと同様に、翻訳用のメモを含めるのが便利です。
ビデオゲームの国際化 –アートアセットの開発者チェックリスト
2.3 ナレーションの国際化
ゲームオーディオは、3つのトラック、すなわちボイスオーバー(VO)、効果音、音楽に分けることができます。これは簡単にローカリゼーションを可能にするので、他の2つのトラックとは別にすべてのVOトラックを保存することをお楽めします。あなたが論理的にすべてのVOファイルを整理する場合は、あなたのゲームにローカライズされたVOを統合することは非常に簡単であることがわかります。
1 つの方法は、文字列識別子 (文字列テーブル内のテキストに割り当てられている) を使用して VO サウンド ファイルに名前を付ける方法です。上記の例では、ナレーション ファイルの名前は string_t1.mp3、string_t2.mp3、string_t3.mp3 です。 この方法の利点は、文字列 (画面に表示) のナレーションがフェッチされ、再生されるようなコード化ができることです。
あなたのスクリプトは、VO制作の基盤です。したがって、ゲーム開発の非常に早い段階でスクリプトを完成させ、コンテキストの正確な定義と共に、できるだけ多くの技術的な側面(長さ、モノラル/ステレオなど)を含める必要があります。
ローカリゼーション ベンダーは、スクリプトを読むことでストーリーの流れを理解できる必要があります。ナレーションのためのビデオゲームの国際化は、あなたのローカライズされたゲームで元の味を保持するのに役立ちます。
サブティテリングシステム
可能であれば、ゲームに適したサブティテリング システムを実装します。再生中のVOファイルの内容と共に字幕が画面に表示されるように設計したり、VO録画を字幕に置き換えることができます。ローカライズ可能なテキストアセットにすべての字幕付きテキストを含める必要があります (翻訳のためにそれらを追跡してください)。
ビデオゲームの国際化 –ナレーションのための開発者チェックリスト
3. メモリの国際化
文字列テーブル ファイルの読み込み中に、ほとんどのゲームで平均的に 1 つまたは 2 つの MB を超えてはならないため、すべてのテキストをメモリに保持できます。ターゲット プラットフォームのメモリが限られている場合は、メモリの問題が発生する可能性が高くなります。この場合、ゲームの各レベルなどに必要に応じて、特定のテキストセットをロードおよびアンロードできます。
英語でゲームを開発していて、ローカリゼーションの対象言語が日本語や他のアジア言語である場合、フォントをメモリに収めるのが難しい場合があります。この問題に対処するには、ゲームの特定の部分に表示されるグリフを必要に応じてメモリに読み込みます。
アジア言語 (2 バイト文字セットを使用) でゲームを開発する場合は、英語やその他のヨーロッパ言語の場合、文字列がより多くのメモリを占める可能性があります。
たとえば、英語は日本語よりも約 1.5 文字、ドイツ語では日本語の 2 倍の文字を使用します。これらの問題を克服し、メモリオーバーフローを回避するには、ヨーロッパ文字を 1 バイトとして格納するエンコーディング (UTF-8 など) に固執することをおそれが最善です。
このようなビデオゲームの国際化のベストプラクティスは、あなたのゲームがすべての言語でうまく動作することを保証します。
4. 命名規則
すべてのローカリゼーション固有のフォルダとファイルに、そのフォルダが表す言語/地域を簡単に解釈できるように名前を付ける必要があります。言語には、地域に基づくバリアントもあります。したがって、言語の 2 文字のコードと国の 2 文字のコードを組み合わせることをお考えです。例の名前は、en-US (アメリカ英語)、ja-JP (日本語)、zh-CN (簡体字中国語)、zh-TW (繁体字中国語)などです。
これは、世界中で広く認識されているISO規格に準拠した良い習慣です。
ファイルの内容を論理的に知れば、ミッションや文字などを説明する名前を付けると、わかりやすいでしょう。例: UI.txt、ミッション1.txt、ミッション2.txtなど
上記のビデオゲームの国際化のベストプラクティスは、簡単にローカライズされるゲームの設計を支援することを目的としています。ローカリゼーションの目標を達成するためには、ゲーム プログラミングの国際化のベスト プラクティスも同様に必要です。
アーキテクチャの非常に初期の段階でローカリゼーションの基礎を築くと、ローカリゼーションが難しくならないことがわかります。ゲームはローカライズされたすべてのバージョンに均等に関与し、プレイヤーは言語用に最初に開発されたものではないことを伝えることができません。
ビデオゲームの国際化やローカリゼーションを地面から取り除く手助けが必要ですか?無料の見積もりのために今日お問い合わせしませんか?
