Ja/Making a Mod

MODの製作

originally translated by N-neko(C-SEC), 2005/7/31

original English version: Making a MOD

MODの製作

この記事はソ－スエンジンのMODの製作を助けるために書かれました。まず、MOD製作を始めるにあたって、そしてチ－ム編成についてのアドバイスがあります。続いてMODのゲ－ムデザインを考えるのに役立つTipがあります。最後に、どのように未解決事項をまとめていきMODを完成させるか、という実際の製作における一番大変な部分についてのステップ･バイ･ステップガイドがあります。

はじめるにあたって

まず、チ－ムの編成から見ていきましょう。ここでのル－ルは「小さいままにする」ということです。チ－ムを管理するのはたとえチ－ム全員が同じ建物にいたとしてもフルタイムの仕事になります。オンラインのチ－ムを扱うなら、その管理に時間をすべて使ってしまって、自分のMODに使う時間がなくなってしまうということもありえます。チ－ムに人を加えれば必ずそれで実行できる仕事が多くなるということではありません。人が多くなれば、管理の時間が増えます。Team Fortessのコアチ－ムは3人でした。Counter-Strikeのコアチ－ムは1人でした。

チ－ムメンバ－を探すときは、必要不可欠な人だけを入れるようにしてください。本能的にコ－ド、モデル、マップを作れるような誰でも加えたいと思うかもしれません。しかし、最初のバ－ジョンにおいては、MODの各領域(コ－ド、サウンド、モデル、マップ)にそれぞれ一人いれば大抵の場合十分です。新しいモデル、サウンド、マップが必要としないとMODということもありえます。作品例を見るまでチ－ムに入れないようにしましょう。彼らが物事を完成させているか確かめてください。もし20個のモデルを作ったというモデラ－でも、そのモデルが半分しか完成していないという状態なら、チ－ムに加えたいとは思わないでしょう。

MODのデザイン

MODの作者として自分に問うべき有用な質問は「なぜ他の人は私のMODをプレイしなければならないのだろう？」です。完全に答えるには難しい質問ですが、うまく答えられるのなら、正しい方向に進んでいることがわかります。他にどんなMODがあるか、それが何を提供しているかを考えて見ましょう。あなたのMODはプレイヤ－に何か新しいことを提供しますか？ あなたが提供するものは他のMODを遊ぶのに忙しいプレイヤ－をひきつけるのに十分なものですか？この質問に答えられないとしても、考えることだけでもMODを作る助けになります。

あなたには商業ベ－スの開発者にはないパワ－があります。新しいゲ－ムプレイスタイルの商品としての可能性を心配しなくてよいのです。商業開発者は、小売への売り込み、損益分岐、といった厄介なことを心配する必要があり、そのためほとんどのゲ－ムが他の定評あるゲ－ムプレイを少し変更しただけのものになっています。しかしあなたはこうしたことを心配する必要がありません。次の大ヒットになるかもしれない本当に新しいゲ－ムプレイのアイデアを試すことができるのです。これがあなたの商業開発者に対する強みです。この強みに集中し、商業開発者が強い領域では対抗しようと時間を費やすことをやめ、仕事を簡単にしましょう。ほとんどのMODはコンテント(マップ、モデル、サウンド、etc)のレベルでは市販製品と戦うことができません。というのもそれらのゲ－ムには長年の経験を持つア－ティストチ－ムがいるからです。そうした製品をゲ－ムプレイで打ち負かしましょう。プレイヤ－は新しいコンテントがほとんどないMODでも、本当に面白いゲ－ムプレイがあれば遊びます。多くの人が気づいていませんが、Team Fortress 1にはリリ－スから1年の間新しいア－トをほとんどなかったのです。

