概要は以上? とにかく MOD 開発(modding)を始めてみたいんだけど。
そうですね、では modding を やってみましょう。モジュール・システムをセットアップしたい、ってことですよね?
訳注:
上記スレッドの冒頭に書かれた当該リンクは http で始まるので、そのままだと最近のブラウザではブロックされて見ることができません。リンク先アドレスを取得して https に置き換える必要があります。あるいは TaleWorlds Entertainment 社の公式ページ https://www.taleworlds.com/en/Games/Warband/ へ行き、「+ DOWNLOADS」を展開すると、少し下にある「Module system:」の右にリンクがあります。現時点で Warband 用の最新 module system v.1.171 を(もっと古いバージョンも)ダウンロードできます。
モジュール・システム(module system または modding system)は、独自 MOD 開発用の環境一式のことです。広義では「3D オブジェクトやアニメーションや効果音といったリソース」を含むことがありますが、正確には「ソース・コードと処理スクリプト(疑似コンパイラ)」だけを指します。上の ModSys は投稿者 Lumos 氏による用語です。また「modder」は MOD 開発者のことです。
パス表記中の区切りがバックスラッシュに見えるしれません。Unicode で円記号「¥」に見せることもできたのですが、コピペの便を優先しました。読み替えて下さい。
もう一つ、Python(言語)処理系が必要です。そいつで MOD システムのソース・ファイル群を(疑似)コンパイルして、ゲーム本体が理解できるような数字、数字、数字だらけのテキスト ファイルにし、あなたの素晴らしい MOD を具現化します。本物の python(ニシキヘビ)を横に置きたければ それも構いませんが、たぶん無駄でしょう。さて、慌てて最新の Python をダウンロードしてはいけません。大前提として、ModSys は 2.x より新しい Python では(少し変更しない限り そのままでは)動作しません [1]。 Python の公式サイトへのリンクも上記スレッド中に書かれているので、Google 検索して探す必要はありません。そこから 2.x.x の最新バージョンを取得します。 (訳注: その Python 公式ダウンロード・サイトへ行き、"Looking for a specific release?" のリストをスクロールすると、"Python 2.7.14 Sept. 16, 2017" が見つかります。ただし脚注 [1] も読んで下さい。)
Python を入手したら、インストールしましょう。管理者権限で作業して下さい。 あ、C:\Python27 ディレクトリにインストールすることをお勧めします(「Python 2.7 なんか若い時から とっくに使ってたから、もう そこにあるよ。」という そこの あなた。おぉ、先見の明あり!)。
次に環境変数 PATHを設定します。「python」という単語をコマンド化するためです。.bat ファイル内やコマンド・プロンプトで長いフルパスを指定しなくても「python」と書くだけで OS が所在を見つけられるようにします。
(訳注: Python を既に別の用途に使っているとか、python コマンドを直に使う機会がなさそう、といった理由で環境変数 PATH を変えたくない場合は、以下の設定をせず、代わりに後述の build_module.bat 中にある 30 個ほどの python コマンドを全て「c:\Python27\python」のようなフルパスに書き換えればよいです。あるいは、その .bat を Cygwin などのシェル・クリプトに移植し、一時的に PATH を指定する方法もあります。)
Windows XP では マイコンピュータ(右クリック)→ プロパティ → 詳細設定 → 環境変数
Windows 7 では スタート → コントロールパネル → システムとセキュリティ → システム → システムの詳細設定 → 環境変数
Windows 8、10、11 では スタート(右クリック) → システム → システムの詳細設定 → 環境変数
下半分にある「システム環境変数」というリストをスクロールして「Path」の行を見つけ、それを選んだ状態で下の「編集」ボタンを押します。 この Path 変数は基本的に単なる文字列で、OS にとって重要な特定のものへの経路を指示します。これはコンピュータごとに異なります。
MOD システムにハックや修正を加えずに(疑似)コンパイラが動作するためには、Path 変数の中に Python フォルダの記述が必要です。例えば Python を C:\Python27 にインストールした場合なら、Path 変数の「末尾」に下記のようなセミコロンと Python のパスを加えます。
;C:\Python27
(訳注: これは Windows 10 より前の方法です。Windows 10 以降では、Path 変数の編集を開始すると項目ごとに行に分けて表示されます。その状態で新規ボタンを押し、現れた新規行に「セミコロンの無い」 Python のパスだけを入力します。)
パスの他の部分を変更したりしないで下さい。重要なシステム要素が含まれているので、絶対にお勧めしません。行を見渡して、「;C:\Python27」が無ければ文末に追加です。過去に自力で加えていないのなら、普通は元々無いはずです。 (訳注: 編集ボタンを押した時点で、行全体が選択された状態になるようなので、そのまま何か入力すると既存の記述が消えてしまいます。初めに End キーか右矢印キーでカーソルを行末へ移動するとよいです。)
いずれにせよ、C:\Python27 の手前のセミコロン「;」に注意して下さい。この Path 変数内では個々のパスを、セミコロンで区切ります。Python のセットアップは以上です。
で、それのどこが modding なんだ?
Modding は ここからですよ。おわかりですよね? 頭の中、まだ爆発してませんね? なら よかった、続けましょう! ここまでで MOD システムが Python 言語エンジンを使う準備ができたので、今度は以下のようにして MOD システムの出力対象外の基礎部分、つまりマップ地形、シーン、テクスチャなどの部分を用意しましょう。
開発には、モジュール開発システムのディレクトリと Mount&Blade Warband のディレクトリ、両方の読み書き権限が必要です。
(訳注: 下図は訳者が追加。mymod1 という MOD を作る場合の例です。)

