Radium Software Development

これは正しくは blog ではないのだけれど，非常に興味深いサイトだったので，チェックしておくことにした。

Kyle Wilson 氏は，現在 Day 1 Studios 社に勤務するプログラマで，同社の看板タイトル "MechAssault" 等のプログラムを担当している。 GDC 2003 では "Game Object Structure Roundtable" の司会を務めた人物でもある。

氏のページには，オブジェクトシステムの設計手法や，ゲーム開発の工学的な考察などを中心に，様々な種類の文書が置かれている。氏の書く文書はとても理路整然としており，技術文書として読みやすいスタイルを完成させているように思える。英語に弱い僕でも苦労することなく読み進めることができた。 blog 系のサイトでは，どちらかと言えば散文的な文体が用いられることが多く，日常会話的な語彙に不足していると，読み進めるのに苦労することが多いように思える。氏のページを読み進めるときの感覚は，そういった状態とは，実に対照的な感覚だった。

ともかく，オブジェクトシステムの設計や，工学的な話題に興味を持っている人にとっては，非常に参考となるページであるはずだ。おすすめかもしれない。

次に面白かったのが， Jamie Fristrom 氏の blog ページ "gamedevleague" だ。

Fristrom 氏は Treyarch 社に勤務するプログラマで，超メジャータイトル "Tony Hawk's Pro Skater" のプログラムを担当したことなどで有名な人物だ。

肝心の blog の方はと言うと，一応，ゲーム開発に関する考察を主題に置いているようなのだけれど，わりと一般論めいたことを多く書いているようにも思える。まあ，要するに普通の blog って感じかな……。

それほど頻繁ではないものの，定期的に更新されているようなので，たまに覗いてみると面白いかもしれない。

gamedevleague のリンクから，いくつかの blog を引き当てることができたのだけれど，どうにも風化してしまっているページが多い。やはり飽きやすい性格の人が多いのかな，この職業ってば……。

そんな中でも，ゲームデザイナ兼コンサルタントの Greg Costikyan 氏が運営する "Games * Design * Art * Culture" は，頻繁に更新の行われている頼もしいページだ。

ええと，実は，まだあまり読んでいない。せっかくだから読んでみよう，いつか必ず……。

また，これはゲーム開発とは直接の関連性が無いページなのだけれど， Joel Spolsky 氏の blog "Joel on Software" などもチェックしておくと良いのかもしれない。

ソフトウェア工学の一般的な話題を取り扱ったページのようだ。これも，また後ほどチェックしよう。いやほんと，いつか必ず……。

もう１つ偶然に見つけたのが，東京在住のゲームプログラマ Gregg Tavares 氏のページ "greggman.com" だ。

非常にキャリアの長いプログラマの方で，日本に来る前は Naughty Dog 社でＡＩプログラム等を担当，現在は Wow Entertainment 社でツール系のプログラムを担当しているとのことだ。

しかし，なんて言うか，ええと，アピール力に優れたページと言うか……。ゲームプログラマと言うと，どうにもシャイな性格の人が多い職種のように思えるのだけど，たまにはこのくらい「グワッ」と来るものがあっても，いいのかもしれないねえ，とか思いながら読んでいた。

ここに登場してくる「ゲームオブジェクト構造」 (Game Object Structure) という用語は，具体的にどのようなものと表すことができるだろうか。同じく Wilson 氏のテキストから引用するならば，次のような解説になるかもしれない。

私が今までに見てきたゲームエンジンは，みな，「ゲームオブジェクト」あるいは
「シーンオブジェクト」，「エンティティ」と呼ばれるような概念を持っていました。

この「ゲームオブジェクト」とは，例えば，動き回るクリーチャーのことであったり，
プレイヤーの進入を検知するための見えない箱のことであったり，戦闘機の機体に
ミサイルを括り付けるための接点のことであったりします。

ともかく，そういった「ゲームオブジェクトクラス」というものが，どのゲームにも
普通は用意されており，それがシステムに対して，衝突判定やレンダリング，
効果音の発声，トリガ操作，等々の処理を行うためのインタフェースを提供している
わけです。

僕は個人的に，ゲームプログラミングの中で最も面白い設計作業が，この部分にあるのではないかと考えている。ゲームオブジェクト自体と，それを扱うシステム全体の設計は，あるソフトウェアがゲームとして動作するための「仕組み」を提供するものであり，ゲーム固有のインフラストラクチャとして最も重要な要素であると信じている。このシステムを，如何に簡潔にモデリングし，如何に扱い易く設計し，如何に効率良く実装し，如何に柔軟性を持たせるか，等々……挑戦すべき課題は多く用意されている。それらを解決するにあたって，ゲームという「システム」を構築するためのエンジニアリング能力が大いに試されることになるのだろうと思う。

ただ唯一の欠点は，他人にアピールのしにくい種類の仕事だということかもしれない。「グラフィックエンジンを担当しました」なんてのは非常に分かりやすい仕事だし，「敵キャラのＡＩを担当しました」なんてのもかなりキャッチーだ。しかし，ゲームオブジェクトの設計ともなると，何しろその存在自体が技術職以外には説明しにくい性質を持っているものだから，いまいちアピールが利かなくなってしまう。別に管理職ってわけでもないしなあ……。

件のレポートには，ゲームオブジェクトに関連する最新の話題が多く載せられている。とても丁寧にまとめられたレポートなので，この分野に興味を持つ人であれば，目を通しておくことによって何かしら得られるものがあるだろうと思う。リンクが充実しているのも嬉しいね……。

これらの話題の中でも，個人的に最も注目を置いているのが "Composition vs. Inheritance" 問題……つまり，「継承」を用いるべきか，「合成」を用いるべきか，という議論だ。この件については，同氏のテキスト "Game Object Structure: Inheritance vs. Aggregation" の方に，さらに詳しくまとめられている。

この議論の要旨は，ゲームオブジェクトの設計において「継承」があまりにも安易に使われているという指摘であり，その状況に対して警鐘を鳴らすものとなっている。そして，その「継承」の代替として，もっと「集約」を用いるべきであるということだ。

OOP 設計の１パターンとして，いわゆる「一枚岩設計」 (monolithic design) と呼ばれるスタイルがある。すべてのクラスを単一の基底クラスから派生させ，単一の継承ツリー (inheritance tree) を構築していくというものだ。これは一見して，いかにも OOP 的な解決方法のように見えるかもしれない。しかしこのスタイルは，設計を進めるにつれ「行き詰まり」を見せてしまうことが多い。継承を深く進めた際に破綻を迎える危険性が高いのだ。

Ion Storm 社の Alex Duran 氏が GDC 2003 講演 "Building Object Systems" の中で述べている失敗例が分かりやすいかもしれない。

氏の話によれば，往年の RPG の名作 "Ultime Underworld" では，継承と派生を利用してオブジェクトの特殊化を行っていたそうだ。典型的な一枚岩設計と呼べるかもしれない。

この設計では「ＮＰＣ」クラスに対して会話ルーチンが実装され，会話の必要なクラスはすべて「ＮＰＣ」クラスの下に派生されるようになっていた。これはそこそこ適切な設計のように思えるのだけれど，世紀の奇作であるところの Ultima シリーズが，そんな凡庸な設計を許すはずが無かったようだ。後になって，プレイヤーが「ドア」と会話する必要が出てきたのだ！

ここで，「ドア」クラスが「ＮＰＣ」クラスとはまったく異なった「枝」に継承されていたとすると，困った事態になってしまう。「ドア」と「ＮＰＣ」の両方の機能を継承するクラスを作成するには，両クラスを多重継承する必要がある。しかし，この例のように，同じ基底を持つ複数の派生クラスを同時に多重継承することは，大抵の OOP 言語において禁じ手とされている。 Herb Sutter 氏が述べているところの「死のダイアモンド」 (Diamond of Death) パターンに当たるものだ。

言語仕様に対して深い理解と十分な警戒心を備えていれば，この手の多重継承を実現することも可能かもしれない。しかし，それには多くの危険性を看過しなければならず，むしろ避けるべきアンチパターンとして挙げることのできるものだ。それに，このように継承を多用してオブジェクトの機能分化を行うことは，往々にして誤った設計方針であることが多くの文献において指摘されている。

そのような OOP トレンドの動きに呼応して，我々も設計方針を改めようというのが，今回の "Composition vs. Inheritance" 問題であるということだ。

ここで指摘されている内容の多くは， Herb Sutter 氏の著作 "Exceptional C++" の中でも取り上げられている。またその一部は，氏のサイトのコンテンツ "Guru of the Week" の中にも見つけることができる。

