Radium Software Development

このとき，もう１つ参考にした資料がある。マサチューセッツ大学の助教授 Emery Berger 氏の一連の研究だ。

Berger 氏はソフトウェアシステム関連の研究を主に行っており，その研究の副産物としていくつかのメモリ管理ライブラリを制作している。その中でも特に有名なのが，高性能メモリアロケータ "Hoard" だ。

今回はパフォーマンスの追求が目的ではないので，敢えて Hoard の存在は無視するとして……面白かったのは，氏の論文 "Reconsidering Custom Memory Allocation" だ。

PowerPoint によるプレゼンテーション資料も用意されている。

氏は論文の中で，カスタムアロケータの必要性を説きつつ，メジャーな幾つかのソフトウェアに搭載されているカスタムアロケータについて評価を行っている。評価方法としては，アルゴリズムの解析を行うほか，メモリ効率の評価や，ベンチマークを走らせての厳密なパフォーマンスの比較などを行っている。

ここでちょっと面白いのは，多くのアプリケーションにおいて Lea allocator (Doug Lea の "dlmalloc") がカスタムアロケータとほぼ同等のパフォーマンスを叩き出していることだ。例外的に Lea allocator が負けているのは，カスタムアロケータが "region memory" と呼ばれる特殊な方式を利用している場合に限定されている。

このことからも，単にパフォーマンスを重視する場合には，とりあえず Lea allocator を選択しておくのが良いということが実証されている。

従って，単純な malloc / free の置換を用意したいのであれば，迷わず Lea allocator を選択すべきなのだろうと思う。問題となるのは，それ以上の特殊な機能性……例えば，断片化への対処や，ガベッジコレクションや，隙間の詰め込み（コンパクション）や，限界までの速度追求など……が求められている場合だ。

Tofte 氏の仮定するコンパイラ（ちなみに ML 言語による実装が存在する）では，入力されたコードに対して静的な解析を行い，個々のオブジェクトに対する "region" を推論によって求める。この "region" から外れたオブジェクトは，到達可能 (reachable) である無しに関わらず破棄される。これは，スタックに似た構造と考えることもできるし，開放手段の無い（一括開放しかできない）ヒープと考えることもできる。

元はコンパイラが行うコード解析のために編み出された方法であるものの，このスタイルを利用したメモリアロケータを設計することもできる。このような region 方式のアロケータでは，個々のブロックの開放を考慮しなくてよいため，メモリの消費効率が大変良く（ブロック毎にタグを設ける必要が無い），動作も考えうる限りで速く（ポインタを前進させるだけで良い），断片化の危険性も無い。また，確保された領域は一括で開放が行われるため，メモリリークを心配する必要も無くなる。

region 方式のアロケータにはこのような特徴があるため，高速なメモリ確保を必要とするソフトウェアや，安定性を重視するサーバーアプリケーションなどでは，この方式が用いられることがあるようだ。代表的なアプリケーションとしては gcc や apache などを挙げることができる。

Emery Berger 氏は，件の論文 "Reconsidering Custom Memory Allocation" において "reap" と呼ばれるメモリ管理方式を提案している。これは，"region" と "heap" の合成語であり，まさに両者の機能を掛け合わせた内容のものとなっている。

region 方式の最大の弱点は，一旦確保した領域を開放することができないということだ。この制限は，各種応用における汎用性を著しく低下させている。ならば，開放の機能を付けてしまえば良いではないか……というのが "reap" のコンセプトであり，ヒープのように個々のメモリブロックを開放することができ，なおかつ，region のように一括での開放を行うこともできるようになっている。

reap では，メモリブロックの開放が発行されるまでは，一般的な region 方式と同じような動作が行われる。そして，一度でも開放が行われると，その開放された領域はヒープ領域として確保され，そこが消費されるまではヒープ的な動作が行われることになる。こうすることによって，region と heap の両者の機能を取り入れることができるようになっている。

region 的な扱いをするアプリケーションであれば，region 並みの速度を保つことができるし，そうでないアプリケーションでも，十分な機能性とそれなりの動作速度を提供することができる。両者のニーズに合致したオールマイティ的なアロケータとなっているわけだ。

このように reap 方式は面白そうな仕組みを持っているものの，肝心のライブラリは LGPL ベースで配布されているため，これをプロダクトにおいてそのまま利用することは考えられない。

興味深いのは，region 方式をベースとしたカスタムアロケータが，意外と多くのアプリケーションにおいて利用されているという事実だ。その多くは動作速度の高さを評価して採用しているようなのだけれど，これを断片化やリークを防ぐ目的で利用するのもアリだろうと思う。

比較的小規模なメモリブロックに関しては，普通にヒープ方式を用いるのが良いだろうと思う。問題となるのは，断片化が問題となるほどの大きなサイズを持つメモリブロックについてだ。これらのメモリブロックに関しては，スタックや region のような制限の強いメモリ管理方式を適用することによって，常に動作を予測可能な範囲に留めておくことが必要とされるのではないかと思う。

TGS 以来，職場で話題になっていたので，自腹で購入してプレイしてみた次第だ。

このゲームをプレイしていて圧倒されるのは，何と言ってもリアルタイムアニメーションのクオリティの高さだ。いわゆる超必殺技に相当する「奥義技」を発動すると，ＦＦの魔法発動シーンのような短いカットシーン・アニメが挿入されるのだけれど（この間にコマンド入力あり），このカットシーンの演出が非常に練られており，戦闘を盛り上げる役目を見事に果たしている。

更に驚くのは，ただ単に質が高いだけでなく，同時に恐ろしいほどの量を揃えてきていることだ。ゲームに登場する１２人のキャラクタには，それぞれ３つのユニークな奥義技が用意されており，しかもそれらの奥義技には２つから４つの「段階」が用意されている。およそ１つの奥義技に対して平均で 2.5 個の段階が用意されていると仮定すると…… 12 x 3 x 2.5 = 90 個のカットシーンということになるのかな……。けっこう鼻血が出そうな分量だ。

これほどの量のカットシーンを，あのクオリティと，あの人数（アニメーション班は１０人程度で構成されているようだ）で仕上げるとなると，かなりの気合と技術が必要とされるだろうと思う。

これらの演出の中でも，特に優れていると感じられるのが，「動き」の表現の豊かさだ。実は僕も，スクリーンショットを見た時点では，「面白いシェーディングをしているな」という程度の感想しか持っておらず，さほど注目もしていなかった。多くの人も同様の感想を持っていたことだと思う。しかし，製品上での「動き」を一度でも観てみれば，その考えはたちまちにして変わるはずだ。誰もが一目見て「凄い」と感じられる演出を，このゲームは作り出してきている。

僕はアニメの演出技法には詳しくないので，この「動き」が，いわゆるリミテッドアニメで言う所の「動き」の表現と同種のものであるかどうかは分からない。ただ，自在なカメラワークから生み出される躍動感などは，「アニメ」とも「漫画」とも「映画」とも違う次元の表現なのだろうと考えている。

特に印象的なのは，ダイナミックなカメラワークと，個気味よく挿入されるモーションブラーや効果線などから生み出される，強烈なまでの「スピード感」の存在だ。個々のエフェクトを見てみれば比較的シンプルなものから構成されているにも関わらず，全体としての「タイミングの良さ」が演出に迫力を与えており，弛むことの無い「気持ち良さ」をプレイヤーに叩きつけてくる。

しかも，これらのカットシーンには DVD 読み込みによる遅延がまったく存在しない。恐らく，音声とのマルチストリーミングを行っているか，あるいはすべてのデータを常駐しているか，そのどちらかだと思うのだけれど……いずれにしろ，メモリ容量的にはきつい制限が課せられるわけで，その制限の中で演出を作り上げなければならないという命題が与えられているわけだ。

背景をグラデーションによって簡素化したり，一部の素材を共有したりというような節約はなされているのだけれど，それでも，特定のカットシーンにしか登場しないキャラクタが存在したり，ユニークなエフェクトが存在したりというように，ほとんど制限を感じさせないような内容となっている。

こういった厳しい制限が課せられている場合，破綻を恐れて内容的な妥協を行ってしまうことが多いと思うのだけれど，そこで制限を恐れることなく，果敢にもギリギリの線を攻め続け，しかもそれを成功させているということは，とても素晴らしいことだと思う。

InfoPath のようなソフトウェアのことを何と呼んだらいいのか，僕にはよく分からない。個人的な印象を言うならば，これは XML のための統合環境だ。GUI ベースでスキーマを設計し，入力用のフォームをデザインし，その中で実際にデータの入力を行い，最後に文書化までを行ってしまう。複雑怪奇な XML Schema の構文を覚える必要はまったく無いし，XML データの実体に対して直に触れることも無い。今まで小難しく感じられていた XML の概念が，すべてテーブルとテキストボックスのインタフェースに取って代わってしまった。これは，口で表す以上に素晴らしいことだと思う。

懸念していたスキーマやフォームの設計に関する機能は，予想していたよりも遥かに充実しているかもしれない。スキーマの定義されていないデタラメな XML データを突っ込んでも，ちゃんと構造を解析して，そこから適当にスキーマを捻り出してしまう。僕らのように最低限のスキーマや DTD さえも定義せずに，ただ単に well-formed な XML を "XML" と偽ってたクチにとっては，これはとても有難い機能だ。これで，貧民からボヘミアンを飛び越して，一気に貴族の世界へと突入することができるに違いない（本当？）。

