Radium Software Development

このようなルールを実践することができれば，いわゆる「クラッシュ系」のバグの頻度はかなり減るはずだ。しかしそれに相対するように，アサーションの失敗によって停止する確率が高まってくる。ルールを厳密に適用すればするほど，アサーション失敗の確率は高くなるはずだ。これは，原因不明のクラッシュによって停止することと比べてみれば，遥かに良い傾向ではあるものの，開発進行の妨げとなることには変わり無い。恐らく，プログラマ以外の人員にとってみれば，「クラッシュによる停止」と「アサーション失敗による停止」のそれぞれが持つ意味の違いなど分からないものだろうと思う。

しかしプログラマにとってみれば，「クラッシュ」と「アサーション失敗」の違いは大きなものだ。アサーション失敗による停止は，あらかじめ想定された停止状態であるから，停止したという事実自体がまたとないデバッグの機会となる。したがって，この時に得られる情報を充実させておくことが重要な意味を持つようになる。関数呼び出しのバックトレース（スタックダンプ）は是非とも欲しいところだし，メモリ割り当ての状態や，グローバルなデータのダンプなど，主要な情報については一通り出力しておくことが好ましいと思う。

もちろん，これらの情報は画面上へ表示するだけでは足りないだろうから，ネットワークを介してホストマシンのディスク上へ出力することや，メモリカードやＨＤＤ等の外部記憶装置へ出力することを，あらかじめ検討しておく必要があるだろうと思う。最近のゲーム機はネットワークへ接続する機能が充実してはいるものの，やはり基本的にはスタンドアロンでデバッグする機会が多いことを考えると，メモリカードのような標準的な装置を選択しておくのが無難なのではないかと思う（ＸｂｏｘならＨＤＤがあるけど……）。

もう１つ，今までの開発経験を通して重要性を感じつつあるのが，バグの発見から修正までのパイプラインを確立しておくことだ。バグの原因に関してはこれまでのような議論に任せておくとして，ひとたびバグが発見されたならば，漏らさずそれを申告し，責任者の割り当てを行い，必ず修正まで導かれるようになっていなければならない。

Jamie Fristrom 氏の記事によれば，開発の初期段階からバグ報告用のデータベースを立ち上げ，チーム内において十分なデバグを行う体制を整えておくことが肝要であるとしている。また，自動ビルドとスモークテスト（全体的なシステムの具合を確認するテスト；機械に電源を入れ「煙が出ていないか確かめる」動作に似ている）を導入しておくことによって，クラッシュバグ付きのコードがチェックインされることを防いでいる。どちらも，コードに不具合があることを日常化させないために役立つ機構だ。

バグを敢えて放置する理由としてよくあるのが，「それは『未実装』なのであってバグでは無い」とか，「対処している時間が無いので保留」などというものではないかと思う。どちらも理由としてはもっともなものなのかもしれないけれど（ただし，主観的にバグだと判断されたならば，それはバグだろうと思う），「分かりきったバグを報告してはいけない」などという雰囲気を作り上げてしまうのは非常に危険だ。些細な問題についてもうやむやにせずに，それを管理し追跡する手段を確立しておくことが，高品質のソフトウェアを制作する上で必須の条件となるだろうと思う。

僕はどちらも実際には使ったことは無い。 "Bugzilla" は Mozilla プロジェクトにおいて十分な実績が認められており，安定性に関しては問題無いだろうと思う（このツールは既に数十万件のバグを処理している）。しかし，それが使いやすさに結び付いているかどうかと言うと，微妙なところだと思う。また，レポートにファイルの添付ができないという制限もある。ゲームのデバグの場合，画像を添付することが重要な意味を持ってくるから，この制限は致命的なものになるかもしれない……。

"GForge" については，実績もあまり無いだけに，安定性に関してやや心配な面がある。特に，元となった SourceForge がプロジェクト管理システムとして必ずしも良いものとは言えなかったことが，その心配を強める方向に働いている。まあ，これぐらいシンプルなシステムの方が，かえって扱いやすいのではないかと思う気持ちもあるのだけれど……。

コマーシャルなプロダクトであれば，例えば Fog Creek Software の "FogBUGZ" などが存在する。

このくらいプリティーなインタフェースならば，プログラマ以外にも容易に受け入れられそうな気がする。機能的にも十分なものであるはずだ。

また，組織内においてグループウェアを利用しているならば，それを利用するのも良い手だろうと思う。僕は Lotus Notes に対してあまり良い印象を持っていないので，できれば避けたいと思っているのだけれど，客観的な判断で言えば，それほど悪い手ではないだろうと思う。

ところで，先日，この "Joel on Software" において紹介されていた面白いウェブサービスがある。 "Mailinator" だ。

Mailinator のサービス内容を一言で説明するならば，「即席メールアカウントサービス」だ。ウェブサイトにある売り文句をそのまま引用すると，次のようなものとなる。

メールを "@mailinator.com" の誰かに送るだけ！
あなたのためのメールアドレスは既に用意されています。
メールが送られたならば，それをチェックしに Mailinator を訪れてください。
あなたへのメールが，あなたの来訪を待っています。

仕組みは簡単だ。 "@mailinator.com" の誰か……例えば "hogehoge@mailinator.com" や "foobar@mailinator.com" など……へメールを送る。すると，そのメールは Mailinator サーバのどこかに数時間保存される。メールを閲覧するには Mailinator のトップページにある "Check your EMAIL!" と書かれたボックスにそのアカウント名（"hogehoge" や "foobar"）を入力するだけで良い。メールが自動削除されるまでの数時間の間であれば，何回でも好きなだけ閲覧することができる。極めてシンプルで無駄のないシステムだ。

このサービスが役に立つのは，自分のメールアドレスをスパマーにさらす危険を冒したくない場合だ。最近では，ちょっとしたウェブサービスの利用や，ソフトウェアの試用を行うにも，メールアドレスの入力を求められることがある。その企業がどんなに有名なものであれ，個人の「活きた」メールアドレスを無闇にさらすのは，できれば避けたいところだ。そんなときには Mailinator を使えばいい。メールアドレスとして Mailinator を指定しておき，しかるべき情報を受け取ったのちに，そのことは綺麗さっぱり忘れてしまう。あとは，いくらその企業が Mailinator に対してスパムを送ったところで知らぬことだ。

同様のスパム対策を行う方法として Yahoo! Mail 等のフリーメールサービスを利用する手段もある。しかし，これは登録の手間の面から言って不十分なところがあった。それが Mailinator ならば，瞬時にアドレスを作成し，好きなときにそれを捨て去ることが可能になる。これは精神的に受け入れやすいものであるはずだと Mailinator のホストである Outscheme 社の Paul Tyma 氏は語っている。

メールで受け取る情報が常にコンフィデンシャルなものであるとは限らない……メールで受け取る情報が恒久的に残したいものであるとは限らない……そのような発想が，この Mailinator サービスの可能性を導き出している。冴えた発想が，シンプルであってもユニークなシステムを作り出す例が，ここに見られるような気がする。

本全体から漂ってくる「ウチは現実主義ですからなー」というオーラがいい感じだ。

しかし，なにしろブ厚い本だから，読み終えることはきっとないだろうと思う。ゆっくりと，必要なところだけ読んでみようと考えている。

たしか，注文したのが 7/28 だったから……約一週間で届いた計算になる。速達便 (DHL) ではなく郵便による配達を指定していたため，もう少しゆったりしているものかと思っていたのだけれど，予想よりもかなり早く届いた。この調子なら，よほど急ぎの用事で無い限りは郵便でも十分だろうと思う。

肝心の内容の方はと言えば……これが，なかなかいい感じだ。 Game Developer Magizine 誌の版下原稿が PDF 化されて完全収録されている。それも，ただ収録するだけではなく PDF によるナビゲーション機能が追加されており，電子媒体上での閲覧に適した形となっている。やはり読みやすさの点では本物の紙媒体にかなわないものの，読み難さを感じさせるほどでは無いし，保存管理する分にはこちらの方がずっと適している。

しかし，こうして見回してみると，やはり Game Developer Magazine と Gamasutra は別モノだと考えた方が良さそうな気がしてくる。たまに大きな記事と Postmortem が転載されているくらいで，他の記事は共通していないものが多い。ううむ……やはり Game Developer Magazine も購読した方がいいかもしれない。昔は職場で定期購読していたような気がするのだけれど，いつの間にか姿を見かけなくなってしまったのだ。

いつかまた，定期購読のリストへ追加してもらえるよう，交渉してみようと考えている。

ゲームシステムに関して興味があるので，是非とも購入してみたいと考えているのだけれど，なぜか amazon ではこの商品を取り扱っていない。古過ぎるのかね……。とにかく，店頭に残っている在庫をあてにするしかなさそうな雰囲気だった。