Sutter 氏はこれらのテキストの中で， C++ の継承というメカニズムが持つ意外な危険性について触れ，その利用をできるだけ控えるよう，何度も繰り返し主張を行っている。またそれと同時に，それらの危険な設計を避けるために役立つ様々なテクニックについて，具体的なコードを提示しつつ（時には軽いウィットを交えて）分かりやすく解説を行っている。

氏の提示する「継承を用いる際のルール」を簡潔にまとめると，次のような内容になる： public 継承については， "IS-A" 関係，つまり「〜の一種である」関係を持つ場合にのみ適用することができる。 protected および private 継承については， "IS-IMPLEMENTED-IN-TERMS-OF" 関係，つまり「〜を用いて実装される」関係を持つ場合の「ごく特殊なケース」にのみ適用することができる。

後者のルールの詳細については，以下の記事 "Uses and Abuses of Inheritance" の中に解説がある（"Exceptional C++" にも同様の節がある）。

その他のケース……例えば， "HAS-A" （〜を包含する）関係や，多くの特殊でない "IS-IMPLEMENTED-IN-TERMS-OF" 関係については，基本的に集約を用いるべきであると指摘されている。また，このように特定の機能を包含の形で実現することを，一般に「層化」 (layering, leveling) と呼ぶようだ。

僕が今までに見てきたいくつかのライブラリや，また実際に僕自身が書いたコードの中には，機能の一部を共有するような目的……つまり，どちらかと言えば "IS-IMPLEMENTED-IN-TERMS-OF" 関係に属するようなシチュエーションにおいて，何も考えずに継承を用いてしまっていることが，頻繁にあったように思える。

僕が C++ に初めて触れた時期は，各社が競って GUI API を OOP 化しようと試みていた時代に当たる。しかし， GUI API という分野は OOP の持つ特性がトリッキーに適合する珍しい分野であり，このトリッキーさが多くの OOP 未体験者に対して悪い影響を与えてしまっていたようにも思える。そういった， Sutter 氏が指摘するところの「９０年代中期に見られた継承偏重指向の流れ」こそが，人々を安易な継承へと駆り立てる一因となっているのかもしれないと思う。

"Composition vs. Inheritance" の議論の中で挙げられているような「コンポーネント設計への移行」とは，まさにこの「層化」の変容を，ゲームオブジェクト構造に対して適用しようというものだと言うことができる。

この辺りの話については， Outrage Games の Scott Shumaker 氏がミシガン大学で行った講義 "Techniques and Strategies for Data-driven design in Game Development" において，「データ駆動型ゲーム設計」の話と絡めて総括的な解説が行われている。

この講義は，ミシガン大学ＡＩ研究室のカリキュラム "Computer Game Design" において行われたものなのだけれど，データ駆動設計の必要性とその実現方法について非常に丁寧な解説が行われている。とてもよくまとめられた内容なので，いわゆる「ハードコーディング」のスタイルから抜け出したいと考えている人は，是非読んで欲しいものだと思う。ていうか，向こうの大学ってば，大学の講義でゲームデザインを教えているどころか，こんなに質の高い講義までやっているとは……いやはや。

余談なのだけれど，教育機関におけるＡＩ研究とゲーム開発の間には不思議な関連性が存在するらしく，サンノゼ州立大学の Rudy Rucker 教授（サイバーポップ系ＳＦ小説家として有名なあの人だ）も，ゲームデザインを担当講義として受け持っている。

しかも，その内容で本を一冊書いてしまっているようだ。まあ，元が文筆家なもんだから，本の一冊ぐらい余裕で書いちゃうわけね……。

ええと，閑話休題……件の講義では，オブジェクトシステム構造の設計手法における過去のトレンドであった「一枚岩的な」継承スタイルには，設計上の根本的な問題点が存在することを指摘し，その解決方法として「コンポーネント設計」が利用できることを提示している。つまり，オブジェクトの持つ諸機能を適当な区分へと分割し，それぞれを「コンポーネント」として独立させることによって「層化」を実現させるというものだ。こうして設計されたコンポーネントベースの構造は，継承ベースの構造と比較して高い汎用性と再利用性を持っており，しかも実行時における動的なクラスの構築を可能にするという副次的な効果も有している。

ここで，オブジェクト設計の話題と同時に必ず持ち出されているのが，データ駆動設計に関する話だ。

Outrage Games の Scott Shumaker 氏の講演にもあったように，この辺りの流れは，もともとオブジェクトシステムにおける「データ駆動性」を高めようという発想から始まっているところが大きい。いかにしてプログラマの手を介さずにゲーム内容を変更できるようにするか，という問題だ。

なかには，こういった「データ駆動性」を敢えて無視し，すべてを「ハードコーティング」によって解決しようという考え方もある。例えば "Jak & Daxter" 等のアクションゲーム作品で知られる Naughty Dog では，独自のスクリプト言語 "GOAL" を導入することによって，ハードコーディングに伴う「作業効率の悪さ」を改善することに成功している。オブジェクトの挙動を始めとしたゲーム内容のほとんどをスクリプト言語によって制御しており，その総コード量はプログラム本体を大きく上回るほどであるそうだ。アクションゲームにおいてこのようなスクリプト制御を採用している例は比較的珍しいと思うのだけれど，ＲＰＧやアドベンチャー系のゲームにおいては，スクリプティングによる実装が一般的な解決法となっているように思える。

ただし，高機能なスクリプト言語を十分に使いこなすには，プログラマ或いはそれに準ずるスキルを備えたゲームデザイナの存在が大量に必要とされることになる。その結果として，トレーニングのコストの問題や，管理・運用面での問題が発生しやすいと考えられる。自由度の高いスクリプト言語によってプログラム外での設計を可能にするということは，転じれば，設計の責任をプログラマ外に委譲するということを意味しているのだから，その委譲先に十分な設計のスキルが保証されていなければ，厄介な問題を引き起こす原因となってしまうことは想像に難くないはずだ。

現に僕自身が，バイト時代にそういう仕事を与えられていたのだけれど（料理人が皿洗いのバイトから始めるようなものだ），そこでは，それらの「スクリプト言語がもたらすデメリット」がすべて発現してしまっていたように思える。不自由な言語仕様，定まらない運用ルール，放任主義がもたらすトレーニング不足……等々。そこでの苦い経験が，常に責任の所在を明らかにしなければならないという重要な教訓を刻み付けることになった（それを常に実践できているとは言い難いものがあるものの……）。

これに対して Scott Bilas 氏の提示するスキーマベースの実装例は，非常にスマートな仕上がりとなっている。しかし，独自の記述言語の設計・実装に費やされるコストや，管理・運用面で発生し得る多種多様なコストのことを考えると，あまり真似したくはない類の事例であるように思える。ヘビーな Mod 対応などを考えているのならともかくとして，通常ならばここまで凝る必要は無いだろうと思うし，たとえ実装の必要が認められたとしても，既存のパブリックな技術リソースを転用することによって，もう少し簡易的な実装が可能になるのではないかと思う。

僕自身が想定するシチュエーションでは，ゲームデザイナは設計レベルの話まで絡んでくるような細かい指示を行うことはなく，最低限のカスタマイズのみ行えれば良いと考えている。 Scott Bilas 氏や Doug Church 氏の提示する「データ駆動重視」のシステムは，設計の能力をある程度ゲームデザイナ側に委譲させることで，プログラマ単体では実現不可能なレベルの「多様性の創出」を行おうという意図があるように感じられる。しかし，僕はこれを敢えて否定しても良いと考えている。あくまでも設計の権限（とそれに伴う責任）はプログラマの手元に掌握しておき，設計者の想定する範囲内に制限された「多様性」を，ゲームデザイナが自由に扱ってもらおうという方針だ。

このような前提に基づいた場合，冗長なプロトタイプや複雑なスキーマを導入するよりも，プログラマが「お膳立て」を行った少数のビルダ関数のみを露出させ，それらの組み合わせによってカスタマイズを行うというような形にまとめた方が良いと思う。生成方法自体にあらかじめ制限を加えてしまうことによって，無軌道なコンクリートクラスの乱立と管理コストの増加を抑えようというわけだ。

ここで問題となるのが，生成に必要とされるインタフェース……つまりビルダ関数自身を，どうやってデータ側に露出するかという手段についてだ。それぞれのビルダが固有の引数を持っていることと，ビルダ自体をネストさせて階層化されたコンポーネントを表現する必要があることを考えると，単純なデータ列では対処が難しいことが分かる（いや，むしろ，こういう問題に対処するためにプロトタイプパターンがあるんだっけ……混乱してきた）。

最も簡易的なのは，ステージ構築用のデータを C++ ソースに変換してしまうことだと思う。この手段を採ることによって，データとコードの間を渡すインタフェースを設計する手間が省け，コンバータを用意することさえ考えれば良くなるのだけれど，この方法は DLL でも用いない限り作業効率が悪くなってしまうので回避したい。