そんなわけで，今後の制作において InfoPath は Excel と並ぶデータ管理の強力な一手段となるだろうと思う。この際だから「できる InfoPath」でも買おうかね。まだ出てないけど……。

用があったのは比較的古い論文だったのだけれど，ついでに最近の論文も漁ってみたところ，何やら面白そうなものが揃っていて興味を惹かれることになった。

例えば，こんな論文がある…… "Interactive Navigation in Complex Environments Using Path Planning" ……複雑なモデルに対するナビゲーションデータを自動生成する手法について述べたものだ。

原理は意外と単純で，モデルに対してランダムに点を打ちまくり，それらの点を一定の規則に従って接続していくというだけのものだ。あとは，点の打ち方やら，接続の規則やらに工夫がなされている。論文を執筆した Brian Salomon 氏らは，実際にこのアルゴリズムを利用したウォークスルー・プログラムを作成し，パフォーマンスの計測やカバレッジの検証などを行っている。その結果によれば，約千二百万個のポリゴンから構成された "Power Plant" モデルに対して，14 時間の処理で 88% のカバレッジを叩き出している。この複雑度での自動生成処理ともなると，ハングアップしなかっただけでも見上げたものかもしれない……。

この手法のように，確率的なアルゴリズムによって大域的なナビゲーションデータの生成を行う手法のことを "Probabilistic Roadmap Method" (PRM) と呼ぶようだ。上の検証において利用されている "Power Plant" のように，複雑度が極端に高く，かつ自由度の高い条件下においては，解析的な手法によって自動生成処理を行うことがほぼ不可能となる。そのため，どうしても確率的な手法を導入せざるを得ないという事情があるようだ。

しかし，一般的なアクションゲームのように比較的単純な構造を持つモデルであれば，不安定性を内包する確率的手法よりも，確実なカバレッジを保証する解析的手法を検討してみた方が良いかもしれない。ううむ……。

そもそも難しいのは，「ナビゲーションデータの生成プロセスを自動化すべきかどうか？」という問題だ。ナビゲーションはＡＩの挙動を大きく左右してしまう要素であるだけに，下手をすると本来の意図通りの動作を行わなくなってしまう危険性がある。例えば，ステージの構成にちょっと手を加えただけでナビゲーションデータが大きく変化してしまい，ＡＩが目的地まで辿り着けなくなってしまったり，何も無い所で右往左往を始めてしまったり……などというシチュエーションだ。

この問題は，「コリジョンモデルを自動生成すべきかどうか？」という問題と似た性質を持っているように思える。ゲームデザイン上の諸問題を突き詰めていくと，「必ずしも『見た目』と衝突判定が一致していた方が良いとは限らない」という結論に達することがある。アクションゲームの類は特にそうだ。操作性と安定性を改善する目的で，意図的にコリジョンを簡略化したり，削ったり，膨らませたり……などというような小手先の改造を施すことがある。

プロセスの自動化によるコストの削減は見逃せない要素だけれど，自動生成が意図せぬ挙動を導いてしまうのも怖い。さて，どうしたものか？

これは，物理やＡＩに共通して言えることなのだけれど，固定的なシーケンスではない「演算による不規則性・偶発性」を高めれば高めるほど，その挙動に対してデザイン上の意図を含ませることが難しくなる。そして同時に，デバッグの工程も非常に困難なものとなる。特に後者はプログラマにとって悩ましい問題だ。

今まであまり調べたことが無かったのだけれど，もしかしたら，ロボット工学の "Motion Planning" の分野には，ＡＩのナビゲーションに関連するヒントが多数存在するのかもしれない。

ちなみに "Motion Planning" という用語には「動作計画」という訳語が当てられているようだ。なんと言うか，あまりにも味気ない訳語だと思う……。

"Flexbot" は，Half-Life 上で動作する bot 開発用のフレームワーク・ライブラリだ。同大学において研究補助員を勤める Aaron Khoo 氏の指導のもと，複数の学部生の手によって制作が行われた。

詳細については IEEE Intelligent Systems の Interactive Entertainment 特集号に寄稿された記事 "Applying Inexpensive AI Techniques to Computer Games" が読みやすくて良いと思う。

この記事において Aaron 氏は，Flexbot フレームワークをベースとした bot システム "Groo" と，仮想チャットＡＩシステム "tt14m" (trash-talking 14-years-old moron) の，２つのシステムに関して，基本的なアーキテクチャの解説を行っている。この "Groo" と，その前身である "Ledgewalker" に関しては，他にもいくつかの論文を同サイトにおいて見つけることができる。

Flexbot は Half-Life 用の bot を作成するためのフレームワーク・ライブラリだ。Half-Life の mod 用 SDK を直接叩くことなく，「センサ」や「アクチュエータ」等の高レベルなインタフェースを利用して bot を設計することができるようになっている。

このフレームワークは，何人かの学生の研究テーマにおいて実際に利用されているほか，ロボット工学関連の講義における教材としても利用されているようだ。

Flexbot サイトの "downloads" ページでは，上の講義において生徒が実際に作成した bot をダウンロードすることができる。例えば，「デスマッチ課題」において優秀な成績を収めた Joe Woods 氏の bot のソースコードは，次のような内容となっている。

このソースコードを見れば分かるように，Flexbot では Lisp に似た組み込み言語が利用されている。この言語の正体は，同大学助教授の Ian Horswill 氏がロボット制御の研究用途に開発した GRL (Generic Robot Language) と呼ばれる言語であり，正しくは Scehme をベースとしてロボット制御用の拡張を施した関数型言語であるようだ。

このような特殊な組み込み言語を利用する理由は，氏らのバックグラウンドを有効に活用するため，というのが最も大きいものだろうと思う。実際のところ，ＡＩやロボット制御の分野においては，Lisp や Prolog をはじめとする関数型言語を利用する研究者が圧倒的多数を占めているようだ。

Flexbot の特徴は，「振る舞い」 (behavior) をベースとしたシステムを利用していることだ。この「振る舞いベースシステム」 (behavior based system) と呼ばれる手法では，ＡＩ処理は「振る舞い」と呼ばれる細かな処理単位へと分解される。それらの「振る舞い」が並列にいくつも実行され，その挙動が組み合わされることによって，全体としての動作が生み出されるようになっている。

例えば "Groo" におけるＡＩ処理は，移動処理を担当する "Movement Behavior" と，その他の８つの振る舞い…… "pitch", "shoot", "fire secondary", "jump", "switch weapon", "reload", "duck", "use" ……へと分解される。これらの振る舞いは全て独立したコンテキストを持っており，例えば "reload" を行いながら "jump" しつつ敵を追いかける (movement) ……などという挙動を容易に行うことが可能となっている。

この，それぞれの「振る舞い」の処理は，単純な FSM (finite state machine) によって構成されるほどシンプルなものであり，それゆえに処理効率に優れているというのが，このシステムにおける基本的な特徴となっているようだ。

特にこの "Groo" は，振る舞いベースシステムの極端な例として指摘することができるかもしれない。基本的に全ての挙動が「振る舞い」によって制御されているためだ。驚くことに，基本的なパス探索アルゴリズムさえも実装されておらず，ナビゲーションもすべて「振る舞い」によって制御されているということだ。

このような極端さは，ロボット工学上の観点から評価すれば何らかの利点が見られるのかもしれないけれど，少なくとも僕にとっては無謀な設計のように思えてならない。このように，各個の「振る舞い」の独立性が高いシステムは，逆に「統合性」に劣ると考えられるためだ。全体としての統合された挙動をデザインすることが難しいと，「見た目に不自然さの感じられない動き」を作り出すことや，動きに対して有機的な「表情」や「思慮」の要素を与えることが難しくなってしまう。その点を真っ先に危惧してしまうわけだ。

余談だけれど，この Zubek 氏の研究も，微妙にゲームＡＩ方面に寄っている部分が見られて面白い。後で目を通してみようと思う。

この記事とほぼ同じ内容が，氏の AAAI (American Association for Artificial Intelligence) の論文 "Making the Human Care: On Building Engaging Bots" にも述べられている。こちらの方が多少詳しい内容となっている。

自然言語をベースとした人間的な会話をＡＩによってシミュレートすることは非常に難しい問題だ。しかし，一般的な会話ではなく，ある種の条件が加えられた会話であれば，十分に機能するものを実装することができるかもしれない。Zubek 氏は，オンラインゲームにおける会話内容には，ある種の「特質」が見られることを分析し，これを次のようにまとめている。

一般的に言って，これらのゲームにおけるオンライン上の会話は，内容が浅く，かつ漠然
としている。会話の内容は IRC におけるそれに似通っており，次のような性質を見つける
ことができる。

＊断続性 − 話題が頻繁に変更されるため，「誰が誰に向かって何を話していたか？」
   などということは，すぐに見失われてしまう。

＊多層性 − １人の人間が同時に複数の「スレッド」に加わるというような状況は決して
   珍しく無い。逆に言えば，ある会話に対して返答を行っている間に，別の会話の内容を
   見失ってしまうこともあり得る。

＊間違ったスペリング，劣悪な文法，粗野な言葉遣い，等々によって埋め尽くされている。