あなたには商業開発者に比べて別の強みもあります。あなたは彼らに比べてずっと早く、そして頻繁にリリ－スを行うことができます。このMOD開発哲学を一文にまとめるとこうなります、「早くリリ－ス、頻繁にリリ－ス。」 商業開発者は2-3年働き、それからゲ－ムをリリ－スして、皆がこれを気に入るように神に願います。あなたはこの神頼みをする必要がありません。まずMOD全体をデザインし、25%の部分を作ってプレイアブルな状態まで磨き上げ、そこでリリ－スして即時にフィ－ドバックを受けることができます。それ以降は、最初のバ－ジョンのフィ－ドバックを聞きながら残りのデザインの追加をはじめ、毎月か二ヶ月に一度リリ－スを続けます。常にプレイヤ－と接触しているので、プレイヤ－が気に入るか確信が持てないことに多くの時間を費やすような状態になることはありません。ここでの秘訣は、MODを断片に分割することです。最初のバ－ジョンは楽しく遊べる状態である必要がありますが、考えた全ての機能を入れる必要はありません。気をつけてください。「早くリリ－ス」というのは質が悪いものをリリ－スするという意味ではなく、小さく、磨かれた追加を繰り返してMODを作るという意味です。Counter-Strikeの最初のバ－ジョンには今の半分の機能もありませんでした。CSのチ－ムは高品質でしたが、大規模ではないMODをリリ－スしました。それから一年、彼らは定期的に機能を追加していき、それに応じてプレイヤ－数は成長し続けたのです。

「違っていることが常によいわけではない。」ゲ－ムデザインを考えるときに「違っていることがよいことだ」ということを信じ込む罠にはまらないようにしてください。ゲ－ムに影響を与えないのならショットガンコ－ドを書き直して新しいモデルを追加する理由はありません。「なぜ他の人は私のMODをプレイしなければならないのだろう？」という最初の質問を思い出してください。「私のMODには新しい戦闘システムと、新しい移動システムがあります。」というのは必ずしもよい答えではありません。あなたの戦闘システムはHalf-Lifeのとは違っている…わかりました、でもそれはより優れたものなのですか？このシステムがMODを楽しく遊べるものにしましたか？新しい移動システムはゲ－ムをより楽しくしますか？プレイヤ－はすでにあるシステムに慣れているので、新しいものを学ばせるにはそれに見返りがあると思わせる必要があります。よって、何かを変更することを考える前に、それがどのように改善するもので、それが自分のMODを楽しくするだろう、ということを確かめましょう。HLと同じままにしておくことも恐れないでください。 自分自身への現実的なゴ－ルを設定しましょう。商業開発者が10種類の武器があるFPSを作るのにかかる時間を考えて見ましょう。もし自分のMODに40種類の武器を作ろうとしているのなら、それは自分の生活を本当に大変なものにするでしょう。ここで頭に留めておくことは「量より質」です。プレイヤ－は、バランスが悪く、他の武器のちょっとした変更にすぎないようなものもまざった40種類の武器よりも、ユニ－クでバランスが取れていて、使って楽しい10種類の武器の方をはるかに好むでしょう。

コンテントと機能を削減することを恐れないでください。MODがいつまでも完成しないようになってきたり、MODの他の部分に比べて質が足りないコンテントがあるなら、削減をはじめましょう。HLの開発においてオリジナルの機能の少なくとも30%が削減されました。これらは、時間的に不可能なのが明らかなもの、開発時間に値しないと判断したものでした。上で「量より質」といったように、プレイヤ－はテストされていない10のマップより、3つのよくプレイテストされたマップを好み、あなたのMODは質が高いコンテントをリリ－スするという評判を受けることになります。あなたのMODの最低の部分を世界に見せてはいけません。

エンジンを理解しましょう。SDKに含まれたドキュメントを読むべきです。そうすることでエンジンでXができる、というだけでなく、うまく動作させるにはXをどのように処理すべきか、ということを学ぶことができます。エンジンでどのような処理がされるか理解していなければ、50のロケットを発射する銃を作れてもMODのネットワ－クトラフィックを増大させるような方法を取ってしまっている可能性があります。これはMODに関わる人全てに関係します。エンジンをわかっていないマップ制作者がプレイヤ－に送信されるデ－タ量を考えずに巨大マップを作ったとしても、皆はネットワ－ク負荷が高いといってあなたのコ－ドを責めるのです。あなたがプログラマなら、他のMODプログラマ、そしてValveの従業員も数人加わっているHL Codersメ－リングリストに入るのがいい考えです。メ－リングリストには昔からのア－カイブがあり、MODでよくある問題への解決法を多く含んでいます。

仕上げ

初期には見栄えのいいコンテントを数多く公開して勢いがあるけれども、プレイヤ－の手の届く最終段階までたどり着かないようなMODは数多くあります。このセクションではMODをリリ－スできるバ－ジョンまでもっていく段階を進む手助けをします。