XML のようなツリー構造状のジェネリックなデータベースを用いれば，完全なデータ駆動を実現できる見込みがあるものの，インタフェース部分の実装を行うのが多少面倒だ。ここでは，適当な既存のスクリプト言語（例えば Lua など）を用いることによって，より簡便な解決が行えるのではないかと考えている。

具体的な方法としては，ビルダ関数をスクリプト言語に向けて露出させ，スクリプト言語側ではそれらの関数を組み合わせて生成プロセスを記述する。このスクリプトはステージ構築用のデータから自動生成するのが好ましい。最悪の場合，簡単なタグの配置と手書きスクリプトの組み合わせでも実現可能だ。その辺りの区分は，ツールの運用ポリシーと突き合わせて決定すれば良いだろうと思う。

７時間程度でクリアできるとの話を聞いていたので，中盤からスパートをかけて一気にクリアした。結局，クリアまでに費やした時間は６時間半ほどだったので，アドベンチャーゲームとしてみれば適度なボリュームだったのではないかと思う。

"Silent Hill 3" をプレイしている間，何よりもまず驚かされるのが，そのビジュアル面における完成度の高さだ。グラフィック技術的にみても，アートデザイン的にみても，間違い無くＰＳ２ソフトの中で最高のレベルを誇る完成度となっている。

個人的に最も印象的だったのが，劇中に登場するキャラクタの「顔」の作り込みの激しさだ。

特にフェイシャルアニメーションが突出して良かった。キャラクタの微妙な情緒の変化に合わせて，ごく自然な様子に顔が動き，それが豊かな表情を作り出す。細やかな口の動きや，それに伴う頬の皺の動き，また，眉や目尻の微妙な変化や，視線を作り出す眼球の動きなど，非常に手間のかかる演出が細かく行われている。カットシーンのデモが画面上で繰り広げられている間，この演技力の高さに，ずっと目を奪われることになった。

それはさておき， "Silent Hill 3" のビジュアル面において圧倒的な存在感を放っているのが，光と影の演出だ。この点について，ここまで本格的に作り込まれたゲームは，既存のＰＳ２タイトルの中には存在しなっただろうし，すべてのプラットフォームのゲームソフトを比較対象に挙げたとしても，恐らく最高のレベルの演出を実現していることだろうと思う。

主人公の周囲の環境は，胸ポケットに取り付けられた携帯ライトによってダイナミックに照らし出される。もちろん，そこから生み出される影も，主人公の動きに合わせてダイナミックに形を変えていく。点光源によって描き出される歪んだ形のシルエットには，不思議と恐怖感を演出する効果があるようだ。暗く狭い地下道の中を小さなライト一個で歩き回る感覚には，同様の実体験を呼び覚ますようなリアリティがある。個人的には，グロテスクなデザインのステージよりも，むしろ地下道の方に強く恐怖を感じたほどだ。

他にも，全体的に暗めな環境を活かして，ライティングによる強烈な効果を狙った演出が随所に見られる。

あら捜しを始めれば，環境光よりも影の方が暗くなるケースがあるなど，細かな矛盾を見つけることができるのだけれど……まあ，そんなことはまったく気にかからないほど，全体の演出レベルは高かったように思える。

このゲームは，周囲のまったく見えない暗闇の中や，深い霧の中，狭い廊下の中というような，常に視界の狭められたシーンを扱っているため，主人公の周囲に限定して大量のリソースを注ぎ込むことができているように思える。そのためか，モデリングについても，テクスチャについても，他の一般的なゲームと比較すると非常にリッチな印象がある。特にテクスチャの描き込みの細かさについては，「ＰＳ２ってこんなにテクスチャ使えたっけ？」というような疑問を抱くことになるくらいだ。

"Silent Hill 3" の世界は，すべてが埃と泥と錆と血痕によって包まれており，平坦なポリゴンなど一欠けらも存在しない。それは，ただリソースを派手に浪費するだけの作り込みでは決してない。何か深い執念をも感じさせるような作り込みの激しさが，そこには存在している。

この味わい深い世界を表現するにあたって，ポスト処理系のエフェクト……特にノイズエフェクトの存在は，非常に重要な役割を担っているように思われる。これらのエフェクトによって画像を「汚す」行為が，低解像度のグラフィックマシンに特有なアーティファクトを拭い去り，結果として，これがゲーム中の画像であることを忘れさせるような臨場感を生み出すことになる。ＰＳ２のフィルレートの高さが救われる一瞬だ。

このゲームの雰囲気は，いわゆるホラー映画などに見られる純粋な「怖さ」よりも，フリーク系の「気色悪さ」を強く感じさせるビジュアルが持ち味となっている。だから，純粋なホラーを求めている人にとっては，何か物足りなさを感じることとなるかもしれないし，逆に，フリーキーなノリが好きな人にとっては，恰好のご馳走となるだろうと思う。不条理な世界の中で繰り広げられる悪夢の数々を楽しむことができれば，きっと幸いだ。

最後に個人的な不満点を挙げるならば，アクションゲームとしてあまり楽しめなかったことが残念だった。特にカメラの問題は，シリーズを通して多くのユーザから指摘を受けている欠点であるだけに，次回こそは何らかの改善があってほしいものだと思う。

OpenOffice Draw は，機能的にも操作性的にも申し分の無いソフトなのだけれど，残念ながら UML 図を描くための機能が欠落してしまっている。そのため， UML を扱う際にはかなり面倒な思いを強いられることになる。

一般に UML 図を描くためのツールと言えば，お馴染み Microsoft の "Visio" や，業界標準ツールであるところの "Rational Rose" ，それから "Borland Together" などの人気が高いようだ。

しかし僕は，基本的なスタンスとして，これらの設計図に対して，単なる見た目の良さを求めてしまったり，必要以上の意味を持たせてしまってはいけないと考えている。いくら完成度の高い設計図でも，更新の行われない文書はすぐに「腐って」しまい，文書としての意味を急激に失ってしまうからだ。

そのようなことを意識した上で， UML 図のような設計図は，初期設計の段階においてのみ有効なものと考えて取り組んだ方が良いと考えている。設計図とは，設計をまとめるために用いられる「ツール」なのであって，設計が終わった後の価値は無いものとしていいかもしれない。ひとたび「動くコード」が出来上がってしまったならば，次の瞬間から，そのコードが「法」となるわけだ。

ただし，途中から開発へ参加してきた人員に対してコンセプトを伝える目的では，初期設計時の道程を記録に残しておくことが役に立つこともあるだろうと思う。また，不特定多数の人間が利用するライブラリの開発などにおいては，これとはまったく異なったポリシーを持つ必要があるだろうと思う。

以上のようなスタンスに立った場合，必要以上に凝った機能を持つツールよりも，メモ帳感覚で扱うことのできるアクセサリ的なソフトの方が，用途に合っていると言えるかもしれない。そこで Kyle Wilson 氏が利用を勧めているのが "UML Pad" だ。

うん，確かにこんな感じで十分かもしれないんだよね……。ただそれにしても，このソフトは機能が不足し過ぎているように思える。いかにも「作りかけ」な匂いが漂ってくるのも，少し気になるところだ。

もう少し良いツールは存在しないものかと適当にリサーチをかけてみたところ，永和システムマネジメントの "Jude" が良いらしいという情報を得た。

これは以前にもちらりと目にした覚えがある。その頃は，まだそれほど魅力を感じないレベルのものだったのだけれど，ものすごい勢いでバージョンアップを繰り返すうちに，十分な機能を備えるツールへと育っていたようだ。

さっそくダウンロードして動かしてみた……ううむ，確かにこれは良い。機能的には比較的シンプルなものなのだけれど，ユーザインタフェースが非常に洗練されていて，いわゆる「使い心地」がとても良い。 Java ゆえに動作が少し重いという弱点と，構文の一部が Java の言語仕様に依存しているという不満点を除けば，十分に要求を満たしてくれるソフトだ。

次に手を付けたのが，ラウンドテーブルセッション "By the Books: Solid Software Engineering for Games" のレポートだ。

このレポートを書いた Noel Llopis 氏は， Kyle Wilson 氏らと同じく Day 1 Studios に勤務するプログラマだ。氏の個人サイトには GDC 2002 における同名セッションのレポートも置かれている。

それで，肝心の内容の方はと言うと……うん，綺麗にまとめられていて読みやすいと思う。一般的なソフトウェア工学分野における各種のトレンドが，ゲーム業界に対して実際にどの程度浸透しているのかという現状を知ることのできる，貴重なレポートだ。

例えば， UML やデザインパターン， OOP などのように，技術的なバックグラウンドを支える要素については，確実に取り込まれてきているという実感がある。しかしその一方で，開発手法や方法論については，数年前からほとんど何も進展していないというのが現状ではないかと思う。小規模な試行を実施しつつも，その有効性に対して疑問を抱きつつある人が多いようだ。