＊ステロタイプ（紋切り型）人格が非常に豊富である。例えば，自慢屋 (boaster) や，
   負け際の悪い人 (sore loser), 好色家 ("are you a chick?" lecher), 等々。

これらの特徴を活かせば，十分に簡単なテキスト処理だけで人間を騙すことが可能かもしれない。そういったコンセプトの元で実験的に制作されたのが "tt14m" システムであり，文字通り「アホな１４歳のダベり」をシミュレートしたというわけだ。

tt14m の実装は，一般的に "Eliza" と呼ばれている会話システム……つまり，いわゆる「人工無能」を利用している。ターゲットのゲームとしては，（当時の）プレイヤー人口の多さから "Counter-Strike" を選択し，bot としてのメイン処理には既存のシステムである "TEAMbot" を利用している。

氏らは，実際にこのシステムを組み込んだサーバをインターネットへ接続し，１６人中８人をＡＩ設定として開放した。そこで氏らは，このシステムがどの程度人間を騙すことができるか，という点を調べようとしたわけだ。結果としては，なかなか興味深いものが得られていると思う。例えば，下のような会話例が挙げられている。

この会話では，(a) と (b) が bot の発言であり，それ以外は人間から発されたものとなっている。ＡＩ同士が何となく会話のようなものを交わしており，それに対して人間が反応を起こす，という一連の「流れ」が形成されているのが分かる。

Zubek 氏らが実験を通して確認しようとしていたのは，「強化版人工無能」のようなシンプルなシステムが，どの程度の間，人間を騙し続けることができるか，という点であったとしている。結果として，多くの人はそこそこ長く騙されていたとしているものの，場合によっては，驚くほど素早くＡＩの存在を見抜かれることがあったと述べている。

プレイヤーにＡＩの存在を見抜かれる理由として最も大きなものは，tt14m の持つ「精神分裂性」によるものだとしている。これは，ＡＩが会話の「流れ」を全く考慮せずに，話題を頻繁に変更してしまうため，人に違和感を覚えさせてしまうというものだ。これを克服するには，単純な単語検索やアクションをトリガーとする人工無能システムではなく，もう少し「話題の冗長性」というものを加味したシステムを設計しなければならない。

もうの１つ要因として挙げられているのは，単純な文体の問題だ。例えば，人間同士はフルネームで呼び合うことが滅多に無いのに対して，ＡＩは設定されたフルネームを馬鹿正直に利用してしまう。人間ならば，"Robzilla" は "Rob" と呼ぶだろうし，"Dr-Azrael" は "Az" と呼ぶだろう。わざわざフルネームを使うのは何だか堅苦しいし，だいいちタイプが面倒くさい。それが "@Zbk@$hooter!" なんて名前になったら，正しくタイピングするだけでも一苦労なわけだけれど，ＡＩはその辺りの事情を全く考慮せずに，単純に引用を行ってしまう。この辺りの問題を，人間に対して違和感を覚えさせないよう解決するには，相当に慎重な言語処理を行う必要がありそうだ。

他の技術的な問題として，回線速度 (ping / roundtrip) の表示が異常になってしまうことや，bot の動作自体に問題が含まれることなどが挙げられているものの，これらの問題は会話処理という目的からは分離された問題として解決することが可能だと思う。

論文と実験の内容は「bot によって人間を騙す」という所に焦点が当てられているものの，Zubek 氏が問題の本質として着目しているのは，「NPC に対して『社交性』の能力を持たす」という点だ。常に決まりきった会話を起こすだけの NPC では無く，状況や前後の流れに応じて的確な内容を生成し，プレイヤーの情緒に訴えかけるような会話を起こす NPC を作り出すことができれば，きっとゲームは楽しくなるに違いない……その点に注目するならば，この実験は「単に人工無能を bot に組み込んだ」という以上の価値を持つものになるかもしれないと思う。

Fristrom 氏のざっくばらんな調子と，率直な物言い，常に現実的な視点や，豊富な知識に基づいた言葉の重さなど，エッセイとして楽しく，かつ頼もしいものとなっていると思う。

そんな Fristrom 氏が，最近，自身のブログの中で触れていたゲームがある。Activision / Luxaflux の最新タイトル "True Crime: Streets of LA" だ。

ゲームの内容は，何となくタイトルから想像することができるかもしれない……要するに GTA3 の二番煎じ的タイトルだ。プレイヤーは拳銃等の武器を持って車に乗り，実際の LA をモデルとした街の中を駆け回って，その中で繰り広げられる様々な出来事を体験していく。

しかし，"GTA" とは決定的に異なる点が１つだけ存在する。それは，主人公が警官であること……つまり，「犯罪ゲーム」ではなく，本当は「正義のゲーム」であるということだ。

Fristrom 氏は，Jack Trout 氏の著作 "Differentiate or Die" （邦題：「ユニーク・ポジショニング」）から，次のようなコンセプトを引用している……もし己が，キラー的な属性を持つトップブランドで無いのならば，むしろその属性の「逆」を目指すようにしなければならない。トップブランドと正面から渡り合うのではなく，逆の方面を攻めることによって差別化を行い，生き残りの道を見出すという戦略だ。

ならば，今やトップブランドとしての地位を確立した "GTA" の「逆」とはなんだろうか……そこから導き出される答えは，「犯罪」の逆，つまり「正義の行使」にあるだろう。それが Fristrom 氏の「読み」だ。

これは，単純な思いつき以上に良いアイデアかもしれない。例えば，漠然と "GTA" のような「車と街と銃の出てくるゲーム」をプレイしたいと考えて店に来た客に対して，新たな注目を喚起することができる。ここで「どのゲームが犯罪ゲームとして優れているか？」という評価を行わせては，多くの人は知名度から "GTA" を選んでしまうに違いない（いきなり "Carmageddon" を選ぶ確率は恐ろしく低いだろう）。しかし，"True Crime" はここで差別化を行っているが故に，顧客の評価を異なった方向へと導く可能性を秘めている。「犯罪ゲームとしての優劣」では無い。「悪玉」になりたいか，あるいは「善玉」になりたいか，だ。

Fristrom 氏は，アメリカの一般的な消費者の多くが，単純な「善玉」よりもむしろ「悪玉」の方を好むという事実を認めてはいる。しかしそれでもなおかつ，確実に一定の割合の人が「善玉」を好むという事実も指摘している。比較論で言ってしまえば劣っているものの，確実な量の「牌」がそこには存在している。

"GTA" を「犯罪的なゲームだから」と言う理由で嫌うアメリカ人も中には居るし，子を持つ親の多くは，自分の子供が犯罪者に育つよりかは警察官になって欲しいと思うだろう。それに，「正義を行使するゲーム」であれば，あとは一部の表現さえ気を遣えば "T" （ティーンエイジ向け）のレーティングを得ることができるかもしれない。Wal-Mart や ToysRus などの大型量販店は，基本的に "M" レート（成人向け）の商品を扱わない方針になっているから，これは流通において大きなアドバンテージとなり得るわけだ。

しかし，ここで Activision は大きなミスを犯してしまっている。ゲーム内容に対して間違った印象を与えるような名称を付けてしまったのだ。"True Crime" ……「真の犯罪」と聞いて，善行を施すゲーム内容を思い浮かべる人はまず居ないはずだ。ここで，「ユニークな属性を与え，差別化を行う」という試みはスポイルされてしまい，"GTA" および他の同種タイトルと同じ土俵で戦う存在へと成り下がってしまっている。

商品の名称がマーケティング的に重要な役割を果たすという事実に対して，Fristrom 氏は以前から注意を喚起していた。

ここで氏は，Jessica Lewis 氏の Gamasutra 記事 "The Sims Online Evolution: A Case Study" を引用し，「命名の失敗」がマーケティングにおいて深刻な問題を引き起こした具体例を指摘している。

ユーザからのフィードバックが直接的に影響を与えた１つの例は，ゲームの価格設定に関
する戦略だ。"The Sims Online" の発売時の価格は $49.99 だったのが，８週間後には
$29.99 にまで下げられている。このような値下げ戦略をとった理由は，"Sims" のプレイ
ヤーおよび「潜在的プレイヤー層」が，このゲームの価値を正確に理解していないという
ことにある。人々は店頭に $29.99 から $39.99 程度の "Sims" 製品が並べられているの
に慣れてしまっていた。そこで "The Sims Online" の箱に $49.99 の値札が貼られている
のを見て，安い方の Sims 拡張パックに手を伸ばしてしまうというわけだ。

Fristrom 氏は，Al Ries 氏の著作 "Positioning" を引用し，次のように述べている……「人々は愚かであると考えなくてはならない。異なった製品を似た名前で出せば，顧客は必ず混乱してしまう。」，「路線の拡大を行ってはならない。完成されたプロダクトから顧客を吸い上げるべきだ」，等々……。

これ以上複雑なマーケティング上の問題については，僕にはとても分からないし，恐らく Fristrom 氏にも分かっていないことが多いだろうと思う。マーケティングはマーケティング専門の担当者を信頼し，それに任せるというのが基本的な考え方だ。しかし，製品の特色を正しく理解し，効果的なマーケティングを展開するには，制作側とマーケティング側の密な協力体制を欠かすことができない。そこに人間的な不信やセクショナリズムが発生しては決してならないし，願わくば，そんな問題が発生しうるような環境が存在しないことを望む。

