2003-12-01
休日を利用してウェブの模様替えを行ってみた。BF1942 を絶ったおかげで，やっとまともなことに休日を使えるようになったような気がする。
このページの生成には自前の Python スクリプトを利用しているのだけれど，このスクリプトに手を加えるのも久々のことだと思う（最後に改造を行ったのがちょうど一年前だ）。これまでに色々と溜まっていた不満点を一気に改善することにした。
文字のエンコーディングに UTF-8 を導入したのも，それらの改良点の内のひとつだ。これで，単一のテキストの中に様々な言語を混在させることができるようになった。
普段の文章を書く分にはそれほど必要な機能でもないのだけれど，例えば人名や地名等の固有名詞を記載する際などに，歯痒い思いをしなくて済むようになる。
もうひとつの大きな変更は，ページのデザインにスタイルシートを導入したことだ。以前は，スタイルシートの適用されない環境でも同じような見た目を保てるように，かなりレガシーに縛られた設計を行っていた。しかし，もう MS-IE と Mozilla (Gecko) 以外をベースとした環境は考えられにくいし，たとえユーザが Lynx を使っていたとしても，下手にテーブルなどを濫用するよりかは，潔くスタイルシートを導入した方が，かえってプレーンな構成となって読みやすくなるに違いない，という結論だ。
デザインの内容に関しては "Open Source Web Design" から拝借してくることにした。
Open Source Web Design - "OSWD" は，多数の「フリー」なウェブデザインソースの配布を行っているアーカイブサイトだ。同サイトの解説ページには，サイトのコンセプトが次のように述べられている。
http://www.oswd.org/about.phtml
まあ，そんなわけで，これを使わない手はなさそうだ。 MovableType のスキン並にお手軽というわけには行かないけれど，出来合いのデザインにちょっと手を加えるだけで，あっと言う間に垢抜けたページを用意することができてしまう。
数百もあるデザインの中から選んだのは，haran 氏の "Gila" だ。
http://www.oswd.org/userinfo.phtml?user=haran
厳密に CSS と XHTML のみで構築されているのが素晴らしいと思う。これが，現時点で最も妥当なウェブデザイン方法だろうと思う。安心して XML + XSLT に移行できるようになるのは，もうちょっと先の話になりそうだから……。
2003-12-02
このページのスタイルシートでは，フォント (font-family) として "Verdana" を指定している。 "Verdana" フォントは， Windows に標準で含まれているフォントの中でも，特に気に入っているフォントのひとつだ。スリムなデザインの中に清潔感と安定感の両方を兼ね備えており，また，大小のどんなサイズでも見た目の良さを保ち続けてくれるため，フォントとして使い勝手が非常に良い。これに対して，例えば "Arial" などは，サイズが大きくなるに従って見た目の単調さが目立ってしまうし，逆に見た目の凝ったフォントでは，小さなサイズでの可読性が低くなる傾向にある。
最近では，プログラミング用のテキストエディタのフォントを Verdana の 10 ポイントに設定して利用している。 CRT でも ClearType を有効にすれば，アンチエイリアシングの効いた滑らかなフォントでプログラミングを行うことができる。比較的小さなサイズでも視認性の高さを保ってくれるものだから，むしろプログラミングに適したフォントなのではないかと考えているほどだ。
一体このようなフォントを，どこの誰が，どのようにして作ったのだろうかと考えると，興味が湧いてくる。 "Verdana" という名前もなんだか意味深長な感じだ。気になったので例のごとく Google に問いかけてみたところ，次のような答えを得ることができた。
http://www.microsoft.com/typography/web/fonts/verdana/defaul...
このページ "Channel Verdana" は， Microsoft Typography サイトのコンテンツの一部だ。ここでは "Verdana" フォントの生い立ちについて詳細な解説が行われている。これによれば， Verdana フォントを生み出したのは，書体デザイナーとして世界的に有名な人物である Matthew Carter 氏であるようだ。
http://www.linotype.com/346/matthewcarter-designerfld.html
http://www.identifont.com/show?16K
Verdana は，一見，普通の Sans Serif 体（"Sans Serif" は「ひげ飾りの無い」という意味を持っており，日本語書体でのゴチック体に相当する）のように見えるのだけれど，実は，コンピュータでの利用を想定して様々な工夫が凝らされている。紙の上での見た目ではなく，スクリーン上での見た目を基準としてデザインが行われているということだ。
このフォントのデザインにおいて，最も注意深く練られている点は，小さなサイズでの視認性の保持だ。カーブと直線を強調したように見えるこの独特のデザインは，縮小時にピクセルが好ましい配置となるよう，意図して構成されたものだ。また， "l", "I", "1" のような類似文字の分別や，文字間のスペーシングの調整などにも細心の注意が払われている。上記ページにある比較画像を見てみれば，他のフォントの同ポイントの文字と比較して，確かに視認性の高さを持っていることが分かるはずだ。
ところで，もうひとつ気になっていた "Verdana" という名前の由来については，下の Daniel Will-Harris 氏の記事に簡単な説明が添えられていた。
http://www.will-harris.com/verdana-georgia.htm
曰く，「緑の豊かな」という意味を持つ形容詞 "verdant" が元となっているようだ。シアトルの風景における緑の豊かさにちなんで付けられた名前なのだろうと思う。
Carter 氏は Verdana の他にも幾つかのフォントを Microsoft に提供している。 "Tahoma" や "Geogia" などがそれにあたるものだ。
Windows の標準フォントには，もうひとつお気に入りのフォントがある。 "Trebuchet MS" だ。
http://www.microsoft.com/typography/web/fonts/trebuche/
この「投石器」の名を持つフォントは，当時 Microsoft に在籍していた書体デザイナー Vincent Connare 氏によるものだ。 Carter 氏とのコラボレーションから貴重な経験を得た Connare 氏は，新たな「コンピュータのためのフォント」として，自らのフォントを生み出すことを試みた。それがこの "Trebuchet" だということだ。
この Trebuchet フォントは，どちらかと言えば無難な容姿とも言える Verdana フォントと比較して，見た目に凝ったデザインとなっているのが特徴だ。特に，小文字の "l" や "g" それから "&" などに「ひねり」が利いており， Verdana には無い種類のファッション性を感じさせるものとなっている。
Connare 氏は上のページにおいて， "Trebuchet" の名前の由来を次のように述べている。
また，上記のページの他に，Connare 氏の個人ページも見つけることができる。こちらのページでは，氏がデザインを行った各種フォントに関する解説や，その他フォントデザイン一般に関するエッセイなどを読むことができる。
Connare 氏のもうひとつの有名な仕事は，かの有名な "Comic Sans MS" をデザインしたことだ。
http://www.microsoft.com/typography/web/fonts/comicsns/
このフォントは， Windows に標準で組み込まれているフォントの中でも，最もキャッチーな見た目を持っているフォントだ。しかし，その容姿の柔らかさがライトユーザを強く惹き付けてしまうためか，やや安直に濫用されてしまっている傾向がある。英語圏の「良識ある」ユーザ達は，この "Comic Sans" に氾濫にほとほとうんざりしているようで， "Ban Comic Sans" （Comic Sans を撲滅せよ！）などと題されたジョークサイトまで立ち上げられてしまう始末だ。
http://www.unknownbeings.co.uk/features/comicsans/index.shtm...
Connare 氏は自身の手記において，このフォントが本来は "Microsoft Bob" のために特注されたフォントであるにも係わらず，いつの間にか Windows のシステムフォントとして組み込まれるまでに至ってしまったという，奇妙な経緯について述べている（ちなみに，肝心の "MS Bob" にこのフォントが使われることは，結局無かったそうだ）。
http://www.connare.com/comic.htm
自らの意図せぬ用途にフォントが利用されてしまったばかりか，いつの間にやら勝手に追放キャンペーンまで行われてしまっているというのだから，制作者本人にとってみれば非常に迷惑な話だ。それでも，自らの生み出した，たった５２文字の創造物が，このようにして世界を埋め尽くすまでに広まったという事実は，本人にとって掛け替えの無い名誉なのだろうと思う。
2003-12-03
先日， "Joel on Software" の Joel Spolsky 氏が， "SpamBayes" と呼ばれるソフトを紹介していた。
http://www.joelonsoftware.com/items/2003/11/22.html
この "SpamBayes" というソフトは，その名前からも何となく分かるように，ベイズ解析 (Bayesian Analysis) を利用してスパムメールのフィルタリングを行うソフトだ。
http://spambayes.sourceforge.net/
Soplsky 氏は，このソフトのおかげで，毎日２００通以上届くスパムメールをすべて遮断することができていると述べている。
「ベイズ解析」とは，１８世紀イギリスの数学者 Thomas Bayes によって編み出された理論を基とした統計手法の一種だ。
以前，某溺愛掲示板に jiro さんがベイズ解析に関する情報を書き込んでいたのを覚えている。ベイズ解析とコンピュータ・アプリケーションの関連性については，そのときのリンクにあった記事「人工知能とコンピューターの未来を握る『ベイズ理論』」や「ＭＳも注目する“ベイズ”って何だ」などが分かりやすい。
http://www.hotwired.co.jp/news/news/20010423302.html
http://www.oricom.co.jp/marketing/0112251.html
ベイズ理論の一般的な基礎知識については，大羽成征氏の "Bayesian Fun Site" が参考になる。
http://hawaii.aist-nara.ac.jp/~shige-o/cgi-bin/wiki/wiki.cgi...
このように，ベイズ理論を応用した統計手法は，データマイニングの一手法として，既にメジャーな存在となりつつあるようだ。同じく jiro さんのリンクから， Microsoft Reseach の "Adaptive Systems and Interaction" のページでは， Microsoft 製品における高度なヒューマン・インタフェースを構築する手法としてベイズ解析が応用されていることを示している。
http://research.microsoft.com/adapt/
上の文書にもあるように， MS Office 製品に付いている「アシスタント」機能や，サポートページにある「話し言葉によるサポート技術情報検索」などが，これらの技術を応用して作られているようだ。
http://www.microsoft.com/japan/enable/nlsearch/
また， MSBNx と呼ばれるベイズ・ネットワーク評価のためのツールキットも配布されている。
http://research.microsoft.com/msbn/
これは， MS Research によるベイズ解析研究の副産物として配布されており，非商用の用途ならば無償で利用することができるとのことだ。
それで，肝心の SpamBayes についてなのだけれど，このソフトは日本語に対応していないため，日本語環境ではあまり良い効果を上げることができない。英文ではスペースや記号を基準としてトークンへの分割が行えるのに対して，日本語では特殊な文章解析を行わなければトークンへの分割を行うことができないためだ。
同じくベイズ解析を利用してスパムのフィルタリングを行うソフトウェアとして "POPFile" がある。
http://popfile.sourceforge.net/
こちらは各言語へのローカライズが着実に進められており，日本語版も Junya Ishihara 氏の手によって対応が行われている。
http://popfile.sourceforge.jp/
SpamBayes のスパルタンなインタフェースと比較して， POPFile の方は非常にソフトな物腰だ（ちなみに SpamBayes は Python で作られており， Python がインストールされていないと動かすことさえできない）。インストーラも親切だし，インタフェースも使いやすいし，フィルタリングソフトとして既に完成されている感がある。
これらのベイズ解析を利用したスパムフィルタの動作原理については， Paul Graham 氏の記事 "A Plan for Spam" に詳しい。
http://www.paulgraham.com/spam.html
この記事には日本語訳が存在する。フリーの Lisp 処理系 "Gauche" の作者として有名な川合史郎氏の翻訳だ。
http://www.shiro.dreamhost.com/scheme/trans/spam-j.html
この記事を参考にする限りでは，非常に限られた情報からでも，スパムの判定を行うことが可能であることが分かる。 HTML コメントを文中に差し挟むことによってフィルタ対策を行ったようなメールでも，ヘッダやタグなどからスパムの判定を行うことができるかもしれない。例えば，真っ赤な文字を出すための "ff0000" が含まれているメールはスパムである確率が高い，とか， aol.com からのメールのほとんどがスパムである，とか，そういった情報からも判定を行うことが可能であり，しかもその基準は過去の傾向から自動的に求められるというわけだ。
ただし，例えば僕のように，圧倒的多数のスパムを海外から受信しており，なおかつ，稀に海外からのメールを受け取る可能性がある場合などは，フィルタの利用に気を付けなければならないだろうと思う。調子に乗って推論エンジンを鍛えてしまうと， "new" や "more" や "super" などのように一般的な単語までブラックリストに入ってしまうかもしれないからだ。フィルタの本格的な運用を始める前に，誤認識が無くなるまで十分なトレーニングを行う必要があるだろうと思う。
2003-12-04
先日のことなのだけれど，ゲーム系コミュニティサイト "Water Cooler Games" に，次のような記事が上げられていた。
http://www.watercoolergames.org/archives/000029.shtml
Macromedia の新製品 "Central" に関する記事だ。同サイトのコントリビュータである Ian Bogost 氏は，このソフトウェアの持つ可能性と，先日発表されたという AOL IM サービスとの連携について触れており，新しいネットワークゲームのインフラとして浮上してくるのではないかと期待を寄せている。
"Macromedia Central" は，先日，開発者向けにリリースが行われたばかりの新しいソフトウェアだ。
http://www.macromedia.com/software/central/
この Central というソフトウェアが，一体何であるかを一言で説明することは，少し難しい問題かもしれない。ニュースサイトなどに載せられている解説は，いまいち表現が一定しておらず，漠然とした像しか映し出されていないように感じられる。
http://japan.internet.com/webtech/20030929/12.html
http://itpro.nikkeibp.co.jp/free/ITPro/USNEWS/20031120/4/
http://internet.watch.impress.co.jp/www/article/2003/0328/ma...
機能面にのみ注目するならば，これは Flash をベースとしたネットワーク・アプリケーション環境だ。これまでの「ブラウザの中で動く Flash アプリ」という構図ではなく，純粋に Flash を主体するアプリケーション環境が構築されている。 Central 環境の中に集約された Flash アプリ群は，コンテンツ・サーバと独自に通信を行い，クライアント側で必要な処理を行いつつ，ユーザにコンテンツを提供する。つまり，今までのような「ウェブの一部としての Flash」という立場から脱却し，ウェブ自体の存在を置き換えてしまうものとして Flash + Central が据えられる，ということのようだ。
これを Macromedia 社の企業戦略的な視点から見つめ直してみると，もう少し違った像が見えてきて面白い。 Macromedia 社の名誉創設者 (Founder Emeritus) である Jeremy Allaire 氏は，同社サイト内にあるコラムにおいて，氏自身の持つインターネットの将来像について語っている。
http://www.macromedia.com/devnet/logged_in/jallaire_central....
http://www.macromedia.com/devnet/logged_in/jallaire_converge...
僕には， Allaire 氏の主張は非常に先進的であり，かつ過激なもののように思える。その主張によれば，インターネットはもうすぐ次の世代へと突入しようとしている。その「次世代インターネット」（氏は冗談混じりに "Internet 2.0" と名付けている）では，現在の WWW を主体とした「インターネット」とは異なった世界が構築される。もちろん，そこで主役となるのが，同社の "Flash" であり "Central" であるということだ。
Allaire 氏は，現状の「インターネット」と「次世代インターネット」の間に存在する相違点を幾つか挙げている。中でも大きなものが，現在のウェブに取って代わるコンテンツ配信環境の存在だ。氏は，インターネットの普及が主にウェブの貢献であったことを認めつつも，それは時代の背景を反映したものであり，当時とは異なるレベルのインフラが発達した現在となっては，アプリケーションもまた異なる進化を遂げる可能性が存在することを指摘している。
確かに現在のインターネットの形態は，ウェブという機構の存在に少し頼り過ぎている感がある。ネットワーク・アプリケーションの処理はウェブサーバ側の比重が極端に高くなっており，クライアント側はただひたすらハイパーテキストのレンダリングを行っているだけだ。そもそも，元は単なるハイパーテキストであるものをアプリケーションのインタフェースとして利用していること自体，少し変な話だと思う。
Macromedia の Central のような環境では，クライアント側の処理の比重が適切なレベルにまで引き上げられることになる。サーバ・クライアント間の通信は SOAP のような技術を主体としたメッセージのやり取りに置き換わり，データは主にクライアント側に蓄積される。クライアントは自律的に処理を行い，ユーザにリアルタイムベースでサービスを提供する。また， Flash をベースとしたアプリケーションではプラットフォームの問題も難なく解決される。何しろ，今や携帯でも Flash が動く時代なのだから，これから先，どんなデバイスにでも Central は浸透していく可能性を秘めているわけだ。
このように Central は， Allaire 氏と Macromedia 社の持つ将来のビジョンの中でも中核的な役割を担う存在となっている。９０年代に Java が全てのプラットフォームの統合を夢見たように， Flash が次世代インターネットの新たなプラットフォームとして君臨して行くという，過激な野望を掲げているわけだ。
ところで， Water Coller Games の記事において Ian Bogost 氏が注目していたのは，先日 Macromedia と AOL が，今後 Central 環境と IM サービスの連携を行っていくと発表したことだった。
http://www.markme.com/mesh/archives/003851.cfm
AOL によって提供される "Presence SDK" を利用すれば， Flash アプリケーション側から，ネットワークの向こうに居る人物とのコミュニケーションを確立することが可能になる。これは，他人の存在を前提とした (presence aware) アプリケーションの可能性を大きく広げるものだ。アプリケーション側にディレクトリサービスやロビーサービスのようなものを用意する必要は無くなり， AOL の IM サービスという既に十分に発達したインフラを利用して，人とのコミュニケーションを確立することができるようになるわけだ。
Macromedia 社の提示する鮮烈なビジョンには興奮を覚える一方で，同時に何故か奇妙な既視感を覚える。最も危うく感じるのは，９０年代中盤にＩＴ界隈を散々惑わした「プッシュ」技術の存在とダブって見えることだ。
http://www.zdnet.co.jp/news/9802/09/push.html
http://www.wired.com/news/business/0,1367,35208,00.html
あの瞬間に一躍時代の寵児となった PointCast や Marimba といった企業は，今では時代の表舞台から姿を消してしまった。 Microsoft の Active 何ちゃらやらも，今ではすっかり目立たない存在となっている。結局，「プッシュ」技術は一度もブレイクを迎えること無く，９０年代のペテンの一つとして終わってしまった。
2003-12-05
先日のこと， Ned Batchelder 氏のブログの中で "Metakit" と呼ばれるライブラリが紹介されていた。
http://www.nedbatchelder.com/blog/200311.html#e20031129T2227...
Metakit は Equi4 Software の Jean-Claude Wippler 氏が開発したデータベースライブラリだ。
http://www.equi4.com/metakit.html
「行」 (row) をレコードの単位として扱うという点では，一般的なリレーショナルデータベースと似た趣を持っているのだけれど，フィールド（Metakit では "property" という用語が使われている）の中に階層的にデータベースを持つことができるという点が，少し独特な機能となっている。ネストした構造体やツリー構造のように RDBMS では扱い難いデータ構造も，これならば簡単に扱うことができそうだ。
Metakit には様々な言語バインディングが存在しており，特に C++ のバインディングがなかなか良く出来ているようだ。使いやすさを追求すると同時に，パフォーマンス的にも優れたライブラリとなっている。
http://www.equi4.com/metakit/intro.html
本格的な DB システムなどは必要とされていないのだけれど，ちょっとしたデータストアとして気軽に DB を利用したい……などというような場合に，良い選択肢となってくれるかもしれないと思う。
この記事を読んでいて急に思い出したのだけれど，件の記事よりも更に前に， Batchelder 氏が Erik Meijer 氏の論文を紹介していた。
http://www.nedbatchelder.com/blog/200310.html#e20031030T1958...
ここで紹介されているのは， Microsoft Webdata 所属の Erik Meijer 氏の論文 "Programming with Circles, Triangles and Rectangles" だ。
http://www.cl.cam.ac.uk/~gmb/Papers/vanilla-xml2003.html
http://research.microsoft.com/~emeijer/
内容は，一般的なプログラミング言語に組み込まれているデータモデル（基本型や構造体等の，いわゆる「ファーストクラス」な型）と， XML のデータモデルとの間に存在する相違点を指摘するものとなっている。両者は一見して似た構造を持っているように思えて，実は細部に異なった概念が用いられている。その違いを無視して無理にバインディングを行おうとすれば，必ず矛盾を抱えてしまうだろう……ということだ。実際に C# の "xsd.exe" や Java の JAXB 等のようなコード生成によるデータバインディングを槍玉に上げ，これらの手法の持つ不完全な面を指摘するものとなっている。
そして氏は "Xen" と呼ばれる新しいデータモデルと，それに対応した仮想的な C# 言語拡張を提言している。これは，これまでのような間接的な「データバインディング」手法とは違って，より直截的な形で XML を扱えるようにしたものだ。例えば， Xen コードの例として次のようなものが挙げられている。
このように， Xen データモデルを用いたクラス定義は XML Schema に似た表現様式を持っている（あるいは Relax NG の compact syntax と比べてみれば，これらが瓜二つなのが分かると思う）。また， Xen によって拡張された C# の言語仕様では，下のような XML リテラルを直接に解釈し，コンパイル時に内部データモデル化を行うことができる。
C# の Xen 拡張におけるもう一つの大きな「売り」は， XQuery のような高機能かつ高レベルなクエリ機能を有していることだ。例えば，次のような例が挙げられている。
これは厳密には XQuery と互換では無いものの， W3C の提示する "XML Query Use Cases" を全てカバーできるということを主眼としているということだ（つまり，実質的に XQuery と同程度の機能性を持っていると言える）。
http://www.w3.org/TR/xquery-use-cases/
このように非常にエキサイティングな要素を揃えている "Xen" データモデルなのだけれど，最大の問題は，まだ実装が存在していないということだろうと思う。しかし， .NET 方面に少なからぬ影響力を持つ Meijer 氏ならば，これを実行に移さない理由は無いだろうと思う。実際に，氏のブログを覗いてみる限りでは，これが実現されるのはそう遠くない未来であるように思える。
http://blogs.gotdotnet.com/emeijer/PermaLink.aspx/f0bdf5c8-e...
2003-12-06
普通の休日。飯ついでに寄った本屋で久しぶりに「ポピュラーサイエンス」などを買ってみた。
そう言えば，ついこの前まで「みんなのサイエンス」だったのが，いつの間にか元の「ポピュラーサイエンス」に戻ってしまっている。一時期は全テキストにルビを振るというようなことまでして幼年層への売り込みを行っていたのだけれど，どうやらその試みも空振りに終わってしまったようだ。無難に「Popular Science の日本語版」という位置付けに回帰している。
いや，結局のところ，それで良かったんじゃないかな，と思う。
「ニュートン」等の老舗と比べると，全体的に垢抜けた雰囲気が楽しげな雑誌だ。ネタ探し程度だったら，このくらい気軽に読める雑誌が良いだろうと思う。職場で定期購読してもらおうか……。
もうひとつ，ついでに，柳沼行の「ふたつのスピカ」を購入して帰った。
http://www.comic-flapper.com/fcomics/supica/main.html
最近何故か流行っている宇宙開発モノのコミックだ。他には，無難に幸村誠の「プラネテス」や，あるいは過激に太田垣康男の "Moonlight Mile" などを読んでみているのだけれど，その中でも「ふたつのスピカ」は，最も純朴とした雰囲気を持つ作品となっている。絵柄からは軽いジュビナイルが連想されるのだけれど，実際には，大人の涙腺を刺激するような切ないエピソードばかりの連続する物語だ。コミックを読んでいて泣けてきたのは久しぶりのことのような気がする。
表向きのテーマは，宇宙飛行士を目指す主人公達の成長の物語なのだけれど，実際には，「獅子号」とそれを取り巻く人々の過去を軸とした，素朴な人間模様を描き出す作品となっている。日常的な存在感を持ったキャラクター達が，意外な所で過去や現在を共有しており，それがひとつの軸に沿って交わっていることが徐々に明かされてくる。その内容が，とても純粋で，明るく切なくて，それでいていちいち泣けてくるのだから堪らない。まだ残されている幾つかの伏線が，今後どのようにして本筋へ絡んでくるのか，今から楽しみだ。
しかし，今更になって宇宙開発がテーマとして人気を持ってきたというのは，一体どういうことなんだろうかと思う。僕が子供の頃は，まだ冷戦時代の宇宙開発競争の余熱が保たれており，ちょうどスペースシャトルなどが実用化されたこともあって，それなりに盛り上がりを見せていたような記憶がある。しかしその熱気も，僕が高校生になる頃にはすっかり冷めており，既に宇宙はホットなフロンティアでは無いんだということが明らかになってきていた。恐らく，僕が生きている間に人間が地球外の地を再び踏むことは無いだろうし，もっと実用本位の開発が続けられることになるのだろうと思う。
そう考えると，これらの物語は本当に純粋なファンタジーでしか無いし，だからこそ人気があるのかもしれないと思う。まあ，世代ってやつやね……。これらの物語が，今時の子供達にとって，僕等が感じるのと同じ程度の面白さを感じさせるものかどうかと言うと，疑わしいところかもしれないと思う。人類は３０年前に月に到達したというのに，それはもう歴史上の事実でしかなくなってしまっている。なぜ今再び宇宙に足を踏み入れることができないのか……その理由を考えると，これらのファンタジーに馳せる想いはより一層強くなるものと，僕は思う。
http://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%9D%E3%83%AD%E8%...
http://www2k.biglobe.ne.jp/~t_muto/apollo/
2003-12-07
そう言えば，先日，ギーク系オンラインマガジンこと "ZZZ Online" において，また奇妙なネタが取り上げられていた。
ここで紹介されているのは，ロシア在住のハードウェア・エンジニア Evgenij Vasiljev 氏が趣味で開発した「ハンドレールガン」こと "Pskov 1100" だ。
http://www.pskovinfo.ru/coilgun/indexe.htm
ソレノイドを利用したシンプルな構造のレールガンを，拳銃のサイズの筐体の中へと見事に収めてしまっている。重量は 1.1kg とのことだから，さほど重くは無い（マグナム銃と同程度だ）。筐体の中に収められた６個の NiCd バッテリーが供給する電力は，内部回路によって 800V にまで高められ，それが１６個のコンデンサ（計 600uF の容量を持つ）へチャージされる。そして，引き金が絞られると同時にその電力は一気にソレノイドへ放出される。この機構を普通に組み立ててしまうと，ソレノイド自身の磁力によって，射出される弾丸の速度が落とされてしまうのだけれど，ここで氏の考案した "V-Switch" と呼ばれる機構が電圧をタイミングよく反転させ，弾丸に与えられるエネルギーを極限まで高めるようになっている。
この銃から射出される弾丸の初速度は秒速 33m ということだから，実際の拳銃と比較するとだいぶ遅い（野球選手の投げる球と同程度の速度）。破壊力も 1.5J 程度ということだから，数値上では改造モデルガン程度の破壊力しか無いことになる。しかし，射出される弾丸が「５寸釘の先端を切り取ったもの」というのだから，まったく穏やかな感じがしない。どう見ても，立派に凶悪な武器だ。
http://www.pskovinfo.ru/coilgun/img/projectile1.jpg
この銃が持っているもうひとつの面白い特徴は，完全な「無音銃」であるということだ。通常の銃器に見られるような火薬をはじめとする科学反応の類を一切利用していないほか，射出される弾丸以外に稼動する部品がまったく存在しないため，完全な無音が保たれることになる。ただ弾丸の空を切る音だけが響くという珍しい銃器だ。制作者の Vasiljev 氏は，この「無音銃」が素晴らしい猟銃になるに違いないと述べている。
昨日，本屋を訪れた際に，西田亙氏の「Linux から目覚めるぼくらのゲームボーイ！」が平積みにされているのを目撃した。
http://www.unixuser.jp/books/gba/index.html
その本屋での売れ行きを見る限りでは，かなり評判は良いようで，残りの冊数も残すところ僅かとなっていた。書籍の中には， UNIX USER 誌上での連載と同じ体裁の解説書の他に， USB 対応の GBA ブートケーブルと， KNOPPIX を使った CD ブート可能な Linux 開発環境が含まれている。 CD ブート可能な開発環境が含まれているというのは，一見親切なはからいのようにも見えるのだけれど， Cygwin ベースで環境を構築すれば Windows 上でも開発が可能なことを考えると，そう親切というわけでもないかもしれない……まあ，あくまでも「UNIX USER 別冊」なのだから，そこは仕方が無いだろうと思う。
内容としては， PC 以外の環境をターゲットとしたクロス開発を行ったことの無い人が，クロス開発の技術を習得するのに絶好の教材……と言いたいところなのだけれど，残念ながら，この書籍だけではまだその「深み」にまで達していないように思える。この少ないページ数では， GBA 自体の解説を行うだけで精一杯だろうから，無理もないことだと思う。願わくば， UNIX USER 誌上の連載記事「GCC プログラミング工房」の単行本が発刊されることが望まれる。それを併せ読むことによって，初めてこの書籍の試みは完遂されるのではないかな，と思う。
2003-12-08
先日，国内において "Medal of Honor: Rising Sun" の日本語版が発売された。
http://www.japan.ea.com/mohrs/
これは，第二次世界大戦をテーマとして扱ったベストセラーゲーム "Medal of Honor" の続編として制作されたものだ。前作では欧州戦線が舞台となっていたのに対して，今作では太平洋戦線が舞台となっている。もちろん，主人公は米兵の一員となり，日本軍を屈服させるべく奮闘するわけだ。
ところが，ごく最近，このゲームの内容がちょっとした物議を醸していたようだ。一体どういう事情かと言うと……次の Penny Arcade のマンガを例にとってみると，その事情がよく分かると思う。
http://www.penny-arcade.com/view.php3?date=2003-11-26
そもそもの議論の発端となったのは， Gamespot に掲載された一件のニュース記事だったようだ。
http://www.gamespot.com/gamecube/action/medalofhonorrisingsu...
この記事は， Medal of Hornor: Rising Sun が日本で発売されたという事実を簡潔に伝えると同時に，その事実の持つ奇妙な面を指摘する内容となっている。
僕も，嫌悪感のようなものはほとんど感じないのだけれど，改めてこう指摘されてみると，多少ながらも奇妙な違和感を覚えるようになってきた……だって，自分のお爺ちゃんにあたる人達を殺すゲームを楽しんでプレイするなんて言うのは，やっぱりちょっとどうかと思うのだけれど……不思議なのは，それを自然と無視することのできる己の感性だ。
この件に関しては，リベラル系ゲーム評論サイト "game girl advance" において交わされている議論が面白い。
http://www.gamegirladvance.com/archives/2003/11/23/join_the_...
ClockworkGrue (Benjamin Johnson) 氏の投稿に対して，非常に多くの反応が寄せられている。意見も人それぞれで多種多様に渡っており，向こうの人々の考え方を知る上で興味深い資料となっているのではないかと思う。
途中で議論が発散してしまっているものの，主な意見としては，「自国民に受ける内容のゲームを作るのは当たり前」とか，「両陣営をプレイ可能にすることで平等な視点を提供すべき」とか，あるいは「そもそも戦争をゲームのテーマとして扱うこと自体問題がある」などというものが見受けられる。ともかく，いずれの意見にも共通して見られるのは，「このゲームを日本で出すのは，マーケティング的に間違い」という論調だ。
しかし，ファミ通集計によれば既に７万本近くの売り上げを達成しているとのことだから，マーケティング的にはほどほどに成功してしまっているというのが，実情なのではないかと思う。最終的に１０万本は堅いものと思われる。
個人的な意見としては， "MoH" のように物語性を重視する内容ならば，多少の偏った視点が存在することは「当たり前」だろうと思う。逆に "BF1942" のように「ゲーム的なゲーム」ならば，様々な陣営を選択できるようにして多様性を強化し，イデオロギー的な色付けは排除しておくのが無難な戦略だろうと思う。
「戦争をテーマとして扱うことが云々」に関しては，程度問題であるものの，大方の場合，問題になるものでは無いだろうと思う。ただ，次に挙げる "waka" 氏のコメントなどは，常に心に留めておきたいものだと思う。
しかし，結局のところは，次の "Bowler" 氏の意見にすべてが集約されてしまうのかもしれないと思う。
http://www.ggdb.com/GGDB/Details.asp?VID=8&Cat=All.Coin-Op
http://www.ggdb.com/GGDB/Details.asp?VID=11&Cat=All.Coin-Op....
まあ，そんなわけで，良いのやら悪いのやら分からないけれど，その辺りはほとんど気にならないというのが実情だ。僕も試しに買ってみようかね……その，お爺ちゃん殺しゲームってやつを……。
2003-12-09
先日読んだ "The Final Hours of Prince of Persia: The Sands of Time" が面白かったのを思い出して，今度は別の記事を読んでみることにした。 Gamespot のシリーズ記事 "Behind the Games" のことだ。
http://www.gamespot.com/features/btg/
このシリーズの中で，唯一，日本産のゲームを扱っているものがある。 "The Final Hours of Metal Gear Solid 2" だ。
http://www.gamespot.com/gamespot/features/video/btg_mgs2/ind...
この記事では， Gamespot の記者である Geoff Keighley 氏がマスターアップ間際の MGS2 チームを取材し，その緊迫した雰囲気を伝えると共に，それまでに開発チームが辿ってきた長い３年間の道程を，開発者自身の回想から紐解くという内容になっている。
MGS2 のメイキングについては， "MGS2 The Making" や "The Document of MGS2" のような「濃い」資料が既に発売されている。それらの資料だけでも，開発現場の雰囲気を知ることは十分に可能かもしれない。
http://www.amazon.co.jp/exec/obidos/ASIN/4789718433
http://www.konamijpn.com/products/mgs2_doc/japanese/index.ht...
しかし，それでもなお，件の記事は興味を誘われる内容となっている。前述の資料群が，その資料性の高さを売りにしているのに対して，この記事は MGS2 チームの精神面を描き出すものとなっているためだ。ゲーム自体について詳しく知りたいのであればともかくとして，開発者自身の人間性について深く理解を得たいのであれば，こちらの記事の方が価値のあるものと感じられるのではないかと思う。
いかに国内のトップノッチに位置する開発集団と言えども，その開発の過程は決して単純なものではない。どこにでも見られるような苦難の道を歩みつつも，強力なタレントの存在と，チーム全体の不断の努力によって，ようやくひとつの大作が生み出される。この記事はその様子を，一編のドキュメンタリーとしてドラマチックに描き出している。
まずひとつ，（こんな言い方はおこがましいのだけれど）感心させられたのは，チームからプログラマに対して向かって寄せられる要求の高さと，それに対して決してダメ出しをしないという，プログラマの持つ度胸の強さだ。
寄せられる期待に対して "Yes" と答えるのはプログラマの本懐であるのかもしれないけれど，それを安易に受け入れれば両者に不幸をもたらすであろうことを理解しているからこそ，プログラマは "No" と答えることがある。「出来ます」と答えたくなる気持ちを抑えて，「出来るけど，出来ない」と言うことのできる勇気を持つことこそが，時に重要な意味を帯びてくるわけだ。
しかし，ゲームプログラマとしての本当の職人性を備えたプログラマは，「出来ないことでも，出来るように変えていく」という力を持っているように思えることがある。そのギリギリのラインでのバランス感覚を保つことが，チームのメンバーから信頼を勝ち得るために必要な条件となるのではないかと思う。
また同時に，プログラマがディレクターに対して寄せている信頼に関しても，とても強いものを感じる。それがどんなに突拍子の無いアイデアであっても決して無下にせずに，丹念にその欠片を拾い集めて，少しでもゲームに反映させて行こうとする真摯な態度をうかがうことができる。
こうした地道な努力の数々が，リッチなゲーム内容を生み出す原動力となったのだろうと思う。
2003-12-10
件の記事を読んでいて強く感じたのは，チームのメンバー間に存在する確かな信頼と，強力な連帯感だ。特にそれは，物語の後半……つまり開発の後期へと進むにつれ，ますますその強さを増していくように思える。
苦労を共にすることによって生まれる連帯感は，人の結びつきを特に強くする働きを持っているように感じられる。一部の例外を除けば，ほとんどのゲームソフトは，その開発の過程において必ず「修羅場」を経験する。それは MGS2 チームのようなトップノッチの集団においても変わらないことであるし，むしろ，平均よりも過酷な労働をこなしていることが分かる。
もちろん，苦しむ必要の無い場面において余計に苦しむことや，理不尽なデスマーチに突入することなどは極力避けなければならないのだけれど，だからと言って，決して苦しむこと自体を恐れてはならないと，僕は思う。本当に優れた製品を作り出す集団は，必ず苦しみを味わっているからだ。
多くの先人達が語ることに，「ゲームの開発には本質的に終わりが存在しない」という言説が存在する。どんなに手間や時間を消費したところで，決して「完成形」に辿り着くことはないという主張だ。したがって，世に出される「製品」としてのゲームは，その洗練の過程の途上にあるものが，外因的な理由（多くは会社の運営上の制約）によって打ち切られ，パブリッシュされているものであると解釈することができる。
だからこそ，本当に実力を持つ人達は，締め切りに近づくほど苦しみを味わうことになる。どんなに力を振り絞ったところで，決して満足することはないという事実を知っているからこそ，最後の瞬間まで全力を尽くそうと努力する。予定されたスケジュールを遅延させることは非難されるべき行為だけれど，スケジュールに余裕の無い状態を非難するのは的外れな指摘だ。ゲームは，工場で定期的に生産される工業製品などとは，まったく異なった性質を持っている。その有機的な特性と，そこに介在する「職人性」の概念に対して深い理解を持たない限りは，適切なマネジメントを行うことはできないのではないかと考える。
ともかく，この MGS2 チームのような「苦しめる職人達」の姿を見る度に，自分は１人の労働者としてどうあるべきなのだろうかという思いが湧いてくる。優れた職人達は，自らの仕事（キャリア）に対して身を捧げるだけでなく，作品全体に対して身を捧げ，集団に対して身を捧げ，リーダーに対しても身を捧げる（そして，優れたリーダーは自らの部下に対して身を捧げる）。一般に「クリエイター」と称される職種では，個人主義が重視されると考えられがちなように思えるのだけれど，本当に優れたクリエイター集団は，むしろ個人よりも集団に重きを置く傾向にあるというのが，僕の知識の範囲内で見えてくる事実のひとつだ。
MGS2 チームは，最終的に７０人を超えるチーム構成に膨れ上がったにも係わらず，その強い連帯感を保つことに成功している。このように，チーム全体が「家族」としての信頼を持ち，互いの仕事やアイデアに関して積極的に討論や連携を行うことのできる雰囲気を作り出す……というのが，「小島流」と呼ばれる制作スタイルであるようだ。
http://www.konamijpn.com/products/psonebooks/policenauts/int...
http://shinjuku.cool.ne.jp/kiri1113/metal/chronicle/body.htm...
http://gourmet.yahoo.co.jp/gourmet/restaurant/Kanto/Tokyo/gu...
開発チームの拡大に伴って，「小島流」のチーム運営が難しくなってきていることは，「ボクらの太陽」の頃に小島氏自身が頻繁に述べていたように記憶している。
http://www.gamespy.com/e32003/interview/ps2/1002714/
５０人を超えるような大規模の集団においてセクショナリズムの発生を防ぐためには，絶対的な信頼を置くことのできるリーダーの存在が欠かせないものであると感じられる。氏等は，このような大規模チーム運営の困難さを語りながらも，今のところはその構造を破綻させずに保つことができているように思える。その観点が，今後の制作においてどのように変化することになるだろうかと考えると，なかなか興味の尽かないことであると思う。
2003-12-11
最近，チェックしているブログの数が増えてきた。そこで，チェックの手間を減らすのと，ブックマークを整理するために， RSS アグリゲータ（RSS リーダ）の導入を考えてみることにした。
まず， RSS 自体の情報については， RSS-DEV Working Group の配布している仕様書 "RDF Site Summary (RSS) 1.0" と，神崎正英氏の解説記事「RSS -- サイト情報の要約と公開」などが参考になった。
http://web.resource.org/rss/1.0/
http://www.kanzaki.com/docs/sw/rss.html
これを参考に，いずれ自分のサイトも RSS に対応させようと思う。今はちょっと暇が無いけど……。
最近は，ブログ文化の台頭と共に RSS を供給するサイトが増えてきたように思える。多くのブログサイトでは RSS 供給を行っている他に，例えば Slashdot のようなコミュニティ系ニュースサイトや， CNET のような一般ニュースサイトでも RSS の供給を行っている。
そう言えば Gamasutra でも RSS の供給が開始されている。どうやら読者からのリクエストによって実現された機能のようだ。
オフィシャルには RSS を供給していなくとも，供給の代行を行っているサイトを探すことによって， RSS の取得を行えるようになることもる。例えば，「ニュースジャンキーサイト」こと "Bulknews" では， asahi.com や ZDNet のような著名ニュースサイトの RSS 供給を行っている。
海外のサイトならば "myRSS" 辺りが役に立つだろうと思う。
例えば "blog*spot" (blogger) のような著名ブログサイトでも，オプションによっては RSS 供給に対応していない場合があるようなので，そういった場合には上のようなサービスを利用しなくてはならないだろうと思う。
そのほかにもユニークな RSS 供給サービスを行っているサイトが存在する。例えば "Google Alert" などは，特定のワードに対する Google での検索結果を毎日記録し，メールや RSS によってその内容を配信するというサービスだ。
http://jade.mcli.dist.maricopa.edu/alan/archives/000123.html
最近では「はてなダイアリー」の RSS 対応が記憶に新しい。
http://diary.hatena.ne.jp/keyword/RSS
個人的には，「はてなアンテナ」が RSS での更新チェックや RSS 代行供給に対応してくれると嬉しいのだけれど……。
いくつかの RSS アグリゲータを調べてみたところ，良さそうなのは SharpReader と gluecose の２つだった。
特に "gluecose" の方は，なかなか良い選択肢のように思える。 RSS 供給を行っていないサイトでも，専用の Python スクリプト（「センサー」と呼ばれる）によって対応が可能なことや，日本語をベースとして開発が行われていることなどが主な特徴だ。ブラウザ部分がタブ形式になっているのも，使い勝手が良いと思う。
でも，結局は SharpReader を選ぶことにした。 .NET framework を利用していることや，微妙な反応の悪さが気になるものの， UI の挙動が気に入ったというのが主な理由だ。ともかく，どちらもいまいち決め手に欠ける部分があるのは確かなことなので，しばらくの間様子を見ながら，情勢に合わせて切り替えて行くことにしようと思う。
2003-12-12
今日は，年末呑みの会の第一弾があった。これから毎週，立て続けに呑み会が催されることになる。週一ペースで呑みなんて，アルコール愛好家にとってみれば何てことは無いのだろうけど，僕のように殆ど呑むことの無い人間にとっては忙しない日々となってしまう。
今日の呑みは，特殊な場所で特殊な方々と呑み。色々な意味で非常に面白い呑みだったと思う。
仕事の方は，そろそろ時間的な制約が実感できる時期に入ろうとしている。比較的ルーズに扱っていたスケジュールに関して，厳密な管理を敷かなくてはならないだろうと思う。何よりまず，自分の進捗に対して厳しくならなければならない……。
"Ratchet & Clank" の Postmortem において Ted Price 氏はモニターテスト (Focus Test) の重要性について説いていた。その主な趣旨は「ゲームデザインが意図通りの効果を発揮しているかどうかを実地において確認する」というものなのだけれど，副次的な効果として挙げられていたものに関しても見逃すことができない。
http://www.gamasutra.com/features/20030613/price_02.shtml
後ろ向きなものの見方かもしれないけれど，この「定期的にプレイアブル盤を作成するために課されるモニターテスト」というのは，非常に重要な効果を持っているように思える。現実に逃れられない制約を課すことが，プロジェクトの明確なマイルストーンとなって進行を押し進める原動力となる。特に，「ＸＸＸに提出のための ROM 焼き」というよりかは，「Ｘ回目のモニターテストなので，Ｘステージ分の素材と，そこに入る予定のフィーチャーを完成させなければならない」という目標の方が，制作側の人間にとって明確な目標となるため，効果は高いものと考えられる。
まあ，そんなわけで，自分も現実的な目標に向かって短距離疾走を始めなければならない時期にさしかかろうとしている。恐らく，インフラやシステムが出揃った時点から急激にコンテンツ作成の流れが速まるに違いないと予測しているのだけれど……どうだろう。もしかしたら，一ヶ月後には胃に穴が空いているかもしれない。そうならないことを祈るのみだ。
2003-12-13
今日は昔の知人の結婚式の２次会で呑み。久しぶりの面子で，まったりとした会話を交わしたりした。いつになく穏やかな呑みだったと思う。
こうした折に，世間の仕事の話に耳を傾けていると，自分の職場の特殊性のようなものを認識してしまうことがある。特に，奇妙な生い立ちを持つ職場で働いている分，その違和感は強いものとなっているように思える。
例えば，先日の Impress PC Watch の大河原克行氏の記事「パソコン業界、東奔西走」では，蒲田の富士通ソリューションスクエアが紹介されていたのだけれど，その先進的な内容にはただ驚かされるばかりだった。自分らの現状は，まさにこの正反対に位置するものだと思う。
http://pc.watch.impress.co.jp/docs/2003/1209/gyokai79.htm
特に，社員の自席を固定しないという「ノンテリトリアルオフィス」のコンセプトなどは，とても挑戦的な試みのように感じられる。
富士通の先進的なオフィス構成に関しては，以前公開された「汐留シティセンター」の記事においても見受けられるものだった。
http://pc.watch.impress.co.jp/docs/2003/0707/gyokai65.htm
自分達がこのような事例を参考にしたところでメリットが得られるかどうかはさておき，なぜこれを真似することができないのか考えてみるのは面白いことだと思う。まず自分の机の上を見回してみて，最初に目に付くのは参考書籍の山だ。これは共有化してしまえば机に置く必要は無い。次に場所を占有している音楽ＣＤやゲームソフト等の私物の類については……個人ロッカーに収納か，あるいは廃棄してしまっても構わない。特殊な開発機材については，職務上必要となるものだからやむを得ない。作業用ＰＣに関しても，特殊なソフトウェア（例えば Softimage や Maya など）を動かす必要性があることから，共通化することは難しい。
周囲の机に目を移してみると，まず多いのは資料の山，それから，ゲーム機本体やコントローラー，スピーカーやトレス台などの雑多な機材，意外なところでは寝袋などの生活用品が多いように思える。あとは，ぬいぐるみやフィギュアなどの「飾り物」だ。それで，それらの全ての物品が常に仕事に必要なものかというと，怪しいところではあると思う。
逆に，個人スペースの存在を尊重する意見を挙げてみるとしたら，どのようなものになるだろうかと思う。例えば……「ゲーム制作は，通常のオフィスワークとは違って，エンターテイメントの創出を行うという特殊な場であるから，制作を行うスペシャリスト達にとってイマジネーションの補助となるような環境でなくてはならない。ゆえに，各々が個人的な空間を構築する権利を持つことに，決して無視できない重要性が見出される。」……こんなところだろうか？
このことに関しては， Joel Spolsky 氏が先日のコラムに書いていたことを思い出す。 "Craftsmanship" － 「職人性」と題された記事だ。
http://www.joelonsoftware.com/articles/Craftsmanship.html
Spolsky 氏は件の記事において，生産性という枠組みでは計ることのできない要素が，高品質のソフトウェアを作成するにあたって必要となることを説いている。ここで挙げられている例で言うならば，「最後の１％のクオリティ」を得るために「５００％の苦労」を費やす覚悟こそが「職人性」の在り処だ。おそらく，このような「職人性」の考え方が，氏の時折主張する「人材第一」のコンセプトを支えているのだろうと思う。
http://www.amazon.co.jp/exec/obidos/ASIN/4894714418
2003-12-14
先日の MGS2 記事のように，努力と友情の物語が繰り広げられている一方で，全く余裕でゲーム制作を行っているという事例も存在する。 Jamie Fristrom 氏の連載コラム "Manager In A Strange Land" で紹介されていた Neversoft の事例だ。
http://www.gamasutra.com/features/20031114/fristrom_01.shtml
Neversoft は "Tony Hawk's Pro Skater" シリーズで有名なデベロッパだ。
この会社は， Playstation 版 "Tony Hawk's Pro Skater" が大ヒットを収めて以来，現在に至るまで，相も変わらず Tony Hawk シリーズを出し続けている。文化の違いからか，僕にはこの Tony Hawk シリーズの魅力というものを正確に理解することはできないのだけれど（"1" も "2" も "3" も "4" も同じゲームに見える！），このシリーズは着実な進化を遂げることによって欧米ゲーマーの心を掴み続けているようだ。シリーズを通して売れなかった製品は無いという恐ろしい状態を維持している。これは，国内で言うところの「三国無双」などのタイトルになぞらえてみると分かりやすいのかもしれないと思う。
http://www.gamerankings.com/itemrankings/itemsearch.asp?item...
先日発売された "Tony Hawk's Underground" は，今までの Tony Hawk シリーズとは一味変わった内容を提供することによって好評を博しているようだ。これまでのシリーズに無い派手な内容のアクションや，ストーリーモードやコンストラクションモード等の各種ゲームモード，それから目玉となっているオンライン対戦など，数々の新機軸を打ち出してきている。
http://www.activision.com/microsite/thug/thug.html
件の記事によれば，その Neversoft が， Tony Hawk シリーズの "3" と "4" の開発においては，いわゆる「修羅場」 (crunch time) を全く経験することなく制作を終えることができたと主張している。
とは言っても，決してゲーム制作に対してストイックな態度を持っているわけでは無くて，単に，スケジュールに対して現実的なものの見方を保っているだけのことのように思える。
しかし，誰だって非現実的なスケジュールを組みたいとは考えていないはずだし，もとより，皆それなりに現実的なスケジューリングを行おうと努力しているはずだ。それでも，最終的なクオリティと残された時間を天秤にかける作業は大変難しいものであり，ちょっとした見積もりの「甘さ」や「欲」が出てしまうところであると思う。必要とされるのは，正しい見積もりを行う洞察力と，それを予定通りに進行させる管理能力と，止め処ない変化に対応して行くだけの俊敏さだ。それらが備えられたならば，あとは単に，そのチームの持つポテンシャルの問題に帰結されることだろうと思う。
2003-12-15
Jamie Fristrom 氏の連載コラム "Manager In A Strange Land" の最新記事は，ゲームプログラムの動作テスト手法について触れたものだった。
http://www.gamasutra.com/features/20031212/fristrom_01.shtml
題名の "Churning" とは「攪拌」の意味であり，ここでは，自動化されたビルド＆テストプロセスのことを指している。
このようなゲームプログラムの動作テスト手法を扱った話として， GDC 2003 における Larry Mellon 氏の公演 "Automated Testing of Massively Multi-Player Systems: Lessons Learned from The Sims Online" が挙げられる。
http://www.gdconf.com/archives/2003/Mellon_Larry-AutomatedTe...
これらの話に登場してくる "Monkey Test" という用語は，普段あまり耳にしない語彙のように思える。これは一般に，「無意味な入力に対する耐久テスト」のことを指す用語であるようだ。エージングテスト（「熟成テスト」の意で，長時間の動作に対する耐久テストのことを指す）の一種として行われるものなのだろうと思う。
ここで挙げられているような「パッドを乱打する」だけのモンキーテストの有効性については，微妙なものがあるだろうと思う。しかし，例えば「状態遷移の瞬間に特定の入力を行うとクラッシュしてしまう」などと言う症状は，よくあるバグのひとつとして挙げられるものだから，そういった類の不具合を探すには良い手段となるかもしれない。
あるいは，「ステージ内に存在するオブジェクトに対してランダムなタイミングでダメージを送信する」などと言うテストは良いかもしれないと思う。「特定の条件下において，状態遷移の瞬間に外部割り込み的な要求を受け取ると，動作が予期せぬものになってしまう」というような症状を何度も目撃したことがあるからだ。
結局，この記事の中で Fristrom 氏は，これらのテスト手法が期待通りの効果を発揮したとは言いがたいと述べている。ここで氏が挙げているような自動ビルド＆テストのプロセスや，上の Larry Mellon 氏の例にあるような非常に凝った機構を実現するには，やはり相当のコストを払う必要がある。それに見合った効果を得ることができるかどうかと言うと……実際には「難しい」と言うのが結論ではないかと思う。
逆に言えば，比較的安いコストで実現できる見込みのあるものについては，積極的に試してみるのが良いかもしれない。例えば，どこかのステージを自動的にロードし，数秒間待機し，退出し，また別のステージをロードして……というような処理を繰り返すだけのテストならば，実装はそれほど難しくないだろうと思う。これでも一応，いわゆる「スモークテスト」として利用することが可能であるはずだ。
http://c2.com/cgi/wiki?SmokeTest
何かゲーム全体に係わるような変更を行ったならば，スモークテストを起動したのちに，トイレへ行って，休憩室でコーヒーを飲んで，そして席に戻ってテストが完了していることを確認すればいい。これによって全てのバグが検出されるわけではないけれど，少なくとも，ステージに入った瞬間にプログラムを停止させてしまうようなクラッシュ系のバグの混入を防ぐことはできるはずだ。
件の記事の最後に，氏は非常にうなずける意見を述べている。
「今日一日の仕事の成果を上げてから帰りたい」という気持ちは非常によく分かるものなのだけれど，これは絶対に避けるべきことだ。サブミットを行った本人が席に残っていれば，まだ即座の対応を行うことが可能であるものの，当人が席を外してしまっているのでは，他の誰かが修正を行うしか手段は無くなってしまう。これは，非常に大きな時間のロスとなる可能性を持っている。
このような事故は，「帰る前にサブミットを行わない」という，非常に単純な心がけを行うだけで回避することが可能なのだから，必ず実践して行くべきだ。もちろん，このルールの適用はプログラマに限らない。特に，アーティストの扱う素材などは，容量の問題から履歴を保存することが難しいため，間違った素材をサブミットされてしまった場合，本人でないと修正することが難しいという状況が発生しやすい。
とにかく言えることは，「サブミットは翌朝まで待て」と，それだけのことだ。
2003-12-16
先日， Ned Batchelder 氏のブログにおいて "IncrediBuild" と呼ばれるソフトが紹介されていた。
http://www.nedbatchelder.com/blog/200311.html#e20031123T1056...
このソフト "IncrediBuild" は， Microsoft Visual Studio に対応した分散ビルド環境だ。
複数のマシンにこのソフトをインストールするだけで，お手軽に分散ビルド環境を構築することができる。コンパイル処理は遠隔プロセスとして各マシンへ分配されるため，受信側 (passive) のマシンに Visual Studio を入れておく必要は無い。その辺りは，この IncrediBuild が自動的に調整を行ってくれるそうだ（内部ではかなり凝ったことをやっているようなのだけれど，件のページにある解説ではこの程度の概要しか分からなかった）。
大規模プログラムのコンパイルや，ハイエンド CG のレンダリングなどのように，純粋に CPU を酷使する類の処理は，分散環境を利用することによって確実に工程時間 (turnaround time) を減らすことができる。具体的な数値については Gamasutra に掲載されていた IncrediBuild のレビュー記事を参照してみると良いだろうと思う。ここでは， C++ で構成された「とある大規模ゲームプロジェクト」のビルドに IncrediBuild を利用した例が挙げられている。これが， 1 台のマシンではビルドに 17 分以上かかっているものが， 10 台のマシンを併用することによって約 5 分にまで短縮されている。
http://www.gamasutra.com/features/20030215/lloyd_01.htm
ちなみに， 30 台のマシンを使えば，これを 1 分 20 秒にまで縮めることができる。コンパイルファームに 30 台もの PC を利用するのは，一般的なゲームデベロッパにとっては現実的な案ではないものの，マシンを増やせば増やすほど効果が得られるらしいという事実は，それなりに参考になるものであると思う。
ただし，このソフトは Visual Studio の標準的なパッケージにしか対応していない。 GCC 等のコンパイラに対応していないことはもちろん， Xbox 開発用の Visual Studio にも残念ながら対応していない（それでも，一応「対応予定」とはされている）。
ライセンスは 1 エージェントにつき $329 とのことだから，さほど高いわけでもないと思う。むしろ，得られる効果を考えれば十分に安い価格だろうと，個人的には考えている。
利用している環境が GCC ベースのものであれば，このような仰々しいパッケージソフトを利用する必要もない。 distcc と ccache によって高度な分散環境を構築することが可能であるからだ。
以前は試用程度に留めていたものを，今では本格的に利用している。利用に関して特に問題は無く，確実に良い効果を得ることができている。
唯一不満点を挙げるとすれば， gcc がバグによって無限ループへ陥ってしまった場合に，それを検出するすべが distcc には用意されていないと言うことだ。これは，一定時間毎にプロセスを監視して，バグっている gcc プロセスを kill するようなプログラムを用意することによって解決が可能であるものの，できれば， distccd に「gcc が一定時間帰ってこなかったら abort する」というようなオプションを追加するのが望ましいだろうと思う。ソースが公開されているのだから，自分で手を加えることも可能なのだけれど，残念ながら，今の自分にはそれほどの余裕が残されていないというのが実情だ。そして，十分な余裕が生まれる頃までには， gcc の方のバグが直されていることだろうと思う（したがって，ここはアドホックな解決法へと逃げておくのが正しい戦略だ！）。
以前から主張しているように， ccache と共有コンパイルサーバの組み合わせは，非常に効果的なコンビネーションとなってくれる。例えば，もし仮に，プロジェクトが 40 個のソースファイルから構成されているとして，現在作業中のファイル（最新版から変更を加えたファイル）の数が 5 個程度であるとしたら，単純に考えて残りの 35 個のファイルは「既に誰かがコンパイルしたものと全く同一の内容である」と考えることができる。これらのファイルに関してコンパイル時間を限りなく 0 まで近づけてくれるのが ccache だ。一見，他愛も無いことのように見えるかもしれないけれど，実はかなり工程時間の短縮に貢献しているのではないかと思う。参加人数が増えれば増えるほど，そのメリットも大きくなるというところがキモだ。
2003-12-17
たとえ IncrediBuild や distcc, ccache のような道具を導入したとしても，プロジェクトの拡大と共に進行するビルド時間の増加を根本的に止めることはできない。特に，システムを構成するコンポーネントの間に複雑な依存関係を抱えたプロジェクトの末路は悲惨なものだ。何かひとつのコンポーネントに対して変更を加えただけで，プロジェクト全体のリビルドが必要とされるような状況に陥ってしまう。また，コンポーネント間に存在する複雑な依存性は，システム全体の分析を困難なものとしてしまう。こうなるともはや，根本的な改善に着手することも難しくなってしまう。
John Lakos の「大規模Ｃ＋＋ソフトウェアデザイン」は，このような大規模プロジェクトに特有の問題を取り扱った書籍だ。
http://www.amazon.co.jp/exec/obidos/ASIN/4894711249
非常に参考になる書籍ではあるものの，必要以上に重いボリュームと（全部で約７００ページある），難解な言い回しの連続する内容は，読解をかなり困難なものとしているように思える。僕も実際には半分も読めていない……こういう本をスラスラと読める人が本当に羨ましいと思う。
このような教科書が既に存在することは心強いものの，全てのプログラマにこの本を読めと言うのは少し乱暴な要望だし，第一，自分でも読みきれていないような本を人に薦めるのは，ちょっと問題があるだろうと思う。実際には，もうすこしシンプルなアイデアに基づいて，依存性の軽減を図っていく必要があるだろうと思う。
とりあえず，現状において，僕は以下のような簡単な規約を提示することにしている。小難しい理屈は抜きにして，最低限これだけは心掛けていきませんか……という一種の提案となるものだ。
これらの規約は，基本的には「ヘッダファイルの連鎖的なインクルードを防ぐ」という明確な目的を持っている。しかし実際には，このような規約を守ることが，結果的に依存性を軽減する設計へと繋がるものと考えている。
一般に，コンポーネント間に発生する依存性というものは，伝播する性質……つまり「推移性」 (transitivity) と呼ばれるものを持っている。この性質により，上位のコンポーネントは下位のコンポーネントに対して「累積的な依存性」を抱えてしまうことになる。
例えば，あるコンポーネントＸが他の１０個のコンポーネントに対して依存性を持っており，もうひとつのコンポーネントＹも，同じように他の１０個のコンポーネントに対して依存性を持っていたとすると，それらのコンポーネントＸ，Ｙを利用するクライアントは，累積的に数えて２２個のコンポーネントへの依存性を抱えてしまうものと考えることができる。
C++ の場合に特に問題となるのは，コンパイル時の結合に対して影響を与える「コンパイル時依存性」 (compile-time dependency) だ。コンパイル時依存性の高いシステムは，実装の変更に対して高いリスクを背負うことになってしまう。これを防ぐために用いられるのが， insulation （絶縁） や compilation firewall と呼ばれているテクニックだ。 OOP で言うところの「カプセル化」が設計の論理面での隠蔽を実現するのに対して，これらのテクニックは実装面での隠蔽を実現するものと考えることができる。
絶縁を行うのに最も簡単な方法は，できるだけ不透明オブジェクト（opaque object － 宣言のみで定義のされていないオブジェクト）を利用するというものだ。 C/C++ では，不透明オブジェクトをポインタないしは参照経由で間接的に操作する限りにおいては，クラスの定義を参照する必要は無い。つまり，関連するヘッダファイルをインクルードする必要が無くなるということだ。
例えば，下の関数 FunctionA は， FunctionB のように書き換えることによって，クラス Element へのコンパイル時依存性を実質的に無くすことができる。
この他にも，具体クラスの実装を不透明オブジェクトの中に閉じ込めることによって，実装（プライベート）部分の絶縁を実現する方法なども多用される。 Herb Sutter が "pimpl idiom" と呼んでいるテクニックだ。
http://www.gotw.ca/publications/mill04.htm
このような工夫を心掛けることによって，ヘッダファイル間に発生する依存性を軽減する（あるいは完全に無くす）ことができる。これは，コンポーネント間の本質的な依存性を無くすものではないものの（この時点ではコンパイル時依存性が抜けただけであり，完全に依存性を無くすには，もう少し突っ込んだ取り組みを行う必要がある），簡単かつ明解なアイデアに基づいてリスクを軽減する方法として提示できるものだと考えている。
2003-12-18
Lakos は前述の書籍において，絶縁を行うべきでない幾つかのケースについても触れている。これは，簡単にまとめると，「システム中で広範囲に利用される小規模な下位レベルクラスに関しては，絶縁を行うべきでない」というものだ。具体的には，依存関係の最下位に位置し（つまり，当該のコンポーネントは他のどのコンポーネントに対しても依存を持たない），インライン化された単純なアクセス関数のみを持つようなクラスのことを指している。
このようなクラスは，絶縁によって生じてしまうパフォーマンスの低下が大き過ぎることと，十分にシンプルな設計であるがゆえに変更の行われる可能性は低いと見ることができるために，絶縁によって得られるメリットよりもリスクの方が大きいと考えられる。例えば， Vector, Matrix や String のようなクラスを例として挙げることができると思う。
Lakos は，上のような「絶縁を行うべきではない幾つかのケース」に関しては，ヘッダファイル内に #include 文を置くことができるとしている。ただし僕個人としては，このような下位コンポーネントに対しても依存性を明確に把握することと，件の「規約」を単純明解なものに保つという目的のために，これに関しても暗黙の #include を行うべきではないと考えている。
最も適当だと思うのは，ドキュメントにおいて依存（インクルードの必要性）のクレームを行っておくことと，「インクルードガード」を利用してインクルードの有無を自動的に確認するというものだ。例えば， Vector クラスを定義するための "vector.h" が，以下のようなインクルードガードを利用していたとする。
ここで， Vector クラスを利用するヘッダファイルでは，以下のような記述を加えることによって "vector.h" のインクルードを確認し，無ければエラーとしてプログラマに警告を示すことができる。
こうすれば，クライアント側では "requires vector.h" という警告を受け取ることによって， vector.h への依存を認識することができる。定義が抜けているために発生するややこしいエラーを見させられるよりかは，こちらの方が遥かに分かりやすいことだろうと思う。
前述の規約にある「規約その２」は，「その１」のおまけのようなものではあるものの，現状においてはそれなりに重要な意味を持つものだと考えている。現状のコンパイラとマシンパワーの組み合わせでは， STL を利用することによって発生するビルド時間の増加が無視できない量にあるためだ。
比較的下位に位置するコンポーネントが，その宣言の中で STL を利用してしまうと，おのずとそのクライアントも STL へのコンパイル時依存性を抱えることになってしまう。 STL は既に完成されたライブラリであり，変更されることが無いと考えれば，依存性の問題はさほど大きくないものと考えることができるものの，依存性を持つだけで実装（ソース）を膨大なものに変えてしまうという欠点は，依然として影響力を持っているように思える。
例えば，比較的下位に位置するコンポーネントが std::map を利用すると，それよりも上位に位置するコンポーネントは全て，そのソース量を数千行増加させてしまう（例えば手元の gcc 3.3.1 では， std::map はプリプロセス後に約七千行にまで膨張する）。これが数個のソースファイルにおいて発生してしまうだけで，全体としての増加量は簡単に一万行を超すこととなってしまうし，最終的には数十万行から百万行以上もの増加を被ることになる。比較的小規模なプロジェクトでも全体では数十万行のソースから構成されていることを考えると，その量の大きさが分かるのではないかと思う。
しかし， STL を利用することによって得られるメリットは決して無視できないものであるから， STL 自体の利用を禁止することは避けたい。そこから得られた結論が，「ヘッダファイル内では STL を利用しない － ソースファイル内の実装においてのみ STL を利用する」というものであるということだ。
これは，後述する理由とも相まって，現状においては相当に妥当な主張となっているように思える。僕自身も，この主張はいつか覆されるべきだと考えている。しかし今のところ出来ることと言えば，そのタイミングを見誤らないよう，慎重に時勢をうかがい続けることだ。
STL は，その本来の目的である総称性 (genericity) に着目するならば，ヘッダファイル内でも自由に参照できるようにするべきかもしれないと思う。そうしなければ，ライブラリの拡張として動作する機能を提供することが難しくなるためだ。
しかし，現状において STL 導入の主目的とされているのは， STL のコンテナクラスの利用であることがほとんどではないかと思う。単純に vector や list を利用したいという目的であれば，それらの組み込みを実装の内へと退避し「絶縁」することは，さほど難しくない作業だろうと思う。
余談になるのだけれど， STL 自体の機能について把握されないまま利用されていることが多いのではないかと思う。 STL はほぼ完全な総称性を実現しているものの，それはあくまでも「応用を制限しない」というコンセプトを実現するものであって，高度な抽象性を提供するものではない。正しく運用を行うには，正しく仕様を把握しておく必要があるわけだ。
例えば，なぜ vector::clear ではメモリは開放されないのか，なぜ大きな構造体の deque は意味をなさないのか，なぜ auto_ptr を格納するコンテナを作ってはいけないのか，等々……それらの基礎的な事実だけでも，把握しなくてはならないことは多く存在する。もちろん，僕自身も把握しきれていないというのが実情だ。
将来的には，最低限の依存性を維持しつつ広範囲に STL を組み込むことのできるような理想的な規約を提示することができるかもしれないし，それ以前に，コンパイラやマシンの性能の向上によってビルド時間の問題が解決されることがあるかもしれない。しかし，それにはもう少しの時間を要することになりそうだというのが，現状での僕の考えだ。
2003-12-19
今日はチームの正式な忘年会。新宿の安っぽい飲み屋で飲み食いを楽しんだ。例年と比較して会費が安いなと思っていたら，単に選んだ店が安っぽかったというだけのことだった。妙に泥臭い雰囲気の店なのだけれど，確かに量だけは出てくる。忘年会でこんなにたらふく食ったのは珍しいことのように思える。
一次会はつつがなく終了して，そのまま二次会に突入。まあ忘年会だし，朝まで続くのは普通のこと。さんざ呑んだり喋ったりで夜が明けることとなった。
来年は少し忙しい一年となりそうだ。思えば今年が余裕有り過ぎたのかもしれない。まあ来年一杯は，久々にその「絶え間なく続く締め切り」の感覚ってものを味わうことになるのではないかな，と思う。
2003-12-20
呑み明けの休日。まあ，例の如く夕方近くまで寝ていた。途中，荷物の受け取りなどがあり，朦朧とした状態で玄関口に出た記憶がある。着払いの荷物だったのだけれど，クレジットカードで支払うことができた。飲み会の会費だなんだで手持ちの現金が少なくなっていたので，カード決算を使うことができたのは幸いだったと思う。
いつもよりも呑みの後遺症は軽かった。アルコールに慣れてきたとか，そういうのは無くて，単に昨日の安飲み屋の出すアルコールが異様に薄かったというだけのことだろうと思う。
飯ついでに立ち寄った本屋で，能澤徹の「コンピュータの発明」を購入した。実のところ，こういうコンピュータ・エンジニアリングの歴史ものには目が無かったりする。気づけば，書籍を手にとってレジへと運んでいた。
http://www.amazon.co.jp/exec/obidos/ASIN/4902403005
帯に書かれている煽り文句が，この本の存在意義を物語っているように思える。
著者の能澤氏は，一般に知られ渡っているコンピュータ史は「引用の引用」によって構成されており，その情報が酷く劣化したものであることを指摘している。
この書籍において能澤氏は，そうした引用の過程で含まれてしまったノイズを除去するために，発明者自身が発明当時に発表した論文を情報源として考証を行い，正しい事実と「コンピュータ史」の提示を行おうとしている。
実際の本文の構成も，ただ事実を記述するのみに留まらず，システムの技術的な説明や，その技術の基となる理論の説明や，当時の時代背景の説明など，かなり突っ込んだ解説を行っており，非常に読み応えのある内容となっている。
まだ読み切ってはいないのだけれど，年末の休みの間にでも読もうと思っている。コンピュータ史マニアにとっては必読の書となりそうな感触だ。
その同じ本屋の棚に，山下章の「チャレンジ！！ パソコンＡＶＧ＆ＲＰＧ」シリーズが平積みされているのを見て，思わず驚いてしまった。こんなの，僕が小学生の頃に読んでいた本なのだけれど……なんでも「１６年ぶりに重版」されたということだ。
http://210.255.112.187/dempabooks/11_avg.html
http://www.bent.co.jp/main/personal/ymst/02/naiyo_fr.htm
恐らく Bothtec の "EGG" シリーズから需要が発生したのだろうと思う。
その本屋と同じ建物にある電器屋では「スターアーサートリロジー」が棚に５，６個も並べられていたりして，どうにも理解に苦しむことが多い。オールドゲームに対する感傷を考慮したって，この地域だけでそんなに売れるあては無いと思うのだけれど……。
2003-12-21
普通の休日。年末ということで，久しぶりに部屋の掃除などをしながら過ごした。
部屋の中に物が増えてきたように思える。どんどんガラクタは捨てていかないと……。
どこのリンクから辿ったのかは忘れたのだけれど， EA Canada の求人広告が面白かった。
http://www.radiumsoftware.com/img/eacanada.jpg
プログラマ限定のネタになってしまうのだけれど……恐らくプログラマを募集しているんだろうと思う。街中で見かけたら，思わずニヤリとしてしまいそうな広告だ。
EA Canada と言えば，以前 Ubisoft との確執が話題となっていた。
http://www.gamespot.com/all/news/news_6076016.html
Ubisoft のモントリオール・スタジオを辞めて EA Canada に移った５人の従業員を，契約違反のかどで訴えているということだ。なんでも， Ubi の重要タイトルであるところの "Splinter Cell" の元メンバーということだから， Ubi 側としても見過ごすわけにはいかなかったのだろうと思う。
ここでも出てくるように，欧米の企業では「会社を辞めた後の一定期間は同業種の企業で働くことができない」という契約を交わすことがあるようだ。非競争条項 (non-compete clause) と呼ばれるものであり，機密情報が競合他社の下へ渡ることを防ぐ目的で交わされるものであるらしい。要するに，守秘義務の一種と考えればいいようだ。この辺りの事情については，以前 FumuFumu に投稿されていた GMan 氏の解説が簡潔で分かりやすかった。
http://fumufumu.q-games.com/archives/000162.php
そう言えば， "Lord British" こと Richard Garriott 氏も， Origin を辞めてから一年間「潜伏」し，それから韓国へと渡っていたような気がする。
http://www.4gamer.net/specials/special_garriott.html
最後に報じられた情報によれば，軍配は Ubisoft の方に上げられているとのことだった。
http://www.gamespot.com/ps2/action/splintercell/news_6076727...
まあ，そういう契約が交わされていたんだから，しょうがないと言えばしょうがないんだけどね……。 "Splinter Cell" というキラータイトルの制作をこなし，制作者としての自信や精力に溢れている時期を，一年間も無駄に過ごさなきゃいけないってのは，本人にとってみれば辛いことだろうと思う。
件の記事によれば， EA Canada はカナダの主要なゲーム企業とひとつして既に存在感を確立しつつあるようだ。依然として Ubisoft が最大手という状況は続いているようなのだけれど（元がフランス系の企業なので，北米の拠点としてカナダを選択したのは自然なことだ……），絶対的な存在であるというわけではないのだろうと思う。
以前読んだ "The Final Hours of Prince of Persia" の中で， "Prince of Persia: The Sands of Time" のディレクターである Patrice Desilets 氏は，自身のカナダでの生い立ちとゲーム産業の関係について語っている。
http://www.gamespot.com/features/6079652/p-12.html
しかし Alias や Softimage のように CG 産業に強みを持つカナダにおいて，ゲーム産業が開花するのは自然な流れのように思える。個人的な心情としては，スポーツタイトルばかりの目立つ EA Canada よりも，ユニークなタイトルに挑戦し急成長を遂げている Ubisoft の方に期待したいところなのだけれど……。
2003-12-22
今日は会社でクリスマスの催しが開かれた。今年は会場が二手に分かれているということで，余裕をもって行っても食い物にありつけるだろうと高をくくっていたのだけれど，案の定，僕が会場に着く頃には殆どの食い物が食い尽くされていた。ううむ，予想していたことではあるけど……油断ならんね。
適当な頃合を見て抜けて，自動販売機のパンで腹を満たした。
また，どこのサイトが元だったかは忘れてしまったのだけれど，どこぞのサイトで "ARQuake" のことが話題に挙げられていたので，久しぶりに件のウェブサイトを訪問してみた。
http://wearables.unisa.edu.au/projects/ARQuake/www/index.htm...
以前は無かった幾つかのビデオが置かれている。
http://wearables.unisa.edu.au/projects/ARQuake/www/videos/in...
あまり良く出来た内容ではないのだけれど，実際に「現実」と「仮想」の合成が一人称視点で行われているという構図には，ちょっと印象的なものを感じる。
"ARQuake" は South Australia 大学はウェアラブル・コンピュータ研究室の Bruce Thomas 助教授が中心となって開発された「強化現実」 (Augmented Reality) 版 Quake だ。 AR を利用した CAD システムであるところの "Tinmith" プロジェクトの派生物として制作されたものであるらしい。
当初の目的は，屋内と屋外の両方でシームレスに運用することのできる AR システムを開発することにあったようなのだけれど，いつの間にか，屋外での動作が可能な AR ゲームシステムを開発することが主目的となってしまっている。 ARQuake 自体の概要については， Communications of the ACM 誌に掲載された記事 "Quake: The Outdoor Augmented Reality Gaming System" が簡潔にまとまっていて分かりやすい。
http://wearables.unisa.edu.au/projects/ARQuake/www/papers/pi...
この手の AR システムは，本来ならば光学あるいは磁気式の追跡システムを利用することになるのだろうけれど， ARQuake や Tinmith は屋外の広範なロケーションを対象としているため，動作範囲を限定してしまうデバイスを利用することは難しい。そこで，位置の取得には GPS を利用しているとのことだ。
ただ，通常の GPS システムでは数メートル単位での誤差が生じてしまうため，そこには特殊な機器が用いられている。位置の取得には並列１２チャネル方式の高精度 GPS が利用されており，方向の取得には磁気インダクタンス方式のデジタル・コンパスが利用されている。どちらも特殊な用途に用いられる追跡システムの一種のようだ。