上図に順番を示した通り、まず下図のように Mount&Blade Warband のインストール・ディレクトリの Modules フォルダを開き、最初に一度だけ、Native フォルダを同じ Modules 下で複製します。(その方法は、Native を選んで Ctrl c と Ctrl v でコピペしてもいいし、Ctrl キーを押しながら Native から余白へドラッグでもよいです。)

このフォルダを、あなたの新しい MOD の名に改名します(例えば mymod1)。後で変更できるので、深刻に考えず、仮決めでも大丈夫です。結果的に、Native や他の既製 MOD の きょうだいフォルダを作ります。
ここが、コンパイルしてできた .txt ファイル群を置き、ゲーム・エンジンに入力させて実行させるためのフォルダです。ゲーム・エンジンは これだけで あなたの MOD の存在を認識します
一方、MOD システムには別途、コンパイルした .txt の出力先フォルダを指示する必要があります。それには MOD システムの(build_module.bat がある)フォルダに含まれる module_info.pyという短いソース・ファイル内で、特定の変数(定数)に出力先パス(相対または絶対)を書きます。重要! 見つけてもファイルを無暗にダブルクリックしないで下さい。拡張子が python に関連付けられている場合、ダブルクリックすると Python に渡されて実行されてしまいます。お好みのテキスト・エディタに渡して開いて下さい。(訳注: 必要なら 拡張子 .py のファイルを予め自分のテキスト・エディタに関連付けておくとよいです。拡張子 .py が付くファイルの一つを右クリック→プログラムから開く→既定のプログラムの選択。)。
module_info.py の内容は、初期状態では次のようなものです。「#」から行末まではコメントで、実行に影響しません。
# Point export_dir to the folder you will be keeping your module
# Make sure you use forward slashes (/) and NOT backward slashes (\)
export_dir = "../WOTS/Modules/Native/"
#export_dir = "C:/Program Files (x86)/Mount&Blade Warband/Modules/Native/"
(訳注: 原文では、コメント化された最終行が Warband でない M&B (つまりバニラ)用の記述なので、Warband 用のモジュール・システム 1.171 のものに変えてあります。また、2 行目のコメント行の最後の「(\)」は、ブラウザではバックスラッシュに見えるかもしれませんが、日本語環境のエディタで当該ファイルを開くと「(¥)」に見えるはずです。このコメントの英語を訳すなら「バックスラッシュじゃなくスラッシュを使え」、日本語環境なら「¥ でなく / で区切れ」という意味です。)
このように、初期状態では「c:」などのドライブ名や「/」で始まっていない、相対パスで指定されています。具体的には、「..」つまりコンパイルする環境のひとつ上のフォルダを調べ、その中に WOTS フォルダがあり、以下 Modules と Native があることを想定し、そこへ .txt ファイル群を出力するよう(MOD システムに)指示しています。
(ちなみに この「WOTS」というのは、この M&B が (一時的に)「Way of the Sword」と呼ばれていた 2005 年か そこら以前の名残です。もし そんな初期のバージョンをプレイしたことがあるなら、古いものが まだ あなたの環境に転がっているかも。)
では、唯一コメント化されていない行の「=」の右辺を変更し、(疑似)コンパイラが あなたの MOD の *.txt を出力すべき先を指定して下さい。Python の構文なのでフォルダの区切りはスラッシュ「/」です。そして末尾にも「/」を付けて下さい。他の .py ファイルがそれを前提に書かれているからです。(コメントにも書かれている通り)ここでの区切りは円記号やバックスラッシュではありません。