この推論が正しいと証明する唯一の方法は，誰かが「法の行使」をテーマとしたゲームを
開発し，正しいマーケティングを行い，同じような額をマーケティングに費やすことだと
思う。もし，その製品が "True Crime" よりも売れたなら，僕の勝ちだ。そして僕はプロ
グラマからマーケティングへキャリアを移すだろう。もし売れなかったならば，僕は今ま
で通り塹壕の中に残って，自分の口を閉じ続けるというわけだ。

氏の書くエッセイは，まさに「塹壕の中の一兵士の叫び声」を連想させるものだと，僕は考えている。その中には有用な情報もあれば，ただ空に発されただけのぼやき声もある。しかし，少なくとも，同じような塹壕の中に篭っている僕にとっては親近感を覚えさせるものだし，誰もなかなか教えてくれない「戦場で少しでも長く生き残る方法」をこっそりと教えてくれる。それは決して，戦局を大きく左右させるような策ではないかもしれない。しかし，「どんな技術やコンセプトも，限られた予算と時間の中で確実に完結させなければ，話にならない」という基本的な事実を，たまに思い起こさせてくれるわけだ。

"Band of Brothers" は，第二次世界大戦を舞台としたＴＶドラマだ。題名の通り「男たちの絆」をテーマとし，欧州戦線を奮闘したエリート部隊「１０１空挺師団Ｅ中隊」の活躍を描いている。スピルバーグとトム・ハンクスのタッグというと，映画「プライベート・ライアン」を連想するのだけれど，まさにあの映画のスケールとクオリティで１０時間以上ものＴＶシリーズを制作した，というのがこの作品の分かりやすい説明だ。

斜に構えてみれば，あからさまな国威発揚映画なのだけれど，やはり金がかかっているだけあってクオリティは異様に高いし，大衆性を狙っているためかテーマがとても分かりやすく作られている。小難しい理屈付けを必要とされるベトナムものなんかよりも，ずっと単純に楽しむことができるはずだ。要するに大河ドラマのノリに近いかもしれない。派手な戦闘シーンに興奮し，兵士達の不屈の精神に励まされ，友情や悲哀の描写に涙する……そんな感じの「型にはまった」タイプのドラマだと思う。

一応，実在した有名な部隊と，そこに実際に所属していた人達を登場人物として扱っているようだ。上のサイトにある「コンパニオンガイド」と併せて観るのが，より深く楽しむコツだと思う。

今から１ヶ月ぐらい前のこと，海外のゲーム通販サイト "EB Games" に "Namco 5 in 1 TV Games" を注文したのだけれど，いまだに何の応答をよこしてくれない。ううむ……あまりにも音沙汰が無いので，自分でも注文したのを忘れかけているところだった。

"Namco 5 in 1 TV Games" は，"Atari 10 in 1" や "Activision 10 in 1" を世に放った JakksPacific (Toymax) が新たに放つポータブルゲームシステム第３弾だ。片手に乗る大きさのジョイスティック風の筐体の中に，ＴＶゲームシステム一式と，往年のナムコの名作ゲームが５つ搭載されている。これをＴＶに繋ぐだけで，即座にゲームを楽しむことができるという愉快な電子ガジェットだ。

何やら楽しそうなオモチャだったので，半分ネタのつもりで注文したんだけれど，一向に出荷される素振りが見られない。よく事情は分からないのだけれど，どうやらクレジットの認証やら決済やらに手間取っているようだ。そもそも，EB Games ってサイト自体が，国外への配送に対して積極的な態度をとっていないように見える……ちょっと失敗したかもしれない。

値段で言えば Wal-Mart の方がずっと安いのだけれど，残念ながら Wal-Mart は国外への販売を一切行っていない。Amazon 等のネット通販サイトのサービスの良さに慣れてしまって，国境の壁をほとんど意識しなくなってしまったものの，そういった店は全体から見れば少数派であるわけだ。まあ，当たり前と言えば当たり前なのだけれど……。

頼みの綱の ThinkGeek も，なぜかこの商品の取り扱いは行っていない。なんでかなあ……。

……とか思っていたら，今度は別の怪しげ商品を仕入れていた。"Power Joy III Retro Arcade Game System" だ。

うーむ。これは怪しい……色々と体のいいことが書いてあるのだけれど，要するに単なる "64 in 1" なんでないかな，と思う。ライセンスはちゃんと取得しているんだろうか……どうにも怪しいところだ。

個人的に気になるタイトルなので，とりあえず Game Rankings でのスコアを調べてみたところ，94 点という得点が付けられていた。

ちなみに，前作のスコアは 89 点だった。また，雑誌等の情報によれば，ゲームの全体的なボリュームも，前作と比較して約 1.5 倍にまでスケールアップされていると聞く。このような伝聞を元にする限りでは，クオリティとボリュームの両面において着実な進化を遂げてきているような感触が伝わってくる。

しかし，個人的に最も脅威に感じているのは，これほどの大作を１年もかけずに完成させ，確実に商戦時期へと投入してきたという事実だ。

前作 "Ratchet & Clank" の北米版は，2002 年の 11 月 5 日に発売された。また「本体同梱パック」として売り出された日本国内版は，約１ヶ月遅れの 12 月 3 日に発売されている。もし仮に，この 12 月 3 日の時点で前作の仕事が完了したと設定し，そこから今作 "Ratchet 2" の開発に着手したと考えるならば，発売まで実に１年も残されていないという計算になる。しかも，マスターアップから出荷までの工程や，その他諸々のマージンを考慮すると，正味で１０ヶ月程度しかないというのが妥当な勘定だろうと思う。Ted Price 氏が Gamasutra に "Ratchet 1" の Postmortem を寄稿していたのがつい先日のように感じられるぐらいだ。

"Ratchet & Clank" シリーズの開発元である Insomniac Games は，PlayStation の "Spyro the Dragon" を開発していた頃も，年に１本のペースで次々と続編を出すという芸当を行っていた経歴がある。今回もそのノリなのだろうけども，１本当たりの制作コストが上昇し続けているにも関わらず，このようなハイペースを保ち続けられていることに驚きを覚える。

"Ratchet 2" の公開済みの情報から想像を行う限りでは，基本的なゲームデザインに対しての変更はそれほど行われていないように思える。いわゆる正統進化系の続編だ。このような作り方ならば，前作の制作過程において蓄積されたノウハウとリソースを活用することによって，効率良く制作を行うことができそうに思えるのだけれど，実際にはそう簡単な話でもないかもしれない。なぜなら，「古い物を暖め直す」ことは，「新しい物に手を付ける」よりも，ずっと難しい行為だからだ。

ちょっとでも経験を積んだプログラマならば，過去に書かれたコードの山を目にしたときに，それらを全てうっちゃって，１からコードを書き直したいという衝動に駆られることがあるのではないかと思う。このような判断が頭をよぎったときに，まず行うべき行為は，そのコードに対して費やされた労力を振り返ってみることだ。もし，それでもなお書き直した方が良いと感じるほどに酷いものであったならば，思い切って書き直してみるべきかもしれない。しかし，一般論を言うならば，このような「白紙への帰着」は，「行うべきではない行為」の１つとして挙げられるものだ。

アーティストだって，１年前の自分が描いた絵よりも，今の自分が書き直したものの方が冴えていると感じることがあるかもしれないし，ゲームデザイナも同様に，古いコンセプトを捨てて新たな挑戦へと取り組みたいと考えることがあるだろうと思う。

しかし，その「白紙への帰着」が，本当に必要な過程であるかどうか判断することは，とても難しい作業だと思う。その「既存の物」に対して手を加える行為が，あまりにも泥臭く感じられるが故に，新たに作り直す方が良くなるに違いないと錯覚してしまうことがあるわけだ。

ひとたび制作者の下から生み出された創造物の原形は，当初は鋭い輝きを放っていても，時を経て形を固めていくとともに，その輝きを失ってしまうことがある。この後退現象は，単なる「飽き」からくるものと考えることもできるけれど，僕はそれ以上に，「洗練を経たが故に失う輝き」というものがあるのではないかと考えている。

当初などんなに質素な創造物も，品質の洗練の過程を経るうちに複雑さを増し続け，最終的には一目見て理解できる以上に複雑なものへと変化を遂げてしまう。このような「意図の知れないもの」や「理解のできないもの」というのは，作り手としては非常に居心地の悪さを感じてしまうものだ。

しかし，その「居心地の悪さ」は，ユーザにとっての「居心地の悪さ」だろうか？自分の中で感じている「悪印象」は，ユーザにとっての「悪印象」だろうか？その判断を，作り手としての「都合の良さ」に基づかせてしまってはいないだろうか？

これは僕のつまらない推測だけれど，これほどまでに "Ratchet 2" を素早く制作し，かつ高いクオリティで完成させることができた理由は，「前作の基本コンセプトに対して手を加えない」というコンセンサスを早期に確立することができたためではないかと考えている。新たなスタートを切り直すことによって「逃げ」を打つ可能性を残すのではなく，過去の自分に対して挑戦を行うという覚悟を作り上げる。それは，ある面においては，本当に勇気のある挑戦なのかもしれないと思う。

氏のサイトを覗くのは，随分と久しぶりのことのような気がする。ついでに関係の無いところまで覗いてみると，いつの間にか SIGGRAPH 2003 のレポートなどが上げられていることに気付いた。