もう１つの目的は「あきばお〜」で Campanella のアルバム "/Campanella" を購入することだった。

秋葉原に着いてから，ＰＣゲームの置いてある店を尋ね回ってみたものの，結局 "Deus Ex" を見つけることはできなかった。それにしても，ＰＣゲームをまともに取り扱っている店ってのも，ずいぶんと減ってしまったものだと思う。特に，頼みの綱にしていた OVERTOP が規模縮小してしまっていたのが辛かった。 Laser5 とか OVERTOP とか，掘り出しものの面白い店だったんだけどなあ……。

もう１つの目的であった "/Campanella" の方は簡単に入手することができた。今回は枚数を豊富に揃えているらしく，まだだいぶ在庫が残っているようだった。店の方でもこのアルバムをプッシュしている感じだった。

あきばお〜の同人専門店の方には今回初めて入ったのだけれど，予想していたよりも音楽ＣＤを豊富に取り扱っているようで，少し驚いた。あきばお〜って言うと，なんかこう狭っ苦しい雰囲気を連想させられるのだけれど（他の店舗がそうだからだ），同人専門店の方は意外と広い店舗に無難なレイアウトとなっており，意外とさっぱりとした印象を受ける。さっさと用事を済ませて出て行く予定だったのだけれど，予想以上の品揃えに興奮してしまい，思わず他のＣＤまで衝動買いしてしまった。

Campanella のように本格的なパッケージングを施したＣＤもある一方で，ＣＤ−Ｒをプラケースに詰めただけの，いかにも自主制作っぽいＣＤなんかもたくさん置いてある。こういうゲリラ感のある売り方も面白いと思う。買う方にとってみりゃバクチだけど……。

結局，バブルＢの「ぞっこん！バーベキュー」を含む数枚のインディーズ盤を購入してきた。しかし，こんな所でバブルＢを買うことになるとは，思ってもみなかったよ……。

それで "/Campanella" の方はというと，内省的な表現を持ちながらも，雰囲気としてはむしろライトにまとまった感のあるアルバムだった。前半のどんよりとした薄暗いムードとは対照的に，後半は明るく広がりを持った展開となっている。最終トラックの "all of us" の爽やかさが，全体を救っている感じで好きだ。

なかでも象徴的な曲は「少年の夢」だろうと思う。静かな終末を予感させる曲。付けられている英語名が "the dream of a dying boy" であることからも，そのことが連想される。終わり行くものを憐れむ心というものは，一種の耽美的な要素を持っているように思える。終わりをただ悲しむのではなく，その儚さを美しさに昇華させるような力がある。「カタルシス」とは，まさにそのようなことを言うのだろうと思う。

だから，自分が死ぬ間際にかけて欲しい曲があるとしたら，例えばこんな曲だろうと思う。

この雑誌の日本版が出ていることは全然知らなかった。本家の方は前々世紀からの伝統を持つ雑誌らしいんだけれど，国内での出版は今年の２月から始められたばかりのようだ。今月号では，いつぞやの Birdman Suit が表紙となっている。件の記事の和訳も載っていた。

雑誌の全体的な内容は，科学雑誌として有名な「ニュートン」を，もうちょっとライトにしたような感じの雰囲気だ。基本的にオリジナルの "Popular Science" 誌を和訳した内容となっている。子供にも読めるようにと，すべてのテキストに振り仮名が振ってあるのだけれど，基本的には大人でも楽しめるような内容となっている。どちらかと言うと中高生向けかな……。

今月号の記事の中でも面白かったのが， Burt Rutan の作り出した小型宇宙船 "SpaceShipOne" と，宇宙旅客機のコンテスト "X PRIZE" の話題だ。

"X PRIZE" は民間主導のプロジェクトであり，「高度 100 km への打ち上げを同機体によって２週間以内に２度行った最初の団体に対して一千万ドルの賞金を与える」という内容のコンテストだ。

このプロジェクトの目的には，宇宙船の開発を民間の主導で行うことによって，低コストかつ営利性のある宇宙開発を実現させよう，というものがあるらしい。また，今までのような政府を主体とした宇宙開発ではなく，民間に対してその可能性を大きく広げることによって，新たなステージへの発展を促そうという意図もあるようだ。

X PRIZE の解説ページでは，同様の懸賞が行われた例として，２０世紀初頭の "Orteig Prize" を挙げている。「ニューヨークからパリまで無着陸で飛行した者に $25,000 の賞金を与える」……チャールズ・リンドバーグの大西洋無着陸横断で有名な懸賞だ。

このような例から，航空産業の発展の過程に存在した多くの障壁は，技術上での問題よりも，むしろ精神面における障害の方が大きかったことを指摘している。今回の X PRIZE も，宇宙旅行というものが政府や大企業のみに独占されるべきものではなく，一介のベンチャー企業にも達成可能な目標であることを証明するために開かれたものなのだろうと思う。

現に X PRIZE には 20 を越える民間の団体が名乗りをあげており，その中には John Carmack 氏の率いる Armadillo Aerospace 社もエントリーされている。

Armadillo Aerospace 社は，純粋に X PRIZE の賞金を獲得することを目標として設立された会社だ。人員は Carmack 氏と数人の趣味人によって構成されており，その活動はボランティア性の高いものとなっている。もちろん，スポンサーは Carmack 氏自身であり， "Doom" や "Quake" において築き上げられた財産がここに注ぎ込まれているようだ。

Armadillo 社のアプローチのユニークな所は，機体の構造によって安定性を実現するのではなく，高性能なコンピュータとセンサ類を駆使し，フィードバック制御を利用して安定した飛行を実現するというところにあるようだ。この辺りが Carmack 氏らしいと言えば，らしいのかも……。

氏らは既にＶＴＶＬ（垂直離着陸装置）の駆動実験に成功しており，ヘリコプターからの落下実験にも着手しているようだ。技術力や資金面においては Rutan 氏らのプロジェクトに大きな差をつけられているものの，その差は人々が予想しているほど大きくはないはずだと Armadillo 社側は指摘している。

また， Rutan 氏らの率いる Scaled Composites 社のプロジェクトでは，フライト実験中に死傷事故が発生してしまったとの情報もある。

この不幸な事故は， Rutan 氏らの主導権を大きく削ぐばかりではなく， X PRIZE 自体の在り方に対しても疑問を投げかけることになるのではないかと思う。

しかし，何と言うか……少し皮肉な言い方をするならば， Carmack 氏にとっては id 社の命運よりも，ロケットを 100 km 上空へ届けることの方が重要な意味を持ちつつあるのだろうと思う。 Armadillo 社自体も，営利的なことはあまり考えて無さそうなところが突っ込みどころだ。賞金だけで開発費を回収できるはずが無いのだから，本来ならば，ベンチャー企業としての運用方法を考えていなければならないのだけれど……。

究極の趣味人としての氏の生き様が，ここに反映されているのだろうなと，個人的には受け取っている。

「ソース管理ツールを使っているか？」，「一発ビルドの方法を用意しているか？」，「バグデータベースを用意しているか？」，等々のような基本的なものから，「新しいコードを書く前にバグを直しているか？」，「スケジュールを常に守っているか？」などという，ちょっとドキっとするようなものまで，色々挙げられている。

「金の許す限りにおいて最も良い道具を使っているか？」なんてのは，ちょっと面白い指摘だと思う。最も速いマシンを使い，最も便利なツールを使うことが，開発の質を高める上で重要な条件となる，という指摘だ。

……と，ここで話が終われば単純だったのだけれど，どうしても１つだけ心に引っかかる項目があった。

８．プログラマが静かな場所で仕事をできるようにしているか？

氏の指摘によれば，プログラマは静かでプライバシの保てる状況に置かれたときに，最も効率良く仕事をこなすことができるとされている。一般にプログラマは，高度の精神集中状態…… "flow" あるいは "in the zone" 状態と呼ばれている……へと入り込んだときに，最高の効率を発揮することができる。これはプログラマに限った話ではなく，作家や科学者，スポーツプレイヤなどにも共通する要素であり，この状態こそが高度なプロフェッショナルとしての「仕事」をもたらすものと考えられているようだ。

ここで難しいのが，この "in the zone" 状態を作り出すには，相当の精神集中を保つ必要があるということだ。慣れた人でもこの状態を作り出すには平均で１５分程度かかるという指摘が挙げられている。しかもこの精神状態は，電話のベルや，他人の話し声のような些細な要因によって簡単に破られてしまう。それを防ぐために，個人の仕事場を壁やドアによって区切り，閉鎖したプライベートな空間を提供することが，高レベルな開発チームを構成する上で必須の条件となるということだ。

しかし，個人的に感じつつあることに，集団でのソフトウェア開発過程において……少なくともゲームの制作において……このような高度の集中状態を保つことが必須の条件となるのだろうか，という疑問がある。あるいは，それを頼りとすることが全体のクオリティに対してプラスの働きをもたらすのだろうか，という疑問だ。