通常の開発からリリ－スバ－ジョンに持っていく時間をまず私達は5週間と見積もります。後続のリリ－スではこれよりうまく進行し、時間が短くなることが多いでしょう。MODの範囲が大きい、またはチ－ムが国際的だったりすると5週間より長くかかることが多いですが、それでも以下のプロセスはほぼ同じです。可能であれば、このリリ－ス時期の間はチ－ムメンバ－が毎日数時間MODに取り組むようにさせます。それができないメンバ－がいるならこのリリ－スに持っていくプロセスからは外した方がよいかもしれません。そうしたメンバ－の担当箇所を要求される活動ができる他のメンバ－に受け渡します。製品をリリ－スするということは、これが小さいものであっても困難な仕事であり、真剣な参加が必要になります。

このセクションには辛辣で厳格に聞こえるようなものも多くあるかもしれません。これは不運なことですが、プロセスの困難さを反映したものです。ここでのアドバイスは多くの製品のリリ－スにおいて学んだ教訓に基づくもので、その大部分はリリ－ス日を遅らせる原因となった手痛い間違いの結果によるものです。この文書の特定のアドバイスについてなぜ必要なのかと思うかもしれませんが、その助言を守らなかったから我々のリリ－スが数週遅れた、ということがあったからかもしれません。

またこのことは将来の雇用主が非常に興味を持つことでもあります。MOD製作者が多くのすばらしいものを作ったということも注目する点ですが、それを作り実際にリリ－スを行い皆が遊んだということは完全に注目することです。世界で一番すばらしいマップ、モデル、コ－ド、サウンドetcがあっても最後の詰めを行わずリリ－スしなかったら役に立たないのです。

恐れないでください、数回こなすうちにずっと簡単になります。MODの3回か4回目のリリ－ス時にはもうエキスパ－トになっているでしょう!

あと5週間

管理の集中化

MODチ－ムから一人だけを出荷リ－ダ－(shipping leader、以下SL)に指定すべきです。この人物がこれからの5週間においてMODの進行を取り仕切ります。今からMODに行う全ての変更はSLの要求があったときのみ行い、全ての変更に関するリクエストはSLに集中させるようにします。チ－ムメンバ－はSLが変更するように要求していない場合にはどんな小さい変更も行ってはいけません。これはSL以外のメンバ－がMODのコントロ－ル権を失うということではありません。というのもSLもチ－ムの一員であり、全てのフィ－ドバックに耳を傾けるからです。SLがいることの重要な点は、MODの全ての変更が一人の人間を通じて行われるということです。これにより、例えばコ－ドの変更を知らないマッパ－が締切直前にマップを変更してゲ－ムに不都合を起こすといったことが起こらなくなります。SLはこれからの5週間におけるコンテント(コ－ド、マップ、モデル、テクスチャなど)の全ての状態を把握し、先ほどの失敗例が決して起こらないようにします。SLを選ぶのは簡単ではありません。いくつかのアドバイスとしては以下があります:

• MODの運営者が最適と即時に決め付けないようにしましょう。特にMODを数ヶ月作っているのにリリ－スにまったく近づいていないときは気をつけましょう。

• ゲ－ムコ－ダ－が最適な選択であることが多いです。リリ－スのプロセスが終わりに近づくほど、ほとんどの修正はゲ－ムコ－ドのものになります。

• SLはできる限りモチベ－ションが高く、規律を守り、統制がとれ、個性が強すぎない(ego-less)ことが求められます。またSLにはこの5週間をリリ－スプロセスに使うことが求められます

• SLにはMODに関して広範な選択を行えることが求められます。リリ－スを行うために機能やコンテントを削減する必要があるということを理解すべきです。

ビルドプロセスの確立

MODをビルドするプロセスを確立する必要があります。ビルドというのは全ての作業物を、インスト－ルして動作させられる状態(通常インスト－ルファイルの形式)に持っていくプロセスです。これはSLがこの5週間に排他的に行う作業で、そのための厳格なプロセスを作るべきです。厳格なプロセスを作ることで、ある人が以前の人と違う方法でビルドを行ったということだけで起こったバグを追跡して何時間も無駄にすることを防ぎます。SLはMODの最終/リリ－ス候補バ－ジョンを管理します。全ての変更はSLに送られ、一つずつ変更による影響を理解しながらSLの手元のMODに統合されていきます。コ－ドとコンテントのバックアップを定期的に取るのを忘れないようにしてください！ SLは毎日プレイテスト用にMODをビルドします。これについては後述します。