SIGGRAPH 2003 なんて数ヶ月も前の話になってしまうのだけれど，今年の SIGGRAPH ネタはいまいち漁り切れていない感触があったので，せっかくの機会だからついでに目を通してみることにした。

氏のレポートを読んでいて面白みを感じたのは，それぞれの技術に対して意外と現実的で冷静な意見を述べている所だ。例えば，お馴染み UNC Gamma チームの "Interactive Shadow Generation" などを挙げた上で，次のような指摘を行っている。

この研究は，私の UNC 時代の記憶の中にある研究などと同じように，恐ろしく膨大かつ
複雑なデータセットを対象としている。細部まで緻密に作られた船舶のモデルや，沢山の
パイプの走る原子反応炉とか，そういう種類の代物を扱っているわけだ。このような条件
の下においては，多くの CPU パワーを遮蔽判定や LOD 処理へと回すことに価値が見出さ
れる。なぜなら，これらのモデルの緻密さは，GPU を死へと追い込むほどの力を持ってい
るからだ。

しかし，ゲーム産業においては，我々は我々自身の手によってデータを作り出す。そして
当然のように，我々はそれを GPU が扱えるだけのスペックの中に収めるだろう。我々は，
前述のような技術に対して処理を割けるだけの CPU 時間を有していない。ＡＩ処理や物
理挙動処理，トリガー処理やゲーム処理など，CPU には優先して処理すべきことが沢山残
されているのだ。

私には，このようなパースペクティブの違いが，学術と我々のコミュニティの間に大きな
断絶を生み出しているように思える。

このように氏は，それぞれの研究内容に対して理解を示しながらも，それを安直に受け入れようとはせずに，冷静な評価を下すことに努めている。僕のような中途半端者は，このように有効性も定かでないネタの中から闇雲に可能性を見出そうと躍起になってしまっているものだから，氏のような冷静な意見に出くわすと，目を覚まされるような思いを受ける。

今回の SIGGRAPH におけるリアルタイム処理の流行りネタは，Peter-Pike Sloan 氏の研究をはじめとする PRT (Precomputed Radiance Transfer) 関連の研究にあったように思えるのだけれど，この傾向に対しても氏は，冷静な意見を下している。

このような話の派手さにも係わらず，PRT はゲームに対して有効に利用されることは無い
だろう。この技術は各種の係数を保持するために大量のメモリを必要とする。また，昨今
のハードウェアは SH （球面調和）ライティング処理を高速化するのに適しているとは言
えない。

もしかしたら，このような制限の数々は，いつの日か問題ではなくなるかもしれない。し
かし，それよりも深刻なのは，ライティング情報が低周波成分によって構成されなければ
ならないということと，全てのライトが無限遠になくてはならないということだ。小さく
鋭いエリアライトを扱うには，より多くの SH 係数を保持する必要がある。すると，小さ
な光源に周囲を囲まれた大きなモデルなどに対しては，PRT は有効な方法では無くなって
しまうわけだ。

そして極めつけに，PRT は動的なモデルを扱うことができない。ゲームでよく利用される
キャラクタモデルのようなものを扱うことができないわけだ。

ここで指摘されているような制限は，一度論文に目を通せば誰でも気付くようなことばかりだ。しかし，そのような制限の存在を理由に「有効ではない」と斬り捨てることは，決して簡単な行為ではないと思う。たとえ多くの制限が存在していたとしても，なお興味を惹かれるだけのポテンシャルの高さと，技術的な面白さを備えているからだ。

小難しい理屈は抜きにして，とりあえず公開されているデモムービーを見てみれば，この技術が何を実現するものであるか理解することができるはずだ。画面下部に表示されるタイムバーの列は，それぞれ「走り」や「ジャンプ」，「しゃがみ」などと言うような，モーションの抽象的な「注釈」 (annotation) を指定するものとなっている。ユーザ側では，複雑なコンフィギュレーションの類を行う必要は一切無く，ただこれらのタイムバーを塗りつぶすことによって「注釈」の指定を行うだけで良い。そうすれば，あとはアルゴリズムがモーションデータベースの中から条件に適合するモーションの断片を抽出し，自動的に合成を行ってくれる。

このようなモーション合成方式は，ゲームにおいても用途が存在するかもしれない。プレイヤーキャラクタに関してはともかくとしても，NPC に関して言えば，このような「高レベルかつ抽象的なモーション制御方式」は理想的なものであると考えられる。格ゲーでもない限り，NPC の挙動をフレーム単位で細かく制御したいというようなシチュエーションはほとんど存在しない。逆に，プログラム側であまりに細かい制御を行ってしまうと，どうしても「機械っぽい動き」が表れてしまい，キャラクタの動作から表情が失われてしまうことがある。むしろ，高い抽象性や冗長性を備えた制御方式の方が好まれるという事情が存在するわけだ。

この研究の中心人物である Okan Arikan 氏は，UNC の計算機科に所属する博士課程生だ。

Arikan 氏は，このようなモーション合成の技術を研究テーマとして扱っているようであり，１年前の SIGGRAPH には "Motion Synthesis & Retargeting" と呼ばれる，今回の技術の基礎となるものを提示している。

余談だけれど，"Projects" のページなどを覗いてみると，微妙に趣味がゲーム方面に偏っているのが分かる。

上の論文に用いられたサンプルデータも Electronic Arts 社から提供を受けたものであるそうだ。なるほど……。

この研究を見ていると，昨年の SIGGRAPH にあった "Motion Graphs" が思い出される。ウィスコンシン大学の Lucas Kovar 氏による研究だ。

これらの研究には似通っている部分がある。前もって与えられた一連のモーションデータと，人の手によって与えられた制約条件を元にして，自動的にモーションの合成を行うという方式だ。ただこちらの "Motion Graphs" は，最初の前処理の段階で，モーションを再構築可能な断片へと分解してしまうという点が異なっている。これによって，ランタイム時に複雑な検索処理を行うことなく，自由なモーションの合成を行うことが可能となる。そのため，どちらかと言えばこちらの技術の方がゲームに向いていると言えるかもしれない。

Kovar 氏の今年の論文も，同じくモーションの分解と合成をテーマとしている。"Snap Together Motion" と題された論文だ。

まだデモ映像に目を通してみた程度なのだけれど，なかなか面白そうなものに感じられる。あとでまた論文の方も覗いてみようと思う。

ここで登場する "Fourth Wall" − 「第四の壁」という用語は，元は演劇理論において用いられる専門用語であり，舞台と客席の間に存在する現実観の違いを，仮想的な「壁」の存在として表したものだ。その絶対的な「壁」の存在を認め，観客はその「壁」を通して舞台を「覗き見る」のだというのが，古典的なリアリズム演劇のコンセプトとなっている。

しかし，脚本家はこの「第四の壁」を存在を意図して……あるいは無意識的に……破ることができる。例えば，Jamie Fristrom 氏がゲームにおける「第四の壁の突破」の例として挙げているのが，"Metal Gear Solid" のボスキャラ「サイコ・マンティス」だ。

実は，この手の演出は Metal Gear シリーズにおいて脈々と受け継がれている伝統であり，PS2 の "MGS2" においても，プレイヤーを混乱に陥れるようなトリックが用意されていた。

Fristrom 氏は，この手の演出が制作者の悪ふざけによっている部分が大きいとし，率直に不快感を表している。僕も MGS2 の「狂った」演出はあまり好きではなかった。ただでさえ加速度的に混乱していくストーリーラインに加え，あのような過激な演出が繰り広げられることによって，最低限守るべきリアリズムさえも蝕まれてしまっていたように感じられる。

Horneman 氏の意見は，このような「壁の突破」が，単なる悪ふざけ以上の手法として存在しうるというものだ。しかし，いずれにせよ，それは「意図的」かつ「効果的」に破られるものでなければならない。制作者のプレイヤーの間に存在する「暗黙のルール」に破綻が生じてしまえば，それはプレイヤーに対して混乱や不快感を与えるものになってしまう。その配慮が存在することによって，初めて「壁の突破」が高等な表現のテクニックとして成立するということだ。

当初は春とか夏とか言われていた発売日はじりじりと延び続け，それがようやく先日発売されたという顛末だ。ひげねこさんの日記を見て思い出すことができたのだけれど，それが無ければ，もうしばらく忘れ続けていたことだろうと思う。

実は，今の仕事では当たり判定を担当していないので，このような本を買う必要に迫られているわけではない。それでも，まあ，一度は深く関わった分野なのだし，持っておいて損はあるまいと思って購入してみた次第だ。

著者の Gino Van Den Bergen 氏は，フリーの衝突判定ライブラリ "SOLID" の作者として有名な人物だ。

SOLID は，凸形 (convex) なオブジェクト同士の交差判定に GJK (Gilbert-Johnson-Keerthi) 法を利用している。この GJK 法の仕組みにはいまいち理解し難い部分があり，また，解説を行っている書籍の存在も少ないため，比較的マイナーな存在となっているように思える。しかし Van Den Bergen 氏は GJK 法の持つメリットを次のように指摘し，積極的な利用を促している。

* GJK 法は非常に汎用的である。このアルゴリズムは，一般的な凸形物体に対して用いる
ことができる。ここでは，GJK 法がどのようにして多面体や２次曲面，凸形物体のミンコ
フスキー和やアフィン変換後の像に対して適用されるかを示す。