例えばＸＰのような，チーム内における協調を重視する方法論においては，このような "in the zone" 状態の必然性は否定される傾向にある。ペアプログラミングなどがその最たるものなのだけれど，問題を個人の領域へと深く落とし込むのではなく，作業を協調させることによってリスクの分散を図ることができるという主張だ。ここでは，チーム内での協調状態を保つことこそが，そのチームの持つ最大のゲインを引き出す鍵となってくる。

これまでに見てきた文献の中においても，チーム内のメンバー間における相互干渉を強めることがメリットをもたらすという主張は，少なからず存在していた。逆に，相互干渉を強めることによって発生するリスクというものも存在するはずだから，その点において極論に走ることはできない。しかし，現在のゲーム制作の現場というものは，どうも個人主義を持ち込んでしまう傾向が強く存在するように思われる（これは個人的な感想だし，僕自身の経験に限定された評価なので，この主張を業界全体へと押し広げることはできないのだけれど……実際はどうなんだろう？）。もしかしたら，これをもう少し弱めることが良い結果をもたらすのではないか，と考えているわけだ。

だから，僕は敢えて Joel 氏の主張とは相反するものを提言したい……「仕事中にプログラマが黙りこくっていないか？」，「隣りの席のターゲット機用モニタが見える状態にあるか？」，「仕事を個人の領域に閉じ込めてはいないか？」，「プログラマ同士が内緒話をしてしまってはいないか？」，「メンバー全員と瞬時に会話のできる手段を用意しているか？」，等々……。

この主張には，下積み時代の経験に基づいているものが多少なりとも存在する。バイト時代には個人席というものが与えられていなかったために，常に隣人のモニタが覗ける状態で仕事をしていた。隣席が近いために無駄話も多かったけれど，そこを介して流れる有用な情報というものも少なからず存在した。そうして自然に情報の流れる状態を保っていたことが，今とは違った面白い状況を作り出していたように思える（正直なところ，あの感覚を正確に思い出すことは出来ないのだけれど……）。

「中途半端な仕事を見せたくない」という理論は，職場の外部へ対してのみ持てば良いだろうと思う。自然に情報の流れる状態を，時間をかけて丹念に作り上げる……それが集団としての "zone" を作り出すということなのではないかと思う。

この記事では，積極的な職場環境の改造から，体制の変化をも引き起こさせようとする，富士通の大胆な試みが紹介されている。

この記事の中でも，レイアウトに関して特に目に付くのが，「ハニカムレイアウト」と呼ばれる円形状の机配置方式を利用していることだ。この特殊な形状を用いることによって，通常の角型机を並べただけのレイアウトや，箱状のパーティションによって区切られたレイアウトとは異なる機能性を実現している。

６角形をベースとしたハニカム形状のレイアウトでは，「振り向いた際に会話範囲内に入る人数」が６人にまで増加するというメリットがある。これによって，会話による情報の伝達の円滑化や，即席での打ち合わせが可能になるなど，小集団におけるコミュニケーションを強化する上で様々なメリットをもたらしているようだ。また，構造的に不均一な円形配置を用いることによって，ヒエラルキーが机の配置に反映されるという現象を防ぐ意図もあるようだ。

休憩室的なスペース（ここでは「インフィニティ・コモンズ」と呼ばれている）をオフィスの中央に配置してあるのも，１つの意図を持ったデザインだ。小さな共有スペースを分散して配置するのではなく，オフィスの中央に全員の利用するスペースを用意することによって，異なる部署間でのインフォーマルなコミュニケーションを発生させることができる。

世間には「喫煙スペースが貴重なコミュニケーションの場になる」というような意見も存在するのだけれど（喫煙スペースは数が少ない上に全体からの利用率が高いため，特殊なコミュニケーションの発生する場となりやすいようだ），これをもっとスマートな形で実現しようというのが，この「インフィニティ・コモンズ」なのだろうと思う。「ゴミ箱も個人の机の横には置かずに，中央スペースなどに配置するようにした」などという徹底が，職場環境からのコミュニケーション強化を実現しようという強い意志として感じられる。

このようなシステマチックなレイアウトも存在する一方で，ゲーム業界において一般的に理想とされているのは，やはり古典的な「職人気質重視系」の職場環境だろうと思う。例えば，ポリフォニー・デジタル社の豊洲オフィスなどは，まさにその代表例として挙げられるものなのではないかと思う。

十分な広さの個人空間に，充実した設備群。空間を意識したレイアウトや，細部に洒落たデザインなど，「もの創り環境の理想系」を具現したオフィスとなっている。仮眠室やシャワー室などのような生活設備を充実させたことは，クランチ・タイム（いわゆる「追い込み状態」）の存在を，制作の過程において必須のものとして肯定したということなのだろうと思う。

このような古典的な「職人志向」の流れが，ゲーム制作の低リスク化と高品質化に対して必須の条件であるかというと，必ずしもそうではないだろうと思う。しかし，個人としてのタレントを重視する企業においては，このように，職人にとって満足の行く環境を提供し続けることが，離職率を低く保つ上で重要な役割を果たすのだろうと思う。

Windows Update をサボっているのがいけないんだよなあ……。ＰＣを数十分も操作していると，不意に svchost が落ちてしまう。とっとと対策を施したいのだけど，今から Update をかけると１時間以上かかってしまうようだ。うう，恨むべしナローバンド……。

夏休みの間，密かに ADSL への移行を申し込んでおいた。今週末には開通する予定だ。とりあえず，現時点で最高速の 24M タイプを選んだのだけれど，果たして実効でどの程度出るものか，今から楽しみにしている。

最初の１年の間，我々は１０人にも満たない人数の小さな集団であったため，同じフロア
の同じ空間を共有して働くことができていた。その「近さ」のおかげで，我々は直接に，
くだけたコミュニケーションをとることができていたわけだ。そして，多くの重要な仕事
の数々が，このような「くだけたコミュニケーション」によって促進されていた。

しかし，チームが成長するにつれ，我々はコミュニケーションに関して難しい問題を抱え
つつあった。そしてついには，技術グループが違うフロアへと移ってしまうと，他のグ
ループと「くだけたコミュニケーション」をとる手段は失われることになってしまった。

しばらくの迷走の後，我々は事態を認識し，ＩＣＱに助けを求めることにした。ＩＣＱは
強力なツールであり，そして時には，くだけた会話よりも良い効果をもたらすことがある。
ＩＣＱによるコミュニケーションは非常にくだけているため，意識せずとも直截的な指示
を行うことができるのだ。雑談も小話も要らないし，上品に振舞おうと緊張する必要も無
い。単に質問を書き込みだけで良いのだ。

上の記事でも指摘されているように，ＩＭツールによるコミュニケーションは，直接の会話とは少し違った性質を持っているように思える。心理的なことなのだけれど，前後に余計なやり取りを交わす必要が無くなるというメリットだ。本当に用件だけを手早く伝えたいのならば，意図的にＩＭツールを使うようにするのも手かもしれない。

また，ＩＭツールは，メールや内線電話によるコミュニケーションとも違った性質を持っている。メールは即時性が弱いし，簡潔な会話を交わすには仰々し過ぎるきらいがある。内線電話による呼び出しは，無理矢理に相手の作業を中断させてしまうし，不在時に対応を行うことが難しい。

ＩＭならば，それらの欠点を補い，即時性の比較的高いコミュニケーション手段を提供することができる。また，通常の会話並に揮発性が高いため，メールのように相手の持つ情報を無駄に増やしてしまうことも無い。

以上のような理由から，ＩＭツールの必要性は主張できるのではないかと思う。しかしここで，ＩＭツールだけでなくチャットも併用しているのは，チャットもＩＭツールと同じように，独自の特殊な性質を持っていると考えているためだ。

ＩＭツールは基本的に１対１のコミュニケーション手段であり，しかも，個々のメッセージが分断されてしまっているため，連続した会話を行いにくいという欠点がある。これに対して，チャットはｎ対ｎのコミュニケーションを提供する手段であり，しかも連続した会話を容易に扱うことができるという特徴がある。

ここで特に注目すべきが，ｎ対ｎのコミュニケーションを可能にするという点だ。１対１のコミュニケーションは，やり取りの手段としては簡潔である反面，会話を局所的なものへと閉じ込めてしまう性質を持っているように思える。このような「会話の閉じ込め」現象を防ぐためには，ｎ対ｎのコミュニケーション手段を提供する必要がある。そうすることによって，会話を全体的なものへと開放することができるのではないかと考えているわけだ。