機能固定

リリ－スはMODの部分を固定していくプロセスです。「固定」というのはその部分はそれ以降変更しないということです。固定された部分に見つかったバグは慎重に考慮すべきです。バグが本当に重要(ゲ－ムを止める位)でなければ、ただそれを記録して、MODの次のバ－ジョンで直すようにします。「簡単な修理」を行いたいという誘惑があるにしろないにしろ、MODの固定された部分を開放するのはできるかぎりやめるべきです。あと5週間という段階では、機能も固定すべきです。このことはMODに新機能を追加してはいけないということです。

プレイテスト

ここからは、毎日、もしくはそれができないなら一日おきにプレイテストをすべきです。プレイテストはSLによって作られたインスト－ル可能なバ－ジョンのゲ－ムで行うべきです。チ－ムメンバ－は自分の手元のバ－ジョンでテストしてはいけません。全員SLに送られたビルドをインスト－ルします（このバ－ジョンが一般に公開されインスト－ルして使用するもので、これをテストすべきなのです）。こうしないと、バ－ジョン違いによって見つかるバグで長時間無駄にすることになります。プレイテストを簡単にするために、MODは常に遊べる状態であるべきです。もしMODが遊べる状態でなかったら毎日非常に心配してください。もしコ－ダ－かマッパ－がMODを壊して遊べなくする変更を作ったなら、それをSLのビルドに組み込む前に熟慮してください。どのくらいの期間ゲ－ムが遊べない状態になるのか？何回のプレイテストができなくなるのか？MODが実行できないため働けないチ－ムメンバ－はどのくらいいるか？MODを壊さない、というのがチ－ムの信条であるべきです。プレイテストをするときはできるだけ多くのメンバ－に遊ばせるにします。作業をしている全員が定期的に遊ぶべきです。外部のプレイヤ－もいれることもわすれないでください。サ－バ－コンソ－ルのログ機能をオンにします(server.cfgの"log"を"on"にします)。これはサ－バ－の全てのアウトプットをgamedir/logsディレクトリにダンプします。(ファイルの名前は日付になります)ゲ－ム内のプレイヤ－がバグを見つけたときに、プレイヤ－に"say"コマンドで"BUG: バグ内容の説明"と言わせるようにします。そうすれば、ゲ－ムが終了したあとに、ログファイルを開き"BUG"という言葉を検索することで全てのバグがあった箇所を見つけることが出来ます。

バグ・変更

SLは全てのバグと変更、そしてその現状をのせたリストを管理すべきです。デ－タベ－スの使用が望ましいです。e-mailはすぐユ－ザのメ－ルボックスの最初のペ－ジからアイテムが流れてしまうのでバグの追跡には不十分です。毎回のプレイテストの後、ログファイルからバグと必要な変更点をSLのリストに加え、仕事をメンバ－に分担します。メンバ－がバグ修正・変更を行ったらその新しい修正をSLに提出し、SLは内容を確かめてバグリストの状態を更新します。バグリストは進行がどれだけうまくいっているかを評価するすばらしいツ－ルです。誰の仕事が過剰で、誰が負担が少なく、誰がバグ修正をしていないのか、MODの完成がどのくらい遠いのか、といったことを見るのに使うことができます。バグリストから何も削除してはいけません、たとえバグが修正されたとしてもです（もちろん、修正されたというマ－クはつけるべきですが）。これはプロジェクトの歴史の中でどんなバグが修正されたかを見るのにとても役に立ちます。何かが逆行して、バグが再現したとしても、前回誰が修正したか知っていればその人に原因を聞くことが出来ます。プロジェクトの終わりでは、リリ－スのプロセスにおいて全てのバグが修正され、変更も行われたことを確かめる必要があります。SLはバグ・変更詳細のバグリストへの追加なしにいかなるバグフィックスや変更をマスタ－コピ－にいれてはいけません。バグリストを作成し管理するのに役に立つソフトウェアもあります。または、スプレッドシ－トでもうまく働くでしょう。繰り返しますが、e-mailはよくない選択です。

うまくいかない機能の削減・延期

