Civilization IV: モジュラー XML 読み込み（翻訳）

これは Kael's Guide to XML Changes in Beyond the Sword の一部 (Appendix A - Modular XML Loading, §14.0〜§14.7) を翻訳したものです。

イントロダクション

モジュラー XML 読み込み (Modular XML Loading, MXMLL) は BtS の新機能で、MOD 制作者が自分の改造を共有および結合しやすくするために設計されています。無印の Civ4 や Warlords の XML ファイルに慣れている方は、ゲームが数十の異なる XML ファイルを読み込むことをご存知でしょう。建物用のファイル、ユニット用のファイルなどがあります。以前は各タイプのファイルをちょうど一つだけ読み込むことができ、そのファイルは特定のファイルパスに厳密な名前で配置する必要がありました。 MXMLL はこれらの制限を回避するための任意の方法です。

モジュール化

これまでのほとんどの MOD は「モノリシック」形式、つまり各タイプのファイルが 1 つずつある形式でした。新しいモジュールは主に次の 3 つの戦略のうちいずれかで作成されます。

1. Warlords MOD の既存コンテンツを BtS 互換モジュールに抽出し、MOD を完全に「ライブラリ」モジュールに分解する
2. 構造化とサイズ削減を目的に大規模な MOD 全体をモジュール形式へ変換
3. 新しいコンテンツをゼロから作成

使用する戦略は、あなたの改造の性質によって異なります。

より大きな MOD で使用されることを意図した「コンポーネント」やコンテンツの制作者は、ライブラリアプローチを取りたいでしょう。例えば、新しいユニットアートスタイル機能の拡張は、スタイルタイプのライブラリとしてパッケージ化できます。各モジュールには 1 つのスタイルのすべてのアートとアート自体のリストが含まれます。ユーザーはそのモジュールを単純に追加するだけで動作させることができます。

新規の技術定義が必要な新しいユニットや、建設に新規資源が必要なユニットなど、互いに参照を持つ複雑で相互依存的な MOD の場合、単独で機能するモジュールを作るのは難しくなります。このような場合、モジュール化は大きなファイルをカテゴリごとに分割して構造化する手段として役立ちます。チームプロジェクトにおいては、チームメンバーが別々のファイルで作業でき、それらを 1 つのファイルへ再結合する必要がなくなるため、分散型の作業方法の恩恵を受けられます（特に大規模なプロジェクトではバージョン管理ソフトウェアが強く推奨されます¹）。

最後の利点として、MOD のファンは自分の所望する変更/修正を実装するモジュールをより簡単に提出でき、開発者はそれらをより迅速にテストおよび統合できます。

仕組み

MXMLL はゲームの XML 読み込み部分で完結動作します。読み込み過程で、ゲームは各ファイルタイプのデータを一つずつ読み取り、各ゲーム要素の数を決定し適切にインデックスを付けます。各ファイルについて、ゲームの「ベース」コンテンツは Warlords から馴染みあるデフォルトのファイルパスから通常通り読み込まれます。その後、MOD の設定パラメータ ModularLoading がチェックされ、1（真）の場合、プレイ中の MOD とカスタムアセット内の新しい Modules フォルダ内部が検索されます。正規表現を使用して各 XML ファイルのタイプが決定され、適切なタイプのファイルのみが読み込まれます。モジュール内の要素はベースコンテンツの後に読み込まれ、一致する Type タグ名を持つベースデータを上書き（置換）できます。モジュールは互いに上書きし合い、最後に読み込まれたものがゲーム内で表示されます。

モジュールの読み込み順序は、モジュールがカスタムアセットにあるか MOD 自体にあるかによって影響を受けません。どちらも他方を上書きする可能性があるため、単に競合するモジュールを持たないようにしましょう。

非対応部分

残念ながら、MXMLL で機能しないファイルのクラスが 1 つあります。サウンドとオーディオデータを扱うファイルです。これらには互換性がありません。また、MissionInfos.xml や CommerceTypes.xml などのいくつかのファイルタイプは SDK の Enum とリンクしているため、SDK に対応する修正がされなければこれらのファイルの拡張は効果がありません。これらのファイルでは MXMLL モジュールを作成しないことをお勧めします。

命名規則

モジュラー XML ファイルを読み込ませるために使用しなければならないファイル命名方式は厳格ですが、シンプルで普遍的です。* は複数文字のワイルドカードなので、Ninja_CIV4UnitInfos.xml のように前に説明的な名前を付けることができます。また、XML ディレクトリの下に任意の数の中間ディレクトリを配置できるため、データは好きなだけネストできます (例: XML/modules/Custom Units/Ninja/Ninja_CIV4UnitInfos.xml)²。これはゲーム本来の読み込み方法とは対照的で、あちらは今でも非常に厳格な構造を持っています。ファイル名が正規表現と合致しないことは、コンテンツが（読み込み警告なしで）ゲームに表示されない最も可能性の高い原因です。

対応ファイルタイプ

以下のタイプがサポートされています。すべての場合において、ゲームは Modules/*_TYPE.xml に一致するファイルを検索します。TYPE は以下の文字列のいずれかです。

スキーマ

このディレクトリ構造についての柔軟性の主たる短所は、すべての XML ファイルが読み込み前に検証される必要があり、ゲームはスキーマファイルが対象 XML ファイルと同じディレクトリにあることを要求する点です。そうでない場合には読み込みが失敗し、"OK" を押すことで他の読み込みを続行できる警告ダイアログが表示されますが、モジュールに関連する他のファイルが参照切れのままになるため、その後 "ITEM NOT FOUND" 警告が発生する可能性があります。場合によっては、元のスキーマファイルを変更せずにコピーして実行することも可能ですが、変更されたスキーマを使用し始めると、最終的には修正が難しい相互検証エラーにつながります。

したがって、すべてのモジュールスキーマファイル名の前に単純に MODULE_NAME_ を付けて、そのモジュールに合わせてリネームすることをお勧めします。これにより、そのスキーマはローカルでのみ使用され、他のモジュールを壊すことはありません。そのスキーマを使用するファイルのヘッダーを更新して、リネームした方を適切に参照するようにすることを忘れないでください。

これは特に、改変された DLL で読み込まれる新しい XML タグを使用するモジュールに当てはまります。ローカルスキーマにより、未改変の DLL の下でもモジュールを読み込むことができ、変更されたスキーマが他の XML ファイルを無効にすることを防ぎます。最も良いこととして、タグが削除されていなければ、未改変の DLL との後方互換性が維持されます。