セッションに参加した技術者のうち大多数が，自分等の開発プロセスの無軌道さ（昔ながらの "hash and slash" スタイル）を認識しているということだから，何らかの方法論を取り入れることに対して意欲を持っていないわけでは無さそうだ。そのようなモチベーションが存在するにも関わらず，やはり上手く行かないというのだから，何か根本的な問題点が残されていると考えるのが正しいのではないかと思う。

中には，方法論の是非を問う議論に達する以前から，巨大な壁にぶち当たってしまっているケースもあるようだ。

……すべての人がＸＰのプラクティス（ペアプログラミングや，コード所有権の放棄など）を
認めているわけではないし，時には猛烈な反発に出くわすこともある。
ある人物は，社内でＸＰを実践しようと試みたものの，プログラマ全員がそれを拒絶し，
もし実行するのなら会社を辞めると脅されたため，中止せざるを得なかったと述べている。

これらの方法論を導入することの是非については，組織や現場の事情に依存する要素も多く，一概には決定できないものがあるだろうと思う。ただ，１つ確実に感じていることは，プログラマの役割に応じてスタイルを切り分けた方が良いだろうということだ。

例えば，ＸＰにおいて実践されている各種のプラクティスには，グループ内の知識やスキルを平均化させることによってリスクの分散を実現しようという意図が含まれている。これは，グループ内の全員が，ほぼ同じ分野の，ほぼ同じレベルの問題を扱っているという前提においては上手くいくものの，比較的特異な分野や局所的な問題を取り扱う「スペシャリスト」が存在する現場においては，そのスペシャリストの持つ貴重な「可能性」を削り取る結果になってしまうのではないかと思う。

逆に，「知識の平均化」が有効な働きをもたらすと考えているのが，「コンテンツとしてのプログラム」を作成する工程についてだ。これは例えば，ゲーム内の特殊なギミックの入れ込みや，敵キャラクタのバリエーション作成，ゲーム全体のフローの構築などといった，比較的専門色の薄い分野のことを指している。

これらの「コンテンツ」を作成するパートについては，作業のスケジューリングに合わせて自由に人員の増減を行えるようにしておくことが好ましい。しかし，人員を２倍に増やしたからと言って，開発速度が２倍になるとは必ずしも限らない。場合によっては，人員を増やすことによって開発速度が低下してしまうことだってある。そういった人員の増減に対して柔軟に適応するには，グループ内における知識の共有とスキルの平均化を図ることが，必ず重要な意味を帯びてくるはずだ。

また，このような「平均化作用」は，全体のクオリティコントロールを行う上でも有効に働くのではないかと思う。全体としてのクオリティの統一が図られやすくなることはもちろんとして，ディレクションを行う人間からの指示が集団に対して行き渡りやすくなることが，良い効果を生み出すのではないかということだ。

そのような発想に基づくと，これらの方法論をプログラマ以外に適用することも可能かもしれないと考えることがある。例えば，各個のアーティストがゲーム内容に対して抱いているイメージがバラバラだったり，あるいは，ツールに対する熟練度が極端に異なっていたりして，コントロールに苦労しているなと感じることはないだろうか。そのような場合に，ＸＰのようなコンセプトの導入がリスクの低下をもたらしてくれるとしたら……どうだろうか。

James Q. Wilson と George Kelling は 1982 年の Atlantic Monthly 誌上において
次のような論説を提示している。

「コミュニティの中に無秩序が発生し，それが対処されないままの状態が続くと，
そこの住民は自らの家庭や近所付き合いに対しても保持する努力を失ってしまい，
荒廃状態を制御しようとしなくなってしまう。」

「例えば，ビルの窓が１つだけ壊され，それが修理されないままの状態で放置されると，
じきに残りの窓もすべて壊されてしまうだろう。たった一個の窓を修理しないでおくことが，
誰もそれを構っていないのだというシグナルとなり，他の窓を壊すことにためらいが
無くなってしまう。誰にも構われていない財産は，いたずらや強奪の対象を求めている者に
とって，恰好の餌食となってしまうのだ。」

別に，プログラマが悪意を持っているというわけではないのだけれど，混沌に対して誰も配慮を行わなくなってしまう状態というものは，案外と簡単に作り出せてしまうものだ。そのような状態に陥ってしまったコードは，まるで香港の九龍城のように荒廃した構造物となってしまう。

しかも，たった１つの窓の破れが九龍城に至るまでの道程は，決して長いものではない。ほんの僅かな怠惰から発生した荒廃は，人知れず進行を繰り返し，加速度的な成長曲線を描いていくことになる。コードの荒廃が「ゲームを制作する」というモチベーションに対しては何ら悪影響をもたらさないどころか，制作進行を一時的に早める効果を持っていることが，更なる状況の悪化を招いているように思える。

このような現象に対して効力を持つのが「コードレビュー」の仕組みだと思うのだけれど，これに対しても否定的な見方をされていることが多いように感じる。例えば Jamie Fristom 氏は自身の blog "gamedevleague" において，コードレビューの効力が過大評価されているのではないかという疑問を提示している。

要するに，あるプロセスに対して払われるコストが，それによって得られる効果を下回っていた場合，そのプロセスは本当に必要なものと言うことができるだろうか，という意見だ。このような「コスト対効果」の割合が，開発の進行によって上下するものだとしたら，その分岐点を見極めることが重要な判断となるのかもしれない。

よく「失敗を恐れては変わることができない」というような格言を引き合いに出すことがあるのだけれど，チームの士気を守るためには「失敗」こそ本当に恐れなければならない要素なのであり，決して「ちょっと試してみようか」では始められないという実情が，そこには存在する。

Taylor 氏自身がプログラマ歴１２年のベテランであり，ゲーム業界内外での経験を併せ持つとあって，なかなか説得力のある内容となっている。主に欧米のスタイルに関する解説となっているのだろうけども，国内においてもさほど差は無いだろうと思う。

この講演において氏は，プログラマチームを構成する各員の役割や，チームを正しく運用する方法について，概論的な解説を行っている。その中でも特に注目したいのが，「偉い人ほどコードを書かない」……あるいは「偉い人ほどコードを書いてはいけない」という指摘だ。

氏は，リードプログラマ（国内では「メインプログラマ」と呼ばれることが多いと思う）の職務を次のように定義している。

※ ゲームの全体構造の設計と監督を行う
※ データパス（コンテンツを処理するフロー）の設計と管理を行う
※ 内部的に必要とされる技術的な設計書を書く
※ デバッグ計画の立案に参加する
※ プログラマチームに必要な機材を確保する
※ 各マネージャと連携し，コーディングが正しい方向へと進んでいることを確認する
※ 仕事のレビューを行い，各プログラマがタスクを完了させられるよう援助する
※ ゲームがパブリッシャやハードウェアメーカーに認可されるよう調停を行う
※ コードを書く

このリストにおいて「コードを書く」というタスクは，最も優先順位の低い仕事となっている。リードプログラマはチームの監督や主要部分の設計，成果のレビューなどに労力を割くべきであり，決してコーディングに重点を置いてはいけないということが述べられている。逆に，リードプログラマ自身がコーディング作業を多く請け負ってしまったがために，チームに対して苦痛をもたらしてしまったという Taylor 氏自身のエピソードが添えられている。

歳をとってからもバリバリのコード書きであることは悪くないと思うし，逆に早熟のリードプログラマーなんてのもあっておかしくない。大切なのは，自分の役割が何であるかを認識し，常にそれにふさわしい行動をとること……あるいは，自分の本当にやりたいことを認識し，それにふさわしい立場を維持できるように努力すること……なのだろうと思う。

ここで挙げたような，方法論や人材運用……つまり，いわゆる「ディレクション業務」に対して強く関心を持つようになったのは，自分の中で起こりつつあり気持ちの変化に関連している。

自分がこのような職業に就いたのは，ただ「痛快なコードを書くこと」が目的であり，それがすべてに優先される事項だった。しかし，最近となっては，自分１人で成せることの小ささを認識しつつある。どんなに優秀な人物であれ，本当に何か大きなことを実現するには，「人を使うすべ」を覚えなくてはならない。その原則が変わることは無いはずだ。

もし，コードを書くことが唯一の目的であれば，一介のコード書きとして居つづけることも悪くないと思うし，極端なことを言えば，個人業として独立するのもアリだと思う。しかし，本当にコードを書くことだけが目的なんだろうか？コードを書く行為自体が楽しいことには間違い無いけれども，自分にはもう少し何か違う目指すべき点があるように思える。そこに向かって歩むには，自分のステータスを上げていくという，避けては通れない道が存在する。