訳注:
相対パス、絶対パスの選択は自由です。もっと大事なのは、実行用のフォルダ(Warband の Modules の下のあなたの MOD のフォルダ。上の例では mymod1)に直接出力するか、それともクッション用のフォルダを挟むか、の選択です。
実行フォルダに直接出力する場合の短所は、例えば「だいぶソースを書き換えたから、ここまでで ちょっとコンパイル確認しておこう」と思ってコンパイル・エラーが出ると、.txt が正しく生成されず、ソース・コードが是正されるまで一切の実行確認ができなくなることです。複数のバグに対処中とか複数の大変更をしている時に、特に困るはず。(この方法の長所は、コピーが一回少ないことと、コピー忘れが起きないことぐらいです。)
だから多少 面倒でもワン・クッションおいて、一旦ワーク・フォルダへ出力させておいて、実行フォルダへ手でコピー(または移動)し直すほうが、トータルでは効率が良いかも。
(なお、コピー元とコピー先のフォルダを両方開かなくても、コピー先フォルダのショートカットをコピー元に作っておけば済みます。コピー元の .txt を全て選び、Ctrl キーを押しながら そのショートカットへドラッグすればコピー元が残るし、残す必要が無ければ(移動で構わなければ)Ctrl 抜きでドラッグします。この最初に「全て選ぶ」作業も、事前にショートカット名の先頭にアンダスコア「_」などを付けて一番上に表示されるようにしておけば、下矢印キー と Shift End、という 2 ストロークでできます。更に、その後 マウスに手を伸ばすのが面倒なら、Ctrl c か Ctrl x してから、Home キーでショートカットへ行き、Enter キーで先へ移動してペーストなど。)
勿論、この手動コピーを、別の bat ファイルやシェル・スクリプトで半自動化するとか、コンパイルの最後に一時停止して確認入力してからコピーする処理を加えるとかも可能でしょう。ただし、そうやって手作業を無くしすぎると、忘れた頃に「module_info.py との不整合」や「想定外の状況」が置き、無用の「大事故」を招き得るので、お好みで。
指定したパスが正しければ、正常に動作するはずです。あなたの MOD 開発のための導入(セットアップ)は これで完了です。ここで最初の難関がやってきます。
難関? どんな?
ご心配なく、どうってことは ありません。あなたの ModSys のフォルダ内の build_module.bat ファイルをダブルクリックして実行してみましょう。これが(疑似)コンパイラです。コンソール画面が現れ、経過が表示されます。エラーの無い良好な表示が 30 行余り出れば、めでたし めでたしです。
'python' is not recognized as internal or external command, operable program or batch file.
これは「Path」変数の設定が抜けているか誤りがあって、コマンドとしての python が見つからないことを意味します。この環境変数に指定したパスが実状と合っているかどうか確認しましょ。原因が判らない場合は、フォーラムのスティッキー(ピン止め)スレッド How to fix "Python not recognized..." (now also for Windows 7)(「Python が認識されません...」の修正方法)を読んで下さい。この問題が無い(無くなった)なら以下を読み進めて下さい。
えっと... "can't open file" とかいうエラーが出るよ! どうしたらいい?
ModSys のフォルダと新規 MOD への読み/書き権限は もちろん大丈夫ですよね。私は試したことがないのでわかりませんが、build_module.bat を管理者として実行すると うまくいくかも。それもダメなら、ModSys のフォルダをデスクトップとか マイ ドキュメントに置くと うまくいくかも。
俺んとこでは別のエラーだ!
フォーラムの検索機能(右上隅)を使って情報を探すか、Modding Q&A board(Modding に関する Q&A 掲示板)で質問して下さい。あなたの質問のために新しいスレッドを立てないで下さい。
(訳注: 質問するなら既存スレッドに返信する形にしなさい、ということ。詳しくは そのリンク先へ行き、Q&A Guidelines という投稿をよく読みましょう。そうしてから元のページに戻り、右上の「Post thread」ボタンを押すと、質問フォーム経由で投稿できます。フォームでは質問のカテゴリを示す WB などの prefix などを選べるし、投稿一覧をカテゴリで絞り込むこともできます。いずれにしても、後述されるように、質問する場合には必ず事前によく調べ、回答する側が困る事態をよく想像した上で、自分がどこを読み何を試し何を理解しているかを、できるだけ他人から見える形で、かつ簡潔に説明を。さもないと、「情報の宝庫」に邪魔な雑音ばかり増えてしまい、大勢が検索しにくくなるので。)
よっしゃぁ、コンパイル無事完了。次は?
よかった、できましたね。これで あなたの MOD の基礎部分は完成しました。あとは実際の改造自体をするだけです。
(訳注: ここで、コンパイルして生成された .txt ファイル群を実行フォルダ(Warband の Modules の mymod1 など)へ反映したことを確認した上で、Warband を起動してみましょう。起動直後の小メニューで mymod1 を選択でき、現時点では Native と全く同じ内容の「あなたの MOD」をプレイできるはずです。)
ただ、知っておくべきことが もう 1 つあります。お気づきと思いますが、ModSys のフォルダには 4 種類の .py ファイルがあります。以下を読んで、それらの目的を理解しておいて下さい。
- header_* ファイル - ヘッダ・ファイルにはゲームの定数が含まれています。変更してよいファイルもありますが、通常は非推奨または不要です。新しい定数を自分で定義したければ、相応の module_* ファイルのほうで可能です。利用できる全ての命令は header_operations.py に文書化されています。 (訳注: コメントなどを拡充した header_operations.py expanded も別途 入手できます)
- ID_* ファイル - ID ファイルには、MOD 内のすべての数値インデックスが含まれています。MOD システムでは、多くの場面で Python 言語の「リスト」をインデックス(0 からの通し番号)でアクセスします。この ID ファイルには そのインデックスが含まれています。ID ファイルはコンパイルを行なうたびに再作成されるので、手での変更は無用です。例えばゲームで実行エラーが発生した場合、インデックスだけ表示される場合があります。それに対応する元のソース内の識別子名を知りたい時に ID ファイル を読みます。
- module_* ファイル - 既に上述の手順の途中でも module_info.py を編集しました。モジュール・ファイルには、部隊、物品、シーン小道具、シーンなど、ゲームのあらゆる要素を関連付けたり操作したりする命令やデータが含まれていて、あなたが主に編集する対象です。開発中の MOD システムの(ソースを置いている)フォルダを時々バックアップすることをお勧めします。 (訳注: 一方で、ゲーム・エンジンにハード・コーディングされていて、MOD 開発者から介入できない要素も多々あります。)
- process_* ファイル - プロセス・ファイルは、疑似コンパイラです。あなたの MOD の記述を基に、ゲーム本体が理解可能な数字の羅列に変換(コンパイル)します。これらのファイルの変更が必要になることは滅多にありません。もし どうしても変更するなら、ご自分がやろうとしていることを完全に理解していなければなりません。いきなり いじったりしないで下さい。MOD システムの他の部分(命令やパラメータを単なるデータと見なし、リストとタプルで記述)とは異なり、プロセス・ファイルは Python の処理として書かれています。 (訳注: process_* だけでなく、Flora_kinds.py などのように リストとタプルと Python の処理が同居しているファイルもあり、それらは build_module.bat から呼ばれず、MOD 開発者が必要に応じて個別に実行します。)
あれ、ちょっと待って。MOD の作り方を教えてくれるんじゃないの?!
それは誰もが自分の力で歩むべき道です。つまり、返答は「いいえ、MOD の作り方をなど説明するつもりはありません。」。ただし、役立つヒントとリンクをいくつか紹介します。
まぁ いいか。どんなこと?
それでは...
- まずはフォーラムで人に質問する時の「文法」と「態度」。この 2 つは非常に重要なので憶えておいて下さい。正しく書き、他の人に対して礼儀正しくすれば、助けが得られる可能性は飛躍的に高まります。句読点など (訳注: punctuation marks 。ピリオド、カンマ、コロンなど) の後にはスペースを入れて下さい。「you」を「u」とか「y」に短縮したり、「help please」を「halp plox」にするのもダメです (訳注: 様々な母語の人たちが集まるフォーラムで そういう略字などを使うのはマナー違反で、もっと万人に通じるように平易に書きましょう、ということ)。 自分が扱われたいように、他人を自分と同等以上の人間として扱いましょう。経験のあるメンバー(わざわざ回答や試行をする時間を割いてくれるメンバー)は、あなたが尊敬するメンター(師匠)に対するのと同じくらい敬意を持って扱われるべきです。質問に遠慮は不要ですが、please(お願いします)という語を使いましょう。
- スティッキー(ピン止め)トピックは あなたの良き友です。フォーラムのトピック一覧で最上位に固定表示させているのは、重要事項だからです。それらを読んでおきましょう。
- フォーラムのルールを読んで下さい。それほど多くはなく、とても端的に書かれています。新しいトピックを作成するときに表示されるボックスも忘れずに読んで下さい。少なくとも一度は読んでおいて損はありません。
- ちょっとした質問がある場合、いちいち新規トピックを立てないで下さい。代わりに、Modding Q&A 掲示板に質問を投稿して下さい。(訳注: 上記「別のエラー...」の項の注を参照のこと。)
- フォーラムの検索機能やフォーラム上の Google 検索を利用して、必要なものを見つけて下さい。
- Modding を学ぶ最良の方法は、試してみることです。凡庸なアドバイスに思えるかもしれませんが、小さいことから始めて下さい。まぁ信じて下さい、私は経験上 知っています。まずは小規模から始めるのが うまい やり方。いきなり巨大プロジェクトを作ろうとするのは、とても まずい考えです。信じて。
header_operations.py を読むと、各「命令」(ModSys を機能させるもの)が どんな動きをするのか わかります。
あれ? マップの編集のしかたは?
念のため大事なことを言っておきます。M&B シリーズの modding では、マップ という用語は、主人公が小さく表示されて街を渡り歩くワールド・マップだけを指します。他のマルチ・プレイヤーのゲームで言うところのマルチ・プレイヤー・マップ、つまり戦場の場面は、MOD の文脈ではシーンと呼びます。もしフォーラムなどで質問者が実際はシーンのことを尋ねているのに、マップの編集方法という言い方をしてしまうと、周囲はとても混乱します。シーンとマップの違いを理解し、使い分けて下さい。
さて、ご質問の件に戻りましょう。ワールド・マップをいじるには、マップ・エディタというアプリケーションが必要です。それは いくつかあって、最もよく知られているのは Thorgrim の MapEditor です。古い M&B 向けに開発されましたが、誰が何と言おうが Warband でも使えます。他に Bloodpass の Warband Map Editor もあります。 (訳注: 両者よりは比較的 新しい、Swyter の Cartographer もあります。2024 年現在も作者はこのスレッドでアクティブです。また、それとは別に、復刻版「OpenBRF Redux」もメンテしています。用途ごとのマップ・エディタの使い分けについては別ページで取り上げている「この投稿」にも情報あり。)
Demonwolf 氏のチュートリアル How to make Campaign Maps は とても良く(私はフォロー中)、現実的なマップ編集を始められます。
どのエディタを使うにせよ、マップが大きくなるほど操作が重くなるので注意して下さい。マップの実体は、単純ながらも頂点数の多い 3D メッシュ(大抵のマップ・エディタは .obj 形式で入出力可能)です。80,000 を超えるような多頂点のマップは、使っているコンピュータへの負荷が大きいので、普通は避けるべきです (訳注: 原文は 2012 年の投稿。今では もっと多頂点のマップを持つ MOD もあります。とは言え、MOD 開発者ではなくユーザの環境次第の話なので、目安としては今でも考慮すべきかも)。
これで全部なの?
そんなところです。さあ、あなたが modding の広大な世界に足を踏み入れる時です。
- Lumos (訳注: ただし訳者がページ全域にわたり かなり編集。発散気味の箇所を整理し、より実務的にしました。)
訳注:
Hello, world! と表示させ、ついでにレジスタを使った簡単な計算もやってみましょう。
無害で簡単な方法は、キャンプ・メニューの選択肢を増やして、それを契機に何か処理をさせることです。display_message 命令に「@」の付いた文字列を渡す方法なら、別途 文字列を定義する必要が無く(1 ファイルの変更だけで完結し)簡単なので、これを使って、ワールド・マップの左下(と [Q キー]-[メッセージ]ボタン で出る履歴ページ)にメッセージを出してみましょう。
本文の上記手順で「Native からのコピー」「新規 MOD のコンパイル」「その MOD の起動」までできたら、次の準備として、この新規 MOD で新規ゲームを開始し、主人公を作り、ワールド・マップに初めて出た辺りでセーブし、一旦ゲームを完全に終了しておきましょう(毎回 New Game から始めたのでは試行やデバグを繰り返すのに時間がかかるからです)。
MOD 開発用のフォルダにあるソース・ファイル module_game_menus.py をテキスト・エディタで開きます。ゲーム中にキャンプ・ボタンを押した時に表示される文「You set up camp」を検索して見つけます。その 40 行余り下に「Resume travelling」という、ゲーム中にキャンプ・メニューから戻るための選択肢として表示される文(直訳すると「旅を再開する」)があります。この語句は他所にもあるので、ここでは説明の都合上「You set up camp」から たどって下さい。今回、その下に(プレイヤーが押せる)選択肢を追加し、それをメッセージ表示の契機にします。
("resume_travelling",[],"Resume travelling.",
[
(change_screen_return),
]
),
#--------------------------------------
("test1",[],"Test 1",
[
(assign, reg7, 3),
(assign, reg8, 2),
(assign, reg9, reg7),
(val_add, reg9, reg8),
(display_message, "@Hello, world! reg7={reg7}, reg8={reg8}, reg9={reg9}."),
(change_screen_return),
]
),
#--------------------------------------
]
上のコードで、横線のコメント行で挟んだ箇所が追加する行です。横線のコメント行自体は不要ですが、後で削除したり、機能の境い目を示すための目印として、あってもよいでしょう。
この .py ファイルを保存し、build_module.bat で(疑似)コンパイルしてできた全 .txt ファイルを Warband の Modules 下の開発中 MOD のフォルダに置きます。もう一度ゲーム(Warband)を起動し、(新規ゲーム時の長い作業をスキップするために)保存してあった場面をロードします。ワールド・マップ上で下欄の「Camp」(キャンプ)ボタンを押し、「Resume travelling 2.」という選択肢が一つ増えているのを確認して下さい。それを選ぶと、マップに戻るとともに、画面左下に Hello, world! と reg7~9の値が表示されるはずです。