* GJK は現状において，近接クエリを行うことのできる手法として最速のものの１つであ
る。適応的 GJK 法においては，時間的なコヒーレンシ (frame coherence) を利用するこ
とによって，他の適応的手法と遜色無いパフォーマンスを引き出すことができる。

* GJK 法は，直感的ではない数学的概念を多く利用しているため，理解し難いという性質
を持っている。しかし，その事実にも係わらず，GJK を実装することは難しくない。また，
このアルゴリズムは，特殊ケースの扱いをほとんど必要としない。

しかし，一般的なビデオゲームにおいては，凸形同士の高速な衝突判定や，正確な近接クエリなどは，本当のニーズではないだろうと思う。一般的に求められるのは，単純なプリミティブ（球や線分や「スイープ球」等）と複雑な凹形物体（地形）との間の高速な交差判定処理だ。そのような条件下においては，この本の内容が必ずしも有用であるとは言えないだろうと思う。一般的な交差判定アルゴリズムや高速化手法については "Real-Time Rendering" が非常によくカバーしているし，その参考文献リストから辿ることのできる文献だけで，相当の情報を集めることができるからだ。

しかし，もし，本格的な物理挙動を扱うなどの目的を持っており，かつ GJK アルゴリズムに興味を持っているならば，この本は「買い」かもしれない。あるいは，衝突判定に関して一通りの知識を揃えたいと思っているならば，やはり「買い」だろうと思う。

……とは言っても，僕もこの本を読破したわけではなくて，数ページに目を通したところで本棚の肥やしとなっている。出版されるのがあと２，３年早ければ，嬉々としてこの本に飛びついていただろうと思う。しかし，今となっては読破するだけの気力も上がってこない。少なくとも，もうしばらくの間は寝かせておくことになりそうだ。

ここで用いられている人月の算出法は，開発にかかった期間（月）に，プロジェクトの最大時の人数を掛けるだけという，投げやりにも程がある方式だ。チームの人数は常に変動し続けるものだから，最大時の人数を月で掛けたとしても正確な人月は割り出せないだろうし，そもそも単純に人月でコストを推し量ってしまうこと自体が危険な思想ではあると思う。

しかし，こうして数値化された結果から各プロジェクトの実態を覗き見てみるのは，なんだか面白いし，そこには思いがけない発見もあるかもしれない。ようするに，PC のベンチマークと同じぐらい当てにならないものなのだけれど，それなりに参考になる要素はあるかもしれない，というものだ。

この連載において繰り返される筆者の主張は，"bang-for-buck" ……つまり，純粋な「コスト対効果」を常に念頭に置きつつ，局面での判断を行うべきである，というものだ。

この表から導き出される "bang-for-buck" の値に目を移してみると，やはり，Factor 5 の "StarWars: Rogue Squadron II" が目立って良い結果を収めている。前作に相当する "Rogue Squadron" での資産があってこその結果ではあるものの，プラットフォームの移行という不安定な時期に経ながらも堅実な制作を行うことができたのは，やはり努力の末の結果であろうと思う。

そして，逆の方向にぶっちぎっているのは，なんと言っても BioWare の "Neverwinter Nights" だ。

度重なるスケジュールの遅延や，Interplay との間に発生した訴訟問題などを経て，開発費は膨らみに膨らみ，最終的には 180 人年（人月ではなく！）ものコストを背負い込むことになった。

Final Fantasy のような超巨大 RPG タイトル並の開発費だ。これだけコストがかかっているとなると，あれがああなってこうなる勘定だから……まあ，せめてミリオンは売らなければ美味い汁にはならないという次元だろうと思う。FF でさえ，コンスタントに製品を出し続けることによって体力を維持することができているというのに……。

このコラムの著者であるところの Jamie Fristrom 氏は，これらのデータに対して，次のような分析を下している。

我々は，無駄な大金を費やすことなく優良なオリジナルゲームを作りたいと考えている。
そしてここには，全く異なる群の中から選び出された勝者達が並んでいる。 "Thief",
"Deus Ex", "No One Lives Forever", 等々。それでは，これらのタイトルから，我々は
どのようなことを学ぶことができるだろうか？

※ 少人数のチーム（２０人程度）を組み，比較的長い期間（２，３年）をかける。

※ 試作を行う。

※ ゲームの目的や焦点を明確にする。

※ ゲームデザインをシステマチックにするよう努力する。

※ プログラマの補助なく，ゲームにアート要素やデザイン要素を加えられるようなツールを用意する。

※ 頻繁にモニターテストを行い，そのフィードバックを取り入れる。

※ 狙撃モードと潜入要素を持つ１人称視点のＰＣタイトルを制作する。

これらの提案はもっともなものに聞こえるだろう……最後の１つを覗いては。

私が以前言っておいたように，このようなテクニックは，あなたの思考を上書きすると
いうよりかは，あなたの思考を刺激するために用いるべきである，ということだ。

Fristrom 氏も念を押しているように，これらのデータはまともなアイデアを提供するものではない。しかし，そこには決して無視できない事実が存在しているはずだ。例えば，Mythic 社の出世作 "Dark Age of Camelot" が，30 人と 18 ヶ月という比較的低予算によって制作されたことを考えれば，MMOG だからといって金がやたらとかかるという言い訳は効かなくなってくるはずだ。

色々細かな理由はあるものの，最も大きかったのは，ヨドバシのオンラインストアで Visual C++ が売り切れていたことだ。しょうもない理由だけれど，まあ，買い物なんてのはそんなもんだね……。

というわけで，しばらくの間は SlickEdit かぶれになりそうな雰囲気だ。ソースコードも，そろそろ本気で UTF-8 に移行してしまおうかと考えている。

と，まあ，風邪もひいていることだし，夜更かしもそこそこにして寝ることにした。

一般に言って RPG は，非常にコストがかさみやすいという性質を持っており，制作側にとって最もリスキーなジャンルの１つとなっているように思える。それが，ネットワークベース……しかも MMO (Massive Multiplayer Online) ともなれば，なおさらのことだ。そのような条件にも係わらず，Mythic の開発チームは "Dark Age of Camelot" という MMORPG を，18 ヶ月の制作期間と最大で 25 人の人員という，非常に低いコストで仕上げることに成功している。これは，驚きに値することであると思う。

この辺りの顛末については，Gamasutra の Postmortem 記事に詳しい。

スピーディーな開発の鍵となったのは，Mythic 社が既にネットワークゲームに対して相当のバックグラウンドを持っていたことと，ゲームデザインに関して迷いが無かったこと，それから，いくつかの小さな幸運が重なったことなどが挙げられるようだ。ゲーム内容について厳しい見方をすれば，"Ultima Online" から "EverQuest" へと続くファンタジー MMORPG の亜流ということで，「３番煎じ」な感は否めない。しかし，前２作において弱かった面（見た目のクオリティや，ゲームバランスの問題）が着実に改善されているとあって，相当の人気を博すことになったようだ。

この Postmortem を読んでいて面白いと思ったのは，彼らが Linux とオープンソース・ソフトウェアをベースとした安価なサーバシステムを構築していることだ。これは，システムソフトウェアのライセンス料や，ハードウェアの導入コストの面などにおいて，大きなアドバンテージとなったようだ。

Camelot のシステムを動かすには，相当な量のデータを管理する必要がある。そこで我々
は当初，アカウント情報の格納に Oracle の利用を検討していた。しかし，Oracle はライ
センス料として $900,000 の見積もりを提示してきたため，この案は早急に議論から取り
除かれることになった。

オラクルが提示してきた金額のショックから立ち直り，このことで笑えるようにもなって
くると，我々は，格納データの管理に MySQL を利用するという，Linux ベースのフリー
ソフトウェア・ソリューションへと移行を行うことにした。

このシステムは，今のところ非常にうまく動いている。

ネットワークゲームのサーバシステムをオープンソース・ソフトウェアの組み合わせへと移行することによってコストの削減を図った例としては，ソニックチームの "Pahntasy Star Online" などが思い出される。

同様の例は他にも存在するだろうと思う。この手のノウハウについては，韓国の方面を漁ってみた方が面白いものが得られるかもしれない。

Linux とオープンソース・ソフトウェアをベースとしたシステムでも，ソフトウェア的には十分に安定した動作を行うことが可能であると思う。まず問題になるのはハードウェアだから，そこさえ押さえることができれば……。

"Computational Complexity of Games and Puzzles" と題されたこのページでは，様々なゲームやパズルの持つ数学的な複雑度について，最新の研究の結果をまとめている。例えば，「上海」は NP 完全問題であり，「倉庫番」は PSPACE 完全問題であり……と言った具合だ。

筆者は，カリフォルニア大学アーバイン校で教授を勤める David Eppstein 氏だ。

氏は "Combinatorial Game Theory" というページの中で，ゲームやパズルに対する組み合わせ論的な分析を取り上げており，膨大な文献へのリンクをまとめている。

数学はからきしダメなので，この辺りの理論についてはほとんど理解できていないのだけれど，言葉の雰囲気ぐらいは何となく伝わってくる……例えば，「NP 完全問題」は多項式時間で解くまともなアルゴリズムが与えられないほど難しく，「PSPACE 完全問題」では多項式領域によって解けるかどうかさえも危うくなってくる。極めつけが「EXPTIME 完全問題」で，指数関数時間に属する問題の中でも最も難しく，実質的に計算不能な難しさを持つということになっている。