例えば，あるバグの調査を２人のプログラマが協力して行っていたとする。なかなかデバグが進まないのだけれど，実は，この２人以外の第三者が決定的な情報を持っており，この第三者ならば容易にバグを直すことができたとしたら，どうだろうか。会話の通りの良い仕事場ならば，耳から自然と入ってくる２人の会話を聞いて，この第三者が助け舟を出しにきてくれるだろう。しかし，会話の通りの悪い仕事場の場合や，この２人がＩＭやメールを使って会話を行っていた場合，この第三者はそれを感知することができず，結果として２人が余計なコストを抱えてしまうことになる。

つまり，時には意図して「会話を垂れ流す」ことが，リスクの回避に役立つのではないかということだ。一見つまらなさそうな情報でも，それを集団という触媒に通してやることによって，「一個人の情報」から「集団としての情報」へと昇華させることができる。集団としての情報を共有し，集団としての状況を把握する……そのような体制を保つことが，集団としての最大の効果を得る上で必須の条件となるのではないかと思う。

以上のような理由から，第一に「会話の通りの良い空間」を作り出すことが重要になると考えている。オフィスのレイアウトの都合上，そのような空間を作り出すことが物理的に無理であると感じたならば，その代替としてチャットソフトを導入してみるのも良い手だろうと考えているわけだ。

同氏が MotoGP2 において利用した半球ライティングのテクニックについて解説した記事だ。

半球ライティングとは，上下２個の半球によって構成された環境光を，非常にシンプルな式（内積がたったの１回だけ！）によってモデル化したものだ。大域的なイルミネーションモデルのうち，最も単純なモデルであるアンビエントモデルに次いで単純なモデルであり，大域モデルの導入としては非常に扱いやすいものとなっている。

ポイントとなるのは，「上下２個の半球」という構成が，多くのシーンに対して適合するものであることだ。つまり，上の半球を「空」，下の半球を「地面」の色に対応させるわけだ。

半球ライティング自体については MSDN にある Philip Taylor 氏の解説が良い手引きとなると思う。

式の導出の過程については，狩野さんが詳しく解説している。

件の記事には "Radiosity Maps" なんていう仰々しい名前が付けられているものの，実際にやっていることはそれほど複雑なことでもない。前もって用意された２次元テクスチャ（コースの全景を上から平行透視でレンダリングしたもの）から地面の色を拾い上げ，それを半球光源の色として利用しつつ，半球ライティングを適用するというものだ。たったこれだけの処理で，地面の変化に合わせて細かく変化する環境光の様子をシミュレートすることができる。

ただ Hargreaves 氏の実装には，かなりの「近似」が加えられている。例えば，上半球の色（空の色）と下半球の色（地面の色）を一枚のテクスチャへと格納するために，ちょっとした圧縮処理が行われているのだけれど，この圧縮によって輝度の変化が失われており，比較的いい加減な環境光の導出が行われるようになってしまっている。

まあ，このテクニックを「環境光をそれっぽく変化させるためのエフェクト」として捉えるならば，この程度の具合でも問題無いかもしれないと思う。

もう１つ重要なのは，このゲームが，立体的な構造を持っていない（あるいは，非常に限定された立体構造を待つ）種類のレースゲームであるということだ。この前提によって，２次元テクスチャから環境光の色を拾い上げるというような処理の方法が可能となっている。一般的なアクションゲームなどにおいて同等のテクニックを実現するには，何らかの方法によって空間の分割を行わなくてはならない。またその場合，必要とされるデータ量は飛躍的に増えてしまうことだろうと思う。

MotoGP2 の例を見ていて気になる点は，オブジェクトの陰影がどうも「のっぺり」としているように見えることだ。これは，オブジェクト内における光の伝播（特に自己投影）が考慮されていないことに起因しているように思える。半球ライティングや IBL のように，全方位から照光を行う処理を導入すると，オブジェクト全体の輝度が均一化されてしまうために，どうしても陰影の薄い見た目になってしまうわけだ。

このような問題に対して，例えば "GT3" などは，「オブジェクトの窪んだ部分に対して暗い頂点色を割り当てる」というような人手による微調整を行うことによって，光の伝播の様子をカバーすることに成功しているようだ。このような微調整の類は，もう少しハードウェアスペックが上がれば PRT (Precomputed Radiance Transfer) のような技術によってシミュレートすることが可能となるかもしれない。

コストやスペックの制限から上のような対策が不可能であるならば，大域的な照光処理は用いずに，むしろシンプルなライティングを用いることによってメリハリのある陰影を作り出した方が無難かもしれないと思う。

Assembly'03 は 8/7 から 8/10 の４日間，フィンランドはヘルシンキの Hartwall Arena において開催された。来場者数は約 4,500 人ほどということだから，大学の学園祭ぐらいの規模を想像すればいいんじゃないかと思う。

手始めにチェックしてみたのは 64k intro 部門で 1st prize を獲得した "zoom3" だ。

このイントロはロシアの Dmitry Andreev 氏によって制作された作品だ。作曲以外の作業をほぼ１人で行っているらしい。

64k intro と言うと，個人的にはソフトウェアレンダリング系の職人芸的なデモなんかを連想してしまうのだけれど， "zoom3" に関してはそれは当てはまらないようだ。シェーダ系のテクニックを駆使したモダンなデモとなっている。かなりフィルを酷使しているようなので，グラフィック性能の良い環境でないと辛いかもしれない。職場のマシン (P4 2GHz + GeForce4Ti) でも，頻繁にスローダウンしているような感じだった。解像度を落とすと幾分スムーズになるので，やはりフィルが痛めつけられているのだろうと思う。

このデモの中で最も印象的なエフェクトは，やはり光と影の演出だろうと思う。 "zoom3" という名前からもなんとなく想像できることなのだけれど，ステンシルシャドウを利用した統一方式の照光処理を行っているようだ。あまり演出として効果的に使われている感じは無いのだけれど，「プログラマ受け」を狙うには十分な効果をあげられているのではないかと思う。

他のエフェクトも凝っていて面白い。画面には常に濃い画面エフェクトがかけられており，少ない素材からも深みのある表現を作り出している。そこへ別のエフェクトがアクセント的に差し込まれ，小気味良くトランス感を引き起こすような演出となっている。ただ，この辺りのエフェクトをスムーズに動かすにはかなりのフィル性能が必要とされるようなので，スペックの足りない環境では解像度を十分に落としておく必要があるかもしれない。

とにかく， 64k intro であることを忘れさせるほどのパワーを持った作品であることは間違い無いだろうと思う。

夏休み中に flipcode のチェックをサボっていたので，見逃していた分をまとめてチェックしてみた。とりあえず "Image Of The Day" をざっと見てみたところ，いつかの "candytron" (farbrausch) の投稿が載せられていた。どうやら，ファイナルバージョンがリリースされたようだ（以前見たのは party バージョンだった）。

実際に比較してみれば分かるのだけれど，ずいぶんと変更が加えられている。素材やエフェクトが追加され，演出にも磨きがかけられている。それでも依然として容量は 64kB だ。

件の記事には，イントロに関する簡単な解説が添えられている。それによれば，このデモには２つの「狙い」が存在したようだ。１つは高度な音声合成を行うこと，もう１つには高度なメッシュ処理を行うこと……メッシュの生成には，やはりサブディビジョン・サーフェス (Catmull-Clark surface) が用いられていたようだ。ファイナルバージョンにはサブディビを利用した演出も追加されている。

"PeerCast" は，その名前からも何となく想像できるように， P2P 技術を利用してストリーミング放送を行うというソフトだ。詳しい技術情報が手に入らない（さもなくばソースを読んでみるしかない……）ので，詳細については今ひとつ分からないところがあるのだけれど，とにかく，ピア同士のリレーによってチャネル情報とストリームの伝播を行っているということは確かなようだ。

特に面白いのが，ストリームの配信についても P2P 方式のメリットを活かしているということだ。 PeerCast サーバント（サーバ件クライアント）がストリームの受信を開始すると，受信側のサーバントはそれと同時に，そのストリームの配信も開始する（リレーを開始する）。そうすることによって，他のサーバントは配信元だけでなく，聴取を行っているノードからもストリームの取得を行うことが可能となる。このような方式のもとであれば，配信元の帯域が食い尽くされてしまう心配をする必要も無くなる……リレーを行っている聴取ノードの下に新たな聴取ノードをくっ付けていけば，いくらでもネットワークを広げることが可能となるわけだ。

このように PeerCast では，聴取という行為自体が PeerCast ネットワークの対障害性を支える要素となっている。たとえ配信側に広い帯域が無くとも，聴取側のリレーによってどこまででも裾野を広げることができるという仕組みだ。この特徴は，高度なインフラを持たない人（あるいは自らのインフラを犠牲にしたくない人）に対してもブロードキャスティングという行為を開放する可能性を持っている。