リリ－スにおいて一番難しく、やっかいで、そして不幸なことに避けられない部分は、現実的に判断して機能を削減することです。Valveではこう格言にしています、「全員、それぞれのお気に入りの機能がゲ－ムから削減されることになる」、と。この格言は本当に起こることではないですが、自分が気に入っていたり、多くの時間をかけた機能が削減されるという事実への心の準備になります。全てのすばらしい機能と、適当な期間内にリリ－スする、ということは両立できないのです。SLは何を完成させ、何を削減するかを、リリ－スプロセスの進行状況に基づいて決定すべきです。リリ－スが近くなればなるほど、バグについてより考えるべきです。このバグを含む機能はこのバ－ジョンに必須なのだろうか？この機能を直すのにかかる時間はどのくらいか？この機能を削減したり、後のバ－ジョンに延期させることはできないだろうか？

激しく、ではなく賢く働く

何度も繰り返すように、リリ－スのプロセスは大変ですが、どう作業をするか注意深くしないとさらに大変になります。多く働くということは、注意深く何を直し、何を延期し、何を削減するか選択することの代わりにはなりません。SLはどのバグ・変更を誰に作業させるか、ということを非常に慎重に決めるべきです。機能がかっこいいからといって、その機能の小さいバグを直すのに一週間も使わないようにしましょう。クラッシュを起こすバグをまず修正します。ゲ－ムをリリ－スする妨げになるバグを修正します。他のメンバ－がバグを修正する妨げになるバグを修正します。SLは正しい選択を行うためにバグの分類をすべきです。例としては、Must Fix(必須)、Severe（深刻）、Medium（中度）、Minor（小さい）、Zero（なし）、Deffered(延期)です。プロジェクトが終わりに近づくにつれて、SLは現れるバグを注意深く評価すべきです。バグを直すとよりプレイテストを行うことができ、通常はより多くのバグが見つかります。もしリリ－ス日まで2週間で、直すのに3日と500行の修正が必要だったら、その部分を削減するか延期しないとリリ－ス日に間に合わせることはできないでしょう。

あと3週間

コンテントロック

ここからはコンテントを完成させることを狙うべきです。ゲ－ムコ－ド自体を除いてゲ－ムのコンテント全てを固定します。マップ、モデル、テクスチャ、サウンド、HUD、起動画面などは全て完成させてSLのマスタ－コピ－に入れます。

シャットダウン

これは5週間の時点でも述べましたが、この時点ではさらに重要です。SL一人だけがゲ－ムのマスタ－コピ－に触ることができ、コ－ダ－はSLから指示があったバグの修正だけに取り組み、SLはそのバグフィックスだけを入れていきます。

プレイテスト

毎日最低二時間MODのプレイテストをすべきです。今からリリ－スまで、できるだけ多くの人をMODに取り組むようにさせましょう。ゲ－ムデザインの大きな変更をするには遅すぎます、そうしようとすら思わないでください。

あと一週間

駆け込みの変更は禁止

SLはしなければいけない変更点を全て評価し、次バ－ジョンに延期されるべきか決定します。ここでの安全な考え方は、全ての変更は、ただ一行のコ－ド変更でもリリ－ス日を2日遅くするということです。

2日間の安全期間

直す必要があるバグが全て直され、それ以外の全てを延期しても、まだ終わりではありません。これから少なくとも48時間待ち、その間に狂ったようにプレイテストをしましょう。全員時間がある限りゲ－ムに取り組むようにさせます。もしさらにバグを見つけたら、直して、またこの48時間のカウントをやりなおします。MODが新しい問題の発見無しに48時間の厳重なプレイテストを通ることができたら、リリ－スの準備は完了です!

リリ－ス後

リリ－スを行って、それをプレイヤ－が気に入ったなら、どこのWebペ－ジもあなたのMODの楽しさを話し合っていることでしょう。これで終わりにするかはあなた次第です。オンラインマルチプレイヤ－分野での私達の経験によると、MODの人気はサポ－トされる間しか続きません。あなたのMODがどんなにすぐれていたとしても、最初のバ－ジョンでは非常に多いプレイヤ－数を集めることはできないでしょう。プレイヤ－数は、新しいコンテンツを繰り返しリリ－スし、バグフィックスを行い、そしてもちろん、コミュニティサポ－トによって時間経過に従い成長します。新しいバ－ジョンをリリ－スするたびに、より多くのプレイヤ－がMODを試し、遊び始めます。何を直し、何を変更し、コミュニティの意見をどう聞くかというのは連続した学びのプロセスです。

グッドラック!