この辺りの話題については，早稲田大学は守屋悦朗教授の記事「計算の複雑さとは何か」が非常に良くまとまっており面白いと思う。

また，駒澤大学の植原隆平助教授の記事「日の目を見なかった問題たち」では，倉庫番における解の判定の難しさについて概論を述べており，これも分かりやすくて面白いと思う。

MIT の助教授 Erik Demaine 氏も似たような研究を行っているのだけれど，こちらは話題がコンピュータゲームに寄っており，興味深い内容となっている。

氏の研究によれば，一般化されたテトリスのシステムにおいて，たとえブロックの順序が完全に知れており，自由なブロック操作が可能であったとしても，「最適のパターン」を求めるアルゴリズムは NP 完全問題に属してしまうそうだ。

ここでは，様々な縮小版の「さめがめ」について分析を行っているのだけど，比較的容易そうな「３列５色」の時点で既に，「全てのブロックが消せるかどうか」という問題は NP 完全問題になってしまうそうだ。他は「１列さめがめ」について最善手を求めるアルゴリズムが辛うじて多項式問題とされている程度であり，思ったよりも「さめがめ」が複雑なゲームであることを示している。

似た研究として，「任意の設定におけるマインスイーパーが解決可能であるかどうか」という問題が NP 完全であることを示した論文がある。英バーミンガム大学の Richard Kaye 氏の研究だ。

これらの研究とは逆の方向で面白いのが，カナダはアルベルタ大学における "GAMES Group" の研究だ。

ここでは，多種のポピュラーなゲームに対して，解法アルゴリズムの研究や，最適手・千日手の調査などを行っている。

ここでの倉庫番の戦歴などを見てみると，その解法の難しさが実感できるかもしれない。

比較的易しいと言われているオリジナルのレベルでさえコンプリートできていないし，比較的序盤であるレベル１０において，既に２千万回ものノード探索が要されていたりと，相当に厳しい戦いとなっている。

確か，Joel on Software において展開されていた C++ 例外処理論争の記事からリンクを辿ったのがきっかけだったと思う。

先日の記事でちょっと面白かったのが，"Storing hierarchical data in a database" というネタだ。

表題の通り，階層（木）構造を持つデータをリレーショナルデータベースに格納するという手法を紹介している。sitepoiont というサイトに掲載された同名記事へのリンクだ。

このようなテクニックは，例えば XML のような階層構造を持つデータを RDBMS へ格納したい場合などに役に立つ。本来なら XML データをネイティブに扱うことのできる XML DB を用いるべきなのだろうけども，まだそのような DB の存在が一般的ではないため，このような変換テクニックが役に立つ場面は色々と存在するのだろうと思う。

ここで用いられている Preorder Tree Traversal というアルゴリズムは初めて耳にする。どうやら，木構造の探索を行うアルゴリズムとして比較的有名なものであるようだ。

このアルゴリズムによって，ノード間のリンクを検索する処理が，単純なインデクスの範囲指定に直されるというところがキモだ。また，部分木の取り出しや，特定のノードのパスの検索などを，単純な SQL 文によって表現することができるというところも面白い。ツリーの更新には比較的重い処理が要求されてしまうものの，書き込みよりも読み取りの方が多いようであれば，十分に元を取ることが可能であろうと思う。

こんな感じで，ちょっとした小ネタの紹介が面白くて，氏のブログをよくチェックしている。今日の記事で面白かったのは，Paul Schmidinger 氏のページの紹介だ。

Paul Schmidinger 氏は，オーストリアはフォアアールベルグ大学に在籍する学生で，フリーでウェブデザインの業務を請け負っているという青年だ。Java を使ったアプレット作成などを得意としているようで，件のサイトでは様々な画像効果のネタを扱ったアプレットを見つけることができる。

特に面白いのが，"Grappa" と呼ばれるアーティスティックなアプレットだ。

原理的には単純なもののように見えるのだけれど，とてもセンスが良くまとまっている。なんとなくマウスを動かしているだけで，それなりに綺麗なパターンが描き出されてしまう。うん……面白いかも。

これは，Gamespot の記者 Geoff Keighley 氏がゲーム制作の裏舞台へと潜入し，その様子をレポートするというコーナーだ。「『侍』はこうして作られた」ばりの臨場感溢れるドキュメンタリーを楽しむことができる。

特に興味を誘われたのが，最新の記事 "The Final Hours of Prince of Persia" だ。

この記事は，今冬最大の期待作とも言われている "Prince of Persia: The Sands of Time" の制作現場を取材したものだ。マスターアップの直前の修羅場の風景から始まり，約２年間の制作の道のりを開発者達の記憶を基に振り返るという構成になっている。

"Prince of Persia: The Sands of Time" は，今冬に UBI が満を持して投入する主力製品の１つだ。

つい最近になるまでは，それほど注目を受けていなかったタイトルであるように思えるのだけれど，実際の製品の評判はかなり良いようだ……話題を振り撒きながらも実際には辛い評価を受けている同社タイトル "XIII" と比較すると，対照的な存在のように思える。

同ソフトが注目を集めるきっかけとなったのは，今年の５月に開催された E3 での出来事だ。この会場において電撃的に公開された同タイトルのデモが非常に強いアピールを持っており，会場を訪れた多くのゲームファンや記者の間に話題を振り撒くことになった。実際に僕の職場の E3 隊の人達も，最注目タイトルとして "POP" を挙げていたのを思い出す（もっとも，"Halo 2" や "Half-Life 2" などは，混み過ぎていて覗き観ることさえままならなかったそうだ……）。

ちなみに，同タイトルは Game Critics Award の "Best of E3 2003" において "Best Action/Adventure Game" 賞を獲得している。

件の記事には，この E3 デモにまつわるエピソードも詳しく語られている。特にその中でも印象的なのが，E3 デモを作成する段階になってから，レンダリングエンジンを作り直すという大掛かりな作業に着手したことだ。

"POP" は当初，"Splinter Cell" 等と同じく Unreal Engine をゲームエンジンとして利用することを考えていたものの，ゲームのメインフィーチャーである「時間の巻き戻し」を実現するためには同エンジンの機能では不足していることが判明し，そのため Ubi オリジナルのレンダリングエンジンである "JADE" を利用することになった……という経緯が存在する。しかし，本制作を開始して７ヶ月が経過した２００３年の２月になって，この "JADE" エンジンでは機能が不足しているという事実が判明してしまったわけだ。

カメラ仕様に関する変更などは，些細な軌道修正でしかなかった。２００３年の始めにこのチームは，更に困難なハードルへと激突することになる。２月の初旬に，プログラマたちは JADE エンジンがこのゲームの膨大なステージと緻密なエフェクト群を既に扱い切れなくなっていることを認識し始めていた。Mallat（POP のプロデューサー）は当時の様子を次のように述べている。

「プログラマチームが僕の所に来て，こんな感じのことを言ったんだ……『悪いニュースがある。このゲームのためにまったく新しいレンダリングエンジンを作り直す必要があるんだ』」

グラフィクスエンジンの変更は，レベルデザインやゲームプレイのコア部分に対して影響をもたらさないものであるものの，E3 における最初のパブリック公開バージョンの作成までたったの３ヶ月しかない今となって，このような大規模な変更が行われることを Mallat は恐れていた。

「公の場でのデビューまであと何ヶ月も無いと言うのに，我々にはグラフィックエンジンが無いときたんだ。本当に慌ててしまったよ。」

そして，この状況を打破したものこそ，Ubi 上海スタジオのプログラマが作成した新レンダリングエンジンだったということだ。新たなエンジンへと置き換えられた "POP" はビジュアル面において新たな前進を遂げ，無事にパブリック公開バージョンとして相応しいクオリティを得ることとなった。この辺りの進化については，記事に載せられているスクリーンショットなどを参照して見ると，その様子をうかがい知ることができるかもしれない。

しかし，PS2 版 "Splinter Cell" において頭角を現した Ubi 上海スタジオが，このような場面にも登場してくるとは思いも寄らなかった……。上海のゲーム産業は，今後も様々な場面において登場する存在となるのかもしれないと思う。

特に，「時間の巻き戻し」によるリプレイシステムと，時間操作と融合した戦闘システムの構成が，僕に強い印象を与えている。

しかし，この「時間の巻き戻し」を思い付く元となったアイデアが，実は，彼らの前の作品である "Donald Duck: Goin' Quackers" にあるというのだから，ちょっと驚かされる。

この "Donald Duck" は，彼らの「あまり誇れない仕事の１つ」として心に残っていたものであるようだ。僕も日本語版をプレイしたことがあるのだけれど，投入されている人数の割には……という感想を持った記憶がある。

これらの背景には，カナダはモントリオールにある Ubi 内部制作スタジオの紆余曲折と，Ubisoft のパブリッシャーとしての急成長という，２つの出来事が関連しているようだ。