ついこの間までは，自分は生来のコード書きであると認識していた（少し恥ずかしい話ではあるけれど）。正味な話，見栄や収入の点を別にしたら，いわゆる「偉い立場」になりたいなんて微塵も思っていなかったし，そういった人たちが現場作業から徐々に離れていく所を見て，自分は決して同じ道を辿りたくないと考えていた。

そんな風に無頼を気取っているのも，もう終わらなくてはならない時期が来たのかもしれない。昔はただ面倒だと考えていたことが，自分の中で次第に重要な意味を持つようになってきている。ただ単に歳をとってしまったのだと言えば，それまでなのかもしれないけれど，自分の立場のあり方について，もう少し真面目に考えてみるべき時が来ているのかもしれないと感じている。

他にも軽い解説を行っているページはあるのだけれど，図解まで使って丁寧に解説しているようなページは，他に無かった。 Flash を使ってアニメーションまで作ってあって……凝ってるなあ。

「安全ピンを抜く→レバーを放す→撃鉄が作動する→導火線に火が点く」という，だいたいの原理は知っていた。しかし，ここまで詳しい内部構造は知る由も無かった。撃鉄が内部で跳ねて，底部の導火線に点火されるって仕組みだったのね……。

このサイト "HowStuffWorks" は，なんでもかんでも，とにかく物事の仕組みを解説してしまおうという，薀蓄系読み物サイトのようだ。

「ロケットエンジンの仕組み」や「地震の発生の仕組み」などというような科学記事を始めとして，「所得税の仕組み」や「国連の仕組み」，果ては「悟りの仕組み」のような超自然現象までも扱ってしまっている。なんでもありだな，こりゃあ……。

軍事関連が意外と充実しているのは，やはりお国柄なのかもしれない。

ついでに「マシンガンの仕組み」で自動小銃の動作原理を調べてみる。

前方へのガス圧がピストンを押し下げて，ボルトを戻すようになっているわけだ。むむむ，なるほど……。

そんな感じで，色々と調べてみると面白そうなサイトだ。 "Money Channel" や "People Channel" など，普段は馴染みの薄い一般教養系のセクションをさらってみるのも，いい感じかもしれない。

イギリスは Climax 社の Shawn Hargreaves 氏（けっこう露出の多い人だ）の記事で，内容は題名が示している通り， Xbox Live のバンドルソフト "MotoGP Online" をたった７週間で仕上げてしまったという顛末についてレポートしたものとなっている。短期間でゲームを制作した例は国内外にも数多くあれど（武勇伝としてはありがちなジャンルだと思う），仮にも Xbox Live の看板タイトルとされていたものが，たったの７週間……つまり２ヶ月未満という，超短期間で制作されたことは，驚愕に値するだろうと思う。

しかも，その道程は予想される以上に険しいものだったようだ。交渉の遅延からプロジェクトの開始をさんざ保留された挙句に，やっとスタートが切られたと思いきや，ネットワークプログラムの担当者がハネムーン旅行へと逃げてしまったという，踏んだり蹴ったりの様子が語られている。結局，ネットワークについてはまったくの素人であるはずの Hargreaves 氏が，ネットワーク層の実装を無理やり担当することになってしまったということだ。本来ならこの時点で絶望的だよね……。

その絶望的な状況を打開することのできた要因は，１つには大きな幸運と，１つには Climax 社の従業員の努力，そしてもう１つは Microsoft との強力な連携にあったのだろうと思う。

「７週間のわりには」という前置きは付くものの，開発チームは予想以上に多くのことを成し遂げたようだ。……単なるデモ版に終わらせるのではなく，製品版のセーブデータが存在する場合にはコースやマシンのアンロックがなされるようにした。ネットワーク機能との統合を行うために，ＵＩ関連のコードはすべて書き直された。ただでさえギリギリな帯域の上にボイスチャットの機能を追加した。等々……。また，「まっさきに削られるかもしれない要素」として実装を行っていたはずのスコアボードシステムは，結果的に，このサービスの人気を支えるフィーチャーとしてユーザに受け入れられることになった。

他にも色々とネットワーク関連の話が挙げられているものの……やはり最も重要なのは，「最低限何が必要で，何が必要で無いか」を適切に見極めることができたということなのだろうと思う。それから，７週間というギリギリの目標に向かって全員が迷うことなく突進できたことは，成功の大きな要因として挙げることができるのではないかと思う。

驚くべきことに，我々はこのゲームを予定通りに片付けることがきた。
なおも素晴らしいことに，このゲームは同時発売タイトルの中でも，
最良の Live システム実装例として広く賞賛されることになった。
私は，我々を助けてくれた Microsoft の皆さんに深く感謝したい。
本当の本当に最後になるまで大したものを見せられなかったにも関わらず，
彼らは我々のことを信じ続けてくれた。

そもそも，我々には適切なスケジュールが与えられていなかったのだ。
「僕らがコーヒーを大量にガブ飲んで寝ずに仕事をすれば，おそらくもしかしたら
何とかならないこともないような気がすることはバッチリ分かっています」なんて
文章以上にまともな言い訳を書くだけの余裕もなかったのだから……。

この記事は Valve Software においてシニア・エンジニアを務める Ken Birdwell 氏が執筆したものだ。同社の出世作である "Half-Life" において用いられた制作手法 "Cabal Process" について，詳細な解説を行っている。「まったく面白味の無い焼き直しゲーム」として終わりそうになっていた "Half-Life" を見事復活させ，ミリオンヒットを記録するほどの傑作にまで押し上げた原動力が，この "Cabal Process" に隠されていると，氏は主張している。

ここで登場してくる "Cabal" という単語の意味がよく分からなかったので，軽く調べてみたところ，「影から状況の操作を行う秘密組織」のことを指して言う単語であるようだ。１７世紀のイングランドに実在した「キャバール政権」が語源となっているらしい。

Birdwell 氏の述べる "Cabal" とは，比較的多人数（少なくとも６人以上）によって行われる連続した会議のことを指している。この "Cabal" は，特定のステージのデザインや，特定のフィーチャーのデザインに関して討議を行う場であり，デザイナだけでなくプログラマやアーティストのような複数のパートの人間が参加して行われる。どちらかと言えば，会議というよりかはブレインストーミングに近い雰囲気を持っているようだ。

Cabal の集いは週に４回のペースで開催され，それぞれの会議は６時間ほどの長さを持っている。この会議では，毎回必ず１人の「書記役」を立て，議事の記録と文書化を義務付けるようにしている。それに加えてもう一人，いわゆる「絵描き役」を立てておき，簡単な図やイラストの類はその場で作成してしまう。このようにして作成された文書の数々は，忘れがちな人々の記憶を支えることはもちろん，後の制作過程における「フレームワーク」として重要な役割を担うことになる。

このように，チーム内の全員が必ず何らかの討議に参加し，皆の意見を積極的に吸い上げ，それらを統合しながらデザインを進めていく……という流れが，この "Cabal Process" のコンセプトとなっているようだ。

このように極端な「ミーティング駆動型」の制作手法を用いることになったそもそもの要因は，彼らが望むところの「ゲームデザイナ」というべき人材を見つけられなかったことにあるようだ。

プロジェクトを始めてから１１ヶ月もの間，我々は「ゲームデザイナ」を探し回っていた。
山ほどの履歴書に目を通し，多くの有望な応募者と面接を行ったものの，我々の望む能力を
備えた人材はついぞ見つけられなかった。我々は神のような「ゲームデザイナ」を真面目に
欲していたのだ。

そして最終的には，我々が理想としているような人材は実在しないのだという結論に達した。
その代わりとして我々は，セクションを越えた人材の力を結集させることによって，
我々自身の理想を作り上げることにした。これこそ，我々が "Cabal" と呼んでいるものだ。

結局，ゲームデザインを専門に行う「ゲームデザイナ」というような役割は立てることなく，実際にコンテントを作成する人員のみで実質的な制作作業を進めることにしたそうだ。３０人ほどの人員を抱える中規模の制作チームにおいて，このような制作方針が採られることは，かなり珍しいケースなのではないかと思う。

Valve Software において実践された "Cabal Process" のように，多数の頭脳を集結させ，その多彩な意見を汲み上げつつも，全体としての見解の統一を保ち，安定した制作を推進させる方法……いわゆる "design by consensus" 手法は，制作スタイルとして１つの理想を実現させたもののように思える。

しかし当然のごとく，現実はそれほど楽観的でない。どんなに多くの頭脳を集めたところで，アイデアの枯れる瞬間は必然的に訪れるものであるし，無理に見解の統一を図ることが，かえって状況の膠着を招いてしまうこともある。逆に，多数のアイデアが出てきたとしても，それらの雑然としたアイデアを洗練するには，相当の時間を割かなくてはならない。これは，少数の頭脳が明確なビジョンを持って全体の指揮を行うよりも，ずっと重ったるくて見通しの悪いものとなってしまう危険性を含んでいる。