ただ，現状でほとんどのチャネルが１０人以下の聴取者数に留まっていることを考えると，ここで P2P 方式を持ち出す必要性というものも，少しあやふやなものになってしまうような気がする。例えば OggVorbis の 40 kbps ストリームを配信したとして，１０人程度までならば ADSL 回線でも支えることが可能だし，光回線サービスを利用すればその１０倍を支えることが可能になる。草の根レベルで１００人も抱えられれば，それは十分な数だろうと思う。

まあ，そんな調子だから，実際の対障害性が云々というよりも，「なんとなく有利そうだから」という理由で利用しているケースが多いのではないかと思う。ともかく，もう少し利用者が増えないことには，本当にこのシステムが有利なのかどうか見極めることは難しいと思う。

あとは， P2P 方式によってもたらされる「匿名性の高さ」に着目して利用しているケースも多いかもしれない。配信の行われているチャネルのリストを見渡してみると，法律的にグレーなコンテンツを扱っているチャネルが多いようだ。実際には，中央に管理を行う組織が存在しないというだけで，決して匿名性の高いものではないはずなのだけれど……。

すでにユーロ圏では販売が開始されており，セールス的にも良い結果を出すことができているようだ。

このソフト "EyeToy" は， SCEA の研究開発部門に所属する Richard Marks 氏が以前からテーマとして扱っていた技術「ゲームのためのビデオ入力法」を応用して制作されたものだ。

このゲームのシステムで面白いと感じたのは，画像入力という手段を，インタラクティビティを強化する手段として利用できていることだ。このゲームでは，被写体となるものであれば何でも入力に用いることができる。例えば， EyeToy のウェブサイトに置かれているデモムービーの１つには，複数のプレイヤが協力して「窓みがきゲーム」をプレイする様子が映されている。他にも，手に何か物を持つことによってリーチを広げることができるかもしれないし，友達と協力してアシュラマン風に「６本の腕」でプレイすることもできるかもしれない。それが簡単過ぎると感じたならば，今度は逆立ちしてプレイしてみるのも一興だろう。ともかく，そのように幅広いインタラクトの方法を持つことが，「現実世界の側での遊びの拡張」を可能にしていると感じたわけだ。

このような発想とは逆に，遊びの要素をゲームマシンの中へと押し込めてしまうことは可能だし，むしろ最近のゲームはそのような流れに向かっているように感じることがある。ゲームマシンの性能の向上に伴って，ゲームの中に作り出される世界の大きさは，とどまることを知らぬかのごとく広がり続けている。それでも依然として，ゲームとプレイヤの間に存在する接点というものは，「コントローラ」と「表示装置」という，極めて制限の高い２つのデバイスの中に閉じ込められてしまっている。

後者のようなベクトルも１つの可能性としては有り得るものだと思う。しかし，それとは別に，もう少し「遊び」の要素を現実世界の側へと押し広げるような方向性を見出すことはできないだろうか……。 "EyeToy" を見ていて感じたのは，そのような考えだった。

「直感性」や「新奇性」というものを狙って開発された特殊デバイスは，過去に多く存在するように思える。例えば，近年流行った音声認識などがその一端として挙げられるのだろうと思う。これは１つの可能性を感じさせる要素ではあるものの，多くの場合において，かえって「遊び」を制限してしまう方向へと働いてしまっていたように思える。音声入力という手段が「もう１つのボタン」や「選択肢を決定するキー」，あるいは「便利な入力手段」としてしか働いていないのではないか，ということだ。

この段階を越えるには，音声入力を使うこと……つまり「話す」という行為そのものが持つ「楽しさ」を探る必要があるように思える。例えば，プライベートな存在に対して話し掛けることのセラビー的な快感を追求するならば，それば「シーマン」となるのかもしれないし，喋りによって「演じる」ことの楽しさを追求するならば，それは「夜明けのマリコ」や「しばいみち」となるのかもしれない。特に，万人に対しての普遍性という点では，前者の例が良いコンセプトを持っていたように思える。

こうしたインタラクトの幅を広げる１つの方法として，最近ユニークな存在だったのが「ボクらの太陽」だ。プレイヤはカートリッジに取り付けられた「太陽センサ」によって「太陽エネルギー」を貯めることができる。この「太陽エネルギー」は，ゲーム中のミッションをクリアする過程において度々必要とされることになる。このような要素を持つことによって，プレイヤはただゲームをプレイするだけでなく，「太陽」という存在との係わり合いを「遊び」の一環として取り入れることができるようになる。

プレイヤが一秒後にボタンを押すか押さないかの判断よりも，太陽光を求めて歩き回ることの方が遥かに高い複雑性を持っていることは疑いようもないことだ。そして，そこからもたらされる体験の数々が，このゲームを特殊な存在として印象付けることになる。

ただ，太陽センサが「ゲージを高めるためのＣボタン」になってしまうようだと，少し勿体無いものがあると思う。もう少し「太陽光を浴びる」行為自体に楽しさを生み出すような要素が用意されていると良いと思うのだけれど……。

このような方向性を考えていく上で，微かな記憶の中から思い出されるゲームが，もう１つある。ちょっとした伝説のソフト……「びっくりマウス」だ。

このゲームのシステムで良いと感じたのは，「絵を描く」という行為自体に対して楽しさを付け加えるようなコンセプトを持っていることだった。マウスを使って描く線から草が生えてきたり，丸を書くとそれが太陽となって光り輝き始めたり，あるいは，絵を描くことによってゲームの目的を達成したり……というふうに，絵を描く行為そのものがゲームに対してのインタラクトとして存在していた。ここで大切なのは，絵を描くという行為が，プレイの過程を担う１つの要素として終わってしまうのではなく，その行為自体が楽しさの本質として捉えられていることだ。

ここから広げることのできる世界は，意外と広大なもののように思える。例えば，絵を描くという行為には様々な種類の要素が存在する。「上手い」絵を描くこと，「下手な」絵を描くこと，大きな絵を描くこと，小さな絵を描くこと，素早く大雑把に絵を描くこと，ゆっくりと緻密な絵を描くこと……等々。どんなに絵の下手な人であっても，絵を描いた経験は必ず存在するはずだし，また，どんなに小さな子供であっても，あるいは高齢なご老人であっても，絵を描く能力は持っているはずだ。原始人だって自ら進んで絵を描いたぐらいだから，きっとそこには原初的な楽しみが存在するのだろうと思う。

そこに着目するならば，単に「自分の描いた絵がゲーム中で動く」だけではない，もっと広いレベルでのインタラクトを持つことが可能だと考えている。

何となく興味は持っていたのだけれど，今まで聴くことのなかったキリンジの曲たち。今になって聴かなかったことを後悔するぐらいに，いい感じだ。基本的には「はっぴいえんど」の生まれ変わりみたいなフォーク・デュオなんだけれど，そこに気だるくも柔らかいボーカルと，すました感じにクールな歌詞が乗せられ，気持ち良くも心に響き渡るようなサウンドを生み出している。

ともあれば同じような曲ばかりになってしまうコンセプトの中にあっても，注意深く洗練されたコードの運びと軽やかなメロディーが，オーディエンスの期待を裏切らない範囲において，最大の個性を発揮するよう仕組まれている。要するに，「こういう曲が聴きたかった」と思う曲ばかりが次々に出てくるという凄さが，このデュオの計り知れない魅力なのだろうと思う。

ところで，キリンジ兄こと掘込高樹氏がナムコの音楽スタッフだったというのは，けっこう有名な話らしい……。

ネットラジオを聴取していて１つ不思議に思うのは，配信側がどのようなモデルによってビジネスを成立させているのか，という点だ。ただ単に趣味でラジオ局を運営するにしても，様々な法律に基づいて請求されるロイヤリティを支払わなければならないわけで，そこでどうしてもビジネスとして成立させなければならないという事情が介在することになる。

例えば "Spinner" や "Live365.com" のようなネットラジオ局では，プレイヤの隙間に表示されるバナー広告や，曲の合間に挿入されるＣＭによって得られる公告収入のほか，現在流している曲のＣＤを amazon 等の通販サイトから購入するためのリンクを常に表示しておき，そのリンクから購買が発生した場合にもたらされる「紹介料」をも収益源として利用しているようだ。

どうやら "Live365.com" の方は，有料会員を募ることによって，会員料からも収益を得ようとしているようだ（会員になれば公告の類をカットすることができる）。もう一方の "Spinner" の方はと言うと，随分前に AOL に吸収されてしまっており，なんだかもう，どうでもいい存在となってしまっている。いちおう先駆け的な存在だったはずなんだけどなあ……。