この２年の間に，フランス生まれのパブリッシャーである Ubisoft は，「Rayman の制作元」という立場から，"Splinter Cell" や "Prince of Persia" のような売れ線タイトルを送り出す大物ゲームパブリッシャーへと育っていった。そして更に重要なことに，モントリオールの "POP Team" と呼ばれる集団は，自力によって急激な成長を遂げていた。２年前，Prince of Persia のチームメンバー達は，今や忘れたい記憶となった "Playmobil" シリーズや，ディズニーの "Donald Duck" 等を手がけていた。そして今，それらの未熟な製品群は人々の知られざるところとなり，彼らの新しいゲーム "Prince of Persia" は，多くの人から今年の期待作として注目される作品となるのだった。

しかし，そのような状況において "POP" のディレクターである Patrice Desilets 氏は，敢えて "Donald Duck" での記憶を引き出し，それを "POP" のキーフィーチャーとして据えてみることに挑戦したようだ。

"Prince of Persia: The Sands of Time" において最も特徴的な要素の１つである「時間の操作」は，Donald Duck のゲームを元としたものだった。Mallat が「ゲームプレイの要」となるものを出せとチームをつつきだしたとき，Desilets は Donald Duck のときにプロデューサに提案したアイデアを引っ張り出してみることにした。それは，ごく簡単に言えば，「プレイヤーが死んだときに時間を巻き戻せるようにする」というものだった。

「Donald Duck をプレイしていて死んじゃったとき，ほんの数秒時間を巻き戻せたらいいな，と考えていたことを思い出したんだ。ステージの最初からプレイし直すんじゃなくてね。」

Donald Duck のプロデューサーがこのアイデアを却下したのに対して，Mallat はこれを受け入れようとしたようだった。Mallat は次のように述べている。

「我々は，この『ゲームの巻き戻し』によって，プレイヤーが絶え間ないチェックポイントを持つことになるんだということを認識しつつあった。そして，常にジャンプしたりトラップを避けたりしているアクロバット系のゲームにおいて，このフィーチャーが非常に重要な意味を持つことになるだろうということを考え始めていた。」

確かにこれは素晴らしいアイデアのように聞こえるが，PlayStation2 上においてこのような「ゲームの巻き戻し」を可能にする技術が存在するかどうかは，まだ誰も知り得ないことだった。

この問に対する答えを得るために，Mallat はリードプログラマである Claude Langlais に助言を求めることにした。これはある意味において，このような疑問を解決するのに良い時期であったと言える。プログラマ達は，どのような技術がゲームエンジンの基礎として適切であるかを探求している最中だったのだ。それまでの数ヶ月の間，Unreal Engine を使うという案に惹かれていたものの，最終的にプログラマと Mallat は，Ubisoft の独自技術である "JADE" を利用することに決定した。"JADE" は "Beyond Good & Evil" のためにフランスで開発されたエンジンであり，この JADE によって「ゲームの巻き戻し」が可能になると Langlais は考えていた。

ディレクターの Desilets 氏は，このように積極的なアイデア出しを続けながらも，「アクロバット」と「時間の操作」という２つの軸を得たところで，これらの要素に焦点を絞り込み，他の凡庸なアイデアを全て消し去っている。例えば，主人公が馬に乗って駆け回るという案や，アラビアの砂漠で戦闘を行うという案や，定番の「魔法の絨毯」に乗って空を飛ぶという案など……最も変わった案としては，主人公が梯子を駆使してカンフーアクションばりに暴れまわるというものまであった。

結果的には，それらのアイデアを捨て，主軸となる２つのコンセプトに限定して要素を洗練させていったことが，このゲームを良い方向へと導く鍵となったということだ。この辺りの判断は，部外者からしてみれば当然の判断のように思えるかもしれないけれど，実際に制作を行っている当事者としてみれば，非常に難しい決断のように感じられるはずだ。そのような状況にあっても，的確な根拠に基づいて決断を下し，明確なビジョンを提示することのできる人物こそが，理想のディレクターとして求められるということだ。

"POP" の開発には，総計で約２年の月日が費やされている。そのうち，最初の１０ヶ月は試作期間として利用され，残りの１４ヶ月は本制作作業に費やされている。ちなみに，試作が行われる以前に，オリジナルの "Prince of Persia" の作者である Jordan Mechner 氏を説得するためのデモ映像の制作が行われており，この作業に数ヶ月の期間が費やされている。

スタッフの人数はおよそ５０人ほどであり，これらの人員は主に本制作となってから投入された。製品のコンセプトが十分に固まってから，一気に人員を投入して仕上げたというわけだ。

件の記事には，長い試作期間の紆余曲折が克明に語られている。前述の Mechner 氏へのプレゼンテーションに用いられた映像もムービーファイルとして載せられている。この映像を見てみると，まだ試作にも入っていないこの段階において，ゲームの核となるアクロバット部分のコンセプトがほぼ固まっていたという様子をうかがうことができる。

この映像は，Mechner 氏が「Tomb Raider の二番煎じではないアイデアを見せて欲しい」と要求してきたのに対して，Ubisoft のスタッフが提示した返答となるものだ。Mechner 氏は，自身がコンサルティングを行った製品 "Prince of Persia 3D" が駄作に終わってしまったことを相当悔いていたらしく，Ubisoft のメンバーが革新的なアイデアを出してこない限りは，制作を許可しないという考えを固めていたようだ。

しかし，Ubisoft の面々が苦心して作り上げたデモ映像は，Mechner の心を見事に解き開くこととなる。

デモ映像の再生が終了すると，Mechner はチームに向き直り，全員の姿を両目で見つめ，一言だけこう言い放った。
「君たち……今私が見たものは，私にビデオゲームを作る楽しみを呼び覚ましてくれたよ。」

こうして Mechner 氏の太鼓判を得たチームは，１０ヶ月という長い試作期間へと突入して行く。

ここでユニークなのは，Mallat 氏らは，ゲームのコンセプトが完全に固まるまでは，決して本制作への移行を認めなかったということだ。普通なら曖昧になりがちな「試作」と「本制作」の間の境界線を明確に定義し，断固としてそれを主張するプロデューサーは，少し珍しい存在のようにも思える。

Mechner 氏へのプレゼンテーションから数ヶ月の間に，ゲームのもう１つの主軸となる「時間の操作」のアイデアの投入や，そのアイデアを実現するためのインフラの選択などが行われた。そして続く数ヶ月をプロトタイプ・バージョンの制作に費やし，２００２年の５月となった時点で，社の重役達への最初のお披露目を行うこととなる。

このときのプロトタイプ・バージョンの映像も，ムービーファイルとして件の記事に載せられている。この映像を見てみれば，主要なアクションやカメラシステム，そして「時間の巻き戻し」等のフィーチャーが，かなり完成に近い形でプロトタイプに実装されていることが分かると思う。

全体のクオリティを見てみれば，完成版からはほど遠いものだと感じられるかもしれないけれど，ゲームシステムのコアとなる部分については，非常に明確な形でアピールが行われているのではないかと思う……少なくとも，僕が今まで体験してきた「試作版」に関しては，ここまで最終形に近いビジョンを提示するものではないことが多かったように思える。

このプロトタイプは，Ubisoft の重役達をもってして「いまだかつて無い完成度のプロトタイプ」と言わしめるほどのものであったものの，Mallat 氏らは決して十分な練り込みが完了したとは考えていなかった。ここで社の上層部との衝突が発生することとなる。

Mallat 氏の心配にも係わらず，社の重役達はチームの拡大と試作期間の終了を Mallat に強く押し付けてきた。会議が終わりに近づくにつれ，成功の幸せの味は，ほろにがい体験へと移り変わっていった。

「私は，重役達に対して怒りを感じながら部屋を出て行ったことを覚えている。もう，本当に腹が立ったんだよ。」

こうして Prince of Persia チームは早過ぎる成功を手にすることとなる。そしてすぐに，この成功が彼らを悩ませることとなるのだった。

最終的に Mallat 氏は，猛烈な論争の末に３ヶ月の延長期間を得ることとなったものの，ここまで強く確信を持って試作を推し進めた理由とは，一体どのようなものであったのだろうかと思う。Mark Cerny 氏のように試作の重要性を強く主張するプロデューサーも世には居るものの，その明確な根拠と方針を提示することは決して簡単なことではないように思える。現に，この "POP" のストーリーにおいても，本制作への突入を待つ間に発生した余剰人員は，組織に対してネガティブな資産を作り出す結果となったはずだ。

それはともかくとして，ここでの Mallat 氏の振る舞いのように，組織の上層と下層の間に立ち，双方の主張のギャップを埋めていく作業を担当することこそが，一般に言う「プロデューサー」の役目として求められるものなのだろうと思う。

もうさすがに埒が明かないので，思い切って BF1942 をアンインストールしてしまうことにした。さすがにアンインストールしてしまえば，なんとか止めることができるだろ�

Reconsidering Custom Memory Allocation (1)

Reconsidering Custom Memory Allocation (2)

NARUTO

Tools and Solutions

Probabilistic Roadmap Method

Flexbot

Building Engaging Bots

Differentiate or Die

Band of Brothers

Things You Shouldn't do

SIGGRAPH 2003

Compositional Motion Synthesis

Breaking the fourth wall

飲み

Collision Detection

The Mythical Man-Month

Visual SlickEdit

Dark Age of Camelot

Games and Mathematics

Preorder Tree Traversal

The Final Hours of Prince of Persia (1)

The Final Hours of Prince of Persia (2)

The Final Hours of Prince of Persia (3)

War Games