そもそも，大規模の制作集団においては，どうやってもある種のヒエラルキーを構築せざるを得ないという事情がある。大規模の集団において全体としてのクオリティの統一を図るには，トップダウン式の指揮系統と，明確な役割分担が欠かせないものとなるはずだ。 Half-Life における３０人という制作集団の規模は，全員の見解の一致によって制作を進めることのできる上限であるようにも思える。

また， Half-Life のゲーム内容を構成する基本要素が，これと言って特異なものではなかったことは，要点として注目に値するだろうと思う。既存の製品群から単純に類推することのできるような内容であったわけだし，彼ら自身，既に十分に慣れ親しんだジャンルであったことは間違い無い。その時点で，各員の持つビジョンの一致を図ることは，比較的容易なタスクとなっていたはずだ。

これに対し，もしゲームの根本を成すアイデア自体が新奇性に富んだものだったとしたら，事態はどのように変化していただろうか。トップダウン式のディレクションを一切行わずに，全員の見解の一致を図ることが，果たして可能であっただろうかと思う。

このように "Cabal Process" の一般性については疑問が残るものの，少なくとも Half-Life の制作過程においては，この方法が非常に上手く適合したようだ。

Cabal process を始めた最初の数ヶ月というもの，プロセスに参加しなかった人間に
とっては，まったく訳の分からない時間が続いていた。

個人のエゴを十分に抑えることができるだろうか……あるいは，多くの人によって
フィルタされることが，ゲームのビジョンをぼやかしてしまわないだろうか……
そういった疑問の数々が明らかにされないまま，プロセスは続けられていた。

しかし，その結果は，これらの不安とはまったく正反対のものであった。プロセスに
参加した人間は，孤立して作業することを嫌うようになり，協力して作業を進める
ことに意欲を見出すようになった。そうして得られたデザインは，常に安定した品質を
保っており，それまでには見られないほど奥が深く，洗練されたものとなっていた。

このような手法を成功させることのできた１つの要因として，テストプレイを非常に重視したことが挙げられるかもしれない。件の記事において Birdwell 氏は，パブリッシャのツテを駆使して延べ２００人ものテストプレイヤを動員し，綿密なテストプレイを行ったことを記している。テストプレイヤの行動を注意深く観察することによって，自分たちの行ったデザインが意図通りに働いているかどうかを確認し，ダメであれば修正を行うという作業を，何度も繰り返し行ったとのことだ。

このように，デザインの各場面における決定因子の一部を，将来的なユーザの反応へと委ねたことは，各メンバーが自主的な判断を行う上で，重要な役割を果たしたのではないかと思う。また同ゲームのように，暗黙な誘導によって進行を制御するゲーム内容の場合には，このように綿密なテストプレイを実施することによってデザインの検証を適宜行うことが，非常に重要な意味を持つのだろうと思う。

国内においても，「猿楽庁」のような専門組織を利用してゲーム内容の検証と調整を行うケースが，しばしば見られる。

しかし，テストプレイにおいて最も重要な作業は，実地においてユーザの反応を目の当たりにし，その受け取られ方を直に感じ取ることだろうと思う。一般にゲームソフトは，たとえそれが発売された後であっても，ユーザの反応を直に観察する機会は非常に限られている。したがってテストプレイとは，ユーザの純粋な反応をサンプルするために用意された，唯一の機会であると言うことができるかもしれない。

この Postmortem 記事の中で， Ion Storm 社の Warren Spector 氏は， "Deus Ex" の制作中に体験したある種の「変化」について述べている。チームに新たな人員が追加されるに従って，次々と新たな発想がもたらされ，チームは次第に「総意」によって動き出していく。

十分な試作を行い，多くの原則や指針を用意したにも関わらず，Deus Ex の制作体制は
変化を迎えつつあった。チームの各員が自分の意見を持ち，その集合によってゲームが
作り出されるようになりつつあったのだ。彼らの多くは，試作時には居なかったメンバー
のはずなのだが。

言い換えるならば…… Deus Ex は「生命を得た」のだ。生命を得て，進化と成長を繰り
返すプロジェクトとなっていた。

そして，制作に伴う「成長の苦しみ」も生み出すようになっていた。皆が同じステージに
立つということは，いつだって簡単なことではない。それは，時には悪夢のようでさえ
あるのだ。

このようにドラスチックな変化を経たにも関わらず，最終的に "Deus Ex" はゲームとして高いまとまりを得ることになった。チームの規模は約２０名ということだから，この規模の小ささが有利に働いたという側面は，少なからず存在するだろうと思う。しかしそれにしても，終始雑然とした意見に揉まれながらも，当初のコンセプトである「多様なプレイヤーの行動を許容する」という要素を守り抜くことができたのは，注目に値する点ではないかと思う。

Fristrom 氏は，「総意によるデザイン」が強力な手段となり得る可能性を主張しつつも，この手法には多くの落とし穴が存在することを指摘している。「ダメな人間が悪影響をもたらす危険性」，「他人の気分を害することを恐れる危険性」，「間違った総意の導き出される危険性」，「最良の選択が行えなくなる危険性」，「状況の膠着を招く危険性」……等々。

"Deus Ex" の制作を成功へと導くことのできた要因は，これらの落とし穴を確実に避けつつ，プロセスを有効に働かせるような行動を，人々が常にとっていたことにあるのだろうと思う。それが意識的なものであったのか，それとも無意識のものであったのかは，あまり明らかにされていない。しかし，例えば次に挙げるようなアグレッシブな議論を積極的に行っていたことと，そこから有用な結論を汲み上げることのできる能力を持っていたことが，このような制作方式を実現する上で重要な意味を持っていたに違い無いと思う。

「主人公には自分の名前を付けるべきだろうか？」

この議論は「聖戦」へと発展し，チームの意見を完全に二分することになった。

「自分の名前を付けられないゲームなんて，ＲＰＧじゃない！」
「名前を設定しておかなきゃ，質の高いストーリーは書けないよ！」
「ストーリーは論点じゃない！」
「いや，そんなことはない！」
云々，云々……。

結局，我々は次のような形で妥協することにした。主人公には，ストーリー上で
用いられる「コードネーム」を設定する一方で，ユーザは自由に「本名」を与える
ことができるようにしておく。この「本名」は様々な形でゲーム中に登場するものの，
台詞として語られることは決して無い。

その中でも印象的なのが，本格的な制作を開始する以前に大量のドキュメントを作成しているという点だ。

"Deus Ex" のゲームデザイン面における挑戦の１つに，「ユーザの行動に関して十分な多様性を許容する」というものがある。これは Spector 氏の持つ RPG 哲学から導き出された１つの結論であるようだ。氏が "Deus Ex" の制作中に執筆した記事 "Remodeling RPGs for the New Millennium" では，このような結論に至るまでの思考が詳しく記されている。

氏の提示する初期デザイン案によれば，プレイヤはそれぞれ「自分の望む自己の姿」を作り出し，「自分の望む方法」によってゲームを進めることを許されるようになる。腕力系のキャラクタならば暴力的な攻略を，技術系のキャラクタならばトリッキーな攻略を選ぶことができる。あるいは，手に入れた武器やアイテム，ステージの構造やキャラクタの相関関係などを自分なりに利用して，自分なりの攻略を組み上げる。このような「本当の意味でのロールプレイング」を楽しんで欲しいという思いが，このゲームのコンセプトを形作ることになったのだろうと思う。

この挑戦を実現するにあたって，まず着手されたのが，ゲーム世界の背景を支えるストーリーの構築だった。ゲームの背景となる世界の中では，一体何が起こっており，それがどのように進行しているのか……その内容を明らかにするため，ゲームとは直接に結び付かないような点についても，設定を詳細に用意することになったということだ。

このようなドキュメントの類は，実際の制作過程に入った後も依然分量を増していき，最盛期には５００ページをも超える長大な資料となってしまう。 "Deus Ex" において脚本を担当した Sheldon Pacotti 氏のページでは，この膨大な資料の一部を目にすることができる。

持病の腱炎と闘いながら，口述筆記ソフトを利用して大量の資料を書き綴ったとのことだ。そのバイタリティは驚愕に値すると思う。

しかし，このような大量のドキュメントを用意することによって制作過程を「縛り付ける」方法は，必ずしも有効に働くとは限らない。現に "Deus Ex" の制作においても，この方法が完全な成功を収めたとは言い難いものがあるようだ。

件の記事において Spector 氏は，ゲームのコンセプトに代表されるような「高レベルなデザイン」の決定を重視するがあまりに，いくつかの「低レベルなデザイン」について遅延が生じてしまったことを認めている。また，これらをもっと早い段階において解決していれば，より良いものを作り上げることが可能だっただろうと述べている。