このように，アメリカでは大小含めて様々な形態でのネットラジオ局が隆盛している状況だったのだけれど，最近では DMCA （デジタルミレニアム著作権法）の流れで，音楽配信についてのロイヤリティ徴収方式が改変されることとなってしまい，一部では大変な騒ぎとなっているようだ。この決定によれば，従来のような収益からの割合ではなく，配信を行った件数からの勘定が行われるために，多くの局にとっては「収益よりもロイヤリティの支払いの方が上回る」状態となってしまう。しかも DMCA が制定された 1998 年まで遡って全部払い直すことを要求されているものだから，すべての局にとって大きな打撃となることは間違いないようだ。

例えば，インディペンデント系のネットラジオ局として有名な "Digitally Imported" などは，広告も何も表示されない良心的なラジオ局のひとつなのだけれど，この場合，従業員のほとんどはボランティアとして運営に従事しており，それでも賄い切れない分については，ユーザからの寄付によって補っているという状態であるようだ。

まあ，このように「まともなこと」を行っているラジオ局はむしろ少数派であり，小規模な「草の根局」のほどんどはロイヤリティの支払いなど完全に無視して配信を行っているというのが実情のようだ。

で，日本の場合はどうであるのかと言うと……なんだかこの辺りは JASRAC 云々とか絡んできて，随分とややこしい話になってしまっているようだ。うー，調べるの面倒だな……。

「ＡＩミドルウェア」なんてのは，一般に言って馴染みの薄い概念なのではないかと思う。開発手段の１つとして認知されつつあるグラフィック関連のミドルウェアとは違って，実際の制作現場における使用例は殆ど存在しない状態であり，また，それによってどのような効果が得られるものなのかという点についても認知がなされていないように感じられる（ていうか，まず，僕が何も分かっちゃいない！）。

例えばＧＤＣにおけるＡＩラウンドテーブルのレポートを覗いてみても，ＡＩミドルウェアに対する風当たりの厳しさがまざまざと受け取れるような内容となっている。

セッションの終わりには，ＡＩミドルウェアの可能性に関して小さな討論が行われた。
そして，我々がそれについて詳しく触れようとすると，ミドルウェア開発者の方々が
ここぞとばかりに張り切ってプレゼンを始めだした。出席者に簡単な挙手を求めてみ
たところ，現時点で利用可能なＡＩミドルウェアを実際に導入している，あるいは導
入を検討している，という人は１人も居ないようだった。その理由には様々なものが
あるものの，基本的には以下のような２，３の意見に分類される。

コントロールの問題：多くの開発者は，ＡＩミドルウェアが自分たちの必要とする基
本的なコントロールを提供できていない感じている（後略）

デザインの問題：多くの開発者は，ＡＩミドルウェアが必然的にゲームのデザインを
左右すると考えており，これは本質的に許容できない問題だとしている（後略）

機能性の問題：多くの開発者は，既存のＡＩミドルウェアが自分たちの必要とするレ
ベルの機能性を十分に提供できていないと考えている（後略）

そんな厳しさの中にあっても，ミドルウェア開発元として最大手の Criterion 社が "RenderWare A.I." の提供を開始するなど，最近になって新たな動きが続いている。どうやら，ツール＆ミドルウェア業界においては，ＡＩという分野が未開拓の新天地として考えられているようだ。

ちなみに，この "RenderWare A.I." の開発は，ゲームＡＩ関連のベンチャー企業である仏 Kynogon 社が担当している。

ＡＩミドルウェアと言うと，実際に利用したプロダクトが皆無なだけに，何とも評価しにくいものがあるのだけれど，もし実際に利用した製品が登場するとしたら，露出の高さから言って，この "RenderWare A.I." が最も早くなるのではないかと予想している。

ところで，先日，軽い興味からこんな本を購入してみた…… "AI Game Programming Wisdom" だ。

"Game Programming Gems" シリーズの出版元として有名な Charles River Media からの出版となっている。構成や装丁も GPG とほとんど同じような内容となっており，実際にゲーム開発の現場に従事する開発者達が，自らの持つＡＩプログラミングのノウハウについて様々な内容の記事を寄稿している。

本の全体の監修は， GPG におけるＡＩセクションの監修者としても有名な Steve Rabin 氏が担当している。もちろん，氏自身も数個の記事を寄稿している。

それで，肝心の内容の方はと言うと，「良くも悪くも GPG と同じような感じ」というのが率直な感想だ。恐らく誰にとっても，参考になるものはなるし，ならないものはならないと思う。最初から最後まで読み通せば実になるという種類の本ではないことを認識しておくことが必要だ。

ただ，ＡＩという概念はゲームデザインと密接に関わりを持つ要素であるだけに，様々なゲームデザインに対応できるだけのレパートリーを蓄積しておくことが重要なタスクとなるように思える。そのような目的において，この本はプログラマに対して即席の知識を与えてくれる参考書となるはずだ。例えば， RTS を作れと言われたら第８章の "FPS, RTS, and RPG AI" が参考になるかもしれないし，レーシングゲームを作れと言われたら，第９章の "Racing and sports AI" が参考になるかもしれない。

ともかく，ＡＩという分野に対して新たな挑戦を試みようと考えている人にとっては，この本の内容が良いスターティングポイントとなってくれるはずだ。七千円という価格は，個人で買う分にはちょっと高いようにも思えるけれど，会社の金で買えるんだったら買っておいて損は無いのではないかと思う。

ざっと見た感じでは， "AI.implant" は３Ｄツール (Maya, 3D Studio Max) との統合に優れており， "DirectIA" は意思決定のフレームワークとして高い完成度を得ているという印象を受けた。また "RenderWare A.I." については，何と言っても "RenderWare Platform" との強力な統合機能を備えていることが魅力だ。

これらのミドルウェアが開発者に対して提供する機能は，主に，経路探索処理 (pathfinding) ，意志決定処理 (decision-making) ，挙動制御処理 (behavior modeling) の３種に分類することができると考えている。

この中でも最も基本的なＡＩ処理であるところの経路探索処理は，基本的にどのミドルウェアもサポートしている機能だ。数あるＡＩ処理の中においても，経路探索処理はモジュールとして独立させやすい特性を持っているため，これを他のコードから分離されたライブラリとして実装することは，理に適った設計のように思える。

経路探索処理においては，処理に必要とされる「経路データ」（ナビゲーションメッシュやウェイポイント等）の作成方法が重要な論点となる。これを自動的に生成する機能があるかどうか，また，これを編集するツールが使いやすいものであるかどうかによって，ゲームデザイナの負担する作業コストが大きく左右される可能性があるからだ。

この問題に関して AI.implant と RenderWare A.I. は経路データの自動生成機能を備えており，また，経路の編集を行うツールも標準で用意されている。そのため，一般的な経路処理……例えば，アクションゲームにおいて敵キャラが用いる経路処理や，ＲＰＧにおいてＮＰＣが用いる経路処理……については，かなり完成された環境が最初から用意されている状態であると考えて良いかもしれない。

意思決定処理は，ＡＩ処理の要とも呼べる機能だ。これには様々な方式が存在しており，上の３つのミドルウェアについても，それぞれ異なったユニークな方式が用いられている。

AI.implant の場合は，意思決定処理としてルールベースシステム（「プロダクションシステム」とも呼ばれる）が用いられている。ルールの記述には単純な二分決定木 (BDT; Binary Decision Tree) を利用することから，本格的なルールベースシステムというよりかは，「単純な "if-then-else" 列による条件判定」とみなした方が正しいかもしれない。

ここで用いられる BDT は，付属のツール（３Ｄツールのプラグインとして統合されている）を使って編集することができる。このツールを上手く運用すれば，いわゆる「思考ルーチン」と呼ばれる部分の挙動を，プログラマの手を介さずに細かく調整することが可能となる。このことは，ゲームデザイナ側におけるＡＩの多様化を考えている場合には，重要なファクタとして働くかもしれない。

ただ，これは意思決定のプロセスとしてはあまりにもシンプルな方法であるため，この仕組みによって特定のゲームデザインに必要とされる機能をすべて実現できるかどうか，という点に関しては難しいものを感じる。

DirectIA の方は，意思決定処理のフレームワークとして "agent-based behavior modeling system" と呼ばれるシステムを備えている。これは，どちらかと言えば本物のルールベースシステムに近い内容であり，本格的な「人工知能」としての仕組みを提供するものとなっているようだ。他にも，個々のルールを記述するために用いられる独自のスクリプト言語や，ＧＵＩによるインタラクティブなテストツールなど，運用をより効率的なものとするための機能が色々と備えられている。

ただ，このフレームワークはあくまでも「仕組み」の部分であり，実装をより簡便なものとするために必要となる「道具」の部分に関しては，いまいち不足しているような印象が見受けられた。（これは記事から受けた印象であるから，実際とは異なる可能性が大いにある）。ここまでストイックな構成だと，「これならば１からＣ＋＋で組むのとさほど変わりないのではないか？」という疑問が湧いてくる。いまいち「これを使えばゲームとしてのクオリティを上げることが可能である」というような，明確なセールスポイントに欠いていることが，「押しの弱さ」に繋がっているわけだ。