上で加えたコードでは reg9 に reg7 の値「3」を写してから reg8 の値「2」を加えています。これらレジスタをどこでも壊してよい、とは限りません。レジスタや変数の用途や有効範囲(スコープ)については、「開発言語の書式」のページに説明があります。
display_message 命令に指定する文字列内の先頭に「@」を付けることで、コンパイラからクイック文字列として解釈され、quick_strings.txt へ出力されます(翻訳時には quick_strings.csv でオーバライド可能)。「@」が無い場合は、その文字列が(コンパイラが生成する)ID_strings.py などで定義された ID である必要があります。その場合のソースの書き方や「@」有無の使い分けについては、他の既存の display_message 命令を探して調べてみて下さい。
訳注: その他のヒント
日本語のコメント?
開発用の .py ファイルに日本語などのコメントやメッセージ表示を入れたい場合があるかもしれません。「MOD 開発で ありがちなエラー」のページにあるように UTF-8 化するための指示行を 1 行を加えればできますが、そこにも注釈したように、母語が他国語の人から読めなくなったり文字化けしたりするなど弊害があるので、これら .py ファイルで英語以外とかローマ字表記を使うのは全くお勧めしません。
一方、(開発時のコメントではなく)でき上がった MOD の、メニューの文言、会話文、ユーザ・インタフェースなどをローカル言語に翻訳(ローカライズ)するのは簡単で、.txt を変更することなく、別フォルダに翻訳版の .csv ファイルを置きます。その方法については この web 文書の「翻訳もし易いモジュール構造」のページを読んで下さい。
字下げ規則?
Python 言語ではインデント(字下げ)の空白数が重要(有意)で、推奨個数も指定されていますが、命令やレコードを並べる区間は module_*.py ファイル内の最外殻のコードではなくリスト [] の中なので、命令やレコードを置く区間ではインデントを配慮不要です。ただし、不揃いだと可読性が下がるので、できれば「コーディング規約」を決めて、インデントを何らか統一しましょう。たとえソース公開予定の無い MOD であっても、いずれコードを抜粋して誰かに質問したくなることもあるかも。だから日頃から自分も他人も読み易いものに整えておきましょう。try ブロックなど、インデントを整えているうちに自分のバグに気付くこともよくあるはず。
(ちなみに、インデントの配慮が不要な区間にもかかわらず、MOD システムの初期状態のように「インデントだらけ」にする書き方は、私(訳者)は好みません。ただでさえ狭い開発用 PC の画面の面積を、大量の空白が占有し、可読性を落とすからです。上記 Hello, world! の 10 行ほどの追加例でも、話の焦点がボケないよう、既存コードのインデントを変更せず、追加分もインデントを合わせましたが、内心は不満です。後で消すような一時的な短いコード区間なら「try ブロックの階層の深さを表わす以外のインデントは皆無」で充分です。その try ブロックですら、実体はリスト内のタプルなので、Python 公式の推奨字下げ数を持ち込む必要は全く無く、1 階層あたり例えば「空白 2 個」とか「1 個」で充分です。4 個などにしても たいていは整形や読解の手間が余計にかかるばかりです。)
実行時エラーとデバグ
コンパイルは問題無く通るのに、実行時にエラーが出る、クラッシュする、意図した処理を通っていないように見える、といった場合があるでしょう。実行時エラーの命令位置の読みかたなどについては、この web 文書の「MOD 開発で ありがちなエラー」のページに説明があります。デバグ、つまり問題対処をするには、ソース・コード(module_*.py など)を見直した上で、処理経路(どこをどう通っているか)や変数値を知るための表示などを書き加えたり、部分的にコメントにするなどして、正常ケースと問題ケースの「境い目」を探すとよいでしょう。
上述 Hello, world! の場合はワールド・マップからキャンプ・メニューを利用しました。では「シーン」、つまり戦場や街中や闘技場などでデバグのため、何か(変数を表示など)したい場合はどうすればよいでしょうか。例えば宿屋にいる時に try_for_agents 命令でループして、そこにいる人物(エージェント)全員の名前とか持ち物を左下メッセージで表示して確認したいとしましょう。宿屋には、店主が必ずいるので、店主に話しかけた時のメニューに選択肢を増設するなどの方法はありそう。その他、既存の選択肢が無かったり出しにくい場所(戦闘中、練習試合中、トーナメント中、街中、隊員一覧画面、スキル画面など)では、見慣れた文言を表示している箇所をソースから見つけ、付近にコードを追記するなど、工夫が必要です。MOD 開発に少し慣れてきて、ミッション・テンプレートやトリガーによって同期/非同期に起きる事象(イベント)を大体理解できたら、非同期なタイミングに影響しないようにトリガー内で情報をある程度 蓄積してからメッセージを出す方法を工夫してみて下さい。また、Warband にはデバグ・モードがあります。その説明は ここでは省略します。
コンパイル・エラー多発時に、1 つ目で停止させる。ついでに(?) Cygwin 導入。
MOD 開発環境に付属の build_module.bat をそのまま使うと、途中でコンパイル・エラーがあっても続行するので、たった一つのエラーが他のエラーを呼び、原因特定をしにくいです。%ERRORLEVEL% を調べて終了させるように書き加えることもできるかもしれません。しかし、.bat やコマンド・プロンプトでできることは かなり限られていて、その程度の拡張でもイライラさせられます。
下記は、カンマをたった一つ書き忘れてコンパイルした時のものです。左側は初期状態の .bat を使った場合で、160 行ほどのメッセージが出て、読む気も失せます。
| 初期状態の build_module.bat | Cygwin の bash 用 自作シェル・スクリプトに写し、set -e を指定 |
|
|
Cygwin などの Unix ライクな環境(Window から独立した大がかりな仮想環境ではなくて、Windows のファイル・システムとの親和性が良くて軽量な Unix 系シェル環境)を導入して、開発全体を効率化するのがお薦めです。上の右側は、.bat の内容を Cygwin の bash スクリプトに移植し、set -e を指定することで最初のエラーで終了させるようにした場合の出力です。
毎日 PC を起動し直した後でも、コマンド履歴が保存されているし、過去のコマンドを検索したり、コマンド行内の指定文字の前後へカーソル移動したり、一部を書き換えたりすることもできます。例えば vi ライクのインライン・コマンドを使えるように .bash_profile ファイルに set -o vi と設定しておけば、「k」とか「/」とか「cw」のような 1~2 文字程度の非常に短いキー手順で そういったコマンドの検索や置換などができます。毎日毎時、同じような形で必ず繰り返される cd や grep や find などのコマンド発行も、苦になりません。awk や sed などのストリーム処理コマンドをはじめ、用意された豊富なコマンドや 必要なら python も組み合わせて、検索や加工のための独自ツールをスクリプトで書くのも、この環境ならストレスを感じずに容易にできます。
訳者(私)の場合、既製 MOD の日本語化作業に参加する時にも Cygwin 環境が重宝しています。訳したところから次々と公開作業場へ書き出すのではなく、(下記のように)sed ファイルに変換対を書き並べたり、awk ファイルに文字列置換関数 sub() や gsub() を書いたりして、それらを(短い名前の)親シェル・スクリプトから呼ぶのです。そうすることで、様々な作業が簡単になり管理し易いです。例えば、その特定の既製 MOD のあるバージョンのある時点の英語原文からいつでも翻訳版を(十数秒程度で)生成、翻訳未了行を抽出、他のかたが訳した固有名詞と自分の訳が表記ゆれしている箇所を見つけるための一時的なファイルを生成、対象の MOD がバージョン・アップして英語原文が変わった箇所に対応、作業領域全体を圧縮してバックアップなど。
下記は A World of Ice and Fire (AWoIaF)という既製 MOD の訳に参加した時に自分用に何千行も書いた sed コマンドの一部です。コメント(独り言)を添えることができるので、その時に考えていたこと、MOD 作者への文言バグの指摘済や未了、ある日のリリース後に変更したこと示す目印などを書き残し、頭の記憶容量をムダに使わずに済みます。
# 句点を補うついでに、性別判定追加。
/^dlga_dplmc_chancellor_talk:dplmc_chancellor_message_ask_type|/ s/|.*/|他の領主へ親書を送って{くれ\/頂戴}。/
# 「きれに」と脱字していたのを修正がてら、平易な文に。
/^str_npc3_personalityclash2_speech_b|/ s/|.*/|このあいだ戦闘で勝った後、相手のものを漁ってたら、^ある男の腕が きれいに切り落とされてたんだ。^シリオのやつの仕業だ! それが俺の腕だったらと思うと!/
# 原文が作りかけに見え、現れないと思ってた。しかし現れたので改めて訳。
/^str_swadian_rebellion_pretender_intro|/ s/|.*/|やぁ 旅のお方、我が名はヴァラール・ブラックファイアー。^ブラックファイアー家の最後の「怪物」メーリス・^ブラックファイアーの息子だ。/
3D の制作
この web 文書や関連投稿では MOD 開発システムの範疇、つまりソース・コードで記述する「動きとかタイミング」の話になりがちです。「3D が得意なので もっと 3D 寄りの制作から始めたい」という場合もあるでしょう。例えば、種族の形状、乗り物(馬の変形)、シーン(宿屋や闘技場や街など)、ワールド・マップ、新しい装備、アニメーションといった 3D 関連オブジェクトを、コードよりも先に作りたいという場合です。でも、マップ・エディタや、「BRF バイナリ・リソースの扱い」のページにある 復刻版 OpenBRF Redux などをある程度 使いこなしてからにしたほうが良いです。もし 3D オブジェクトやアニメーションをソース・コードにどのように関連付けるかとか、OpenBRF Redux がどんなファイル形式を受け付けるかとか、視点の遠近に対応した LoD の用意、といったことを理解せずに自分の 2D/3D ツール での制作だけ先行すると、全くの徒労に終わる可能性がありそう。大規模制作に着手するのは、コードと 2D/3D が「ちゃんと つながるはずだ」ということを ある程度 確認してからにしましょう。
MOD システムが出力しないもの
(疑似)コンパイルで生成されるのは MOD に必要なファイルの一部(30 本余りの *.txt ファイル)だけです。それらだけを Modules フォルダ下の独自 MOD のフォルダに置いても、Warband の MOD として実行できません。このページの冒頭から説明しているように、先に Native 下と同じフォルダやファイルを複製する方法で自分の MOD の実行フォルダを作り、コンパイラで生成した自分の .txt 群を そこへ かぶせる必要があります。
WinMerge などの比較ツールを使って、MOD システムの出力と既存の Modules\Native フォルダ下 と比べると、MOD システムが出力しない(出力対象外の)フォルダとファイルは下記だ、ということが判ります。
コンパイルで生成されない、Native 由来のフォルダとファイル
- フォルダ: 全部(Data, languages, Music, Resource, SceneObj, Sounds, Textures)
- ファイル: game_variables.txt, main.bmp, map.txt, module.ini, module.ini.bak, module_fast.ini
一方、MOD システム v.1.171 の初期状態のコンパイル出力結果と Native v1.174 とで、対応する .txt 群だけ比べると、差は ほぼゼロ(strings.txt 内のクレジットの ごく一部が異なるだけ)です。そのことも WinMerge などで両 MOD のフォルダ丸ごと同士を比較すると判ります。
ゲーム・エンジンにハード・コーディングされていること
この web 文書や関連投稿の随所で触れられている通り、MOD 開発者が操ることのできない「ハード・コーディングされた」領域がいくつもあるようです。しかも公開情報がほぼ無い上に、エンジンの変遷などの経時変化もあいまって、熟練者の間でも見解が不統一だったり、古い情報が溢れてたりします。だから、ハード・コーディングに関しては、フォーラムなどで断定的な意見を見かけても、鵜呑みにはできません。はっきりと安定した症状が現れるものや 誰の目にも明らかなことは まだしも、タイミングや環境によって結果が一定しない場合は、追跡も難しいし、質問しようにも再現条件や症状を整理しにくいです。あなたがミッション・テンプレートに複数のトリガー、という構造を大体 理解したら、闘技場の練習試合の処理にメッセージや「ボットのチームを動的変更する処理」を加えるなどして動きやタイミングを調べてみるとよいです。自分のコードに誤りが無さそうなのに、意図した動きにならなかったり、不安定になる場合は、知らず知らずのうちに(?) ハード・コーディングに(不毛な)対抗をしようとしているかもしれません。その見極め(ハード~だと断定することや境界条件を見つけること)が容易でないのがつらいところです。この「チーム」については、この web 文書でもいくつかの投稿を紹介していて、フォーラム内を探していくと関連情報も多いですが、上述のように混乱ぎみです。誰よりも詳しくなるまで自分で「よく試す」のが一番です。
- 脚注と出典:
- [1] この「Python 2 のみ」は厳密に言うと誤りです。あなたが Python に精通しているなら、ModSys が使用する Python「コンパイラ」を自由に書き直して、Python 3 に置き換えられます。