また，必要に応じて増やされていったはずの５００ページものドキュメントは，開発中盤において大幅な見直しが行われ，最終的に２７０ページほどの分量……つまり約半分にまで減らされたしまったとのことだ。何回かの試作を経るうちに，「本当に必要な情報」と「本来は必要でない情報」の区別が付くようになったため，敢えて不要な部分を刈り取る作業を行ったと述べている。

Half-Life の事例においても， Cabal Process によって生み出された大量のドキュメントを利用しているものの，これはあくまでも「フレームワーク」であり，詳細については各自が制作時に決定するものとされている。この場合のドキュメントとは，ゲーム全体としてのコンセプトを取りまとめる「道具」であり，それと同時に，チーム全体としての見解を統一する「媒介」として働く。そうすることによって，文書としては表しきれないような漠然としたビジョンを，全員で共有することが可能になるということだ。

氏の方法論によれば，制作に必要とされるデザインの過程は，「マクロデザイン」 (Macro Design) と「マイクロデザイン」 (Micro Design) の２種類に大別される。「マクロデザイン」とは，ゲームの全容を概観的に定義するものであり，「５ページほどのドキュメントで十分」としている。これに対して「マイクロデザイン」とは，ゲームの細部を定義するものであり，これは実際の制作と並行して進めれば良いとしている。

デザインの過程は２つの要素に分離されます。
それが「マクロデザイン」と「マイクロデザイン」です。
マクロデザインは試作段階において完成させられるものとします。
マイクロデザインは実際の制作に伴って作成していきます。

この方法論は，ゲーム開発における「最も危険な迷信」から生み出されたものです。

迷信：「初期構想は明らかであるほど良い」

これを，次のように言い換えましょう。

迷信：「少なくとも１００ページはないと，私のゲームは記述できない」

これは忘れましょう。ゲームの制作を開始するのにこのようなドキュメントは
必要ありませんし，将来に渡って必要となることは無いでしょう。

このように Cerny 氏は，プロジェクトの初期段階において詳細過ぎるドキュメントを提示することは，単にリソースの無駄であるばかりか，制作過程において悪影響を及ぼすものとして，その害悪を断罪している。そして，このような強い主張を行う背景には，「あらゆるゲームには必ず，実際に制作を始めてみなければ分からない要素が存在する」という，氏の経験に基づいた確信が存在しているようだ。

氏は以前より，一般に「試作」 (pre-production) と呼ばれている工程に対して，もっと重点を置くべきだと主張している。前述のように「実際に制作を始めてみなければ分からない要素」が存在するのであれば，制作に入る以前から細部を決定することは不可能であり，もしそれを無理に行おうとするならば，必ず不幸な結果を招くことになるだろうということだ。またそれは，単に「失敗したデザイン」として残るだけでなく，不要な前提や制約を作り出してしまったり，見解の不一致による「勘違い」 (misleading) 等の現象を引き起こすことになってしまう。

このような失敗を避けて通るには，「デザイン」と「制作」という２つの工程を並行して進める必要性が出てくる。つまり，「デザイン」から始めて「制作」へ流れていくという，古典的なウォーターフォール型の工程管理手法に固執するのではなく，「デザインと制作の反復」というスパイラル型（あるいは「反復型」）の工程管理を意識することによって，両者が単体では決定することの困難な要素を無理なく解決していこうということだ。

Cerny 氏はこれまでの主張に基づき，試作には十分な期間とリソースを注ぎ込む必要があるとしている。そのようにして，「物量を別にすれば極めて完成形に近いバージョン」を作り上げ，この内容なら上手く行くに違い無いという確信と，今後のコンテント制作において指針となるべき「マクロデザイン」を手に入れる。つまり，マクロデザインを完成させるために存在する工程が「試作」なのであると言うことができるかもしれない。

この方法論は，氏が監修を担当した製品 "Jak & Daxter" や "Ratchet & Clank" などにおいて実践が行われている。その実践の様子は， GDC 2003 における Brian Allgeier 氏の講演 "Designing a Ratchet and Clank Level" などにおいて垣間見ることが可能だ。

このようなプロトタイピングの手法は，「後にリスクとなる要素を先に解決しておく」という効用の他に，「制作者間における合意を，実際の作業に先行して実現する」という意味を持っているように思える。これは，例えば「ペーパープロトタイピング」の考え方などにも現れているものだ（利用されるテクノロジに関して大きな差異はあるものの……）。

これらの手法における要点は，デザインという工程を「デザイナが紙の上でアイデアをもてあそぶ」というレベルから分離させ，「全員で顔を突き合わせて，実際に動くものを作ってみる」という過程を経ることによって，「制作者間における合意を実現する」ということにある。あるいは「集団というフィルタを通す過程」と言ってもいいかもしれない。「要求の分析と定義」というような小難しい用語によって表される抽象的な工程ではなく，実際に動くもののイメージを全員で作り上げることによって，それぞれの要求を明確に把握することが可能となるというアイデアだ。

目的はやや異なるものの，文書ではなく実演と共同作業によって分析を行うという点では，オブジェクト設計手法における「ＣＲＣカード」の手法なども，これに近いものがあるかもしれない。

これらの手法において共通する点は，ここで得られる結果（ドキュメント）が意味を持つばかりではなく，こういった過程を経ること自体が重要な意味を持っているということだ。プロトタイピングという工程が，プロダクトに関わる人員……一般業務ならば，それは「クライアント」と「エンジニア」であり，ゲーム制作ならば「デザイナ」と「プログラマ」と「アーティスト」の関係かもしれない……に対して，統一された見解をもたらすための媒介として働いてくれるというわけだ。

Half-Life における Cabal Process も，これに類するものと考えることができると思う。彼らの場合は，実際の制作においてビジョンを見失ってしまったために，敢えて会議室にこもるという手段を選択した。そのような過程を経て得られた確固たる「マクロデザイン」が，彼らを正常な方向へと導くことを可能にしたのだろうと思う。

Cerny 氏の "Method" が他の手法と比較して魅力的なのは，実際に制作を行いながらデザインを決定することができるという点だ。彼らは（もちろん我々も）ゲーム制作者なのだから，ゲームを制作する作業が最も楽しいことには違い無いし，実のところ，会議室にこもるのはあまり好きじゃないはずだ。実際に「モノ」を作っているという充実感は，何にもまして士気を高めるものとなるし，その感覚は大切に育てていくべきものだろうと思う。

ゲーム自体は出来上がってきているはずなのに，それがちっとも面白くならないという事実を認識した Valve Software のメンバーが最初に行ったことは，その「失敗作」の中から，わずかながらも面白いと思える要素をすべて抽出し，それらを１つのステージへと詰め込んでみるという作業だった。そして，少しでも面白くなりそうなアイデアについては，そこから更に派生を導き出してみる。逆に，あまり面白くなさそうなアイデアについては，躊躇することなく刈り取っていく。実装に時間のかかりそうなアイデアについては，十分に簡単な仕組みへと変換して組み込みを行ってみる。そのような作業を，可能な限り繰り返していった。

そうして作り上げられた「ごった煮」のステージは，そのままの状態では決して使いものにならないような代物だ。しかし，そのような過程を経ることは，「自分たちがかつて面白いと考えていたものは何であったのか？」という認識を取り戻す上で，非常に重要な役割を果たすことになったようだ。

……それは素晴らしいものだった。
言うなれば「ダイ・ハード」と「死霊のはらわた」がごっちゃになったような，
まあ，とんでもない代物だ。
しかし，これこそが「ビジョン」だった。
これこそが，我々のゲームとしてあるべきものだった。
それは，バカでかくて，おっかなくて……まだまだ煮詰める必要のあるものだったけれど，
これを見た後となっては，これ以下のもので満足することは決して無いはずだ。
あと，やるべきことと言ったら，これを１００ステージも作るだけのことだ。
大丈夫，問題無い。

その次に行ったことは，ゲームとしての「体験の密度」という要素を認識することだった。つまり，ゲームの進行において，プレイヤの刺激となるもの……例えば，新たな敵の登場や，新たな武器の登場，鮮烈なエフェクト，場面の転換，物語の急転，特殊なアクション，等々……を，時間的な間隔を考慮しつつ配分するというデザインの手法だ。

このように，ゲームプレイの上で刺激を作り出す要素を，ただ意味も無くランダムに配置するのではなく，ゲームの進行と時間的な経過を考慮しながら意図を持って配分していくという作業は，ゲームとしての「テンポ」を作り出す上で非常に重要な役割を果たしているように思える。この配分を上手く行い，プレイヤの期待を裏切らないような進行を実現させれば，おのずと強い「引き」を作り出すことができるはずだ。プレイヤは自然のうちに「もうしばらくすれば，何か楽しくなるに違いない」という期待感を絶え間なく持つようになり，ゲームの中へと強く引き込まれることになる。