ただ，この製品はまだ発売されていない上に，詳細について不明な点も多い。ゆえに現時点では，この事例から AI.implant の評価を行うことは難しそうだ。

AI.implant については，ＣＧプロダクション向けに制作されているという背景もあり，ＣＧツールとの連携や，「挙動の自然さ」という点において強みがあるように思える。しかし，このまま大した顧客も付かない状態が続くようだと，開発が打ち切られてしまう可能性も危惧されるのではないかと思う。通常のミドルウェアについても現実には厳しい展開が強いられているというのに，ましてやＡＩミドルウェアというような特殊な製品において安定した未来が待ち受けているかと言うと，とてもそうは思えないというわけだ。

そういった面を考慮すると， RenderWare のように「既に実績のある」，あるいは「安定した資本が背景にある」（Criterion 社は Cannon の傘下にある）という状況は，開発者にとって強く魅力として映るのだろうと思う。

これは，名前からも何となく察しがつくように，湾岸戦争および先のイラク戦を題材として扱った mod だ。連合勢力 (Coalition) と，反抗勢力 (Opposition) の２チームに分かれて戦うことになる。比較的地味な兵器ばかり登場する BF1942 とはうって変わって，近代的で派手な兵器が多数登場するところが痛快で面白い。Ｍ１エイブラムズで砂漠を快走したり，ＲＰＧでブラックホークを打ち落としたりすることも可能だ。このあたりの「シチュエーションに浸り具合」が，多くの米国ティーンの心を鷲掴み状態なんだろうなあと思う。

とまあ "DesertCombat" 自体は良く出来た mod の１つなのだけれど，これが無料で配布されていることに驚きを感じる。かの有名な "Counter-Strike" が無料の mod として開発されたことは有名だけれど（開発者である Minh Le は当時ただの学生でしかなかった）， DesertCombat の方はそこそこまともな規模のチームが主体となっており，そのリソースは果たしてどこから提供されるものなのだろうかと，疑問を感じてしまう。

この場合， DesertCombat が結構ヤバい内容を扱っているというのが，興味を惹かれるところだ。世にテロリストを殺すゲームは多けれど，これは「テロリストは完全な犯罪者である」という共通認識があるからこそであって，「米国軍がイラクに侵攻するゲーム」が堂々と作れるかというと，ちょっと難しいものを感じる。……いやまあ，作っちゃってる所もあるけど。

この monzy.com は，色々とアホなことをやらかしている陽気なナイスガイ "Monzy" こと Dan Maynes-Aminzade 氏の個人ページだ。なんて言うか，こういう陽気なアメリカ人は行動力が計り知れないから恐ろしいと思う

と，ここで終われば話は単純なのだけれど，実はこの Monzy 氏は， "Tangible Media" （"Tangible" は「触れることのできる」という意味を持つ）の研究で有名な MIT Media Lab の石井研究室に所属する修士生だ。

MIT Tangible Media Gruop と言えば，最近，未来的音響デバイス "Audiopad" が slashdot などにおいて話題に上げられていた。

他にも，プロジェクトの紹介ページを覗いてみると，いろいろと面白い研究が紹介されている。

この中にある "Actuated Workbench" などが Monzy 氏の関わった研究だ。

と，ここで真面目な研究ばかりやっていてくれれば話は単純なのだけれど，そこはさずがの Monzy 氏というか，ここでもとんでもないことをやらかしてしまっている。氏が CHI 2003 (Computer Human Interface Conference) に出展した "You're In Control" と呼ばれるシステムが，とんでもない曲者なのだ……。

もう，画像を見れば一発で何をするものか分かると思うんだけど…… "You're In Control" = "UrineControl" ということで（Urine は「尿」を意味する単語），小便器と尿をコントロールデバイスとして使うという，前代未聞のシステムだ。

この論文によれば "You're In Control" プロジェクトの位置付けは以下のようなものになっている。

排尿行為は基本的な身体機能を果たしているだけでなく，社会的な重要性を持つ行為でも
ある。放出によって気分を爽快にするだけでなく，自らのテリトリを印付けるという原始
的な欲求も満たすのである。女性ならば，トイレに集まり近所様とお喋りを交わすことが，
付き合いにおける重要な儀式となっている。男性ならば，雪に自分の名前を書いたり，タ
バコを消したり，あるいは街灯柱の周囲に集まって，自らの男らしさを主張する勝負とな
ることもある。

"You're In Control" プロジェクトは，コンピュータ技術を利用することによって排尿行
為を拡張しようという試みである。我々は，排尿行為にインタラクティビティを追加する
ことが，娯楽面や衛生面，それから教育面において価値のある応用であると考える。

つまり，このシステムによって，ええとその，「コントロール」が上手くなれば，トイレの掃除の手間を減らし，衛生性を向上させることが可能になるという理屈だ。まあ，そんなことはさておき，ウェブページにリンクされているビデオを観てみれば，陽気なアメリカ人達が便器に水をかけてゲヒャゲヒャ楽しんでいる姿を見ることができるはずだ。デモのために "Custom input controller" まで用意したってんだから，なんとも周到なことだ。

そんな感じで，この研究は MIT のバカ研究の１つとして有名なものとなっているようだ。なんだかなあ……。

最近は GDAlgorithms-List のログをほとんどチェックしなくなってしまったのだけれど，こんな感じで興味の惹かれる話題があると，たまに内容をチェックしてみている。結局のところ，言語の壁を乗り越えるのが辛いものだから，雑談レベルの話まで追いかけるのは難しいと感じてしまうのだ……。

件のスレッドにおける議論の内容は，「60 Hz とは本当に重要な意味を持つリフレッシュレートなのか」というものだ。この点に関しては，ゲームの種類によって特性というものが存在するだろうから，一概にどれが良いと決めてかかることはできないだろうと思う。

例えば，あまりゲームとは関係無いのだけれど，ビデオ撮影されている最近の「水戸黄門」シリーズは，どうにも安っぽい印象があって，あまり好きでは無い……やはり時代劇はフィルム撮影であって欲しいと思う。フィルム映像の持つ鮮やかな色の再現力と，24 Hz という動きの柔らかさが，独特の「枯れた」雰囲気を作り出している。もちろん，そのような雰囲気が適するゲームも存在するのだろうと思う。

このスレッドにおいて，もう１つ取り上げられているのが，「表示装置のリフレッシュレートを越えたフレームレートを感知できるプレイヤが存在する」という話だ。議論に参加している数人の投稿者によれば，超スゴ腕級の Quake プレイヤ達は，表示装置のリフレッシュレートを遥かに超えたフレームレート（例えば 300 Hz など）を好んで利用しているという。最新のグラフィック環境を揃えた上で，表示系のオプションを最低精度にまで下げ，画面同期オプションを無効にすることによって，そのような超高フレームレート状態をわざわざ作り出しているということだ。

この現象に対する Thatcher Ulrich 氏の解説が面白い。氏は UNC の Marc Olano 氏が行った研究を参考に挙げている。"Combatting Rendering Latency" ……レンダリングシステムにおける表示遅延を極限まで下げる方法について扱った論文だ。

通常，CRT の画面更新は，画面の左上から右下へ向かって，走査線に沿って行われる。この画面更新にかかる時間が 1/60 sec = 16.7 ms であり，つまり画面左上の画素が表示されてから，画面右下の画素が表示されるまでには，実に 16.7 ms の遅延があるということになっている。これは，ほとんどのアプリケーションにおいては大した問題とならないものの， Olano 氏が研究で扱っているような HMD (head-mounted display) 装置では軽視できない問題となるようだ。 VR (Virtual Reality) や AR (Augmented Reality) においては，僅かな反応の遅れがユーザに対して違和感を覚えさせることとなり，没入感を減少させる原因となるからだ。

そこで用いられるアイデアが "Just-In-Time Pixels" (JITP) という方式だ。これは，画面上の各画素が更新される正確な時間を推定し，その時間における正しいレンダリングを画素毎に行うというものだ。この方式を適用した上で高速にカメラを回転させると，上のページの Plate 2 にあるように，上下で剪断された画像が生成される。これは一見しておかしな結果のように思われるかもしれないけれど，実際にこのような視点の移動を行いながら表示を行うと，むしろ歪みの無い画像として認識されるということだ。

ただし，本当の "JITP" を行うには，１画素毎にレンダリング環境の更新を行う必要がある。これはさすがに負荷が高過ぎるということで，これを走査線毎に行う方法や，あるいは左上と右下の２点でのみ行い，その間は線形補間によって補うというような方法も挙げられている。また，表示物に対して上の画像 (Plate 2) に見られるような剪断を施すことによって， JITP に近い効果を極めて低負荷で得ることが可能かもしれないと Ulrich 氏は指摘している。

