2003-06-01
次に手を付けてみたのが， Robi Polikar 氏の "The Wavelet Tutorial" だ。
http://engineering.rowan.edu/~polikar/WAVELETS/WTtutorial.ht...
これは，工学系の学生に向けたウェーブレットの即席講座だ。何だかちょっと掟破りっぽい香りのする内容なのだけれど（話がぶっちゃけ過ぎているような感じがしないでもない），実践的な入門書としてはこのくらいが適当なのかもしれない。アナライザによるプロッティングなどを交えつつ，実践面から見たウェーブレットの優位性と，その原理について簡単な解説を行っている。
ここでもやはり，周波数と時間の関係がトレードオフであることが強調されている。その制約を受けつつも理想的な解析を行うことのできる手法がウェーブレットであることを示し，その利用価値を定めようとしている。また，比較対象として短時間フーリエ変換 (STFT - Short Term Fourier Transform) での解析例を挙げ，フーリエ変換をベースとした手法の限界を具体的に示している。
この文献では，最終的に離散ウェーブレット変換 (DWT - Discrete Wavelet Transform) まで解説を行っているのだけれど，最後の方は内容が若干散漫になってしまっているような気がする。まあ，こんなもんかな……。
余談だけれど，このページ，書式が整理されていなくて，少し居心地が悪い。理工系の人間って，嫌でも論文の書式とか身に付けなきゃならんから，ワープロの使い方なんて当然マスターしているものだと思っていたのだけれど……むむむ。このままでは印刷に不便だったので，思わず MS Word で整形してしまった。近頃は Word でウェブ書いちゃう時代なんだよなあ……。
続いて参照したのが， Clemens Valens 氏の "A Really Friendly Guide to Wavelets" だ。
http://perso.wanadoo.fr/polyvalens/clemens/wavelets/wavelets...
こちらは，これまでの文献とはうって変わり，数学的な見地からウェーブレット変換の持つ諸性質を解説している。ただし，ウェーブレット変換の手法自体に対する解説はほとんど無いので，あらかじめウェーブレット変換がどんなものであるのか把握していることが前提となるのだろうと思う。
この文献では，前述の "The Wavelet Tutorial" では第４章に当たる内容……つまり，連続ウェーブレット変換から離散ウェーブレット変換が導き出されるまでの過程を，１ステップづつ丁寧に解説している。ローパスフィルタの役割を担う「スケーリング関数」の導入によって係数の打ち切りが可能になる，って辺りがキモかな……。そこから先は，何となく馴染みのあるフィルターバンクを使い，極めてシンプルなメカニズムによって離散ウェーブレット変換が構成可能であることを示している。
……たった今気が付いたんだけれど，これってパート３までシリーズ化されているんだなあ。全然気付かなかった。
http://perso.wanadoo.fr/polyvalens/clemens/lifting/lifting.h...
http://perso.wanadoo.fr/polyvalens/clemens/ezw/ezw.html
高速ウェーブレット変換や，非可逆圧縮アルゴリズムへのウェーブレットの応用など，わりと重要そうな応用を扱っている。ああ，こっちも読まなきゃなあ……。
……と，ここまで読み進めてみて，何となく概論のようなものは見えてきたように思える（恐ろしく迂闊な理解ではあろうけども）。ここから先は，もう少し応用の方面を調べてみたいと思っている。例えば JPEG 2000 の仕様を詳しく調べてみるとか，ウェーブレットを利用したフィルタの構成方法を調べてみるとか……。
もう１つ，優先して調べたいと考えているのが，ウェーブレット変換を行うライブラリの存在だ。実際に興味を持つべきは原理と応用と実践であって，その手段については極力手を抜くべきだと考えている。例えば，フーリエ変換ならば FFTW ライブラリを使えば良いというように，何か定番のツールがあると助かるのだけれど……どうだろうか。
http://www.cipr.rpi.edu/research/SPIHT/
2003-06-02
まだ眠気も覚めやらぬ朝のウェブ巡回中のこと， Eurographics 2003 の paper をチェックしなきゃなあ，と思いつつ GDC 2003 のアーカイブを開くという大ボケをかましながらも，実はその GDC 2003 のアーカイブがいつの間にか更新されていることに気がついた。
http://www.gdconf.com/archives/2003/
３月の時点では未公開だったスライドや，ラウンドテーブルセッションのレポートなどが追加されている。ああ，今さらだけど読んでおかなきゃ……。
追加された資料の中でも，まず最初に興味を惹かれたのが， Insomniac Games は Brian Allgeier 氏の講演 "Designing a Ratchet and Clank Level" だった。
http://www.gdconf.com/archives/2003/Allgier_Brian.zip
この講演では， Allgeier 氏らが "Ratchet and Clank" において実践した制作フローについて，実に詳細な解説を行っている。計画的な制作工程を実現させる上で必要となるであろう多くの知見が含まれており，資料としてかなり参考になるのではないかと思う。
同作品において氏が担当したのは，主にステージのデザイン（設計）であったようだ。すべてのステージを３人のデザイナによって分担し，それぞれのステージに対して２人のアーティストと１人のプログラマを専門的に割り当てる。そして，それを約６週間かけて仕上げる，というイテレーションをベースとして制作を進めたとのことだ。
人月リソースの割り当てはそのようなものとして，これを滞り無く進行させることが最大の使命となる。どのようにフローを構成すれば進行に妨げが出ないだろうか？ どの要素に対してどの程度のリソースを割り当てることが可能なのか？ 制作過程において発生した問題についてはどのように対処すれば良いのだろうか？
これらの問題を解決するにあたって重要な役割を担ったのが， Cerny Games でお馴染みの Mark Cerny 氏の存在であったようだ。 GDC Europe において行われた同氏の講演 "The Method" には，その辺りの問題に対して氏の持つアイデアが詰め込まれている。
http://www.gamasutra.com/gdce/2002/mark_cerny.zip
マクロデザインのレベルにおいて，ゲームの全体像の調整と，制作に必要とされるリソースの配分を決定しておくことがコツなのだろうなと思う。比較的短期間のイテレーションを明確に定義して，問題解決をその枠の中で行うという手法も興味深い。あとは，試作段階において主要なゲームシステムの検証を完了させておくことも重要なタスクとなるのだろうと思う。
また Cerny 氏の存在は，制作の各場面において重要決定を下すブレーンの役割としても有効に働いたようだ。要するに，チーム全体が行き詰まりを見せた瞬間に，外部からスパっとメスを入れる役目なんだろうなと思う。たとえ完全な解決策とは限らずとも，そういう強力な決定意志がどこかに存在することによって，硬直化した状況が突き崩される……そんなシチュエーションが，どのような組織においても少なからず発生するのではないかと思う。
資料を見ていて特に面白かったのが，各所において具体的な数値が提示されていることだ。
敵キャラクタのプロトタイピングについては， Gamasutra の記事 "Giving Life to Ratchet & Clank" にも紹介されていた。
http://www.gamasutra.com/features/20030211/lally_pfv.htm
まず最初にアニメーションの仕様を決定してしまう，という設計手法は，考えてみれば当然の方法論だと思うのだけれど，意外と実践されていないケースが多いのではないかと思う。この辺りのフローが整理されていないと，制限された素材を使って無理やり制作を行うハメになってしまう。しかもプロトタイピングが不完全（あるいは皆無）だと，後から完成版の素材が揃ってきたときに，それを結合する段階において二度手間を踏むことになってしまう。
制作上のどの要素に関しても，最初から作り込みを行おうとすると，後に他と依存関係を持つ要素で足の引っ張り合いを行ってしまうことは必然だ。従って，いかにして作り込みの要素を設計から分離するか，という問題は，解決しておいて然るべきもののように思われる。しかも単に分離しただけでは駄目で，それが後に問題無く消化できるようになっていなくてはならない。 Insomniac の採用した「プロトタイピングを明確に工程化する」という方法論は，そういった問題に対する１つの解答なのだろうと思う。
2003-06-03
今日も仕事を終え，何事も無く家に着くと，不在中に amazon から一冊の本が届いていたことに気が付いた。えへへ……ついに買っちゃったんだよな，これ……。
http://www.amazon.co.jp/exec/obidos/ASIN/4627018304
Saunders MacLane の大書「数学 − その形式と機能」だ。絶対に読了できるはずが無いと分かっているにも関わらず，勢いにまかせて購入ボタンを押してしまったのだ。ええい，どうしてくれようか……。
高校や大学の教養課程における数学の授業は，基礎的な分野に対して丁寧なカテゴライズを行っている反面，それぞれのカテゴリが見事に分断されてしまっており，数学という大きな括りによって全体を見渡すことができなくなってしまっているのではないかと考えることがある。これらのカテゴリが，それぞれどのような意味を持ち，どのような関連性によって結び付けられるのだろうか。
そのような大域的な視点を持っていないものだから，例えば複素解析の授業にオイラーの公式などが出てきた瞬間，不意に自分の居場所を見失ってしまう。先ほどまで虚数や実数が云々とか言っていたものが，急に平面的な広がりを持ち始める瞬間だ。しかも，何故にここで自然対数の底が出てくるのだろうか？ 何故に三角関数？ 極座標？ これまでまったくバラバラに扱っていたものが，たった１つのシンプルな公式によって繋がりを持ってしまう様子は，理論よりもむしろ詐欺に近いものを感じさせられる。
http://www.wikipedia.org/wiki/Euler%27s_formula
件の本の第一章は，自然数の数学的な定義から始められている。そこを出発点として演繹を繰り返し，有理数，実数，関数，幾何学，線形代数，微積分……というように，数学の基礎となる概念を相互に関連付けながら，一連なりに駆け抜けていく。そしてこの本を読み終える頃には，今まで得ることのなかった「数学の構造」について概観を掴むことができるようになっているだろう……とのことだ。
つうか，ごたくはいいから，とっとと読まないとね……。
直感的に数学を理解し，それを自由に駆使するというのは，一体どんな気分なのだろうかと考えることがある。例えばプログラマならば，プログラミングを長い間続けていると，理論よりもむしろ直観からプログラミングを行うことが可能となってくる。熟練した数学者というものも，恐らくそのような感じで，数式の間に存在する関連性を直感的に理解することができるようになるんだろうな，と思う。
しかし例えば，伝説の天才ことラマヌジャンのような人物のレベルになると，その思考の構造を理解することは，極めて難しい問題となるのだろうと思う。
http://scienceworld.wolfram.com/biography/Ramanujan.html
http://poema.hp.infoseek.co.jp/2003/jan/nisimura.html
http://www-gap.dcs.st-and.ac.uk/~history/Mathematicians/Rama...
数学とは何の関連も持たない環境に生まれ育った氏が，奇妙な巡り合わせから天才的かつ特異な能力を発揮するようになったことは，非常に興味深いとともに，極めて不思議な印象を与える話として記憶に残る。
彼の残した「まるで神から直接手渡されたかのような数式の数々」は，今でも多くの人の心を惑わし続けているという話だ。
http://www.amazon.com/exec/obidos/ASIN/0387949410
もっとも，「まるで神から直接手渡されたかのようなコードの数々」なんて，絶対に読みたいとは思わないのだから，プログラマは直感的な才能に頼らない方が有り難いものかもしれないと思う。
http://info.astrian.net/jargon/terms/y/You_are_not_expected_...
2003-06-04
ダメダメの日々。コーディングがちっとも進みやしない。
この半年と言うもの，無駄に時間を費やし続けているような気がしてならない。さすがに罪悪感を覚え始めている。
やはり，中途半端にインフラへ手を出すのは危険だと感じる。ミドルウェアの導入を本気で視野に入れ始めているぐらいだ。ミドルウェアに対する周囲の高い不信感は，いまだ拭い切れていない状態なのだけれど，自分達自身に対する不信感の方がそれを上回るのは，もはや時間の問題なのかもしれないと考えている。
http://www.tmstation.scei.co.jp/public/Newsletter0008/result...
それにしても，いつの間にか「ミドルウェアと言ったら即ち RenderWare 」という時代になってしまっているのも，なんだか怖い感じがする。対抗馬として有力に見えていた Intrinsic Alchemy も，なんだかゴタゴタした状況に巻き込まれてしまい，先行きが非常に危ぶまれている状態だ。開発技術の高度化によって躍進を遂げているように見えるツール・ミドルウェア業界も，その実は非常に辛い状況に立たされているのかもしれない。 S/N Systems や Criterion, それからウェブテクノロジのように，ひとたび顧客を獲得したところは安泰としても，それ以外がさっぱりなあ……。
GDC 2003 の公開資料を読み進めている。次に手を付けてみたのは，ゲーム AI に関するラウンドテーブルセッションのレポート資料だ。
http://www.gdconf.com/archives/2003/dybsand_eric.doc
http://www.gdconf.com/archives/2003/Woodcock_Steve.doc
http://www.gdconf.com/archives/2003/Kirby_Neil.doc
これでも一応 AI プログラマの端くれなのだから，読んでおかなければならぬだろう……。
このセッションは， Eric Dybsand 氏と Steven Woodcock 氏，それから Neil Kirby 氏の３人によって司会されている。 GDC の各種セッションの中でも比較的人気が高いようで，そのために３日編成で開催されているとのことだ。その辺りの事情については Woodcock 氏のレポートに詳しく解説されている。
３日間のセッションのうち，１日目は一般的な内容の討議を行い，２日目は FPS, RTS, RPG の３つのジャンルに分かれ，より専門的な内容の討議を行っている。そして３日目は AI 初心者に向けた質問会の場となっているようだ。
プロセッサの性能は指数関数的な向上を続け，またそれと同時に，並列的な処理を行うアーキテクチャが台頭してきたこともあって， CPU が描画以外の処理に割くことのできる余裕は，ますます増え続ける傾向にある。ゲーム AI の処理などは，まさにその恩恵を受けるべき分野であり，これまではリソース上の制限から許されることの無かった様々な試みが，競って開始されるものと考えていた。
しかし，実際のところでは，そのような方向性での進展はあまり無く，逆に落ち着きを取り戻しつつあるかのように思えることさえある。ちょっと浮ついた技術者ならば誰もが夢想していたような「ニューラルネットワーク」や「遺伝的アルゴリズム」等の技術が本格的に応用されることはいまだなく，もっと現実的な範囲内での技術の向上と成熟が繰り返されている段階だ。
昔から定番の問題であった「経路探索」については， A* アルゴリズムの教育普及が進んだことによって，ほぼ「解決済み」の問題として扱われている。もはやその部分で余計な試行錯誤を行う必要は無く，枯れた技術として A* を用いれば，ほぼ例外無く解決できるということだ。この辺りの情報源としては Gamasutra や Game Programming Gems が役に立つ。
経路探索に似た１つの技法として "Steering Behavior" も取り上げられている。これは Craig Reynolds 氏の著名なサイトのことを指しているのだろうと思う。
http://www.red3d.com/cwr/steer/
Java による各種アルゴリズムの解説が楽しげなさサイトだ。最近は SCEA R&D と共同で研究を行っているらしく，その成果が "OpenSteer" という名前のライブラリとして公開されている。
http://opensteer.sourceforge.net/
このライブラリ自体は，実はそれほど利用価値のあるものでもない。ただ，これから AI の挙動を設計しようというときに，このデモをインスピレーションの材料とするのは面白い利用方法だと思うし，あるいは実験用のプラットフォームとして使ってみるもの良いかもしれない。
今後の AI の発展の方向性として関心を持ち続けているのが，高度な主体的存在を成すエージェント同士の相互干渉が "Emergence" −「創発性」を生み出す原動力となるのではないか，というアイデアだ。ただ右から左に動く物体や，ただプレイヤーのみを追いかける NPC 等を配置することによってゲームを構築することは，決して不可能ではない。しかしそれでは，極めて狭い可能性の事象しか表現することができない。そうではなく，エージェント達がそれぞれ独自の思考と行動様式を持ち，それらが相互に認識と干渉を行うようなシステムを作り上げることができれば，そこから自ずと豊かな可能性の表現が導き出されるのではないか……ということだ。
例えば……本当はあまり相応しい例ではないのかもしれないけれど， "The Lord of the Rings" における AI エンジン "Massive" の成功などが，このアイデアを支えるイメージとして，脳裏に深く焼き付いている。
http://www.massivesoftware.com/massive.html
http://www.lordoftherings.net/effects/launch.html
2003-06-05
引き続き GDC 2003 の資料を読み進めている。次に手を付けたのは， Maxis は Larry Mellon 氏の "Automated Testing of Massively Multi-Player Systems: Lessons Learned from The Sims Online" だ。
http://www.gdconf.com/archives/2003/Mellon_Larry-AutomatedTe...
この講演は， Maxis の最新作 "The Sims Online" において氏らが導入したテスト手法を解説したものだ。ゲーム制作におけるテスト手法の導入事例と言うだけでも，かなり珍しい内容のテーマだと思うのだけれど，この資料を見る限りでは，かなり本格的なテストシステムの構築に成功しており，しかもそれが相応の効果を上げていることが分かる。
"The Sims Online" のテスト手法において大きなキーとなるのが， "Monkey Test" と "Sniff Test" の２種類のテストの存在だ。
"Monkey Test" とは，ゲーム内に用意されたフィーチャーの動作を確認するために用いられるテストだ。 "Sims Script" と呼ばれる独自のスクリプト言語と，テスト用のダミーインタフェース ("NullView") を利用して，特定のフィーチャーに対応するテストを用意していく。例えば「アバターが椅子に座れるかどうか」という内容のテストならば，次のような制御を通して動作の確認を行う。
"The Sims Online" においては，古典的な単体テストは行わずに，この "Monkey Test" を重点的に行っていったとのことだ（これは「貧者の単体テスト」であると述べている）。たしかに，ゲーム制作の現場的な事情を考慮した場合，下部のライブラリを除いては，このような「フィーチャー指向」でテストを行うことが優れていると思えるところがある。
また，このような種類のテストを用意することは，多くのゲームプログラマにとって受け入れやすい規準となるのではないかと思う。厳密で冗長な単体テストを逐次用意することは，ゲームプログラマにとって苦痛に感じられることがある。しかし，ゲームのフィーチャーに対するテストならば，みんな喜んで（あるいは渋々ながらも）用意してくれるだろうと思う。検証対象をゲーム内容と重ねることによって，手段（テスト）を目的（ゲームを作ること！）と直結させることが可能となるからだ。
"Sniff Test" （嗅ぎつけテスト）は，コードのチェックイン前に履行することが義務付けられているテストスイートのことを指している。要するに退行テストの一種と捉えることができるかもしれない。
Mellon 氏は講演の中で，バグの混入したコードが検証無しにチェックインされることに対しての危険性を強調している。例えばコードに対して何らかの変更を行ったとして，それが既に開発済みの要素に対して不具合を発生させてしまうことがある。このようなタイプのバグは，軽いチェックでは発見することが難しい。しかも，バグの混入から発見までの期間が長引けば長引くほど，発見と修正のコストは高くついてしまう。
これに対して「番犬」の役割を果たすのが Sniff Test の存在だ。このような検証手段を用意し，それを義務化することによって，前述したようなリスクの発生を防ぐことができ，システムの安定化と開発の効率化を図ることが可能となる。
また，このテストには，稼動中のコードに対して信頼性を与えるという効果も備わっている。稼動中のコードに発生する不具合というものは，意外と広い範囲に対して影響を及ぼしてしまうことがある。例えば，他のスタッフの作業に支障をきたしてしまったり， QA チームの作業範囲を狭めてしまったり，突然の上司の来訪に戸惑ってしまったり，等々……。これらの不安材料を取り除くことが，意外と侮れない効果を含んでいるように思える。
"The Sims Online" における Sniff Test のプロセスは，完全に自動化されていたとのことだ。専用のホストが定期的にリポジトリの内容をチェックアウトし，コンパイルし，実行する。結果としてエラーが得られた場合は，その概要をメールでプログラマに報告する。それと同時に，問題となったソースの「拘留」が発動され，プログラマはバグの即時収拾を求められるというわけだ。
2003-06-06
"The Sims Online" で用いられたようなテスト手法を実現するには，いくつかの特殊な機構を用意する必要がある。その中でも最も大きな要素は，ゲーム内における所定の操作をスクリプト言語によって制御可能としたことと， "NullView" と呼ばれるダミーインタフェースを用意したことではないかと思う。
ゲーム内のフィーチャーをテストする目的でスクリプト制御システムを導入したというのは，なかなか興味深い話だ。たしかに，その方がテストスイートは組みやすくなるだろうし，ロジックとインタフェースのレイヤー分けを強化するという意味でもプラスに働くものがあるかもしれない。
究極的なことを言えば，そこにスクリプト言語を用いるべきであるというような確固たる理由は無いだろうと思う。軽くて速い C++ コンパイラのライセンスを人数分と，あとは十分に使いやすいライブラリが存在すれば良いはずだ。要は，実際問題としての「使いやすさ」の問題と，「どこまでがコードで，どこまでがデータであるべきか？」という便宜上の境界線を設定しておきたい，というだけの話だ。
NullView の存在も重要な要素だ。「ロケットマウス」のような操作のマクロ化によってテストを行うことも不可能ではないものの，やはりそれには限界が存在する（それもかなり低いレベルの限界だ）。通常のユーザインタフェースと共に，プログラマブルなダミーインタフェースを用意しておくという条件は，フィーチャー指向のテストを実現するにあたって必須の条件となるだろうと思う。
実際に "The Sims Online" においては，あるフィーチャーを用意すると同時に，それに対応する NullView を用意することを義務付けていたようだ。追加コストの面で不安が感じられるものの，用意しておけば何かと役に立つことがあるかもしれない。ちょっと微妙なラインだけどね……。
"The Sims Online" では，このような機構を用意することでテストを有効に運用することができたとしているが，すべてのゲームに対してこのようなテストシステムを適用することが可能かと言うと，難しい問題であるように思える。特に３Ｄアクションゲームのような，リアルタイム性が非常に高く，空間的な自由度の高いゲームでは，そのシステムの厳密な検証は複雑かつ困難なものとなるだろう。
しかしそれでも，テストの余地がまったく残されていないわけでは無いはずだ。
例えば， DOOM のような３Ｄシューターを開発しているとする。このシステムに対し，「エリアＡを踏破することが可能か？」とか，「誘導ミサイルをジャンプでかわすことが可能か？」とか，「ボスＡの弱点をピストルで攻撃することが可能か？」というような種類のテストを自動で行うことは不可能だ。それにはやはり従来の人手による QA チェックが必要とされる。
しかし，例えば「自動ドアとスイッチを組み合わせた場合に，スイッチを叩く動作がドアの機能に正常に伝わるか」というようなフィーチャーのテストを行うことは可能だろうし，そのテストを用意する意義は大きいように思える。特にオブジェクト同士の動作のリンクは，些細な内部仕様の変更によって破綻することがあるため，退行テストによって得られる信頼性の向上は決して無視できないものとなるはずだ。
個人的な経験を挙げるならば，オブジェクトの持つ内部フラグの状態遷移にちょっとした変更を加えた際に，気付きにくいバグを混入させてしまったことがある。ドア→スイッチの順に生成している個所が全て動かなくなってしまったのだ（スイッチ→ドアの順なら正常に動作するため，簡単な動作チェックでは気付くことができなかった）。
少なくとも僕の経験に関して言えば，このような種類のミスは日常的に発生している。本来ならば，仕様の厳密な設定と，単体テストによる検証を経ることで，十分な信頼性を得ることが可能なのだろうけど，どうもそういうストイックな話は非現実的な匂いを感じてしまう（気合が足りないだけだろうか……）。
また，人手でなければテストできないような項目が多い場合，テストを補佐するためのツールを用意しておくことにも重要な意義が感じられる。適切なシチュエーションを仕組んだ「テストステージ」を用意しておくことはもちろん，ゲーム内において特定のシチュエーションまで移行する過程を自動化したツールや（ここではスクリプト制御が大いに活躍するだろう），以前述べたような「ジャーナリング」の機能も役に立つだろう。
最後に忘れてはならないのが，テストに要されるコストの問題だ。テストは決してコスト無しに実現されるような類のものではないし， "The Sims Online" のような本格的なテストシステムを構築するには，それ相応のコストが費やされることになるはずだ。
そこで，「何をテストし，何をテストしないべきか」というような取捨選択が，意外と重要な意味を占めるようになってくるのではないかと予想している。また，実装時に迷いを感じないためにも，「何をどうテストするか」といったポリシーを前もって設定しておくことが必要となるだろうと思う。
そのような項目を検討するにあたって，今回のような事例の紹介は，参考にすべき点が多く存在するのではないかと考えている。
2003-06-07
E3 の Half-Life 2 デモの衝撃がいまだに忘れられなくて，思わず初代 Half-Life に手を出してしまった。あわわ……。
http://www.amazon.co.jp/exec/obidos/ASIN/B00009993I
http://moon.cyberfront.co.jp/title/pc/12_middle/
今さら Half-Life なんて……って気もしなくないんだけれど，体験版しかプレイしたことが無いのだからしょうがない。体験版がかなり手厳しかったこと（実は体験版の方が難易度が高いようだ）と， Quake2 エンジンを利用しているためにビジュアル面に見るべき所が無かったこと（Unreal の登場によって Quake2 エンジンのビジュアルは既に陳腐化していた）から，当時は食指が動かなかったわけだ。
しかし，今にして思えば，その判断は間違っていたかもしれない。このゲームは，今プレイしても見るべき所が多いと感じる。当時，これをリアルタイムに体験していたら，さらに違った印象を持つことになっただろうと思う。素直にプレイしておけば良かった……。
久しぶりにゲームを長時間プレイしているような気がする。さすがに手首が痛くなってきた。いわゆる RSI ってやつだ。
http://www.google.co.jp/search?q=%94%BD%95%9C%90%AB%89%DF%98...
なんか微妙に 3D 酔いしてるような気もするし……。うへえ。
2003-06-08
やっとのことで Half-Life をクリアした。ちょっとくたびれてしまったけれど，非常に充実した内容だったので満足している。 FPS を最後までプレイしたのは久しぶりのような気がするな……。
クリアまでのプレイを通じて，個人的に最も楽しいと感じたのが，敵兵集団との戦闘の数々だった。逆に，エイリアン系の敵キャラが繰り出してくる「いかにも DOOM 的な」動きには，あまり面白味を感じられなかった。プレイヤーを見つけると，「キシャーッ」とか一声叫んだあとに，ただプレイヤーを追いかけ攻撃し続ける……というような類の，あれだ。
実のところ，敵兵の AI にしたって，それほど高度な思考を行っているわけではないように思われる。柱の影に隠れて攻撃してくるのは，柱の影にウェイポイントが設置されていることが条件であるし，敵兵同士の連携や進退のタイミングも，冷静に観察してみればよく理由の分からない動きをしていると感じられることがある。
それでも，ただ闇雲に突っ込んでくるのではなく，「一応ちゃんと考えているように動く様子」が楽しいと感じられる。状態とパラメータを多く用意し，遷移を複雑に構成することによって，見かけの行動パターンを豊富に見せる……とか，ステージ設計とウェイポイント配置の妙によって「本当に戦闘を行っているような感覚」を呼び覚ます……とか，そういった作りこみの細かさが良い印象を作り出しているのだろうと思う。
物陰に隠れて弾を装填している最中に，頭上から手榴弾を投げ込まれたら，そりゃ誰だって驚くだろうと思う。そういったシチュエーションを作り出す想像力の逞しさが，優れた設計に結び付くのだろうと思う。
例えば "Quake 3 Arena" の AI などは，これとは実に対照的な存在だった。高度な技術力によってウェイ捜索の自動化に成功したことは，制作コストの大幅な削減に結び付いたという点において優れた選択だったのだけれど，そのために「人間臭さ」を持った動きを作り出すことが不可能となってしまったという印象がある。
無駄の感じられない動きで敵を追跡し，アイテムを確実に拾い集め，精密な射撃でプレイヤーを脅かす Q3A AI の存在は，「賢い AI 」という点ではある一定のレベルを実現しているものの，それがゲームとしての面白さに直結しているかどうかというと，難しいところがある。「プレイヤーが望んでいるのは必ずしも賢い AI ではない」という点において，将棋や囲碁の AI とは違った性質を持っているという前提を認識することが，ゲーム AI 設計の第二歩目となるのだろうと思う（もちろん，第一歩目は賢い AI を作ることだ）。
そう言えば，このゲームでは銃火器の装填に要される時間の長さがゲーム性に対して大きな影響を及ぼしているように思える。このゲームの銃火器は，弾を一定数撃った後に装填しなければいけないというルールなのだけれど，この装填時間が比較的長めに設定されている。そのためプレイヤーは，ただ反射神経にまかせて弾を撃ちまくるだけではなく，「ある程度撃ったら物陰に隠れて装填を行う」という流れを，常に頭に入れておかなければならない。この「攻撃」と「装填」という攻守の入れ換えの生み出すリズムが，戦闘のメリハリとなっていて気持ち良く感じる。
この条件は敵兵についても同様だ。そこから，「物陰に身を隠して，敵に弾を撃たせ切ってから，装填の瞬間を狙って踊り出る」という基本戦略が生み出される。もちろん，物陰に身を隠している間に，後ろに回り込まれてしまうこともあるし，上から手榴弾を投げ込まれることもある。この辺りのシステムがもう少し作り込まれていたら，本気で戦闘だけを楽しめるゲームになっていたかもしれないと思う。
いわゆる「イベント」の類がすべてゲームプレイ中に発生する，というシステムも面白い。これはむしろ Quake2 エンジンという制限の上でゲームを設計するにあたって，自然と生み出された流れなのかもしれない。ともかく，プレイヤーの操作が拘束される瞬間というものがほとんど存在せず，すべての事象がシームレスに進行する様は，なかなか新鮮で面白い。これに一人称視点というシステムが相まって，ゲームへの没入感はかつて無いほど高くなっている。
そのような自由度の高い設計だから，当然，ゲームとしての「ハマリ」も存在するのだけれど（例えば，ゲーム進行上の重要人物を撃ち殺してしまえば，そこでゲームはハマってしまう），そういった流れは意外にも発生しない。プレイヤーを誘導する仕組みを作り上げるのが上手いのかな……。ともかく，僕がプレイした限りでは，ハマリが発生することは一度も無かった。ハマると強制ゲームオーバーになるということも，一度クリアした後に気付いたことだ。
これは余談だけれど， Quake2 エンジンは，「基本はソフトウェアレンダリング，オプション的にハードウェアレンダリング」という構成なので，実際にはソフトウェアレンダリングを選択した方が「制作意図通りの画像」を得られているような感じがする。もちろん，ハードウェアレンダリングの方が高速なのは確実だし，解像度も高く設定することが可能だし，バイリニアフィルタ等のエフェクトも有効になるのだけれど，必ずしもそれが画質の向上には結び付いていないのではないか，という印象がある。
最近のＰＣならば，ソフトウェアレンダリングでも十分にフルフレームレートを叩き出すことが可能だ。ハードウェアレンダリングのねっとりした画質に違和感を覚えたならば，ソフトウェアレンダリングを選択してプレイしてみるのも良い手だろうと思う。
そんなわけで，これがああなって，あれがこうなると， Half-Life 2 ではこうなるってわけね……というような，時代の推移を改めて認識することができた。ええと，それはともかくとして……単純に面白い FPS だったなあ。これまでにプレイした中で最も面白い FPS として挙げることができるかもしれない。
このところ長らく FPS から遠ざかっていたのだけれど，久しぶりに興味が湧いてきた。これを機会に何か他のゲームもプレイしてみようかと考えている。
2003-06-09
相も変わらず，ちくちくと細かいコーディング作業を続けている。こんなの適当に片付けて，早く先へ進んでしまった方がいいのかもしれないと考え始めている……考えているくせに，そうできないまま立ち止まっているのは，単に危機感が足りていないのか，それとも，元々その程度の行動力しかなかったのか……。
少し思うところあって， iostream の拡張に手を出すことにした。 "operator <<" を自前のクラスに向けてオーバーロードする……というような細工は普段からやっていることなのだけれど，自前のストリーム (ostream, istream) を作成するというような種類の拡張については，これまで手を出したことが無かった。
iostream の拡張など基本テクニックのひとつなのだから，軽く検索にでもかければ，すぐに適切な資料を見つけることができるだろうと踏んでいたのだけれど，いざ探し始めてみると，それほど簡単に見つけられるものでも無いことが分かってきた。意外と少ないんだな，これが……。
実際に拡張を行ったサンプルコードを提示していて分かりやすかったのが， Dietmar Kuhl 氏のページ "Information About IOstreams" だ。
http://www.informatik.uni-konstanz.de/~kuehl/c++/iostream/
このページでは，実際に数種類の自前ストリームを作成することによって iostream 拡張の手順を分かりやすく解説している。簡単な拡張ならば，このコードを真似するだけでも十分にカバーすることが可能かもしれない。
あとは， Open UNIX 8 のドキュメント内にある "iostream examples" のページも参考になった。
http://ou800doc.caldera.com/SDK_clib/CTOC-_iostream_Examples...
iostream ライブラリの基本的な解説に加え， "Deriving new streambuf classes" や "Extending streams" の項では，自前での拡張を行う方法について軽く説明を行っている。ただ，なにぶん古い資料だけに，読み進める際には少しばかりの注意が必要かもしれない。
iostream ライブラリの仕様の詳細については， Rogue Wave SourcePro C++ のサポートページ内にあるオンラインドキュメントが参考になる。
http://www.roguewave.com/support/docs/sourcepro/stdlibug/VII...
http://www.roguewave.com/support/docs/sourcepro/stdlibref/in...
ユーザーズガイドを読み進めつつ，関数の仕様についてはリファレンスを参照すれば，基本的な仕様についてほぼ完全にカバーすることが可能となるはずだ。特に，第３８章の "Creating New Stream Classes by Derivation" などは，まさに今回の目的そのものの内容となっている。
http://www.roguewave.com/support/docs/sourcepro/stdlibug/38....
ところで，この Rogue Wave 社のサイトに置かれている各種オンラインドキュメントは， C++ 標準ライブラリのマニュアルとして非常に役立つ。僕は他に適切なマニュアルを持っていないものだから，標準ライブラリのリファレンスと言えば専らこのサイトを利用させてもらっている。本来は同社製品のサポートページの一部であるらしいんだけどね……。
通常， GCC (g++) には C++ 標準ライブラリとして libstdc++ が搭載されている。このライブラリにおける iostream の仕様については，同ライブラリのドキュメント内にある以下のページが参考になる。
http://gcc.gnu.org/onlinedocs/libstdc++/27_io/howto.html
ただ，本格的に拡張を行うのでなければ，ここまで込み入ったことを調べる必要も無いかもしれない。それとも，スレッド関連の話ぐらいは気にしておいた方がいいかな……。
また，このドキュメントによれば， Angelika Langer & Klaus Kreft 共著の "Standard C++ IOStreams and Locales" が iostream の解説書として参考になるとのことだ。
http://home.camelot.de/langer/iostreams.htm
より深い知識を求めるならば，こういった資料が必要となるかもしれない。幸いながら，僕はデバッグ用に簡単なインタフェースを用意したかっただけなので，これまでに挙げた資料だけで十分に間に合わすことができそうだ。
2003-06-10
ギーク系情報サイト "ZZZ Online" の "Weekly Picture" に，面白い写真が掲載されていた。帝政ロシア時代の写真家 Prokudin-Gorskii 氏が残した写真の数々だ。
http://www.loc.gov/exhibits/empire/
一見するとこれらの写真は，ロシアの美しい名所を映し出しただけの，ただの観光写真のように見えてしまうかもしれない。しかしこれらの写真には，ただの観光写真とは決定的に異なる点が１つ存在する。それは，これらの写真が，カラー写真の撮影技術が普及するよりも遥か前， 1910 年付近に撮影されたものであるということだ。
http://international.loc.gov/mtfph/php/pcolor01.html
これらの写真は，今からおよそ一世紀前，まだ帝政が敷かれていた頃の，ロシアの美しい風景の数々を色鮮やかに映し出している。革命前夜のロシアに生きる人々の姿は，どことなく素朴な感じがして，何とも言えないエキゾチックな雰囲気を漂わせている。
http://www-2.cs.cmu.edu/~dellaert/aligned/
まだ白黒写真の撮影技術さえも満足に確立されていなかったこの時代に，このように美しく鮮明な画像を数多く残した（氏の現存するコレクションは数千枚に達する）ことは，まさに驚愕に値する。
http://www.loc.gov/exhibits/empire/work.html
ところで，カラーフィルムの原形さえも存在しなかったこの時代に，一体どうしてこのように鮮明なカラー画像を残すことができたのだろうか。上記のサイト "The Empire That Was Russia" の解説によれば，３原色に分離した白黒写真を同時に撮影するという技術を応用したものであるようだ。３原色への分離はカラーフィルタによって行われ，各色成分のネガは別々のガラス版へと白黒撮影される。そして，そのガラス版画像を，対応するカラーフィルタを通してスクリーンに投射すれば，元の画像を復元することができるという仕組みだ。
http://www.loc.gov/exhibits/empire/making.html
氏はもともと，学校教育での教材に用いることを目的として，この大業に着手したらしい。ロシアの広大な土地と多彩な文化を写真に収め，それらを通じて子供達の自国に対する見識を広めてもらおうという意志だったのだろうと思う。この野心的なプロジェクトは，当時の皇帝であるニコライ２世の協力を得ることに成功し，運輸省の特別列車を利用してロシアの広大な土地を駆け巡ることが可能となった。そのような背景があったためか，これらの写真は単なる風景写真や趣味の域に留まらず，資料として非常に価値の高いコレクションとなっている。
http://www.loc.gov/exhibits/empire/gorskii.html
大戦前の時代などと言うと，専ら白黒写真の世界というような印象がある。しかし，これらの写真の存在は，そんな人々の印象を一気に塗り替えるだけのインパクトを持っているのではないかと思う。このように鮮やかな色が付くだけで，人に与える印象は随分異なってくるものだ。セピア色に劣化した遠い世界ではなく，その時代のその場所に，確かにその世界が存在したのだという「確信」を，この写真は与えてくれる。
http://www.loc.gov/exhibits/empire/images/p87-4240.jpg
http://www.loc.gov/exhibits/empire/images/p87_7214__01578_.j...
http://www.loc.gov/exhibits/empire/images/p87_4499__00747_.j...
これらの写真を撮り終えた直後に，ロシアは赤色革命を迎える。氏はその後，写真と共にノルウェーやイングランドを移動し，最終的にフランスへと移住することになる。 1944 年に氏がソビエトの追手に殺害されると（彼が帝国について記していた文書を隠滅することが目的だったらしい），彼のコレクションは相続人の手を介して米国議会図書館へと売り渡されることになった。
そして今，彼の残したコレクションは，デジタル合成技術（その正体は，ただの MATLAB プログラムだ）の手を借りて，再び元の色を取り戻そうとしている。これらの画像を観たとき，何故か言いようの無い郷愁を感じるのは，単に僕が懐古趣味者であるというだけの理由ではないはずだ。
2003-06-11
うだつの上がらない水曜日。
一日かけて作業を行った結論として，「Expression Template に手を出してはいけない」という教訓を得るに至った。
http://osl.iu.edu/~tveldhui/papers/Expression-Templates/expr...
そして，おもむろに "cvs remove" とキーを叩く。
しかし，たとえそのような諫言を呈されたとしても，これに手を出す人は後を絶たないだろうと思う。 C++ のテンプレート機能は，コンパイラの問題解決能力に対して，当初の予想を遥かに上回る可能性を与え続けている。コードを叩き鍛え上げることを喜びとするサディスト的コーダーたちが，このような手段の存在を黙って見過ごすはずがない。
何気無い職場での無駄話の最中に，ソフトウェア特許関連の話題が挙がってきた。昨今の風潮として，ゲームメーカー各社が知的財産獲得へかける情熱にはなみならぬものがあり，各社はできるだけ多くの特許を取得すべく多大な努力を払い続けている。しかし，その多くはイノベーションの保護と言うよりも人質交換の材料（クロスライセンシング）として扱われているのが常であり，関連分野に対して手当たり次第に特許をバラ撒いておくことが，組織間の抗争における「抑止力」として働くという実情がそこにはある。自分のような三文技術者にとっては何とも住み心地の悪い緊張状態だと思う。
特許庁の特許電子図書館 (IPDL) サービスで検索をかけてみると， 2002 年中に公開された特許情報の内，コナミには 371 件，ナムコには 366 件の該当項目が挙げられる。ゲーム会社の中では，この２社が特に精力的な活動を行っているようだ。もっとも，これはソニーの 7725 件と比較すれば，まだ少ない方だと言えるのかもしれないけれど……（公開件数と登録数はイコールでないため，実際の特許登録数はこれよりもだいぶ少ない）。
http://www.ipdl.jpo.go.jp/Tokujitu/tokujitu.htm
たまには特許データベースをサーフィンしてみるのも面白い。特許情報をランダムに閲覧するには， IPDL の「公報テキスト検索」ページを利用するのがお勧めだ。検索キーワードの種別には「出願人／権利者」を選択し，対応するボックスに適当なゲーム会社の名前を入力する。ここで 500 件以上のヒットがあると一覧表示ができないため，そのような場合には公開日（あるいは申請日）の絞込みを行うと良い。例えば 2002 年中の情報を調べたいならば "20020101:20021231" というような指定を行う。
こうして得られた一覧に目を通しながら，面白そうな内容の特許を勘で選んでチェックしていく。例えば，ええと……セガの特開 2002-074257 にある「カード束読み取り装置及びそのカード及びカードケース及びカードの製造方法及びそれを用いたゲーム装置及びゲームプログラムを記録したコンピュータ読み取り可能な記録媒体」は，最近アーケード方面で話題の「アヴァロンの鍵」に関連する特許だろうと思われる。束の状態で投入されたカードを読み取る装置のアイデアだ。
この請求内容によれば，あのカードには側面に蛍光塗料でバーコードが書き込まれており，カードを束ねた状態のままでも安定して読み取りを行うことが可能となっているということだ。なるほど……それならば原価も安く済むし，偽造も（塗料が手に入らない限り）難しいし，デッキを組むというゲーム内容にも即している。上手いもんだよね……。
もう一件，興味を惹かれたのは，コナミの特開 2003-099802 にある「ゲーム装置、プログラム及び画像表示方法」だ。これは請求内容から察するに "Silent Hill 3" で用いられている影の生成方法に関連する特許だろうと思われる。特許というものは本来，技術情報を公開することに目的があるわけだから，こういった所から技術を吸収するのは正しい方向性だと言えると思う……。
ただし，よくよく読み進めてみると，請求内容があまりにも概論的過ぎて，技術資料としては役に立たないことが分かってきた。シャドウ（ライト）マッピングっぽい内容を匂わせながらも，ステンシルシャドウっぽいような絶妙の言い回し。しかも，アレがああなってこうだから……ううむ。
2003-06-12
ふとした機会から，ヲノサトルの最新アルバム "El Nino" （電子時代の地誌学、または地球温暖化現象の影響に関する恋愛心理学的考察）を購入することになった。
http://www.polystar.co.jp/contents/artist/database/wono.html
http://www.amazon.co.jp/exec/obidos/ASIN/B00007GR9X
ヲノサトルは昔から（メジャーに登場する以前から……）好きだったんだけれど，このところしばらくノーマークだった。
ところが，たまに訪れた氏のページで件のアルバムの視聴曲を聴いてみたところ，これが非常に良かったので，すぐさま購入に踏み切ったというわけだ。
４年ぶりのソロアルバムは，以前の作品と比較すると驚くほどクオリティが上がっているように思える。以前の作品……例えば「ビキニ・ムーン」などは，ややこざっぱりとまとまり過ぎてしまっているような印象があった。しかし今回のアルバムでは，氏の持つ個性であるところの「甘く優しくも前衛的なスタイル」が遺憾無く発揮されており，聴いていてとても楽しいアルバムへと仕上がっている。
トラッド・ミュージックの裏に重厚なブレークビートが打ち込まれ，スムースなピアノの上にトゲついたブリープが突き刺さる。そんな前衛的なアレンジを繰り広げながらも，メロディーは絶妙に甘く切なくて，うっすらと心に染み込んでくるような自然さを持っている。一枚ムケたヲノサトルは，甘い仮面の下にとてつもなく強烈な個性を潜ませたマエストロだ。もう大ファンだよ……。
特に，１０曲目の「アフタヌーン・ウエザー」がお気に入りだ。
http://www2.gol.com/users/wono/_en10.mp3
余談なんだけれど，坂本龍一が作曲した六本木ヒルズの祝典音楽 "The Landsong" が，かなりいい感じだった。
http://www.j-wave.co.jp/original/radiosakamoto/audition/top....
いいなあ，この，なんて言うか，肩の力抜き加減が……。氏がたまに作るイージーリスニング系の曲が好きなのかもしれない。六本木ヒルズ森タワーのロビーにこの曲がかけられていたとしても，何の違和感も無いよね。仕事中にかけておくのも良し。
2003-06-13
週末の気晴らしにと，ギーク系雑貨販売で有名な ThinkGeek のサイトを久しぶりにを覗いてみたところ，何やら面白げなラインナップをいくつか見つけることができた。うう，こういうの楽しいなあ……。
まず，まっ先に興味を惹かれたのが "Atari Classics 10-in-1" と "Activision 10-in-1" だ。
http://www.thinkgeek.com/cubegoodies/toys/5d39/
http://www.thinkgeek.com/cubegoodies/toys/5d41/
あの「ＴＶに繋ぐだけで遊べる」シリーズのノリで，アタリやアクティビジョンの往年の名作が遊べてしまうという商品のようだ。しかし，それにしても渋いタイトルを持ってきたものだなあ……
http://www.thinkgeek.com/cubegoodies/toys/5d39/images/
http://www.thinkgeek.com/cubegoodies/toys/5d41/images/
スクリーンショットから察するに，どちらも Atari 2600 のタイトルを持ってきたもののようだ。
http://www.atariage.com/screenshot_page.html?SystemID=2600&S...
http://www.thinkgeek.com/cubegoodies/toys/5d39/images/350/
http://www.atariage.com/screenshot_page.html?SystemID=2600&S...
http://www.thinkgeek.com/cubegoodies/toys/5d41/images/356/
コンシューマゲーム機の元祖とも呼べるこの機体。後に「アタリショック」と呼ばれる伝説を生み出したのも，この機体だ。ジョイスティックの「分かっていらっしゃる」デザインも良い。ちなみに，元祖はこんな感じだ。
http://www.atariage.com/2600/systems/sys_AtariVCSB.jpg
値段は $24.99 （約三千円）とのことで，それほど悪くもない価格だと思う。実際のゲーム内容についてはともかくとしても（結局はすぐに飽きてしまうような内容のものばかりだ），ネタとして面白いので，とりあえず買っておくことにした。
ThinkGeek は大人のためのグッズショップだ。例えば "Cube Goodies" のコーナーを見れば，職場のキュービクルへ持ち込んで楽しむようなアイテムが沢山揃えられている。
http://www.thinkgeek.com/cubegoodies/
特殊文房具に特殊コーヒーマグに特殊卓上時計に……わくわくするようなアイテムばかりだ。よく見るとラインナップの中に「毛布」が揃えられているのは，職場に泊まるときにはこれを使えよ，ってことなんだろうな……。
http://www.thinkgeek.com/cubegoodies/blankets/
"Accessories" の中にある "C.H.I.M.P." という商品は，自分の机の背後を警戒するために使う湾曲鏡だ。こんな用途のためにわざわざ商品を作ってしまうんだから，遊び心があるというか，馬鹿げているというか……。
http://www.thinkgeek.com/computing/accessories/2940/
お遊び的アイテムが多いなかでも，セキュリティ関連のグッズは実用になるものがあるかもしれない。
http://www.thinkgeek.com/gadgets/security/
虹彩パターン識別によるバイオメトリクス装置なんてのは，かなり本格的な代物だ。キーボードポートに取り付けてユーザーのタイプ情報をキャプチャーするデバイス "Key Katcher" なんてのも凄いアイテムだけれど，これはどちらかと言えば，セキュリティ装置ってよりもハッキング装置の類だな……。
"Personal Password Manager" は，キーホルダー型のパスワード管理ツールだ。パスワードの自動生成と管理（一定期間が過ぎるとパスワードを変更するように警告する）を行ってくれる。パスワードは要するに「鍵」なんだから，物理的に鍵と結び付けてしまおうという発想は，なかなかしっくり来るものがある。試しに購入してみようかと思ったんだけれど，残念ながら売り切れ中だった。やっぱり，みんな横着したいんだよね……（それにしたって，同じパスワードを使い続けるよりかは幾分安全かもしれない。）。
http://www.thinkgeek.com/gadgets/security/5a60/
あとは "TopHead Dual LCD" が面白かった。
http://www.fastechinc.com/TopHead.htm
１５インチＬＣＤの上に６．４インチの小窓ディスプレイを取り付けた製品だ。かなりキワモノっぽいけれど，実はそこそこ実用性があるのではないかと思っている。フルスクリーンでアプリケーションを動かしながら小窓でデバッグしたり，フルスクリーンでゲームをしながら小窓でウェブをブラウズしたり……「ながら生活」を強化する一品として活用しようってわけ。だめかな……。
2003-06-14
平凡な土曜。昼過ぎに起きて，駅前へ買い物に出かける。
無印で買ったアルマイト製のカードケース。名詞交換なんて滅多にやる機会の無い職場に育ってしまったものだから，こんな基本的なモノも持たずに今まで仕事をしていた。そのうち必要になることもあるだろうと思い，何気無く買ってみた次第。
それから，近くの電器屋に寄ってＰＣゲームのコーナーを物色していた。最近自分の中で密かに高まりつつあるＰＣゲーム熱に乗って，ちょっと古めのやつを色々遊んでみようと考えている。
そこで手に取ったのが，昨年辺りから話題になっている多人数ＦＰＳ "Battlefield 1942" だ。多人数対戦というコンセプトに興味があったのと，何か１つミリタリー系のゲーム（特に大戦モノ）に手を出してみようという意図で，このゲームを選んだ。
家に帰ってからは，ゲームをプレイしたり，本を読んだり……。まったくもって平凡な土曜日。一日の食事が松屋で完結しているような日は，いつもこんな感じだったかもしれない。
2003-06-15
そんな調子で，昨日から "Battlefield 1942" をプレイしていた。
http://www.japan.ea.com/battlefield1942/battlefield1942/home...
"Battlefield 1942" は，３２人対３２人の計６４人までのオンライン対戦に対応したＦＰＳだ。第二次世界大戦時の有名な戦場を舞台として，多人数のプレイヤーが入り乱れ戦うゲームとなっている。システムとしては，フィールド上に設けられた「陣地」を制圧していくことが主な目的となっている。言うなれば，「陣取り合戦」あるいは「戦争ごっこ」をＰＣ上で再現したような内容，というのが分かりやすい説明ではないかと思う。
以上の前提からも分かるように， "Battlefield 1942" の主目的はオンライン対戦にあると考えていいようだ。しかしながら，僕の家はインフラが貧弱なので（情けなや），敢えてオフラインのみでプレイを試みることにした。もっとも，オンライン対戦にハマってしまうのが怖い，というのも大きな理由の１つなのだけれど……。
そうやってシングルゲームを数時間プレイし続けた結果，ひしひしと感じたのが，やはりこのゲームはマルチプレイヤー対戦を前提として作られているな，という認識だった。そのことを最も感じさせるのが，このゲームに備わっているＡＩの弱さだ。対戦相手としての「強い／弱い」ではなく，実装としての貧弱さという点において気になるものがある。
ＡＩの動きに不満を感じるのは，単純に言って「賢くない」ということと，「演技力が無い」ということの二点が挙げられる。前者は，分かりやすいところで言うならば，道の端で立ち往生してしまっているキャラや，平地の真ん中で右往左往してしまっているキャラなどが度々見かけられることを明らかに指摘できる。後者は，ＡＩが戦闘行為以外の行動をまったくとらないことに物足りなさを感じた。
もう１点，目立って気になったのが，シングル時の無線通信の意味の無さだ。このゲームでは無線通信や「叫び」を使って味方に指示を送ることができるのだけど，これに対してＡＩは何ら応答をよこさないし，実のところ内部的に処理すらしていないのではないかという気がする。こういった多人数での戦略系アクションゲームは，味方との連携が楽しくなるところのはずなのに，味方に無視されながら戦っているのはかなり空しい感じだ。
「演技力の無さ」の点は，このゲーム全体に見られる演出面でのおざなりさとも相まって，かなり気になるものがあった。陣地から飛び出しては黙々と戦闘を行い，死ねばまた陣地から出てくるだけ……というようなＮＰＣの存在は，ＲＴＳで言うところの「ユニット」の存在にしか見えなくなってくる。
この「演技力」の点に関しては，実は対人戦よりも対ＡＩ戦の方が優れたものにできる可能性があると，以前から考えている。人間は対戦する行為自体に精一杯になってしまう傾向があるから，気の利いたアクションを見せる余裕など実は残されていない（しかも，これはオフライン対戦についても同様に言えることだ）。そこは，むしろＡＩの方が，情緒豊かでウィットに富んだ演技を見せることができるのではないかと思っている。
ＡＩの演技力という点では， "MGS" や "Halo", "Half-life" などが優れた作り込みを行っている。敵キャラの挙動に関しては MGS2 が格段に優れているものの，プレイヤーの仲間となるＮＰＣが存在しない点を見れば，まだ模索されていない領域が多く存在するように思える。僕は Anubis に野戦ステージが用意されていたことから，てっきり MGS3 では多対多の野戦を持ってくるものかと予想していたのだけれど，そういった方向性はいまだ試みられていないようだ（もっとも，それじゃスニーキングじゃなくなっちゃうんだけれど……）。
……というような感じで，ゲーム内容を勘違いして買ってしまった者としての恨み辛みは色々と残っているものの，基本的なところでは良く出来たゲームだと考えている。マルチプレイヤー対戦は間違いなく楽しいものだろうし，シングルでもＮＰＣの上限数と思考レベルを上げることによって，かなりいい線まで持っていくことができる。一つ一つの動きは甘くても，数が居るとなんとかなるものだなあという，浅いような深いような考察がそこにはあったりして……。
ところで， "Battlefield 1942" によって切り拓かれた「多人数対戦ＦＰＳ」というジャンルは，最近になって遂に "Massive Multiplayer" の域にまで達しようとしているようだ。その先駆けとなるのが Sony Online Entertainment の "PlanetSide" だ。
http://www.watch.impress.co.jp/game/docs/20030602/planet.htm
"EverQuest" で有名な同社の放つ最新作ということで，一応注目度は高まっているようなのだけれど，個人的には静観を保っている。会員制によってプレイが義務化してしまうことに対しての拒絶感があるのと，ＦＰＳに冗長性を持ち込むことに対して疑問を感じるからだ。
"PlanetSide" に関して，同作品が初の本格的大規模対戦ＦＰＳだという点以外に，もう１つ注目していることがある。人間集団同士の対立構図をオンライン上に持ち込もうとしている点だ。過去に同様のシステムを試みたゲームとして Funcom の "Anarchy Online" という MMORPG があるのだけれど，これは残念ながら失敗に終わってしまっている。
http://www.watch.impress.co.jp/game/docs/20020213/yuki14.htm
PvP (Player versus Player) 行為がご法度として扱われがちな MMORPG に対して，人間同士の対立構図を敢えて持ち込んだことは注目に値すると思う。常にＮＰＣを相手にするよりも，人間を相手とした方が強いアピールが生じるのではないかと考えるからだ。しかし，その結果を見るよりも早く Anarchy Online は自滅してしまった。正式サービス開始後もプレイヤー人口が思うように延びず，早々に廃れてしまったためだと耳にしている。同作品が実験的な要素を含みながらも自滅してしまったことは残念だと考えている。何しろ，その実験の結果を見届けることができなかったのだから……。
2003-06-16
Tim Rowley の SIGGRAPH 2003 論文リストに，ちょぼちょぼと目を通している。
http://www.cs.brown.edu/people/tor/sig2003.html
今年もネタ的には色々あるのだけれど，リアルタイム系の技術として最も面白かったのが， Tomas Akenine-Moller 氏の "A Geometry-Based Soft Shadow Volume Algorithm Using Graphics Hardware" だった。
http://www.ce.chalmers.se/staff/tomasm/pubs/soft_sig2003.pdf
http://www.ce.chalmers.se/staff/tomasm/soft/
この論文は，幾何ベースでの投影アルゴリズム（要するにシャドウボリューム法）においてソフトシャドウを扱うという内容のものだ。しかも，それは単なる「ソフトなシャドウ」などではなく，かなり汎用的なエリアライト（面積を持った光源）の処理を実現している。
氏らは SIGGRAPH 2003 に続き Eurographics 2003 でも，同論文の改良版である "An Optimized Soft Shadow Volume Algorithm with Real-Time Performance" を寄稿している。
http://www.ce.chalmers.se/staff/tomasm/pubs/soft_gfxhw2003.p...
また，氏らは去年開催された Eurographics 2002 においても "Approximate Soft Shadows on Arbitrary Surfaces using Penumbra Wedges" という論文を発表している。
http://www.ce.chalmers.se/staff/tomasm/pubs/soft_egwr2002.pd...
前述の２つの論文は，この論文で提示した手法を改良し，その手法のハードウェア化を実現したものだと捉えればいいと思う。
ちなみに Tomas Akenine-Moller 氏は，あの "Real-Time Rendering" の共著者として有名な人物だ。そう言えば，件の本でも幾何ベースのソフトシャドウ方式について地味に触れていたような気がする。
シャドウボリュームを用いた投影アルゴリズムを使用する際に，まず問題となるのが，影のエッジが明瞭過ぎて不自然に感じてしまうことだろうと思う。これは，シャドウボリュームによる遮蔽範囲の判定が，「影内」あるいは「影外」の，いわゆる「０／１」で行われているためだ。そのために，「完全な影」 (umbra) しか扱うことができなくなってしまっている。
ところで，「完全な影」とは，一体どのような状態を表すのだろうか。この問いに対する最も簡潔な答えが，「点光源によって生み出される影」というものだろうと思う。上中央の図にあるように，「完全な点光源」は「完全な影」を作り出す。また，並行光源は「無限遠にある点光源」として扱うことができるため，やはり同様に「完全な影」を作り出す。
しかし，実世界に存在する光源のうち，人間の作り出すものの多くには面積（体積）が伴っている。電灯の光も，松明の光も，ただ一点から光が放出されるようなものではなく，それなりの面積を持った光源であるはずだ。そういった意味で言えば，実世界に理想的な点光源などは滅多に存在しない。そのため，「完全な影」は不自然な状態として目に映ってしまうことが多い。それは本来，非常に特殊なケースであるはずなのだ。
上右側の図は，光源が面積（体積）を持っている場合に発生する影の様子を表した模式図となっている。この図を見れば分かるように，光源と遮蔽物の相関関係によって生み出される領域には３つの区分が存在する。まず１つは「完全に光源の影響を受ける領域」であり，もう１つは「完全に光源の影響を受けない領域」，そして「そのどちらでもない領域」の３つだ。このうち最後の領域に当たるのが，いわゆる「半影」 (penumbra) と呼ばれる状態だ。
Akenine-Moller 氏らの提案する幾何ベースのソフトシャドウ方式では，この「半影領域」を幾何的に解決し，その領域内において光源の「遮蔽量」 (coverage) を画素毎に求める。このような複雑な処理は，一昔前ならばソフトウェアレンダリングでしか実現できないようなものだったのだけれど，近頃の強力なピクセルシェーダの機能を用いれば，ハードウェアベースで実装することが可能となる。その方法を具体的に提示しているのが，件の論文ということだ。
ところで，実在する光源においても「完全な影」を作り出すものは存在する。人間にとって最も身近な点光源であるところの「太陽光」が，その分かりやすい例だ。だから，真昼の太陽光を扱う限りにおいては，ボリュームシャドウによって生み出される硬いエッジは，単にジャギーの問題として扱うことができるのではないかと考えている。
2003-06-17
今回のようなソフトシャドウの話や，可視判定の話などになると，必ずと言っていいほど "umbra", "penumbra" という単語が登場してくる。これらの単語はもともと，日食（月食）現象を解説する際に，「暗黒部」と「半暗部」を表す単語として用いられるもののようだ。
http://csep10.phys.utk.edu/astr161/lect/time/eclipses.html
ここで新たに登場してきた「日食」というキーワードは，半影状態ととてもよく似た現象を扱っているように思える。このアナロジーをソフトシャドウの解説として用いるのは，ちょっとした面白い解説方法かもしれないと考えている。
僕は本格的な日食というものを体験したことが無いのだけれど，皆既日食が発生すると，辺りはまるで夜中のように暗くなるらしい。部分日食でも，蝕の深いものであれば，それ相応に暗くなるということだ。
http://www.interq.or.jp/sun/nishizak/eclipse/australia2/ecli...
ここで，部分日蝕が発生した際にもたらされる光量の変化を，光量計を使わずに計算から求めたいとする。この場合，一体どのような方法が考えられるだろうか。
複雑な事情をすべて無視し，極端まで現象を簡略化して考えるとすれば，「太陽の見た目の面積のうち，月によって覆われる領域の割合」を求めることによって，光量を導き出すことができるだろうと思う。月による遮蔽量 (coverage) が 80% であれば，光量は通常の 20% になるし，遮蔽量が 10% であれば，光量は 90% になると予想できる（実際には様々な理由から，そうはならないのだろうけども……）。
ソフトシャドウ処理において，半影領域における画素の明るさを求める際にも，同じような考え方を用いることができる。
まず，視点を画素の位置へと移動し，光源の方向を向くようにする。次に，半影領域を作り出している辺（エッジ）を光源のなす平面へと投影し，これを「押し出し」 (extrude) することによって，遮蔽される領域を特定する。最後に，何らかの演算によって，遮蔽領域と光源とが重なっている部分の面積を求めれば，最終的に光源の遮蔽量を得ることができる。
以上の処理を半影領域に対して画素毎に実行することで，半影領域における光量の変化を正しく再現することができる。こうして得られた画像は，単なる「ソフトなシャドウ」や，グラデーション系のハックによって得られる紛い物のソフトシャドウとは違って，「違和感」 (artifact) や「矛盾」 (inconsistency) のほとんど存在しない，説得力のあるビジュアルになることだろうと思う。
ところで，「画素ごとにエッジを投影して，面積を求めて……」なんて処理は，ひどく複雑なもののように思える。一昔前ならば，間違い無くソフトウェアでの実装に回された種類の処理だろう。しかし，今時の高性能なピクセルシェーダをもってすれば，この処理をシェーダ上で完結させることも十分に可能だ。恐ろしい時代になったものだよ！
現に Ulf Assarsson 氏らは， Eurographics 2003 の論文 "An Optimized Soft Shadow Volume Algorithm with Real-Time Performance" において，このアルゴリズムをピクセルシェーダ上に実装している。 Akenine-Moller 氏のページを参照すれば，そのピクセルシェーダ部分のソースを見つけることができる。
http://www.ce.chalmers.se/staff/tomasm/soft/TexturedRect.txt
この６０ステップほどのシェーダで，半影領域の処理が完結してしまっているわけだ……。いやあ，それにしても，１ピクセル６０ステップですか……。こちとらアルファの加減算さえままならんのですが……。ううむ。
ピクセルシェーダでの実装に成功したこともあって，このアルゴリズムは既に実用的な速度を叩き出し始めている。例えば，下の「グレイと球光源」のシーンで，実に 50 fps 以上の速度が出ているようだ。
http://www.ce.chalmers.se/staff/tomasm/images/gray_sphere.jp...
現時点でこの速度が実現できてしまっているのだから，もっと手法が洗練され，ハードウェアの性能も向上すれば，プロダクトへの応用も十分に可能なレベルとなるだろうと思う。瑣末な問題は残っているとしても，幾何ベースの投影を利用する際に有力なオプションの１つとなるであろうことは間違いないのではないかと思う。
2003-06-18
改めて Ulf Assarsson 氏のハードウェアソフトシャドウの実装を眺めたときに，まず何よりも驚きを感じるのは，ピクセルシェーダを使って相当に複雑な幾何演算を実現していることだ。僕らがベクターユニットを使ってやっと実装しているような処理を，特に苦労する様子も見せずに，難なく画素毎の処理として実現してしまっている。
近頃のピクセルシェーダが非常に高等な機能を持っていることは， IF さんのデモなどを通して何となく認識しているつもりではあったのだけれど……それにしても，実際にこのような応用を見せつけられてしまうと，本当にここまで出来てしまうものなのかという驚きを隠せない。
そして Assarsson 氏の実装には，ピクセルシェーダの他にもう１つ重要な要素が存在する。それは，仮想的な４次元テクスチャをルックアップテーブルとして利用することで，比較的複雑な演算を単純化することに成功していることだ。
光源遮蔽量を求める一連のプロセスにおいて，最も複雑な処理となりうるのは，辺（エッジ）の位置情報から遮蔽領域の面積を求める処理だろうと思う。仮にこれをナイーブな方法で実装するとなると，エッジを押し出して作った台形を光源の形状によってクリップし，その結果得られた多角形の面積を正確に求めてやらなければならない。これは，いかにピクセルシェーダが高機能と言えども難しい処理となるだろうし，そもそも条件分岐が必要になるという時点で，シェーダ上での実装は非現実的なものとなってしまうのではないかと思う。
しかし，ここには意外な抜け道が残されている。ヒントはこんな感じだ。
つまり，光源形状によってクリップされたエッジの頂点座標を (x1, y1) および (x2, y2) で表せば，そのときの遮蔽量は，
というような４次元関数として表すことができる。それならば，この関数を４次元テクスチャによってテーブル化してしまえば，面倒な処理をすべて省いてしまうことができるのではないだろうか。
ここでもし，４次元テクスチャを直接に扱うことのできるハードウェアが存在すれば，即座に結論を導き出すことができるのだけれど，残念ながら今のところそのようなハードウェアは主流に存在しない。そこで Assarsson 氏らは， n*n の大きさを持つ２次元テクスチャを n*n 個並べることによって，仮想的な４次元テクスチャを作り出すというアイデアを提示している。
このようにして構築された仮想４次元テクスチャは， n^4 個のテクセルを持つことになる。これは非常に大きな量のように思われるかもしれないけれど，現実的な線で n=32 程度に抑えておけば， 1024x1024 の大きさに収まることになる。特に近頃のハードウェアならば，この程度の大きさのテクスチャなど，それほど無茶なものとも思われないはずだ。
2003-06-19
SIGGRAPH 2003 での Ulf Assarsson 氏の論文 "A Geometry-based Soft Shadow Volume Algorithm using Graphics Hardware" では，仮想的な４次元テクスチャを遮蔽関数のルックアップテーブルとして導入することによって，大幅な処理の簡略化を実現している。この「４次元テクスチャ」というトリックは，幾何ベースソフトシャドウ法の実用性を大幅に引き上げる飛躍をもたらしているものの，実際にはもう少し改善を行う余地が残されている。
Eurographics 2003 における同氏の論文 "An Optimized Soft Shadow Volume Algorithm with Real-Time Performance" では，遮蔽関数の完全なテーブル化を行うのではなく，もう少し解析的なプロセスを差し挟むことによって，テクスチャの必要量を下げることに成功している。具体的には，エッジをなす２つの頂点の仰角をパラメータとして用いることによって，２次元テクスチャをルックアップテーブルとして用いることができるというものだ。この方法は多少演算量が増加するものの，他に簡略化された要素などと差し引きを行うと，最終的なステップ数はほとんど変わらないものとなっている。
このほかにも， "An Optimized Soft Shadow..." の実装には様々な改良が施されている。その中でも最も影響の大きいものは，やはりピクセルシェーダ部分の改良にあるようだ。以前の実装では Cg 言語による 250 ステップもの処理だったものを，改良版ではピクセルシェーダ 2.0 による 60 ステップ程度の実装にまで絞り込むことに成功している。
しかし，それでもまだ，ピクセル処理は全体に対してのボトルネックとなっているようで，ソフトシャドウ処理の適用範囲の広さが，パフォーマンスに対して大きな影響を及ぼしているという側面があるようだ。現に，半影領域の特定方法をよりタイトなものへと改良したところ，以前の手法に比べ 1.2 倍から 2 倍程度のパフォーマンスの改善が得られたとの記述がある。
ここまでの流れを見ても分かるように， Tomas Akenine-Moller 氏らの提唱するソフトシャドウアルゴリズムは，シェーダ的に見た場合，現時点で既にかなりの洗練が達成されている感がある。そこで逆に問題となってくるのが，各種ボリュームを求める際に用いられるジオメトリ的な処理の負荷だ。この部分に関して，現段階では単純に CPU 側での解決を行っていることもあり，まだ多くの改善の余地が残されていると言える。
まず問題となるのが，半影ボリューム (penumbra wedge) を生成する処理の負荷だ。ゲーム等のアプリケーションに対して今回の手法を導入する際には，この処理のシェーダ化が必須条件になると思われる。 Assarsson 氏はこの作業にまだ着手できていないようなのだけれど，論文の中で「じきに実装する」と述べていることから，恐らく次の論文にはシェーダ化された状態の実装が提示されることになるだろうと思う。
現時点で残されているもう１つの大きな課題が，輪郭線（シルエットエッジ）の抽出プロセスの高速化だ。この処理は，隣接するポリゴンの情報……つまり「トポロジー的」な要素が絡んでくるため，シェーダによって解決することが非常に難しい種類の問題となっている。
ゲーム等のアプリケーションにおいては，できるだけ CPU の負荷を軽減しなくてはならないという命題が存在するため，シルエットエッジ法のように CPU パワーを食い潰す危険性のある手法は遠ざけられるきらいがある。そのような事情があるため，多くの場合は「押し出しモデル法」や「隠しポリゴン法」などのトリックを使うことによって，シルエットエッジの生成自体を回避しているというのが現状のようだ。
http://if.dynsite.net/t-pot/program/75_shadow2Vol/index.html
この「シルエットエッジ問題」に関しては，以前 spin で紹介されていた Tom Hall 氏の "Silhouette Tracking" が，１つの面白い方向性を提示している。
http://www.geocities.com/tom_j_hall/
これは，いわゆる「時間的な一連性」 (temporal coherence) を応用する系統のテクニックだ。１つのステップの間にシルエットエッジの形状が大幅に変化することはないだろうという前提を置くことによって，処理の大幅な簡略化を実現している。
この手法を導入したとしても，シルエットエッジの生成が CPU 側の処理となってしまうという現状には変わりがない。それにしても，普通に「しらみ潰し法」を用いるよりかは遥かにマシなパフォーマンスが得られることは確かなはずだ。メッシュの密度が上がれば上がるほど，この問題は深刻化してくるのだから，なおさら何らかの手を打たねばならない。 "Silhouette Tracking" が適切な解決法であるかどうかは別としても，似たような手法をどこかで導入しなくてはならないだろうと思う。
2003-06-20
先日， Bugie のサイトで Halo2 の予告編ムービーが公開された。 E3 会場で展示されていた映像と同じ内容のものだ。
http://halo.bungie.net/site/halo/features/av.html
ちょっと霞みのかかったような画質が気にかかるのだけど，それでも，これまでネット上に流されていた隠し撮りの映像と比較すれば，格段に見やすいものとなっていると思う。
Halo2 は，他のゲームに先駆けて，いわゆる「統一光源モデル」と呼ばれる種類の方式を採用しているとあって，観察対象としては面白い側面を持っているように思える。映像を見れば分かるように，バンプが凸凹しまくり，スペキュラが光りまくりの，全体的にギラついた感じのビジュアルで深く攻め込んでおり，他のゲームとは様々な意味で一味違う，トンがったイメージを作りあげている。
恐らく，数年後にこの映像を見返したとき，「そういえば，この世代ってこういうビジュアルだったなあ」とか，「Xbox って言えば，こういう画だったよね」とか，そういった感慨と共に振り返ることになるのではないかと思う。良い意味でも悪い意味でも，「per-pixel 世代の結晶」が，ここに存在するように感じる。３年ぐらい前に夢見た未来は，こんな感じだったかもしれない。
次の３年間のストライドを方向付けるベクトルは，一体どこを向いているのだろうかと想像する。有望な候補がいくつか挙がってきたように思えるけれど，その見極めはまだ明確にできていないような感覚が残る。そこでの見極めを誤れば，インドに行くつもりがキューバに流れ着いてしまうかもしれない。願わくば PS3 の踏み出す一歩が， PS2 のときのような「当ての外れたベクトル」ではないことを期待するのだけど……。
今回のムービーを注意深く観察してみると，以前 Chris Butcher 氏らが指摘していた "popping" の問題が，かなり分かりやすい形で現れていることに気付く。特にムービー前半の，人物がアップになるカットなどにおいて，影の落ちる領域がパキパキと「非連続的な変化」を起こしているのが分かると思う。
この現象については，法線の立て方や，その補間の方法，あるいはメッシュの粗さや，ボリュームの生成方法，最終的には光源モデル自体などに理由を押し付けることが可能なものの，最終的にはソフトシャドウさえ実現されれば，完全に解決できてしまう種類の問題なのかもしれない。
シャドウボリュームの問題と関連して，「太陽光は並行光源としてみることができる」という理屈を持ち出しているのだけれど，実際にはどの程度「並行」なんだろうかというところに疑問が湧く。本当に理想的な並行光源ならば，そこから落とされる影は半影領域の無い「ハードシャドウ」となるはずなのだけれど，実際には，たとえ真夏日の昼間の太陽であっても，それなりの半影領域を持っているように見えることがある。
細かな現象まで厳密に考慮するならば，太陽周辺のコロナや，大気中での散乱現象によってもたらされる光の成分まで勘定に入れなければならないのだろうけど，とりあえずそれらの要素は無視するとして，太陽の大きさと距離がどのような関係にあるのかという点についてのみ調べてみたい。
下の資料によれば，太陽の平均的な半径は約 695,980 km であり（恐らく自転軸方向に潰れている），太陽から地球までの平均的な距離は約 149,597,890 km であるという（これも厳密には真円でない）。
http://portal.acm.org/citation.cfm?id=584482&coll=portal&dl=...
ここで，太陽を見上げたときの仰角が 60 度となる設定で，身長 1.6 m の人間が立っていたとすると，その頭の部分における半影領域の幅は，以下のようになる。
このように，たった数センチの半影ということならば，素のハードシャドウや，軽くぼかしを入れた程度のハードシャドウでも，それほど問題は起こらないかもしれない。
ただ，実際には光線方向と並行な面になるほど半影領域は広くなるわけで，条件によっては違和感を生み出すこともあるだろうし，その違和感は，連続的な変化を含むアニメーションの方が大きくなるだろうと思う。静止画では気付きにくい類の違和感 (artifact) があることに気をつけなければならない。
2003-06-21
数日前， ThinkGeek から "Atari Classics 10-in-1" と "Activision Classics 10-in-1" が届いた。
http://www.thinkgeek.com/interests/lanparty/5d39/
さっそく仕事場のモニタに繋げて，食後の休みの時間などに，気晴らしに遊んでいる。
この製品に収録されているゲームは，いずれも Atari 2600 コンソールの中でも名作と呼ばれるものばかりだ。しかし，いかにこれらのゲームが名作と呼ばれようと，所詮はオールドゲームということで，すぐに限界は見えてくる。オールドゲームに対する強い愛情を持たない限りは，これらのゲームを純粋に楽しむことは不可能だろうと思う（僕もさすがにこれはちょっと……）。
この製品の販売元は，普通にトイザらスなどで量販するような子供向けのオモチャとしてこれを作ったつもりみたいなのだけれど，いくらなんでもそれは無理があるだろうと思う。良くてマニア向けのコレクターアイテムだよなあ……。まあ，その点で言うならば，あの本体のデザインは非常に良く出来ていると思う。
これらのゲームを遊んでいると，なぜこのゲーム機に対して後に悪名が付きまとうことになったのか，その理由が分かるような気がしてくる。７０年代の人間にしてみれば，このレベルは非常に画期的なものだったのかもしれないけれど，この流れを８０年代まで引っ張ろうとしたことには，さすがに無理があったのだろうと思う。なにしろ，８３年にはファミコンの登場が控えているのだから……。
http://www.atariage.com/2600/history.html
そんな "Atari 10-in-1" の中でも，最も面白く感じたのは "Centipede" だった。
http://www.atariage.com/screenshot_page.html?SoftwareLabelID...
http://www.atariage.com/manual_thumbs.html?SoftwareLabelID=7...
他にも "Missle Command" や "Asteroids" などのような著名なゲームが入っており，それらも一応面白くはあるのだけれど，ゲームバランスの点で自分の嗜好とマッチしたのが "Centipede" だったように思える。
余談なのだけれど，たった今調べてみたところ， Atari のベクタースキャンゲームの名作 "Major Havoc" の発売が 1983 年ということだった。
http://www.klov.com/M/Major_Havoc.html
Mark Cerny って人物は，この頃……つまりファミコンが発売された頃から，ゲームを作り続けているわけだ。それで現役プログラマってんだから，もう，呆れたものだとしか言いようが無いというか……。
これらの "10-in-1" シリーズを販売している Jakks Pacific 社では， Atari, Activision の "10-in-1" に続く商品として "Namco 5-in-1" を企画しているようだ。
http://www.jakkstvgames.com/namco.html
むむ……こいつが出ていれば，最初からこちらを選んでいたものを……。５つとも間違いようの無い名作ばかりだ。発売されたら即購入することになるだろうと思う。今回も本体のデザインが（オールドゲーマー的にみて）非常にイカしており，子供向けの玩具という説には疑問を抱かざるを得ない。とにかく，しばらくの間 ThinkGeek から目が離せなさそうだ。
気になるのは，これらのゲームを内部的にどう実装しているのかということだ。 Atari や Activision の "10-in-1" の場合は， Atari 2600 の互換ハードウェアを載せているようだったのだけれど，今回は元がアーケードゲームということで，互換ハードウェアの線は難しいように思える。かと言ってファミコン互換のハードウェアを載せることには問題がありそうだし，エミュレータの線もコスト的に難しそうだし……。
気になるのは，これらがすべて Z80 世代のゲームだということなのだけれど……いやあ，どうだろうね……。
http://www.system16.com/namco/index.html
2003-06-22
極めてダラけた日曜日。 Battlefield 1942 の mod "Desert Combat" をダウンロードする傍ら， CPU との対戦に打ち込んでいた。これはこれで結構面白い対戦になるのだけれど，やはり肝心な部分での不満が残る。うーむ……まあ，色々と理由があってこういうシステムになっているのだろうという察しはつく。それはそうと認めた上で，自分ならばこれとは違った形にまとめようとするだろうという，強い願望を感じることになった。
最近のゲームでこんなことを感じるのは，ちょっと珍しい経験かもしれないと思う。あるゲームを，その製品の状態以上に面白くするには，相当な労力を払わなければならないだろうと感じることが多い一方で，今回の "BF" のように，まだまだ面白くできる要素が残されていると強く確信する機会は少なくなってきている。そう感じさせられるのは，ゲームの完成度が低いゆえなのか，それとも，いまだ洗練されないほど新しい要素を含んでいるためなのか……。
ええと，御託は置いておくとして……感覚的な言い方をすれば，「三国無双」ぐらいの「嘘」と， "BF" ぐらいの「真面目さ」の，中間の辺りが未開拓の分野になるんだろうなと思う。三国無双のようにダイナミックな AI-LOD は，アクションゲームとしてみる分には１つの解決策なのだけれど，このゲームを単なるアクションゲームとして終わらせて欲しくはないと考える人の数は，決して少なくないはずだ。逆に "BF" は……ここから先は長くなるのでカット。
そういった意味で言えば， NCSoft の "Kingdom Under Fire: The Crusaders" には，少し期待を寄せている。
http://www.gamespot.com/xbox/strategy/kingdomunderfire2tc/sc...
ていうか，日本で出るのかな，これ……。
休日の間，散々にダラけた生活を送っていたせいで，生活時間がすっかり狂ってしまった。もう，まともに食事する気も起きないので，松屋に行って適当に食事を済ますことにした。
試しに頼んでみたシーズンメニューの「サラダキムチ牛めし」は，本当に牛めしの上にキムチを乗っけただけの，非常にコンポジット感の高いメニューだった。いやあ，ここまで開き直られると，逆にツッコミようがないと言うか……。
http://www.matsuyafoods.co.jp/menu/index.html
この手の「コンポーネント指向」メニューは，ガストなどのような低価格帯ファミレスでも見つけることができる。メニューをよく見回してみると，様々な品目に対して共通のコンポーネントが使用されていたりするわけで……まあ，値段相応と言えば，確かにその通りなのだけれど。
あと，最近になって，牛めしを頼むとオーダーに「クイックメニュー」というコメントが付けられるようになった。どうやら，牛めしなどのように調理の早いメニューを優先して処理することによって，「クイックメニューならば数十秒で出すことができる」という特徴を前面に押し出そうという作戦のようだ。
そんなに松屋を観察してどうすんだって感じだけれど……ええと，暇なんだからしょうがないんだよ……。
2003-06-23
ふと，自宅の机の手元に目をやってみると，結構な量の紙の束が積み上げられつつあった。ウェブ上で興味のある記事を見つけ出しては，再生紙に印刷してバインダに挟み込むという行為を続けているのだけれど，その中でも，読んでる途中に興味を失ってしまったものや，あるいは理解力不足から読み切ることができなかったものなどが，こうして自宅の机の上に積み上げられていくことになる。
特に有用だと感じたものについては職場のバインダに挟んで別途整理している。それなのに，このようにどんどん「積読」が溜まってしまっているのは，自分の知識不足から手に余してしまう内容のものが，最近特に多くなっているためなのだろうと思う。内容が理解できるかどうかも吟味せずにやたら印刷するものだから，このように山が積み上がってしまう。
しかし，よくよく考えてみれば，これだけの紙を無駄に浪費しながらも，そのほとんどが私用に過ぎないものばかりなのだから，少しばかりの罪悪感を覚えてしまう。うう，さすがに電子化とか考えてみた方がいいんだろうか……。
http://www.sony.jp/CorporateCruise/Press/199907/99-0727A/
そんな紙の束の一番上に積まれていたプリントアウトは，最近の Gamasutra の記事 "Postmortem: Insomniac Games' Ratchet & Clank" だった。最近，様々な所でレクチャーを行っている Insomniac Games の制作チームが，遂に "Postmortem" にも登場したという恰好だ。
http://www.gamasutra.com/features/20030613/price_01.shtml
ただ，内容的には以前の講演の繰り返しになってしまっている部分も多く，人によってはもう満腹になってしまっているかもしれない。そんな調子だから，僕も軽く目を通すつもりで印刷したものだった。
まず記事の冒頭で明かされているのは，彼らの出世作 "Spyro the dragon" の制作が終えてから "Ratchet & Clank" の制作へ移行するまでの間に，実はコードネーム "I5" と呼ばれるプロジェクトの試作が行われていたという事実だ。結局このプロジェクトは，試作を半年間も続けた挙句に，様々な要因から制作に行き詰まってしまうのだけれど，この時に，よりポジティブな形でプロジェクトを放棄することを可能としたのが，パブリッシャ側のプロデューサの存在だったと述べている。デベロッパ−パブリッシャ間の関係が特に厳しい欧米においては，このように双方が非常に協力的な体制を取るということ自体，稀有なケースとして映るものがあるようだ。
次に，「うまくいったこと」のなかで第一に挙げているのが「プロトタイピング」なのだけれど，これについては既に様々な機会で述べられていることなので，敢えてスキップする。二番目の「Naughty Dog と技術を共有できたこと」なんてのも，おいそりゃ羨ましい話だなあ，って程度であり，あまり参考になるとは言い難いものがある（あっ，うちもＰＤから技術供与を受けられれば！）。彼らは元から比較的親しい関係にあったわけだし， Mark Cerny という強力な掛け橋的存在もあったわけだから，無償条件での技術提携が可能になったというのも，それほど不思議な話ではないかもしれない。
「うまくいかなかったこと」の方は，「ディスク焼くの大変でした」とか，「ムービー作るの大変でした」とか，「ステージの広さの勘定に失敗しました」とか，あーやっぱそこで詰まりますか，というような内容ばかりで，どちらかと言えば同情を誘うような内容となっている。実は，もう少しばかりスマートな事後分析を期待していたのだけれど，思いっきり自分らの体験と被るような内容ばかりで，逆に切なくなってしまう。ううむ……。
他人の失敗談というものには，何らかの参考になる要素が含まれているものだと思う。その轍を踏まぬように気をつければ，落とし穴を１つ回避することができるかもしれない。また，もちろん，成功談にも参考になる要素がある。しかし，自分の経験と同じ内容の失敗談や成功談というものには，案外参考になる要素が無いものだと感じることがある。同じ方法で成功を収めたと聞けば，その方法への盲信を強めてしまうかもしれないし，同じ失敗談を聞けば，「やはり他人も失敗するんだ」という同情や安心感に変わってしまう危険性があると思う。
Gamasutra の人気記事でもある "Postmortem" を読むときに，いつも考えるようにしているのは，そんなことかもしれない。そして，そういった判断基準に立ったときに，今回の記事は軽く読み流す程度で良さそうな感じがしたものだから，こうして机の上に置き去られているというわけだった。
2003-06-24
他にも，束の中に埋もれている印刷物を拾い出してみた。
まず出てきたのが， Peter Wonka 氏らの "Instant Architecture" だ。
http://www.cg.tuwien.ac.at/research/vr/instantarchitecture/
これは，ビルやアパートのような建築物の外見を自動的に生成するという技術だ。題名と摘要だけ見て，もしかしたら使える要素があるかもしれないと感じ，読み始めてみたのだけれど，結局要点を得られないまま興味を失ってしまった。
結局のところ，独自の方式に従っ