これは，ゲームデザインにおいてごく基本的な要素であると言えるものの，これを上手く押さえてあるかどうかによって，ゲームに対する「引きの強さ」が大きく異なってくるように思える。特に，「バイオハザード」や「デビルメイクライ」等に代表されるカプコン系のアドベンチャーゲームには，この点におけるバランスの良さを強く感じることがある。もちろん "Half-Life" も，同じように「引き」の魅力を強く感じるゲームだった。

そして，その次に挙げられているコンセプトは， "Half-Life" においてはあまり認識することのできなかった要素であるものの，後に彼らが目指すことになる方向性を大きく決定付けている要素であるように思える。

次の「理論」は，プレイヤの存在を認識することだった。
つまり，ゲームはプレイヤのアクションを常に受け入れなければならないということだ。

例えば，プレイヤが銃を撃ったとき，ゲームはただ単に効果音を鳴らすだけではなく，
もっと何か恒久的なものを残すことによって，それを受け入れなければならない。
それは，「プレイヤが銃を撃った」という事実を，視覚的に証明するものであるべきなのだ。

「プレイヤが銃を撃つと，壁に穴が空く」なんてのは，とても良い案なのだけれど，
これは技術的な問題とゲーム進行上の問題から実現することができなかった。
我々はその代替として，壁に「デカール」……つまり，弾痕と爆発の跡を残すことによって
プレイヤのアクションを恒久的に表現することにした。

また，例えば，プレイヤが押せそうなものを押した場合，
オブジェクトはそれを無視するのではなく，ちゃんと動くようになっていなければならない。
破壊できそうなものをバールで叩いたならば，それはちゃんと壊れなければならない。
誰か人のいる部屋に侵入したならば，その人はプレイヤを無視してはならない。

つまり，簡潔に表すなら次のようになる：
「ゲームがプレイヤを無視したならば，プレイヤもまたゲームを無視するだろう」

このコンセプトについて "Half-Life" から伝わってくるものは，実のところ，それほど無かった。プリミティブな Quake2 エンジンの枠組みの中で実現可能な要素は相当に限られていたようであり，特に物理挙動の面においては不具合の方が目立つと言っても良いほどだった。例えば，押したはずの箱がガクガク震え出したり，壁に押し付けた箱が宙に浮いてしまったり……というような現象を頻繁に見ることができる。

このコンセプトは，むしろ "Half-Life 2" へと受け継がれたものと考えることができるだろうと思う。なぜストーリー重視のシューターゲームに対して，強力な物理エンジンを組み込む必要性があったのか。また，それによって表現されるべきものとは，一体何であったのか……。その真相と固い決意を，この記事の中から感じ取ることができるように思える。

目の付け所が，こう……いかにもギークっぽいというか，いい感じに怪しげな科学記事ばかりを集めてくるニュースサイトだ。このサイトと Geeknews と ThinkGeek と，あとは jwz's Journal でもチェックしておけば，そのうち立派なギークになれることうけあいだ……なって嬉しいものかどうかは，別として。

今回の ZZZ Online の記事の中でも，特に光っているのが "BirdMan Suit" の話題だ。

ヒレ状の「翼」を取り付けたダイビングスーツを使って，空中を滑空するというものらしい。通常のスカイダイビングと同じように飛行機から飛び降りるのだけれど，落下しつつも揚力を得て飛行するわけだ。この飛行技術を極めれば，崖からのフリーフォールによって滑空することも可能となるらしい。特殊な推進力を一切用いることなく，純粋に翼の揚力のみで飛ぶというのが驚きだ。

特に，崖からのフリーフォールで滑空する姿を撮影したムービーが印象的だ。途中まで普通に落下しているのが，十分な速力を得たところで滑空に切り替わるんだな……。人間がムササビのように滑空する姿は，どこか非現実的で，ちょっと可笑しい。

BirdMan Suit が誕生するに至った経緯については Popular Science の記事に詳しく解説されている。

どうやら，翼の面積をこれ以上大きくすると，人間の腕では強度が足りなくなってしまうとのことだ。このように小さな面積の翼で十分な揚力を得るには，かなり高い速度を保つ必要がある。具体的には時速 100 km 程度の飛行速度が必要とされるようだ。この速度のまま地表に軟着陸することは到底不可能であるため，着陸時にはパラシュートを利用することになるのだけれど，将来的にこれを無くすことが「鳥人間」 (birdman) たちの夢となっているらしい。

同様の原理によって飛行することを試みた人間は，過去に多く存在するものの，つい最近になるまで，その技術を確立することはできなかったようだ。なんと言っても，飛行を試みた７５人の挑戦者のうち，実に７２人が事故によって失命しているというのだから，そもそもこのような発明に挑戦すること自体が命を捨てるようなものだったのだ。

このスーツを開発した Jari Kuosma 氏らのグループは，命がけの実験をひたすら繰り返すことによって，安定した飛行技術を確立することに成功した。強靭な合成繊維を使用した翼の登場と，確実に動作する緊急離脱装置を考案したことにより，この技術は十分な成熟を迎え，今では米国パラシュート協会の正式な認可を受けるほどの製品となっているということだ。

任意の画像から欠落した部分を補完するというアルゴリズムだ。上の図では，左の元画像から，真ん中のマスク画像にある領域を切り取り，そこから補完処理によって再生された画像を右に表示している。いきなり右の画像を見せられても何の違和感も覚えないくらいに，自然な補完がなされている様子が分かると思う。

原理は比較的シンプルだ。基本的には，「ぼかし」を使って欠落した部分を埋めつつ，同じ画像内に「似た部分」を見つけ，それをうまい具合に貼り合わせる……というような処理を繰り返しているだけのことだ。ただ，この「ぼかし」の処理と，「似た部分」を見つける処理に工夫が凝らされており，そのおかげで見た目に違和感の無い自然な画像を生成することが可能となっている。

ただし，結局はイメージベースであるために，どうしても限界は生じてしまう。例えば，立体的な構造を持つ画像を部分的に削除した場合，その構造を無視して補完を行ってしまうため，人間の認識的には違和感のある画像を生み出しやすくなる。同じような理由で「前景」と「背景」という区別も無視してしまうため，物体と背景の間にある境界部分を削除した場合なども，おかしな画像を生み出しやすくなるようだ。

また，構造的な曖昧さを含む画像も苦手な処理対象となる。例えば，２つの物体がクロスしている部分などを削除してしまうと，その構造を解決できないまま曖昧に補完を行ってしまうため，下手な合成の手際のように「ぐちゃぐちゃっ」とした画像が出来上がってしまう。

そのような些細な問題はさておき，最も大きな問題として存在しているのが，その基本的な演算量の多さだ。上の図にある画像は 384x256 の解像度を持っているのだけれど，この画像の補完処理を行うのに 150 分以上の時間がかけられている。ううむ……これはちょっと，あまり「実用的」な速度とは言い難いものがあるのではないかと思う。

補完に用いられる処理のうち，最も重い負荷となるのは，「似た画像」を探す評価過程にあるようだ。回転や拡縮を行いつつあらゆる可能性を試行するため，画像の面積が増えれば増えるほど，演算量も飛躍的に増えてしまう。上の画像の半分の解像度である 192x128 の画像では，数百秒程度で処理を完了することができるということだから，逆に解像度を増やす方向に持っていけば，とんでもない時間が費やされることは間違い無い。

以上のような制約が残されているために，この技術をそのまま実用に持ち込むことは難しいように思える。小さな範囲について補完を施すならまだしも，高い解像度の画像の広範囲をカバーするには，処理速度の面でかなりの改善を行うことが必須だ。

それでも，このような機能がフォトショップなどに積まれればとても面白いと思うし，そうすることによって誰でも気軽に高品質な合成作業を行うことが可能となるはずだ。また，合成作業の自動化が可能となることから，様々な応用を生み出すことになるだろうと思う。そう言った意味で言えば，将来的なアプリケーションへの応用が期待される技術の１つなのではないかと思う。

Bloggers

Game Object System (1)

Game Object System (2)

Game Object System (3)

Game Object System (4)

Game Object System (5)

Silent Hill 3

Jude

Solid Software Engineering for Games (1)

Solid Software Engineering for Games (2)

Solid Software Engineering for Games (3)

Solid Software Engineering for Games (4)

HowStuffWorks

In Seven Weeks

Design by Concensus (1)

Design by Consensus (2)

Design by Consensus (3)

Design Documents (1)

Design Documents (2)

Design Documents (3)

起死回生の過程

BirdMan Suit

Fragment-Based Image Completion