正直なところ，このマシンにはあまり興味を持っていなかったのだけれど，７月に行われた詳細なスペックの発表以来，強く興味を惹かれている要素が２つだけ存在する。１つは Universal Media Disk - "UMD" の存在と，もう１つは無線ＬＡＮ (IEEE 802.11) インタフェースの存在だ。先の発表において IEEE 802.11 インタフェースが搭載されると聞いた瞬間，俄然，このマシンに対する興味が湧いてきた。つまるところ，それ以外の機能はどうでもいいとさえ考えている。

無線ＬＡＮに関してはズブの素人なので，まずは軽く IEEE 802.11 の規格について調べてみることにした。どうやら Intel の How-To サイト内にある「快適ワイヤレスライフ」のページが分かりやすくて良さそうだ。

ここでも説明されているように，「アクセスポイント」を介して有線ＬＡＮやインターネットへ接続することが，無線ＬＡＮの主な利用形態となっている。ＰＳＰに搭載される予定の IEEE 802.11 インタフェースも，ホットスポット等のアクセスポイントを介してＬＡＮ対戦やインターネット対戦を行うことが，主な使い道として想定されているのだろうと思う。

しかし，それよりも面白そうなのが「アドホックモード」の存在だ。この「アドホックモード」では，アクセスポイントのような中継機を介すことなく，端末同士で直接に通信を行うことが可能となっている。衝突による通信効率の悪さなどは存在するものの，接続ケーブルやアクセスポイント等の特殊な機器を用いることなく即席にコネクションを確立できるというのは，だいぶスマートな感覚だ。それでいて，赤外線通信のように不安定で低速なコネクションに悩まされることも無い。

ここで更に面白いのは，アドホック通信のリレーを行う……つまり，いわゆるＰ２Ｐ方式のリンクを繋いでいくことによって，比較的広域なネットワークを形成することが可能であるということだ。このような通信方式のことを「アドホックネットワーク」あるいは「ワイヤレスＰ２Ｐ」と呼ぶらしい。

ワイヤレスＰ２Ｐについてはスカイリー・ネットワークス社の梅田英和氏が先進的な研究を行っている。同社ではアドホックネットワーク用のミドルウェア "DECENTRA" を提供しているほか， Bluetooth 通信を利用したワイヤレスＰ２Ｐ携帯端末 "Gadgety" の開発なども行っているようだ。

スカイリー社の取り組んでいるような試みが，ひとつの技術として確立されれば，特殊なアクセスポイントやＩＳＰを介すことなく，携帯端末のみによって比較的広域なネットワークを形成することが可能となるかもしれない。そこでは，100m 圏内に存在する端末同士が結合や分離を繰り返すことによって，有機的に変化するネットワークを生み出すことになる。ユーザはそのネットワークに対して自由に情報を放ったり，あるいは受け取ったりすることができるようになる。

IEEE 802.11 の仕様には詳しくないのだけれど，アドホックモード時にブロードキャスティングを行うことができるようであれば面白いと思う。これによって，有線ＬＡＮの持つ静的な特性に縛られない，無線ならではの新たなネットワークの様式を生み出すことができるかもしれないと考えている。

微妙なニュアンスの問題なのだけれど，ここで重要だと感じているのは，ＰＳＰが「実感のある距離範囲に制限された無線通信手段を持つ携帯機」であることだ。これは，「どこでも，どこへでも接続可能な携帯電話」や，「据え置き機の持つ広帯域な有線ネットワーク」とは，まったく異なった性質を持つものだと考えている。梅田氏の言葉を借りるならば，これが，情報の伝達という行為に対して「距離」を楽しむ要素をもたらすものだと捉えているからだ。

沢山あるのですが、“距離”を楽しめることが特徴だと考えてます。ホットスポットと呼
んでいるのですが、「DECENTRA」を使って情報を発信するポイントになる地点を、駅なん
かに設置しておくわけです。そしてそこから、「次に来る電車の何両目が比較的空いてい
ます」なんて情報をホームにいる人だけに流せる。CDショップの前を通ると音楽のランキ
ング情報が流れてきたりとかね。応用して実際に現場に行かないと謎が解けないゲームな
んかもできてしまう。もちろんその情報をさらに自分が発信源になってさらに周囲に広げ
ることもできるんです。

インターネットによって“距離”という概念を意識しないで情報をやり取りできるように
なったからこそ、逆に“距離”を感じる新しい情報伝達ツールを提供したいんです。

ＰＳＰに与えられた無線ＬＡＮという要素は，ゲーム機に対して「距離」の概念を追加する手段になると考えている。これは，「距離や位置を得たいんだったらＧＰＳを積めばいい」という話ではない。重要なのは，ＰＳＰが人間に対して無線通信という「第六のセンス」を与え得るということだ。

無線ＬＡＮの通じる距離（１００ｍ程度）というものは，人間にとって「近さ」を実感させる距離の限界だと考えている。その範囲に対して万能の知覚を与え，そこに存在する情報や個体に対してアクセスする手段を与えるのがＰＳＰだ。それは，コンピュータの中に作り出された仮想空間の中に「代替現実感」を求めるのとは，本質的に異なったアプローチになると考えている。むしろそれとは逆に，現実の世界を強化し，より多面的な情報の与え方というものを定義するものとなるかもしれない。

ＰＳＰに付加された他の機能は，もはやただのインタフェースでしかない。ましてや，ＰＳＰは「ただの持ち運べるゲームマシン」ではない。無線によってもたらされる新たなエンターテインメントの探求こそが，このマシンに与えられた唯一の使命なのだと，気違いじみたことを勝手に夢想している。

まあ，そんな感じのものは，前からあったわけだけれど……。

内容の方はと言えば，よく見る感じの典型的な Postmortem 記事となっている。「チーム内の活発なコミュニケーションが良い影響をもたらした」，「周到に用意したデバッグシステムが役に立った」，「人材の不足に苦しんだ」，「ゲームデザインの紆余曲折に苦しんだ」，等々。どこのプロダクションでも繰り返されているような成功と失敗の事例がずらっと並べられている。

ただひとつ，「コンシューマ機での開発経験が無かったために，ＰＣとのスタイルの違いに苦しんだ」というようなことが述べられているのだけれど，これは逆に，自分がコンシューマ機での開発経験しか持っていないために，ユニークな意見のように感じられた。どうやら，ＰＣ向けのゲームの開発においては，仮想メモリの存在をあてにしてメモリを浪費してしまうという，一種の「気の緩み」が，少なからず発生してしまうようだ。

このようなメモリ管理の「甘さ」は，コンシューマ機においては致命的な問題を引き起こす危険性を持っている。メモリの不足が即座に「重大な欠陥」へと結び付いてしまうからだ。

ひとつ面白いのは，HUD (heads-up display) 等の表示系統のデザインに Macromedia Flash を利用していることだ。Flash 上でレイアウトやアニメーションの編集を行い，それをゲーム中に再生する，というような方式を採っているようだ。同様の方法によって表示系統をデザインしているという事例は，最近よく耳にするようになったと思う。

同様の工程を Maya や 3DS Max 等のＣＧツールによって実現することは可能だ。しかし，Flash 自体が持つオーサリング環境としての完成度の高さや，運用面での簡便さなどが影響し，「なんとなく Flash を使ったほうがいいかもしれないね」というような風潮が強くなっているように思える。

実のところ，「運用面での簡便さ」という要素が，決して無視できない力を秘めているように思える。基本的に価格が安く，また他のＣＧツールと比べて一般性の高い機材であるがゆえに，アウトソーシングを行う際に有利に働くという側面が存在するようだ。実際に "Star Wars Starfighter" の開発においては，デザイン作業の一部を Orage Design という外部の会社へと分散させた経緯が述べられている。

また，他言語へのローカライズの際にも，Flash の持つ簡便性が有利に働くことがあるようだ。確かに，言語が変わるだけで表示系統のレイアウトは随分狂うものだから，この修正が簡単に行えるようになるとしたら，それはとても便利なことかもしれない。

……というように，なんとなくメリットは思いつくのだけれど，僕自身は Flash を使ったことが無いし，僕の周囲にも強力な推進派が居るわけではないので，そこで決定的な動機を見つけることができないでいる。結局のところ，なん

Bug Tracking (4)

Bug Tracking (5)

Mailinator

夏休み

夏休み

買物

Popular Science

Into The Zone

オフィスレイアウト

W32.Blaster.Worm

Instant Messenger

Hemisphere Lighting

zoom3

ADSL

EyeToy

DMCA

AI Wisdom (1)

AI Wisdom (2)

呑み

AI Wisdom (3)

DesertCombat

You're In Control

Combatting Rendering Latency

Playstation Portable

Star Wars Starfighter