
ゲーム(ここでは M&B Warband)をインストールしたディレクトリ(mb_warband.exe がある場所)の Modules フォルダ下には各 MOD 毎に独立したフォルダがあり、その中に MOD に固有のファイルを置きます。Warband に最初から付いてくる Native(ネイティブ)という MOD のファイルも他と独立しています。ゲームのインストール・ディレクトリには CommonRes (リソース・フォルダ)、languages、Sounds、Textures といったフォルダがあり、全 MOD から共通的に参照できます。ただし、それらは(一部の共通的なユーザ・インタフェースなどを除くと)ほとんどを Native のみが使います。一方、各 MOD のフォルダにも似たようなフォルダがあります。Warband では、MOD を完全に独立させる(互いに干渉しないようにする)ために、このようにフォルダの構造を利用してモジュール化する方式となっています。
このモジュール化は、プログラム・コードやバイナリ・リソースだけでなく、ローカライズ(つまり各国語への翻訳版の作成作業)にも当てはまります。ゲーム内の登場人物が話す「会話文」、物品や人物や街の名、プレイヤー向けの一覧表など、あらゆる文言が最初は英語で書かれています。これを他の言語に翻訳する際に、英語のファイルを変更せずに、languages 下の各言語のフォルダに csv ファイルを追加するだけで、オーバライド(機能だけ上書き)できます。
(訳注: Warband では例えば、インストール・ディレクトリ下の languages\en\ にある ui.csv というファイルは、ユーザ・インタフェースを英語で記述していて、これを日本語に翻訳したい場合でも、それ自体を書き換えたりしません。インストール・ディレクトリ下の languages\ja\ に ui.csv を置いて それを訳せば、全 MOD に共通して反映されるし、各 MOD に固有の訳(金銭の単位など)にしたければ 各 MOD のフォルダ下の languages\ja に ui.csv を置いて訳すようにします。後者が前者の全ての ID (「|」の左側の識別子)を含む必要はありません。両方の ui.csv に同じ ID の行があれば、ゲーム・エンジンは MOD 側を優先して使います。その他のファイルも同様ですが、conversation.txt などのようにファイル名の対応が変則的なものもあり、それについては後述されます。)
MOD は適切なディレクトリに置く必要があります。もう少し詳しく見ていきましょう。
Mod のフォルダとファイル
MOD とは正確には何でしょうか? MOD の実体は、多くのフォルダとファイルの集まりです。新しく独自 MOD を作る作業は、それらファイルを作っていく作業です。だから、各フォルダにどのような種類のファイルを置くのか、開発環境や外部ツールをどう使うかを理解しておくことが大事です。以下で説明します。
今、mymod1 という名の独自 MOD を作るとしましょう(名称は いつでも変更可)。開発するファイルとフォルダは全て下記フォルダに置きます。(標準的なパスと名前でインストールした場合の例)
C:\Program Files\Mount and Blade - Warband\Modules\mymod1\
(訳注: ここから下では 各 MOD の実行フォルダ下のフォルダの説明と、ゲーム・エンジン mb_warband.exe と同階層のフォルダの説明が混在しています。)
languages
(訳注: 翻訳用フォルダです。Warband を日本語化してプレイしたことのあるかたは よくご存じですね。Warband 本体、各 MOD(既成や 今作ろうとしているもの)それぞれに languages フォルダがあり、そこへ ja など言語毎のフォルダを作って *.csv を置けば *.txt より優先されるので、.txt を変更せずに その MOD の翻訳版を作れます。)
csv ファイルの編集にはテキスト・エディタを使います
(訳注: テキスト・エディタは任意ですが、日本語などの翻訳版を作るには、UTF8 でエンコードできる必要があります。もし cp932 などのエンコードで日本語ファイルを作ってしまった場合は、それを全文コピーし、別の utf-8 のファイルに貼り付けるとよいです。あるいは例えば vim エディタなら、別ファイル無しでも完結します。vim で日本語を書いた後に :set all で確認して fileencoding=cp932 だった場合、次のようにします。:w で保存後、ビジュアル選択で全文をクリップボードに写し、:e! ++enc=utf-8 とします。???? などが表示されます。今度はビジュアル選択しないように気を付けて、ファイル先頭で 10000d コマンドを必要数繰り返すなどして 全行を消し、i で挿入モードにして、クリップボードから貼り付けます。読み取り専用になっているので、:w! で保存。:set all で確認します。途中の失敗が不安な場合は事前にバックアップを。)。
ゲーム起動直後の小メニューで英語以外の「言語」を指定すると、MOD 毎のその言語のフォルダ(Modules\mymod1\languages\ja など)内の csv ファイルの各「行」が最優先で使われ、英語原文に対応する行が そこに無い部分(行)については共通言語フォルダの その言語フォルダ(exe があるディレクトリの languages/ja など)内の csv ファイルの「行」が使われます。そこにも対応しなければ .txt などにある英語原文がそのまま表示されます。つまりこの原理により、訳文を作った行だけが(都合よく)翻訳されて表示され、訳が未了の行は英語のまま表示されます。
各 .csv ファイルには、ヒントや会話文などゲーム内にある様々なテキストが含まれていて、訳してよいのは各行の「|」の後ろ(右側)のテキストだけです。手前(左側)は ID なので変更不可です。
(訳注: 原文では ここに「第 2 ロード中 画面」に表示される「ヒント」の数が module.ini で可変うんぬんという記述がありますが、module.ini はローカライズできないはず(もし言語毎に諸数値を変更できたら、難易度が変わって大混乱?)。言語毎にヒント数を変えられるかのような誤解を招くので、割愛しました。)
訳注
翻訳したい対象の MOD 名が modA だとして、modA\languages フォルダ下に置く *.csv ファイルのうち、Warband の languages\en フォルダ下と同名のものは、hints.csv、ui.csv、uimain.csv の計 3 つだけです。それらは、各ファイル内の各行の「|」の手前に書かれた id で対応づけられます。それ以外のほとんどの csv ファイルは modA フォルダにある *.txt ファイルに対応しますが、例えば dialogs.csv が conversation.txt に対応したり、内容の書式が異なるなど、変則的です。
そこで MOD の翻訳版を作るかたは、Warband に備わっている、英語版の *.csv 一式を自動生成する機能を利用するとよいです。MOD システムのソース・コードや Python は不要で、Warband 起動時に [Configure]-[映像] でウィンドウ・モードに設定し、翻訳対象の MOD を「英語」で開始します。ワールド・マップに出るところまでゲームを進めて、メニューから [View]-[Create Language Template]-[Default] を選ぶと、(その MOD ではなく)Warband のフォルダに出力先フォルダと その MOD の英語版 *.csv ファイルが生成されます。ただし、どの MOD で それを実行した場合でも そのフォルダの位置と名前は固定で、毎回断わりなく上書きされるので、事前に改名や移動をしておくなど要注意です。
自分の MOD の会話文を(最初は英語で)書く時には、各国語の翻訳者の都合を可能な限り考慮しましょう。状況によっては、一部の言語に翻訳できない事態が生じ得ます。例えば、あなたが会話文(英語原文)に「He is{s1} a sailor」という文を書いておき、「n't」という語をクイック文字列として登録し、実行中に条件によって文字レジスタ s1 にそれを入れたり空を入れたりしたとします。英語では これでよいですが、日本語に訳す人は困りますよね? なぜなら(表示文中に条件判定させるための)3 項演算子が、数値レジスタにはあるけれど、文字列レジスタには無く、「n't」を「ではない」などに訳すしかないからです。「彼は船員{s1}。」が否定文の時はよいですが、肯定文の場合に s1 が空なので訳を付けられません。たとえ空の代わりに「空白 1 文字」のクイック文字列にしたとしても、それが他所で共通的に使われそうなので、「です」とか「だ」には訳しにくいです。結果的に「彼は船員。」のような言葉足らずの文になるのを我慢するか、(文意を損なわない程度に)クイック文字列「n't」を「ただし、~だ」などに訳し、2 文に分けて {s1} を文末に置く、といったことをするしかない事態になってしまいます(後者の場合でも、「n't」が複数個所で汎用的に使われていたら破綻します)。この「n't」 は ほんの一例です。このような問題は、日本語以外の言語でも きっと起きるでしょう。だから、想像力(他人への迷惑に気付く能力?)を働かせ、気が付く限り考慮した英語原文を作っておかないと、どこかの翻訳者から(その国の訛りのある英語で)「あんたの MOD は最高に面白いんだけど、ここんとこ英語原文を変えてほしい」という連絡を受けることになりそう。既存 MOD の翻訳作業は、そういう「作り手側の留意すべき点」に気付く よい機会でもあります。
(翻訳作業と直接は関係ない話です)単にゲームをプレイする際、言語切り替えとゲームのセーブを交互にしていると、セーブ・データに英語と日本語が混じってしまい、問題を起こします。例えば「マップ上で近隣にいる候伯」とか「出会った候伯」とか「クエスト」などは明らかにセーブ対象ですが、それらの ID ではなく文字列そのものがセーブ・データに保存されます(中を覗いてみると わかります)。日本語で保存してから英語でロードすると、見た目は文字化けというより大抵は空っぽになり、例えばマップでどこかの候伯の隊にマウスをかざしても、名前が見えなくなったりします。それを英語モードのままセーブしてしまうと、たぶん修復不能になります。だから、(翻訳作業かどうかにかかわらず)頻繁に言語を切り替える場合は、日本語のセーブと英語のセーブを分離すべきです。例えば 9 個あるセーブ枠に混在させるのは可としても、枠に「ja」とか「en」という文字を含めるとか、セーブ・データ(sg00.sav ~ sg08.sav と last_savegame_backup.sav)をバックアップする際に圧縮ファイル名に「混在」とか「ja のみ」などがわかる文字を含めるなど。
「でも、既存 MOD の翻訳作業中に英語に切り替える必要なんか ある?」というかた、それは翻訳中に見つかった「疑問」や「原文バグ」や「動作バグ」を、MOD 作者に英語で伝える時に、英語モードのスクリーン・ショットや会話文の書き起こし(または当該 dlga_ 行)などを添えたほうが親切だからですよ。
「セーブ・データのバックアップなんか、残さないよ。」というかた、翻訳する人は、翻訳した文を実際に全てプレイして確認(踏査)しようとするからですよ。文章の見た目の印象とか、改行位置とか、選択肢ボタンに大きな字で 1 行に収まってるか、など。でも、特定の人物との会話とか、クエストとか、あるいはゲームに一度しか現れないメッセージとか、そういう個々の状況を作るだけのために何時間もプレイしたり新規に戻ったりを繰り返すヒマはないですよね、翻訳作業中は特に。だから関連する場面を どんどん こまめにセーブし、圧縮したファイル名に長い説明を書いておいて、いつでも再プレイできるようにしておくんです。例えば、「新規からコンパニオン誰それゲットまで」とか、「新規から3。xxクエスト前後。どこそこの根城に攻撃直前」など。
Music
OGG、WAV、MP3 ファイルの編集には Audacity という外部ツールを使うとよいです。モジュール化するには、モジュール・システム内の module_music.py 内の該当する全てのトラックに対して音楽トラック・フラグ mtf_module_track を使います。このフォルダには、比較的 再生時間の長い、BGM(背景音楽)を置きます。
CommonRes/Resource
(訳注: CommonRes は mb_warband.exe と同階層のフォルダで、全 MOD 共通リソースの置き場。Resource は各 MOD 下のフォルダ。)
OpenBRF(または OpenBRF Redux)という専用の外部ツールを使って .brf 形式の複数ファイルにまとめ、それらを置きます。Wings 3D、Blender など お好みの外部ツールと組み合わせます。作成した独自 brf ファイルの使用をゲーム・エンジンに伝えてモジュール化するには、module.ini 内で load_mod_resource または load_module_resource を brf ファイルの数だけ(複数)指定します(既存の load_resource は共通リソースの指定です)。このフォルダには、スケルトン、アニメーション、メッシュなどのグラフィクスが含まれています。 スケルトンは、リグ付きメッシュのアニメーションを提供します。メッシュは、ゲーム内のオブジェクトに 3 次元の形状を与えます。これらは、マテリアルが UV マッピングされるか、またはラップされる対象です。マテリアル、テクスチャ、シェーダのデータも含まれています。 スケルトン、アニメーション、メッシュなどを再加工するなら、単にそれらをエクスポートして、外部ツールにインポートして行ないます。
(訳注: リグは 3D オブジェクトに付加する関節や骨格などの機能。マテリアルは色、凹凸、透明度など、材質を指定するもの。UV マッピングは基のマテリアルの上に切手のように画像を貼り付けること。ラップは その貼り付けが一部でなくオブジェクト全体を包む状態。外部ツールとして上記本文では Wings 3D、Blender が例に挙がっていますが、Wings 3D でできるのはモデリングと、マテリアルやテクスチャの操作ぐらいで、スケルトン、リグ、アニメーションを扱うことはできないようです。また、OpenBRF や OpenBRF Redux にインポートできるスケルトン、リグ、アニメーションの形式はかなり限定的です。)
SceneObj
このフォルダに置く .sco ファイルは、宿屋(居酒屋)や闘技場や城を構成する壁や小道具、シーン内の地形、入場点といった、シーン内の物の位置関係を決める情報を含んでいます。このシーン関連フォルダは共通フォルダには無く、各 MOD の環境内にモジュール化されています。シーンを編集するにはゲーム動作中にイン・ゲーム・エディタを使います。詳しくは この web 文書のイン・ゲーム・エディタのページに説明があります。
(訳注: .sco のファイル名とソース・コードの関連付けは、 module_scenes.py のレコードにシーン ID としてファイル名の一部を指定することで行ないます。たとえ独自 MOD 全体の「コード」が未完成あるいは ほとんど手つかずであっても、複数「シーン」を先行開発したり、分業したりできます。最初は Native などから SceneObj フォルダをワーク用の MOD へ写しておき、編集してできた .sco のファイル名を他の既存 .sco と入れ替えれば、主人公を当該地点(街や城)まで あちこち移動させる必要もなく、一ヶ所の街か城へ出入りしながら、他の街の宿屋や闘技場のシーンを編集できそうです。)
Sounds
OGG、WAV、MP3 といった形式の音声ファイルを扱うには Audacity という外部ツールを使うとよいです。これらファイルをモジュール化する(他 MOD に影響しないようにする)には、module.ini 内で scan_module_sounds = 1 にするだけです。このフォルダには(Music フォルダと違い)、効果音のような比較的短い音声を置きます。
Textures
DDS、TGA、JPEG 形式のファイルの編集には GIMP や Paint.NET といった外部ツールを使えます。モジュール化するには、module.ini 内で scan_module_textures = 1 にするだけです。このフォルダには、拡散テクスチャ、バンプ・マップ、環境マップ、スペキュラ・マップなどのマテリアル用の 様々な種類のファイルに使用される画像ファイルを置きます。拡散テクスチャはマテリアルの色付けに使用されます。バンプ・マップは青または緑に見え、明るい領域が隆起し、暗い領域が凹むことでマテリアルに奥行きを与えます。環境マップはマテリアル上に現れる反射です。スペキュラ・マップはバンプ・マップと同様の手法ですが、白黒で、マテリアルの反射率を決定します。
main.bmp
起動直後の小メニューで MOD を選択時に表示される画像です。編集には GIMP や Paint.NET といった外部ツールを使えます。単に MOD のフォルダに置けばモジュール化されるし、置かなければ共通の main.bmp が使われます。GIMP で書き出す(エクスポートする)場合、忘れずに [互換性のオプション] の左にある [+] を展開し、[色空間の情報を書き込まない] にチェックを入れて下さい。
(訳注: 左図は訳者が追加。MOD のフォルダに置いた main.bmp が、図で白地に見えている領域に表示される。この「mod1」という文字も、訳者がテスト用に当該画像に含めたもの。)
module.ini
このファイルの編集にはメモ帳などを使用します。このファイルは常にモジュール化されていて(MOD 毎に存在する必要があり)、例えば表示するヒント数 num_hints や、どの BRF をロードするかなど、ゲームに指示するための様々な設定が含まれています。
map.txt
常にローカルでモジュール化された TXT ファイルです。これを簡単に編集するためのツールのうち現在も更新が続いているものは、現時点ではありません。Thorgrim 氏のマップ・エディタは古いかもしれませんが、まだ動作します。Bloodpass Warband Map Editor もあります。
訳注
上記の 2 つのマップ・エディタより若干 新しいSwyter 氏の Cartographer もあります。用途ごとの これらマップ・エディタの使い分けについて別ページの「この投稿」にも情報があります。
Swyter 氏のエディタについて。私的に作ったツールを公開しただけ、との作者の言葉通り、メニューもボタンも無く、機能は必要最小限です。入力となる module_parties.py や map.txt など(サンプル一式が付属)を所定のフォルダに置き、編集後の出力も そこへ上書きされます。入力ファイルから得た街や村の座標を基に、立体地図上にその建物(マップ・アイコンを代替する簡易アイコン)が表示され、建物の移動や回転ができます。高さ方向は地面に付くように自動計算されます。地形メッシュについては、任意ディレクトリから任意の .obj をインポート/エクスポートすることもできます(ただし、インポートして そのままエクスポートしても、小数点の丸めかたが変更されます)。操作キーの説明は Readme.txt にあります。
*.txt
その他の諸々の TXT ファイルについては、モジュール・システムで(module_*.py などが疑似コンパイルされた結果)生成されます。常にローカルでモジュール化されています(他の MOD に影響しません)。これらのファイルには、MOD が使う あらゆるタイプの処理(命令のオペコード)やデータが含まれています。