2004-03-01
今までは，「まあ，ゲームプログラムなんだし，精度よりも速度を取っておくべきなのでは……」という判断から，あまり深く考えることなく "-ffast-math" オプションを利用していた。しかし，前述のような現象を確認してしまうと，果たしてこの判断は正しいのだろうかという疑念が湧いてくる。とにかく，実際にこのオプション (-ffast-math) が浮動小数点演算に対してどの程度の影響を及ぼしているのか，確認しておいた方が良いかもしれない。
GCC のマニュアルを参照してみると， "-ffast-math" の解説には次のような記述がある。
http://gcc.gnu.org/onlinedocs/gcc-3.3.3/gcc/Optimize-Options...
つまり， -ffast-math は，これらのオプションのエイリアスとなっているようだ。
まず， -fno-math-errno と -fno-trapping-math と -fno-signaling-nans の３つのオプションについては， FPU 演算例外を扱わない限りは有効にすることができる。また，よほど特殊なケースを扱わない限りは， -ffinite-math-only も有効にしておいて問題無いだろうと思う。やはり，最も影響が大きいと思われるのは -funsafe-math-optimizations だ。
例えば，次のようなコードが記述されているとする。
このコードを "-O2" と "-fomit-frame-pointer" を有効にしてコンパイルし，アセンブリリスティングを取得してみると，以下のようなコードが生成されていることが分かる。
見ての通り，元のソースに記述された通りの処理だ。
次に，これを "-ffast-math" を加えた状態でコンパイルしてみると，生成コードは以下のように変化する。
定数である "sqrt2 / sqrt3" を結合することにより，除算をひとつ減らすことができている。今時のプロセッサでさえ，除算命令は侮れないレイテンシを持っているから，これは決して無視できない最適化であると言えると思う。
ただし，精度は微妙に変化してしまう。この test_func に sqrt(5) を入力してみると，返値は以下のようになる。
このように，定数の結合は精度の低下を招くことがある。その誤差は僅かなものであるものの，厳密な意味においては「記述されたままの演算」とは異なる結果となってしまうため，単なる最適化オプション ("-Ox") では有効にならないような仕様になっている。
逆に言えば，特殊な最適化の指定を行わない限り，コンパイラは最大限に精度を保とうとする。例えば， test_func を次のように書き換えてみる。
このようなコードを書いてから，「こりゃあ sqrt2 以降は定数だけだから，きっとコンパイラが勝手に結合してくれるんだよなあ。最近のコンパイラは頭いいしなあ……」と油断していると，以下のようなコードが吐かれてしまう。
もちろん， -ffast-math を追加すれば以下のように変化する。
あるいは，以下のように演算順序を変えてやることによっても，同様の効果を得ることができる。
これならば，無理に最適化を強めなくても "-fmerge-constants" を付けるだけで最適化が行われる。 "-O2" ならばデフォルトで有効となっているオプションだ。
何となく状況のつかめたところで，「果たして -ffast-math オプションは付けるべきかどうか」という話に戻るのだけれど，これはなかなか決めることの難しい問題であるように思える。
恐らく，自分１人だけでプログラミングを行っているとしたら，「-ffast-math は切る」という結論に辿り着いただろうと思う。この -ffast-math オプションは，プログラマから精度をコントロールする手段を奪い取ってしまう。これは，多くのケース － 特にゲームにおいては問題にならないと考えられるものの，それでも例えば衝突判定などのように，局所的に演算精度がクリティカルとなる場面が存在するかもしれない。
一方で， -ffast-math を切った場合の最適化に関しては，記述する人間が気をつけてさえいれば如何にもコントロールすることができる。定数をカッコで括ったり，定数項が結合できるように演算順序を入れ替えたりなど，許容できる変更を明示的に行うようにすれば良い。あくまでもコントロールの及ぶ範囲において最適化を利用しようという考え方だ。
ただ，チーム開発においては，この判断は微妙なものとなるかもしれない。果たして，この問題がクリティカルとなる範囲を担当するプログラマは，チームの内の何％となるのだろうかと思う。それが極めて少ない割合となるのならば，全員に対してポリシーを云々するよりも，事態の説明だけを行っておき，のちに -ffast-math を有効にするべきなのかもしれないと思う。
2004-03-02
ソフトウェア工学の分野において，最適化の話題に関して調べてみると，かなり高い確率で「最適化の行為を諌める話」と遭遇する。少し前，巷で XP などが流行ったのと同時に，その確率は急激に高まったように思える。
昔からよく耳にするのは， "Premature optimization is the root of all evil" － 「早まった最適化は諸悪の根源である」という言説だ。
http://c2.com/cgi/wiki?PrematureOptimization
これはよく Donald Knuth 氏の言葉として引用されているように思えるのだけれど，実際には，クイックソートの発明者として有名な Tony Hoare 氏の言葉であるようだ。
http://www.research.microsoft.com/~thoare/
最適化に関連した話題を辿って C2 Wiki の中をさまよっていると，本当に多くの話題がこの中に含まれていることが分かる。その内容はあまりにも混沌としており，そこからまともなアイデアを拾い上げることは，決して簡単な作業ではないかもしれない。しかし，その情報量の多さには，思わず何らかの可能性を感じてしまう。
中には "First Rule Of Optimization" － 「最適化の第一法則」なんてものもある。
http://c2.com/cgi/wiki?FirstRuleOfOptimization
http://c2.com/cgi/wiki?SecondRuleOfOptimization
http://c2.com/cgi/wiki?ThirdRuleOfOptimization
まあ， "First Rule", "Second Rule" あたりは冗談としても， "Third Rule" － 「最適化の前にプロファイルを」 － などは，もっともな意見かもしれない。特にリアルタイムＣＧをベースとしたゲームにおいては，実際のデータセットに基づいた考察を行わないことには，どうにも説得力を得ることができないように思える。
例えば， id Software の "Quake" に利用されたＣＧエンジンは，最終的な形態 (BSP + PVS) へと辿り着くまでに何度も実験が繰り返されており，その過程では，実に週単位でエンジンを入れ替えるようなペースで開発が行われたという逸話がある。
http://www.bluesnews.com/abrash/
さすがにこのペースは異常だと思うけれど，「とにかく書いて，動かしてみなければ気が済まない」という感覚は，何となく理解することができる。
先日， Visual Basic の開発者である Paul Vick 氏が，自身のブログに "The Ten Rules of Performance" という文書を上げていた。
http://www.panopticoncentral.net/PermaLink.aspx/eacfc5e0-42d...
この文書において氏は，自身が Microsoft 社内での開発において適用している「最適化のルール」について述べている。その中には，ゲームプログラミングには当てはまらない項目もあるものの（例えばメモリに関する指摘などには通じない部分が多い），大方においては共有することのできるコンセプトとなっているのではないかと思う。
ゲーム開発者は一般的に，パフォーマンスに関して非常に敏感な神経を持っているものの，それが必ずしも理想的な結果を導き出しているとは限らない。上の Paul 氏の指摘にもあるように，「新しいフィーチャー」や「発症中のバグ」等の要素と比較すると，パフォーマンスの問題は「二の次」に回されてしまうことが多い。
これは，「フィーチャー」や「バグ」が目に見える要素であるうえに，数量的に扱うことのできる要素であることから，開発者の注目を引き付けやすくなっているためだと思われる（「バグが千個」などと言われれば，誰でもその重大さを理解することができるはずだ）。これに対してパフォーマンスの問題は，悪化の状態を明確に示す手段がなかなか存在しないために，曖昧な危機感を持たれながらも放置されてしまう傾向にある。結果として，「新しいフィーチャーを実装する」というタスクや「発症中のバグを修正する」というタスクが優先され続け，パフォーマンスの問題はずるずると無視され続けてしまうわけだ。
しかし実際には，ゲームにおけるパフォーマンスの問題とは，根本的な品質を左右しうる重要なファクターのひとつである。故に，これを常に目に見える問題として提示し続けることが重要であると感じる。それは，プログラムのプロファイリングを厳密に行うという意味でもあるし，デザイナやアーティストに対して明確なガイドラインを提示するという面でもカバーする必要がある。
2004-03-03
ゲーム開発において最適化をどの程度優先して行うべきかという問題は，結論を出すことの難しい項目となっているように思える。 XP のような開発手法が最適化を「二の次」に回しているのは，単に，それが許されるという前提が存在しているからに他ならない。ゲーム開発の場合には，その前提が必ずしも成り立つとは思えないというのが，個人的な見解だ。
ゲームの場合は，プログラムの開発と平行して，素材の制作やゲームデザインの構築なども行わなくてはならない。その過程において，パフォーマンスの問題は非常に重要な検討項目となりうる。例えば，「ポリゴンが何枚出るか」などと言う項目は，アーティストにとって重要な項目であるし，また，「キャラクタが何体出るか」などと言う項目は，ゲームデザインにおいて重要な項目となる。
従って，これらの項目は，出来る限り早い段階において決定されるか，あるいは現実的な見積りを出せるようになっていなければならない。この文脈において最適化の作業は，決して "YAGNI" に属さないわけだ。
もうひとつ，ゲーム開発において最適化を前倒しにしなくてはならない理由として，最適化を後回しにすることによって生じるコストの問題がある。これまでに述べたように，ゲーム開発においては，プログラムの開発と平行してコンテンツの作成が行われる。そのため，これらのコンテンツに対して影響を与えるような変更が行われる場合，既に作成されたコンテンツの量に比例して追加のコストが発生する。したがって，最適化を制作工程の最後に回してしまう行為は，最適化に必要とされるコストを最大にまで高めてしまう危険性を伴っていると考えることができる。
パフォーマンスの改善を行うためにデータ形式の変更が必要されるならば，既に作成された全データに関して変換を行わなければならない。また，単純な変換だけではなく，何らかの要素を追加・削除しなくてはならないとすれば，全データの再編集を行う必要まで生じてしまうかもしれない。
また，場合によっては，仕様に対して影響を与えずに最適化を行うことが難しいこともある。 Paul Vick 氏の言葉にもあったように，パフォーマンスの問題はコードの記述よりも設計の方に起因することが多い。仕様に対して影響を与えずに設計を変更することができれば幸いだけれど，効果的な最適化を実現するような設計の変更は，往々にして広範囲に影響を波及させる。それがゲームデザインにまで影響を与えるようであると，最適化に伴うリスクは極めて高いと判断することができる。
以上のことをまとめると，試作の段階において最適化が完了しているという状態が，最も理想的な姿であるように思える。これは，実際にはほぼ不可能であるものの，ゲームのビジュアル・コンセプトやデザインの骨格を試作の段階において確定させなければならないとすれば，パフォーマンスはそれらの要素を裏付ける「根拠」として固まっていなければならないはずだ。そうでなければ，最終的に予想していたほどのパフォーマンスが得られなかったばかりに，ビジュアルやゲームデザインを大きく変動させなければならない事態へと陥ってしまうかもしれない。
2004-03-04
３月に入ってからと言うもの，仕事の方が本格的に忙しくなってきた。まあ，まだ短距離走みたいなものだから，一時を耐えしのげば何とかなるだろうと思う。マスターアップ間際の辛さと比べれば，こんなものはまだまだ……。
最適化に関連したトピックをたどって C2 Wiki をさまよっていたのだけれど，内容が非常に雑然としており，なかなかまとまった結論を出すことができずにいる。
ちょっと面白かったのは， Eddie Edwards 氏がゲーム開発に関連した話題について，精力的な書き込みを行っていることだ。
http://c2.com/cgi/wiki?EddieEdwards
"Extreme Programming For Games", "Optimization Patterns", "Most Games Programmers Dont Grok Object Orientation" 等のページの内容が充実している。
http://c2.com/cgi/wiki?ExtremeProgrammingForGames
http://c2.com/cgi/wiki?OptimizationPatterns
http://c2.com/cgi/wiki?MostGamesProgrammersDontGrokObjectOri...
ここで登場する "Optimization Pattern" － 「最適化パターン」とは，各種の最適化の手法をパターン言語によって記述したものだ。一般的な最適化の手法に対して語彙を与えるという意味では非常に面白いアイデアだと思う。「省メモリプログラミング」のコンセプトに通じるものを感じる。
http://www.amazon.co.jp/exec/obidos/ASIN/4894714086
ただし，件のページから辿ることのできる範囲にある内容は，あまり整理されていないうえに，量の面でも充実しておらず，率直に言って参考にはならなかった。もう少し英語の読解力があれば，何かしら得るものがあったかもしれないけれど，この手の議論はコンテキストを正確に理解していないと読めない部分が多く，苦労のわりには見返りの少ないことが多いと感じる。
「最適化パターン」に関連した話題としては， Ken Auer 氏と Kent Beck 氏が "Lazy Optimization" という記事を書いている。
http://www.rolemodelsoftware.com/moreAboutUs/publications/ar...
ここでは，一般的な最適化の手法に関して，技術的な細部に触れるのではなく，プロセスの進め方やエンジニアリングの方針について詳しく触れている。非常に整理されており面白い内容だと思う。ただし，やや嗜好が XP 的な方向へと傾いているような雰囲気が感じられる。常日頃からパフォーマンスがクリティカルな要素となる自分らの分野に関しては，そぐわない部分も少なからず存在するように思える。
2004-03-05
Gamasutra には "Game Programming Patterns" というセクションが存在する。ゲームプログラミングに特化されたデザインパターンの話題を扱うページのようだ。
http://www.gamasutra.com/patterns/
ただし，現在はほとんどメンテナンスされていないように見える。リンクも死んだものばかりだ。残念……。
このページの管理者の１人である Zack Booth Simpson 氏のページには，ゲームプログラミングや，プログラミング一般に関連した話題を扱った記事が多数置かれている。
http://www.mine-control.com/zack/
氏は元 Origin Systems のプログラマであり，現在は独立系の開発者として活動するかたわら，高校の数学講師などを勤めているそうだ。例えば，電子回路の働きを空気圧によって模した教材 "Introduction To Transistor Logic By Pneumatic Analogy" などは，高校の授業のために氏が独自に考案したネタなのだろうと思う。
http://www.mine-control.com/zack/transistor/transistor.html
閑話休題……氏のページには "Design Pattern for Computer Games" というページがある。
http://www.mine-control.com/zack/patterns/gamepatterns.html
ここでは，ゲームプログラミングにおいて頻繁に登場する幾つかの機構がパターン言語によって記述されている。簡単な内容ではあるけれど，実のところ，ここに挙げられている機構は全て，自分の係わったどのプロジェクトでも必ず実装されていたものばかりだ。内容の細部や実装の方法などに違いはあれど，大抵のゲームではこのような機構を揃えることになるのではないかと思う。
例えば "Spatial Index" などは，普段は「衝突判定用のＢＢツリー構造」や「カリング用のシーングラフ構造」などのように，特定の用途に特化された形で扱われているものなのだけれど，これらの機構は，ここで述べられているような「空間インデクス」の概念として一般化することが可能だ。
では，一般化することに何のメリットがあるのだろうか。例えば，「衝突判定を高速化するためのＢＢツリー構造」を作成するのではなく，「空間の階層化を行うジェネリックなＢＢツリー構造」を作成すれば，それを衝突判定の高速化のためだけに用いるのではなく，広範囲に応用の利くモジュールとして運用することが可能となる。
実のところ，「空間インデクス」の機能を提供するジェネリックなモジュールを用意しておくと，実際に様々な場面においてこれを役立てることができる。これには，ジェネリックなインデクスの機構 (std::map) が非常に高い応用性を持っているのと同じような感覚がある。空間上の一定の領域を占めるエレメントに関して，少しでも「ｎ対ｎの関係」が生まれそうになったら，そこにすかさず「空間インデクス」を導入してやることによって，コンビネーションによる反復回数の爆発的増加を避けることができるわけだ。
他にもゲームプログラミングには，特有の「パターン」が幾つか存在するように思える。一昔前ならば，ジャンル毎に作り方も全く異なったのかもしれないけれど，最近の主流のゲームは以前よりも多くの共通点を持っているように思える。それは，何らかの形での３Ｄ表現であったり，何らかの形でのアルタイム性であったり，それに関連した非同期処理であったり，システムの動的かつ非線形的な性質であったり……そのように考えると，共有されるべきノウハウはむしろ増加する傾向にあり，それらをパターンの形で整理することには，少なからぬ意義を感じる。
2004-03-06
今日は土曜日。昼頃に起きて，一週間分の洗濯を済ました後，普通に出社した。今週は土・日の両方とも出社する予定だ。
最近になって知ったのだけれど，随分と昔から話題になっていた Elektron 社のシンセサイザ "Monomachine" の出荷が，ようやく先月から始められたようだ。
http://www5f.biglobe.ne.jp/~fukusan/products/elektron/monoma...
http://www.miroc.co.jp/news/daily_news/040223/monomachine.ht...
http://news.harmony-central.com/Newp/2004/SFX-6-Released.htm...
キーボードの無い「テーブルトップ」こと "SFX-60" が約２０万円，キーボード付きモデルの "SFX-6" が約３０万とのことで，アマチュアにはなかなか手の出ない価格設定となっている。音源の特殊性を考えると理解し難い価格ではあるのだけれど，完全にマニアとプロ向けの商売ということで，こういう価格もアリなのだろうと思う。どんなに高くても買う人は買うだろうからなあ……。
"Monomachinie" は，５種類の異なるモデリング方式の音源を搭載したデジタルシンセサイザだ。複数のモデリング方式を搭載したシンセサイザは他にも多くあれど， Monomachine はその方式の選択が非常にマニアックであるという点で，独自のキャラクタを作り出している。ウェブにあるサンプルを聴いてみれば，そのキャラクタの強烈さが分かるはずだ。
http://www.monomachine.com/sound/
しかし，２１世紀にもなって，まさか "SID" や "FM+" のような音源を前面に押し出したシンセサイザが登場するとは思いも寄らなかった。しかも，そのコンセプトがわりと多くの人に受け入れられているようだから恐ろしい……。
製品の実際の操作風景については，先日アナハイムで開催された NAMM Show でのデモを収録した Sonic State のムービーが参考になる。
http://www.sonicftp.com/vids/wmv/wnamm04_elektron_monomachin...
http://www.sonicftp.com/mp3_demos/elektron_monomachine_namm....
また，個人的に注目しているポイントとして，その本体デザインの良さがある。妙に横長いフォルムのキーボード付きバージョンはともかくとして，テーブルトップの方のソリッドでスパルタンなデザインには，非常にそそられるものがある。こういうメカメカしいのが好きさね……。
http://www.monomachine.com/showroom/
いくらなんでも高価過ぎるので実際に手を出す気は無いけれど，現在，最も憧れのハードウェアであることには間違いない。
余談だけれど，同じ NAMM Show に出展されていた Korg の４トラック MTR "CR-4" も面白そうな製品だ。
http://www.sonicstate.com/news/shownews.cfm?newsid=1362
昔懐かしのカセットテープを利用しての４トラックレコーディング環境を提供するアナログ MTR だ。本体にはモニター用のスピーカーに加えてギターアンプとエフェクタも搭載されており，これ一台さえあればガレージバンドのレコーディングぐらい簡単にこなせてしまうという，なかなかユニークな製品となっている。
CD-R を搭載した完全デジタル MTR なども珍しくないこのご時世に，カセットテープベースの４トラック MTR なんてのは，時代錯誤も甚だしいかもしれないけれど，案外，この「直感的なアナログ操作」が共感を呼びそうに思える。複雑なセットアップやオペレーションが必要とされるデジタル環境よりも，「カセットテープを突っ込んで，ギターとマイクのプラグを差し込んで，ボタンを押せばそれでおしまい」の，この環境の方が，むしろ向いていると感じる人は，少なからず存在するのではないかと思う。
2004-03-07
今日は日曜日。公共料金の支払いなどを済ませながら昼過ぎに出社した。
珍しいことに，職場には殆ど人が居なかった。いつもならば，隣のチームの人たちが忙しなさげに動いているのだけれど……自販機のストックが無くなっている様子からうかがうに，昨日までが忙しかったのかもしれないと思う。
昨日から着手していたタスクが一段落した所で帰宅した。キリ良く仕事を終えることができて気分がいい。ほんの僅かずつではあるけれど，見通しは明るくなりつつあるように思える。ギリギリな状態には変わりないけどなあ……。
帰宅するや否や，今やらずは何時になるやも分からぬとばかりに "FeedDemon" の登録手続きを行った。随分と前から登録しようと決心していたのだけれど，なかなか暇が無くて先送りにしていたところ，いつの間にか試用期限が差し迫っていたという具合だ。
http://www.bradsoft.com/feeddemon/index.asp
結局， FeedDemon 以外の売り物の RSS リーダは試してみていないのだけれど，他の製品を試すまでもなく，これで十分な使用感が得られるだろうと確信したため，迷わず登録することにした。今のところ不満点は何も見当たらないし，日本語の扱いにも問題を感じたことは無い。非常に完成度の高いソフトウェアだと思う。
そういえば，今月から asahi.com が RDF によるニュース記事の供給を開始している。おかげで asahi.com にアクセス割合が高くなった。
http://www.asahi.com/information/rss/index.html
なんだかんだ言って，アサヒは IT 化に積極的な態度を取っている方だと思う。
IT ニュース系では "@IT" が RSS の供給を行っている。
http://www.atmarkit.co.jp/aboutus/rss/rss.html
現状では RSS を利用しているユーザの絶対数が限られていることから，これらのサービスによって購読数が大幅に上下することは無いだろうと思う。従って，このようなサービスを行う意義を問うとしたら，純粋に技術的なアプローチとして見るべきかもしれない。 HTML のようなマークアップ言語によって構成された「ページ」を提供することと， RSS のようなメタデータ形式によって表現された「情報」を提供することの間には，大きな違いが存在する。あとは，クライアントの側でその「情報」をどう料理するかという点が重要になってくるのだけれど……その内容次第で，これらの RSS 供給の意義は，如何様にも変化するのだろうと思う。
2004-03-08
Impress Game Watch に，西川善司氏による "Deus Ex: Invisible War" の技術紹介記事が載せられていた。
http://www.watch.impress.co.jp/game/docs/20040308/3ddeus.htm
結局のところ，語学面で障害を感じたことから，このゲーム "Deus Ex: Invisible War" は購入するに至っていないのだけれど，デモ版をプレイしてみた限りで感じた幾つかの事柄がある。
Unreal エンジンをベースとしてシステムを構築し，様々な手法のハイブリッドによって光源表現を行うというスタイルには，昨年の "Splinter Cell" と同じ方向性を感じる。むしろ，全体的な質で言えば "Splinter Cell" の方が高いレベルを維持しているのではないかと思う。
http://www.watch.impress.co.jp/game/docs/20030403/tcsc2.htm
このスタイルに関しては，これはこれでなかなか上手く行っているのではないかと思う。電灯のスイッチを切れば光源が消え，ドラム缶に火を点ければ新たに光源が現れ，それらの光源の変化に応じてダイナミックに影が投じられる。至極自然な表現だ。
ただ，最初のビルにあるトイレに入り，何気なく電灯を消してドアを閉じたとき，ある種の違和感を覚えることになった。ドアを閉じても部屋が全く暗くならないのだ。
誰でも自分の家で試してみれば分かることだけれど，廊下の電灯を点けて，トイレの電灯を消して，そして徐々にトイレのドアを閉めてみれば，最初は間接光によってほんのりと明るかった室内が，ドアを閉じることによって全くの暗闇へと変化する様子を観察することができるはずだ（別にトイレじゃなくたっていいけど！）
ここで，グローバルイルミネーションの技術を導入すれば云々云々……と説くことはできるけれど，そこまで大層なことをしなくとも，「ドアの開閉と環境光の強さ」を何らかの方法によって関連付けてやるだけで，この変化をかなりの部分で演出することが可能になると考えている。
現在主流のリアルタイムＣＧ技術では，直接照明以外の全ての光源が「環境光」という恐ろしく曖昧な概念の中にまとめられている。これは，そのような曖昧な扱いでも十分な表現が可能だからこそ，そうなっているのだろうけども，それにしてもぞんざいな扱いを受けているものだと思う。
例えば，あるキャラクタモデルのレンダリングを行うだけであれば，これは局所照明の技術のみによって十分な表現を得ることが可能だ。しかしそこに「周囲の空間との相関性」を持ち込もうとするとき，何らかの大域照明的なアイデア － 最も基本的な所では「環境光」の変化を扱うことなど － が必要とされるように思える。
このようなコンセプトを実現する技術としては，以前，藤田将洋さんが紹介していた "Real-Time Global Illumination on GPU" などが面白いと思う。
http://web.sfc.keio.ac.jp/~syoyo/lucille/blog/archives/00016...
http://www.cs.ucf.edu/graphics/GI-Sumant.html
これは，いつか見た Gene Greger 氏の "The Irradiance Volume" の現代版と言った趣ではないかと思う。
http://world.std.com/~gene/professional/publications/irradia...
ただし，これらの技術はあくまでも「箱庭」の中でしか実験されていないという点が気にかかる。ＣＧの原初の時代において Cornell Box を Radiosity によってレンダリングすることはできても，「本当のシーン」を扱えるようになるまでには十年以上の歳月が必要とされたことを思い出さなくてはならないと思う。それに，そもそも十年経った後にメジャーとなった技術は Radiosity 以外のものだった。
これらの「空間上の点サンプル」手法も，何らかの手段によってジオメトリ情報を考慮しないことには，複雑なシーンに対して効率的な処理を行うことは難しいと感じるし，逆にジオメトリを意識し始めると，それを無視することによって得ていたアルゴリズムの単純さが一気に失われてしまうように思える。
2004-03-09
個人的にお気に入りのゲーム業界ブログ人であるところの Jamie Fristrom 氏が，長らく使用していたブログサイト "gamedevleague" を捨てて，新たなサイトを立ち上げている。その名も "GameDevBlog" だ。
どうやら blog*spot (Bloggers) のサービスの悪さに嫌気がさして， TypePad への移行を決心したということのようだ。 TypePad の垢抜けたスキンのおかげで，見た目の問題は完全に克服されているし，今度のサイトは当然の如く RSS 供給にも対応している。
最近の記事の中でも面白かったのは， "Gaming Markets Balkanized" というポストだ。
http://www.gamedevblog.com/2004/03/gaming_markets_.html
"Balkanize" とは聞き慣れない単語なのだけれど，どうやら「（バルカン半島のように）小国に分割する」という意味を持つ動詞であるようだ。むむ，なるほど……。
http://dictionary.goo.ne.jp/search.php?MT=balkanize&kind=ej
この記事の中で Fristrom 氏は， Amazon の提供する「この商品を買った人は，こんな商品も買ってます」の機能を利用して，ちょっとしたマーケットの分析を行っている。
このように， Amazon の「この商品を買った人は～」機能を利用して簡単なマーケットの分析を行うという手法は，手軽に用いることのできるテクニックとして面白いものかもしれない。日本の場合は， Amazon の利用者層自体にかなりの偏りが認められることから，必ずしも統計的に正しい結果が得られるとは思わないけれど，それでも，参考資料の１つとして扱う分には害は無いものだろうと思う。
例えば……最新ヒット作であるところの「戦国無双」などを覗いてみると，「三国無双」「鬼武者３」「ドラクエ」「ガンダム」等々の，いかにも PS2 のコア層に受けそうなタイトルが並んでいる。
http://www.amazon.co.jp/exec/obidos/tg/sim-explorer/explore-...
「ウイイレ」や「ドラゴンボール」の購入者層なども，これらのコア層と重なる領域を持っているように見える。
http://www.amazon.co.jp/exec/obidos/tg/sim-explorer/explore-...
http://www.amazon.co.jp/exec/obidos/tg/sim-explorer/explore-...
ただ，これが「太鼓の達人」などになると，だいぶ様子が異なってくる。
http://www.amazon.co.jp/exec/obidos/tg/sim-explorer/explore-...
「太鼓の達人」と「みんゴル」がユーザを共有しているという状況は，なんとなく理解できるものとして，興味深いのは，このリストの中に PS2 本体やメモリーカード等の基本的なハードウェア製品群が挙げられていることだ。
件の記事のコメントの中で "tlo" 氏は次のように発言している。
それにしても，この機能を利用して Amazon の中をさまよい歩いてみるのは，なかなか面白い行為だ。思うままに「関連する商品」をクリックして行くと，要所においてループする箇所が見つけられる。漠然としたものではあるけれど，そこに「島」のような群の存在を見出すことができる。
どうやら，「ＮＡＲＵＴＯ」や「ＯＮＥ ＰＩＥＣＥ」等の「アニメ版権系」の島には，「ロックマンエクゼ」や「ラチェット＆クランク」が食い込んでいるようだ。この辺りは， PS2 のコア層からは分断された「島」の存在となっている。
http://www.amazon.co.jp/exec/obidos/tg/sim-explorer/explore-...
http://www.amazon.co.jp/exec/obidos/tg/sim-explorer/explore-...
任天堂系と PS2 系は，完全に世界が分断されてしまっているように見える。そこに共通項を見出すことは，なかなか難しい。
http://www.amazon.co.jp/exec/obidos/tg/sim-explorer/explore-...
2004-03-10
先日，家の近所のコンビニで「ファミコンミニ」が売られているのを見かけた。
http://www.watch.impress.co.jp/game/docs/20040114/fm.htm
思わず買ってしまいそうになるのだけれど，「スーパーマリオ」や「ゼルダ」のような人気ソフトはとっくに売り切れており，あとは「ドンキーコング」や「パックマン」のような地味なタイトルばかりしか残されていない。さすがにこれは買わないなあ……。
ラインナップの多彩さからうかがうに，これらのソフトがエミュレータをベースとして動いていることは，ほぼ間違い無さそうだ。先日発表されたファミコンミニ版「機動戦士Ｚガンダム・ホットスクランブル」の「限定２０００名プレゼント」のような企画を行うことが可能になったのも，ひとえにエミュレーション技術の恩恵なのだろうと思う。
http://www.watch.impress.co.jp/game/docs/20040303/z.htm
GBA 上でファミコンのエミュレーションを行うとして，まず気にかかる点は，それぞれハードウェアが持っている解像度の微妙な違いだ。オリジナルのファミコンは 256x240 のオーバースキャン表示であるのに対して， GBA は 240x160 のアンダースキャン表示であり，アスペクト比も微妙に異なっている。
適当なウェブサイトからスクリーンショットを入手して比較してみると，どうやら，オリジナルのファミコンのスクリーンのうち，中央 240x213 の部分をトリミングし，縦方向に縮小して表示しているようであることが分かる。
http://www.radiumosoftware.com/img/030410_.png
また，このトリミングを行う位置は，ソフト毎に都合の良い位置を選択しているのではないかと思う。オリジナルのファミコンのスクリーンはかなりのオーバースキャンだから，ゲームプレイに対してクリティカルな部分（例えば「スーパーマリオ」ならば画面上部のスコア表示など）さえ守られれば，それより上下の十数ドットが削れたところで，それほどプレイ感は変わらないだろうと思う。
次に気になるのは，ファミコンのエミュレーションを行うのに CPU パワーが足りているのかどうかという話なのだけれど…… GBA 上で動くオープンソースのファミコンエミュレータも公開されているぐらいだから，どうにか足りてしまうのだろうと思う。
サウンドに関しては， GBA が都合よく矩形波を２チャネル積んでいるから，これをうまく pAPU の機能にアサインすることができれば， CPU 側に負担をかけることなくリアルなサウンドを再現することができるかもしれない。資料を覗いてみると，矩形波のデューティー比の設定も同じ仕様となっているようだ。三角波は PCM で問題無いだろうし……。
http://www.work.de/nocash/gbatek.htm
2004-03-11
そう言えば，先日，某所において， GBA でファミコンのカートリッジを遊んでしまうという怪しげなハードウェア「アドファミ」のことが話題となっていた。
http://www.famicom-plaza.com/new/adfami/
何とも言えないアジア臭の溢れる素敵な製品なのだけれど……要するにやっていることは， GBA 上でのファミコンのエミュレーションだ。恐らく製品自体は， GBA で動作するファミコンエミュレータと，ファミコンカートリッジから ROM データを吸い出して GBA へと供給するインタフェースを結合したものなのだろうと思う。それにしても，ディスクシステムまで普通に動作してしまうというのは，結構凄いことだなあ……。
ちょっと不思議なのは，ファミコンのゲームをプレイするのに GBA 用のソフトを１本だけ用意することを必要としていることだ。しかもそのソフトは， GBA 用のものであれば何でも良いとされている。これは恐らく，正式なライセンスを取得せずにエミュレータを起動するためにとられた処置なのだろうと思う。
GBA カートリッジの仕様を調べてみると，ヘッダ領域の４バイト目以降に "Nintendo(R)" のロゴイメージを格納するフィールドが用意されていることが分かる。
http://www.work.de/nocash/gbatek.htm#cartridges
このフィールドに格納されたロゴイメージは， GBA 本体の起動時に読み込まれ，起動時のスプラッシュアニメーションと共に表示される（試しにカートリッジを抜いた状態で起動してみると， "Nintendo(R)" の部分だけが表示されなくなる）。またこのロゴイメージは，実は GBA 本体にも同じものが格納されており，両者のデータは起動時に比較が行われる。そして，それらのイメージに少しでも相違があれば，起動は拒絶される。このような仕組みを組み込んでおくことによって，「起動可能なカートリッジを製造するにはロゴイメージを格納しなければならない」という状況を作り出しているわけだ。
例の「アドファミ」では，このロゴイメージを自分自身の中に格納するのではなく，他の正式ソフトウェアから「吸い出す」ことによって，ロゴイメージを格納せずとも起動することを可能にしているのだろうと思う。そのような工夫を施すことによって，法的なトラブルの発生するリスクを最小限に保ちつつも，ライセンス無しに起動するソフトを作り出すことが可能になるのではないか，ということだ。
あまり関係は無いのだけれど，先日 "Game Girl Advance" において，ゲームウォッチ版 "Zelda" のことが話題に挙げられていた。
http://www.gamegirladvance.com/archives/2004/03/04/doublescr...
http://www.gameandwatch.com/screen/multiscreen/zelda/index.h...
ゲームウォッチに「ゼルダ」なんてあったっけ……って感じなのだけれど，どうやら国外においてのみ販売されていた製品のようだ。 1989 年の発売ということだから，元祖ゲームウォッチシリーズの中でも比較的後期の製品……あるは最後の製品でもあるのかもしれない。
元のポストでは，最近話題の任天堂の２画面次世代携帯ゲーム機に関して，ゲームウォッチの「マルチスクリーン」シリーズを例に挙げ，その未来像を類推している。そのような観点から見ると，この "Zelda" は興味深い製品だ。他のマルチスクリーンシリーズは皆，ただフィールドを拡張するという目的から２画面構成をとっているのに対して，この "Zelda" は，システムとして新たな機能を追加するために副画面を利用している。任天堂の提唱する「２画面だからこそ実現できる遊び」というものも，例えばこのような所に存在するものなのだろうか，ということだ。
2004-03-12
先日， Clive Thompson 氏のブログ "collision detection" に次のようなポストがあった。
http://www.collisiondetection.net/mt/archives/000740.html
この記事において氏は，イギリスのアマチュアバンド "MJ Hibbett and The Varidators" の曲 "Programming is a poetry for our time" を紹介している。
http://mjhibbett.tripod.com/sampler/programming.htm
何の変哲も無いフォークソングなのだけれど，歌詞が面白い。これは，ポエム系プログラマーとしては，決して無視することのできないネタだ……。
ちなみに，イギリスを代表する詩人の１人であるバイロン卿の娘こそが，「最初のプログラマー」として有名なオーガスタ・エイダだ。
http://www.nikkei-bookdirect.com/science/page/magazine/9908/...
そう考えると，プログラミングと詩の関係は，コンピュータがこの世に生まれた瞬間から始まっていたものなのかもしれない。そうだ，そうに違いない……。
まあ，それはともかくとして……プログラムが「文学」あるいは「言論」としての性質を持つかどうか，という問題は，実は意外な所にも影響を与えていることを Thompson 氏は指摘している。 DMCA （デジタル・ミレニアム著作権法）による CSS 暗号解除プログラムの配布停止命令が，憲法によって保護されている「言論の自由」を抑圧するものとなるのではないかという主張だ。 DMCA を掲げる人々の言い分によれば，ソースコードの配布とソフトウェア（実行形式）の配布は同じ意味を持つという理屈なのだけれど，もし，ソースコードが「言論」としての性質を持つものであるとすれば，これを制限することは「言論の自由」を脅かすものとなりかねない。
カーネギーメロン大学の David Touretzky 教授は，自身のウェブサイトにおいて "Gallery of CSS Descramblers" というコンテンツを公開している。配布が停止されているはずの CSS 解除コードを，さまざまな表現の形式によって公開するという試みだ。
http://www-2.cs.cmu.edu/~dst/DeCSS/Gallery/index.html
この件については HotWired の記事に詳しい。
http://www.hotwired.co.jp/news/news/culture/story/2001032220...
http://www.hotwired.co.jp/news/news/culture/story/2001032320...
件のサイトにおいて公開されている「コード」の中には， CSS 解除コードをラジオドラマ形式で表現したものや，ロックミュージックの形で表現したもの，さらには，俳句（いわゆる "Haiku"）によって表現されたものなども存在する。
http://www-2.cs.cmu.edu/~dst/DeCSS/Gallery/css_descramble.mp...
http://www-2.cs.cmu.edu/~dst/DeCSS/Gallery/css_descramble_jo...
http://www-2.cs.cmu.edu/~dst/DeCSS/Gallery/decss-haiku.txt
僕自身は，プログラムの言論としての性質が云々ということを主張する気はないけれども，例えば，ポエムかぶれなプログラマがコードの中に詩の一編でも入れたところで，その行為を批判することは無いだろうし，むしろ，そういった人間性の込められたコードの方が，面白味があっていいかもしれないと思う。詩作の趣味の無い人には，コードのコメントに格言の引用を混ぜておくという小技がお勧めだ。海外の物書きがよくやるような，気の利いた引用によって文章にウィットを与えるというやつを，ソースコードの中で行うわけだ。
2004-03-13
今日は土曜日。一週間分の洗濯を済ませた後に出社した……というのは，先週と同じパターンだ。恐らく，今月中はずっとこんな調子だろうと思う。ああ，今月は "Battlefield Vietnam" が出るというのに……。
http://www.japan.ea.com/battlefield/vietnam/index.html
先日（とは言っても先月のことだけれど）， Chris Pratley のブログに次のようなポストがあった。
http://weblogs.asp.net/chris_pratley/archive/2004/02/09/7047...
このポスト "Program Management" において Pratley 氏は，「プログラムマネージャ」という役職についての解説を行っている。ちなみに同氏は Microsoft OneNote の開発チームにおいてプログラムマネージャを勤める人物であり，件のポストの内容も，そこでの経験を反映したものとなっている。
氏によれば，プログラムマネージャとは，開発者の側に身を置きながらも，マーケティングと開発の中間の位置に立ち，両者の仲介を行うという役職だ。彼らは両サイドの都合を理解しており，両者の適合しない意見に対して折り合いを付けることができる。自身はコードを殆ど書かないものの，設計や工程を管理する役割として重要な責任を担っている。
どのような業種においても，このようなマネージャ的な役職は存在するものだと思うし，もちろんゲーム制作の現場においても，こういった役職は欠かせない存在となっている。本当に下っ端として働いていた頃は，このような役職の存在を意識することも無かったのだけれど，最近になってようやく，このような役割を担う人々の苦労というものが垣間見えるようになってきたと感じる。このような人々が，あるときは「フィルター」となり，またあるときは「手足」となることによって，他セクションとの円滑なコミュニケーションが生まれ，より良い制作体制が築かれて行くことになる。
Pratley 氏の言葉の中でも印象的なのは，「決定」という行動に対する意識の持ち方だ。
ゲーム制作の場合には，ゲーム内容に係わる「決定」についてはゲームデザイナ（プランナ）に委ねるべき，という風習があるように思える。上の話にもあるように，問題に対して「決定」を下すという行為は，非常に困難を伴う作業であるから，これを他人の手に委ねるということは，作業の効率を上げるためにも重要な意味を持っている。ただ，それが「安易に良心を他人に預ける」という行為になってはいないだろうかと，たまに危惧することもある。
最後に氏は，次のような言葉によって記事を締めくくっている。マネージャに委ねられた「決定」という行為が，どれほどの苦労をもたらすものなのかがよく伝わってくる内容であると思う。
2004-03-14
今日は日曜日。昼頃に起きて出社した。
地下鉄の青山一丁目駅を出て，赤坂御用地を左手に眺めながら青山通りを下って行くと，暖かい春の陽気にやられてしまって，思わず何処かへ逃避してしまいたくなるような衝動に駆られる。御用地に入ったことは一度も無いけれど（恐らく，これからも無いだろう），外から眺めているだけでも十分に綺麗な景観だ。あそこで花見でもできたら最高だろうに……。
先々週の休日に「鬼武者３」を買ったのだけれど，時間が無くて殆どプレイできていない。ジャック・ブランが戦国時代にワープしてからしばらくした所でプレイを止めてしまっている。とりあえずのところ，ジャックのムチ攻撃はなかなかの好感触だ。刀剣での殺陣とは大きく異なる種類のアクションだけれど，このシリーズが持っているプレイヤーアクションの感触の良さは，ちゃんと受け継がれているように思える。
やはり，グラフィックは驚くほど綺麗だ。流石に Xbox の "NINJA GAIDEN" などと比較すると見劣りしてしまうのだけれど……自然地形のテクスチャワークなどは PS2 とは思えないほどの鮮やかさだし，冒頭の本願寺のシーンの細かな作り込みなどは，非常に気合が入っており圧倒される。特に炎系のエフェクトの美しさが印象的だ。
まだ冒頭しかプレイできていないものの，ゲーム内容には「シリーズものとしての苦しみ」のようなものを感じる所がある。例えば，カラス天狗こと「阿児」の存在には，どうにも「とってつけた」ような感触が拭えない。阿児の主なフィーチャーは，プレイヤーの手の届かない場所に配置された「天狗宝箱」を取りに行ってくれるというものだ。所定の位置に近づいてから○ボタンを押すことによって阿児がアクションを起こすのだけれど，結局のところ，プレイヤーはただ「特定の位置に近づいて○ボタンを押す」だけだから，ただ阿児が取りに行ってくれるということ以外は，自分で宝箱を開ける動作とあまり変化が無い。しいて挙げるとすれば，プレイヤーの待ち時間が多くなることぐらいだ。
それならば，何故にこのようなフィーチャーが追加されているのか……単純に見れば意味の無いフィーチャーなのだけれど，何となくその理由に察しがつくだけに，見ていていたたまれない気分になってしまう。むむ……。
2004-03-15
「鬼武者」の前に買った "MGS2 Substance" は，雷電の VR ミッションの達成率を 100% にするところまで進めてある。「もう元は取った」とか言いながらも，なんだかんだで遊び続けてしまった。
"MSG2 Substance" は，単純に言って面白いゲームだ。単に潜入ミッションゲームとして見るならば，むしろ MGS2 本編よりも楽しむことができると言うのが結論だ。 VR ミッションでは，刀装備やエルード移動などのように，本編では滅多に利用することのなかったフィーチャーを余すことなく活用することができる。折角作り込んであるシステムなんだから，このくらい再利用してやらなきゃ勿体無いよなあ……。
他にも，「攻殻機動隊」や「戦国無双」など，やってみたいゲームは多くあるのだけれど，仕事の方が切羽詰まっているため，とても手を出せそうにない。それに，今週の１８日には "Battlefield Vietnam" が発売されてしまうので，来月以降はこのゲームにかかりっきりになってしまうことが予想される……仕事もまだ終わっちゃいないわけだし，他のゲームをプレイしている暇は無いだろうなあ。
http://www.japan.ea.com/battlefield/vietnam/index.html
http://www.watch.impress.co.jp/game/docs/20040305/eabf.htm
http://www1.plala.or.jp/seiryu/Preview/BFV/bfv.html
EA のページでは日本語版の予告編ムービーが公開されている。「肉喰ってる奴らのオーラ」が満載の素敵なムービーだ。
http://www.japan.ea.com/battlefield/vietnam/video_trailer_j_...
こうして実際の画面を見てみると，相変わらず見た目のアピールに弱いゲームではあると思う。レンダリングやアニメーションのクオリティで言えば，他のゲーム……例えば "Far Cry" や "Call of Duty" などに大きく水をあけられてしまっている。同種類のマルチプレイヤー系戦闘ゲームで言えば， Novalogic の "Joint Operations: Typhoon Rising" などの方が，グラフィック表現的に秀でているように感じられる。
http://www.gamespot.com/pc/action/jointoperations/preview_60...
http://www.novalogic.com/downloaddetails.asp?GameKey=JOTR
しかし，実際にプレイしたときの楽しさは，やはり見た目の印象とは別の所にあるものだ。 BF Vietnam に追加されている「舟艇や戦車をヘリで輸送」という無茶なフィーチャーなどを見る限りでは， BF の持つ「懐の広さ」は健在であるように思える。この辺りのプレイ感に関して，最終的にどの程度の差が出てしまうものなのか……両方のゲームをプレイし比べてみるのが今から楽しみだ。
ともかく，来月までは全ておあずけだ。巷の人々は，今週中にはパッケージを入手してプレイし始めてしまうのかと思うと，ちょっと悔しい。くそう，待ってろよ……。
2004-03-16
最近，あまり専門書を買っていないような気がする。欲しい本は沢山あるのだけれど，結局は積読になってしまうことを考えると，勿体無くて手を出すことができないというのが，買い控えしてしまう理由だ。
現状でも欲しい本は何冊かある。まず差し迫って欲しいのは， Microsoft InfoPath の関連書籍だ。結構頻繁に利用しているツールなのだけれど，本当に「軽く」しか使えていないものだから，できれば参考書などを購入して手っ取り早くマスターしたいと考えている。
しばらくの間待ちさえすれば，和書でも適当なものが出るだろうと予想していたのだけれど，現状では数冊の洋書しか発売されていない。その中で最も有力な候補を挙げるとすれば， Roger Jennings の "Introducing Microsoft® Office InfoPath™ 2003" などが該当するのではないかと思う。
http://www.oakleaf.ws/infopath/
http://www.microsoft.com/MSPress/books/6511.asp
７月発売予定とのことで，まだ大分先の話ではあるのだけれど，その頃になっても適当な和書が存在しないようであれば，購入を検討しようと考えている。
次に欲しいのは， Stuart Russell と Peter Norvig の "Artificial Intelligence: A Modern Approach" だ。
この本は「エージェントアプローチ 人工知能」という書名で翻訳されている。
http://www.amazon.co.jp/exec/obidos/ASIN/4320028783/
AI に関する知識を深めるには面白そうな本なのだけれど……本体価格 15,000 円という値段の高さと，全 937 ページという量の多さに腰が引けてしまい，購入することができずにいる。こういう本が格好の積読書になるんだ……。
同じテーマで行くならば， Amazon の「おすすめ」に出ていた「知識と推論」が良いかもしれない。
http://www.amazon.co.jp/exec/obidos/ASIN/4781910084/
全 160 ページの 1,500 円ということで，この辺りが無難な線だな，と思う。
ゲームプログラミングの関連書籍では，最近発売された Daniel Sanchez-Crespo Dalmau 氏の "Core Techniques and Algorithms in Game Programming" の評判が良い。
http://www.amazon.com/exec/obidos/ASIN/0131020099
http://www.gamasutra.com/columns/books/20040302/index.shtml
一冊の本の中にあらゆるゲームプログラミング関連のトピックを詰め込んだという大書のようだ。 "Real-Time Redering" のゲーム版みたいなものかな，と思う。できれば一度立ち読みしてみたいものだけれど……。
ゲームプログラミングと言えば，今月末には "Game Programming Gems 4" の発売が控えている。 GDC 2004 の開催と同時に販売を開始する予定のようだ。
http://www.satori.org/gamegems/
http://www.amazon.com/exec/obidos/tg/detail/-/1584502959/
何気に "AI Game Programming Wisdom 2" も既に発売されている。
http://www.amazon.com/exec/obidos/tg/detail/-/1584502894/
この辺りも積読になってしまう可能性は高いのだけれど……見栄を張る意味でも購入しておいて損は無いかな，と思う。会社の金で買うのも一興だけれど，クレジット決済を経費で落とすにはテクニックが必要だ。むむ……。
2004-03-17
ブログには大別して２つのタイプがあるように思える。ひとつは，短いポストを大量に行う「ニュース系」のブログと，もうひとつは，まとまった量の文章を日に１回以下のペースでポストする「物書き系」のブログだ。先日の "Program Manager" の話に出てきた Chris Pratley 氏のブログは，典型的な「物書き系」として分類されるブログだと思う。更新の頻度はあまり高くないのだけれど（今月は特に少ないようで残念だ），非常に読み応えのあるポストを多く行っている。
http://weblogs.asp.net/chris_pratley/
Pratley 氏は Microsoft OneNote の開発チームにおいてプログラムマネージャを務める人物だ。つい先日のポスト "Starting out as a Program Manager" では，氏の実体験をベースとして，プログラムマネージャが実際にマネージャとしての感覚を得るまでの道程の険しさを解説している。
http://weblogs.asp.net/chris_pratley/archive/2004/03/16/9031...
どうやら氏は，その昔，日本で働いていた経験があるようだ。
Chris 氏はそれからレドモンドの Microsoft 本社に移り， Excel のアジア言語版の開発に携わることになる。そこでの出来事が，氏の後の考え方に影響を与えることになったようだ。
2004-03-18
Pratley 氏のブログが他の Microsoft 技術者のブログと異なっている点は，「新たなプロダクトを作り上げる」というフレッシュな興奮に溢れていることだ。氏がプログラムマネージャとして係っているプロダクト "OneNote" は，現在 Microsoft が展開している新たな試みのひとつだ。綿々と続く Windows や Office の製品群とは異なり，極めてゼロに近い状態から新たな挑戦を行おうとしている。また，同じ「新たなプロダクト」でも， "InfoPath" が既存の市場の取り込みを狙っているのとは異なり， "OneNote" は現状では市場の存在さえもが明確ではない領域を対象としている。果たしてこの試みが成功を収めることになるかどうかは，僕には予想もつかないことだけれど，少なくとも，これが挑戦的な類の試みであることは間違いないだろうと思う。
現在 OneNote は，基本的に Office 製品のラインナップのひとつとして扱われているものの，本来は TabletPC 向けのアプリケーションとして開発されたものであるようだ。ゲイツ氏が TabletPC の強力な推進者であることも手伝って，社内の立場的には比較的有利な状況が与えられているように見える。
http://weblogs.asp.net/chris_pratley/archive/2004/01/31/6564...
個人的にも OneNote には興味を持っていたものの， Office の "Editions" には含まれていない製品である（単体でパッケージを買わなくてはならない）うえに，単体でもそれなりに値の張る製品であるため，残念ながら購入するまでには至っていない。
http://www.microsoft.com/japan/office/onenote/prodinfo/defau...
http://www.amazon.co.jp/exec/obidos/ASIN/B0000CNXY8
その代わりに，体験版をインストールして試してみている。６０日間無料で使うことのできるバージョンだ。
http://www.microsoft.com/office/onenote/prodinfo/trial.mspx
OneNote は，基本的には「アウトラインエディタ」の一種なのだけれど，より「汚く」情報の管理を行うことができるという点で，非常にユニークなソフトウェアとなっている。
OneNote のインタフェースはとても直感的なものだ。ノートを選んで，テキストを打って，マウス操作で移動したり分類したり……あらかじめ定められた「形式」や「構造」のようなものは存在しなく，２次元の平面とその階層の中に，自由に情報を配置することができる。この辺りの自由度の高さは，実際に使ってみれば分かると思うのだけれど，なかなか心地の良いものだと感じる。
特に便利だと感じたのは，万能なドラッグ＆ドロップ機能だ。例えば，ウェブページの一部分をぐりぐりっと選択して，それを OneNote 上にドロップするだけで，簡単にウェブページの「切り抜き」を作成することができてしまう。多少書式が崩れてしまうのは目をつぶるとしても，フォント設定や画像の埋め込み程度はそれなりに再現してくれる。この機能を利用して， OneNote を「ウェブ用スクラップブック」として使ってみるというのも，面白い利用方法かもしれない。
2004-03-19
Pratley 氏のブログへのポスト "OneNote Genesis" によれば，このソフトウェアの基本的なコンセプトは， Steven Sinofsky 氏とのメールのやりとりの中から生まれたものであるようだ。
http://weblogs.asp.net/chris_pratley/archive/2004/01/30/6489...
個人的には，やはり「スクラップブック」として利用するのが面白いのではないかと思う。これまでは，ちょっとした情報の管理を行う際に，個人用の Wiki やテキストファイル，それからブラウザのブックマークなどを利用していたのだけれど，これらの方法はいずれも何かしらの問題点を抱えていると感じる。この中でも Wiki はかなり強力なツールだったのだけれど，扱える書式に制限があるために，情報の引用を行うことが難しくなってしまっている。また，直線的な構造とハイパーリンクによってしか情報の管理を行うことができないため，上手く整理を行うには丁寧な抽象化を心掛ける必要があった。これが意外とオーバーヘッドになってしまうというのが， Wiki に対する個人的な印象だ。
その一方で OneNote ならば，直感的なインタフェースと自由な書式のおかげで，情報を「汚い」状態のまま管理することが可能となる。よく参照する資料を貼り集めたノートを作ってみたり，興味のあるウェブ上の記事を貼り集めたノートを作ってみたり，ちょっとしたアイデアを書き留めたノートを作ってみたり……あるいは，ファイルの埋め込みが可能なことを利用して，「ファイル置き場」として使ってみるのも面白いかもしれない。論文の pdf をずらっと並べて，その横に自分の感想やら覚え書きやらを残しておけたら，なかなか便利なんじゃないかと思う。もちろん，他の手段を利用して同様の仕組みを実現することは可能だけれど， OneNote の場合は扱い易さの面で大きなアドバンテージが存在するはずだ。
また，これを TabletPC によって持ち歩くことができれば，また別の次元での利便性が生まれるだろうと思う。僕は今のところ，休憩の間に読み終えられないような量の文書は，紙に印刷してから移動中に読むようにしているのだけれど，この印刷までの工程が意外と面倒であるし（大抵 html2ps を使っている），そのうえ紙の無駄使いになっていると感じることがある。これが， PC 上と TabletPC 上の OneNote の同期によって実現することができれば，どんなに便利なことだろうと思う。
……とは言うものの，いまだ真価は掴みかねているというのが率直な感想だ。その点については InfoPath も同様かもしれない。ともかく，これらふたつのソフトウェアが注目すべき存在であることには違いないだろうと思う。
2004-03-20
今日は土曜日。さすがにテンパってきているためか，プログラマの皆さんはほぼ全員出社している。いきなり修羅場だよなあ……。
少し早めに帰ろうかとも思っていたのだけれど，結局，終電近くまで粘って作業することになってしまった。これだけ踏ん張ってもまだ見通しは明るくならない。帰宅できているだけ幸せだと見るべきか。
最近，コード書き用のエディタとして使っている SlickEdit が，たまに重くなってしまうことがある。ソースコードの量は，まだ大規模プロジェクトと言うほどの量にも達していないと思うのだけれど， Context Tagging 機能が発動する度に 0.5 秒ぐらい待たされるようなレスポンスとなってしまっている。
とは言え，この強力な Context Tagging 機能は，一度体験してしまうとなかなか外すことができなくなってしまう。特に「参照先の周辺のコメントをポップアップ表示する」という機能は，これによってコメントやドキュメンテーションの概念を再構築する必要性が生まれるのではないだろうかと思えるほどに強力な機能だ（同様の機能は IntelliSense にも存在する）。
自分の周囲ではエディタとして Microsoft Visual Studio を使う人が増え続けているのだけれど，僕は敢えて SlickEdit を使ってみることにした。特にこだわりがあったわけではないのだけれど，例えば MSVS は EUC エンコーディングをサポートしていないし，シンタクス解析に対応している言語の種類も限られている（SlickEdit ならば Perl や Python にも対応している）。そのような些細な点を考慮すると，現状では SlickEdit の方が自分に向いていると思えるわけだ。
しかし，そのような状況も次第に変化し続け，いずれは僕も MSVS を使うようになるだろうと思う。統合開発環境としての MSVS の成長は目覚しい一方で， SlickEdit はこれと言って革新的な機能を付け加えることはなく，緩慢な成長を続けているだけのように見える。この状態が長く続けば，いつかきっと MSVS は何か決定的な要素を搭載し，僕のような人間をもユーザとして取り込んでしまうことだろうと思う。
まあ，それ以前に，そもそもコストパフォーマンスの面で SlickEdit は非常に分が悪い。一方はエディタだけで数万もするのに対して，もう一方は同じ価格で開発環境一式が揃うってんだから……。ともかく， Longhorn ベースの VS が登場したときこそ，移行のタイミングとなるのではないかと予想している。
2004-03-21
今日は日曜日。昼頃に起きて出社。家の外に出ると，また冬に戻ってしまったかのような寒さが肌に沁み込んでくる。
さて，来週はどうなっていることやら……。
本当に締め切りに間に合うんだろうかという焦燥感に責め立てられ続けながらも，残されたタスクの量を慎重に見積もり，多少の楽観的な観測を加えれば，ギリギリで何とかなるのではないかという微かな希望が湧いてくる。部外者的にはかなりヤバい状況に見えると思うんだけどね……。
先日，このような状況と関連のあるような話を Jamie Fristrom 氏がしていた。 Gamasutra の連載記事 "Manager In A Strange Land" の "The Dead Zone" という記事だ。
http://www.gamasutra.com/features/20040213/fristrom_01.shtml
この記事の冒頭は次のようなくだりから始められている。
このような感覚は，僕自身も何度か経験したことがあるように思える。当たり前のことかもしれないけれど，ゲームという「製品」は，完成するまで「製品」と呼べる状態にはならない。完成の瞬間を迎えるそのときまで，どこかしらに仮の部分を抱えており，それが「製品」を「製品」と呼ぶに相応しくない状態へと押し留めることになる。
いつまで経っても仮のままのテクスチャ，仮のモデル，仮のアニメーション，仮のギミック，仮のアクション，仮のカットシーン，仮のテキスト，仮のサウンド，仮のタイトル画面……それらの部品の完成版が全て揃い，正しく組み合わさったとき，はじめて「製品」と呼べるものがそこに出現する（これは通常アルファ版とかベータ版とか呼ばれているものに相当する）。
Fristrom 氏はこの現象のアナロジーとして「家の建築」を挙げている。家を建てる過程においては，内装が完了するその瞬間まで，家が家として見えることは無い。コンクリが打ち終わったからと言って，その家に住み始めようとする人は居ないだろう。
また，家を建てる過程においては，全ての部屋が平行して作成されることになる。まずは玄関から完成させて，次に居間を完成させて……なんて作り方をする業者はどこにも居ないだろう。ゲームも同じようなもので，まずステージ１を完成させて，次にステージ２を完成させて……などという作り方をすることは殆ど無いだろうし，少なくとも一般的な手法ではない。
ゲームショーや E3 に出展されるデモは，そのような工程を捻り曲げ，無理矢理に居間だけを完成させて，それをユーザに見せているようなものだ。デモを見た人々は，さもそのゲームが完成に近づいているような印象を受けるのだけれど，実際には，その部屋の裏にはまだ骨組みしか出来ていない部屋の数々が並んでいる。そのギャップを部外者が知ったら，大抵は驚きを覚えることだろうと思う。
2004-03-22
このような「完成するまで完成に見えない」という現象は，プロジェクトの進捗の把握を難しくする働きを持っている。部品は確実に揃い始めているにもかかわらず，制作者達の視点から見てみれば，いつまでたっても終わりが見えてこない。そして，本当の「終わり」が実感できるような段階に達するまで，うっすらとした焦燥感にさらされ続けることになる。
この現象は，開発チームの規模が膨らめば膨らむほど，長く強いものとなる。一般に，規模の大きなチームほど作業の並列性が高くなるためだ。
Fristrom 氏は，このように「いつまでたっても完成しない」という感覚に捕らわれてしまう期間のことを "Dead Zone" と名付けている。氏によれば，この "Dead Zone" は，一般向けのデモを公開した直後から始まり，全てのコンテントが揃う数週間前まで続く。その数ヶ月の間，「完成した」と言えるものは何一つ存在しない状況が続くわけだ。
このような進捗の把握し難さは，制作者達自身の感覚を狂わせるだけでなく，外部に対してのアピールを難しくするという弊害も併せ持っている。例えば，パブリッシャーから外注の形で制作を請け負っているような立場の場合，進捗を明確に示すことのできるものが無い状態というのは，非常に危うい状態であると言えるのではないかと思う。「もし，E3 のデモから６ヶ月が経っているにもかかわらず，完成しているステージは E3 のデモで公開した部分だけだと知ったら，パブリッシャーは卒倒してしまうかもしれない」とは Fristrom 氏の弁だ。
この Dead Zone 現象に対して Fristrom 氏が述べている助言は，ひたすらスケジューリングを厳密に行うことだ。適切なマイルストーンを設け，定期的に進捗の確認を行い，製品の見た目から伝わってくる部分によって進捗を「感じる」のではなく，データとして進捗を「分析」できるようにしておかなければならない。それさえ上手く働いていれば，完成の時期に関して確信を持つことができるし，あるいは，間に合いそうもない部分の削り落としに着手することもできる。
Dead Zone の期間は，作業の並列性やコンテントの量が増加するほど，長い期間に渡ることになる。例えば，「ドラクエ」のように複雑かつ大規模なゲームの開発現場においては，恐ろしく長期間の Dead Zone を体験することになるのではないかと思う。そもそもの設定された開発期間が長いうえに，こなすべき膨大な量のコンテント，それを支えるのは１作ごとに使い捨てのシステムと制作体制，更には，比較的初期の段階から一般に情報が公開されていることなど，現場を圧迫する要素があまりにも多いように思える。
また，逆の方向性として興味があるのは，「三国無双」や "Final Fantasy" ，それに "Jak & Daxter" や "Ratchet & Clank" のように，コンスタントなペースでプロダクトを出し続けているデベロッパーの存在だ。このような場合，開発の過程において開発者達の受け取る感覚はだいぶ異なってくるだろうし，そもそも "Dead Zone" のような期間が存在するのかどうかも定かではない。
2004-03-23
忙しい……この手の締め切り間際の忙しさには独特の味わいがある。目の回るような忙しさによって意識が高揚し，ある面では作業効率が劇的に向上するのだけれど，他方では溜まりゆく老廃物を無気力に見つめる己の姿がある。後先のことを考えずに実装を詰め込んでいく行為には，普段の仕事のやり方には無い「ライブ感」があって楽しい。コンテントが全て揃った後に山積みになったバグを一つ一つ潰していくのに似た楽しみだ。問題は，確実に体力が擦り減らされてしまうことと，終わった後の片付けのことなのだけれど……まあ，後者については，これが終わってから考えれば良いと思う。
IT 技術系のブログを読んでいると，ごくまれに， dogfood がどうのこうの，という表現が出てくることがある。いまいち意味を掴みかねていたのだけれど，最近になってようやく，これが Microsoft の内部用語だということが分かってきた。
http://www.google.com/search?num=50&q=microsoft+dogfood
文章の中では "eat your own dogfood" などといった感じで使われることが多い。「己のドッグフードを食らえ」 － どうやらこれは「自分の作っているものを普段から使うようにしよう」という訓示を表した言い回しであるようだ。
"The Jargon File" の解説には，次のようにある。
http://www.everything2.com/index.pl?node=dogfood
これに関しては，先日， Bob Congdon 氏が自身のブログの中で触れていた。
http://www.bobcongdon.net/blog/2004_03_01_congdon_archive.ht...
ここに登場する Ned 氏とは，もちろん（？） Ned Batchelder 氏のことだ。この御二方は過去に IBM および Iris Associates に在籍していたという経歴があり，そこで Lotus Notes や Domino Server の開発に携わっていたようだ。グループウェアなんてのは IT 化された組織には必須のものだから，まさに「ドッグフード」としてはうってつけのものかもしれない。また， Microsoft 社員が自ら，未完成の Windows プラットフォームや Office ツール，それから MSVC などを始めとする開発スイートなどを利用するのも，ごく自然な行為のように思える。なにしろ組織の規模が規模だから，内部で利用するだけでも相当のテストになるのではないかと思う。
個人的に思うのは，ゲーム開発に用いられるインハウス・ツールの類は，プログラマがそれを自ら率先して利用するという状態を作り出さないと，どうしてもサポートが弱くなってしまうという事実だ。「ツールを作るのはプログラマ，ツールを使うのはプランナ」というような「住み分け」が発生してしまうと，ツール開発の方向性と現場のニーズの間に「ずれ」が生じてしまう。 Jamie Fristrom 氏が，「プログラマである自分が，テンポラリのミッションデザイナとして加わることによって，開発プロセスの改善を図ることができた」と言っていたのも，いわゆる「己のドッグフードを食らう」行為の一例なのだろうと思う。
http://www.gamasutra.com/features/20040103/fristrom_01.shtml
2004-03-24
昨日までは忙しさに対してハイになることで乗り切ることができていたのだけれど，今日になって現実を冷静に見据えてみると，これがまた非常にギリギリの状態であることが分かってくる。もはやこれは，楽観的に構えているだけでは乗り切ることができないなと感じる。現実的な解決方法を練りつつ事を進めないと……。
ある仕様の一部分をカットしたとして，その分浮いた労力を他の重要な部分（例えばゲームのコアとなる要素）に費やし，結果として元の状態よりも良い品質を得たならば，それは成功となる。逆に，労力を分散させることによって成功するパターンもあるのだろうけども……個人的な経験に限定すれば，前者の行為の方が成功であるケースが多いように思える。もっとも，そのようなジレンマに陥るのは「深く広く最大限の可能性を見積もった仕様」が渡された場合のみであって，これが例えば「浅く狭く」だったりすると，逆にこちらから創出を行わなくてはならなくなることもある。
もしかしたら，「そこまで出来てこそのゲームプログラマ」なのかもしれないけれど……その辺りの解釈は組織の持つ文化によって大きく異なってくるのだろうと思う。
先日横でプレイしていた "Ninja Gaiden" のスタッフリストを何気なく覗いてみたところ，プランナー数人に対してプログラマーが十数人という人数構成になっており，非常に驚かされた。これだけ比率が異なってくると，それぞれの役割の分担の方法もかなり異なってくることだろうと思う。
それはさておき，もうひとつの重要な要素は，バグだ。バグに関しては，同様に品質に対して影響を与える要素でありながらも，トレードオフにかけることのできないほどクリティカルな要素となっている。バグのあるゲームソフトは，バグのある洗濯機と同じぐらい低品質なものとみなされる。基本的にバグの無い状態が当たり前と考えられているから，たとえ仕様の実装が追いついていないとしても，最終的にはバグの修正の方が優先される。ゆえに，バグの放置はゲームソフトの品質を大きく落としかねないと見ることができる。必ず，放置したツケは大きいと思い知らされる。
しかしそのような「バグを減らす努力」も，マイナスをゼロに戻すだけの行為であって，それをプラスへと持ち上げるには，それとはまた別の力が必要となってくる。結局，そこで僕の出来ることと言えば，プラスへと跳躍する力を持った人が，マイナスではなくゼロの高さから飛び立てるよう，せいぜい地ならしをしておく程度のことであったりするわけだ。
2004-03-29
目の回るような忙しさだった３月も，ようやく終わりを迎えようとしている。先日，なんとか無事にマイルストーンへと到達することができた。最後の数日間の忙しさは尋常なものではなかったけれど，その苦労も報われたと感じる。先行きの見えにくい展開に一時期はどうなることかと思ったものの，最終的には目標のクオリティに極めて近いものが達成できたと思う。
このようなマイルストーンの締め切り間際に，いつも悩ましく思うのが，どの時期まで変更を許容するかという判断だ。この手の創作物の持つクオリティは，最後の「仕上げ」の期間に急激な上昇を迎えるため，締め切り間際の数日間や数時間における作業が重要な意味を持ってくることがある。それだから，本当に締め切り間際のギリギリとなっても，食事を抜いたり徹夜をしたりしてまで粘ろうとする人々が存在するのだけれど，そのような無理がかえって作業ミスを誘発してしまい，逆にクオリティの低下を招いてしまうこともある。
原理的なことを言えば，どんなコードやデータの変更も問題を発生させる可能性を含んでいるのだから，どんなに注意して作業を行ったとしても，必ず不具合（バグ）は発生する。クオリティを保証するためのテストは絶対に必要な工程であり，テストの不十分なソフトウェアは潜在的なクオリティの低さを抱えてしまうことになる。そのような観点からみれば，締め切り間際に駆け込みで要素を詰め込む行為は，すなわちクオリティの低下を意味するものとなるのではないかと思う。
例えば，ある開発中のゲームのデモがゲームショーに出展されているとして，そのゲームが展示中にハングアップしてしまったら，そのゲームに対するユーザの印象はかなり悪くなるだろう。もしそれが，たった１行のコードを書き換えたことや，あるいはたった１枚のテクスチャを入れ替えたことにより誘発されたものだとしたら……その僅かな「仕上げ」によって得られるはずのクオリティがスポイルされるばかりか，本来持つクオリティさえも削られてしまうのだから，それは完全な失敗だ。
そこで，締め切りよりも前の段階において制作作業自体は停止させ，テストと修正作業のみを行う期間というものを設けることになる。この期間は，理性的に考えれば絶対に必要な要素なのだけれど，クオリティを追求する制作者にとってみれば辛い期間かもしれない。その時間を制作作業に当てれば，今よりもずっとクオリティを向上させることが可能だと分かっているのに，それを行うことは許されない。制作者としての自我と理性が衝突する瞬間だ。
僕自身は，賭けよりも安牌を選ぶタイプだから，最後に駆け込みで作業を行うようなことはあまり無い。比較的早い段階において安全な到達点を模索しておき，そこへ着地することを目標としてしまう。最後に無理をしてまで要素を詰め込んだりするのは非常に危険な行為だと感じる。
しかし，だからと言って，最後の瞬間まで己の力の限りを振り絞ろうとする人々を責める気にはなれない。それは自分勝手な行為なのかもしれないけれど，そういった行為の背景には，クオリティに対する飽くなき欲求が存在する。たとえエゴイスティックに振舞ってしまったとしても，できる限りクオリティを追求したいという欲求……それはアーティストとしての適性であり，また天性でもあるのだろうと思う。その欲求こそが高いクオリティを実現する原動力となるのだから，それを消沈させてしまうような行為はできる限り避けるべきだと感じる。
2004-03-30
前述のような理由もあって，実際には開発の最後の瞬間までを全力で走り抜くことは「まず」できない。ビデオゲームがソフトウェアの一種である以上，品質を保証するためには一定量のテストを行うことが必須であり，その保証はゲームに対して何らかの変更を加えた時点で無効になると一般には考えられている。
そのような制約を受け入れつつも，拘束される時間を最小限に抑えるためには，効率の良いテスト手法と堅牢なバージョン管理手法を確立することが必要であると感じる。前者（ゲームにおけるテスト手法）については「開かれた問題」であるがゆえに解を得ることは難しいのだけれど，後者は調査と投資次第で解を得ることが可能であるはずだと考えている。
NXN 社の "Alienbrain" などは，まさにこの用途のために存在するツールなのだろうけども，あまりいい噂を聞かない。宣伝を見る限りでは，バージョン管理の他にプロジェクト管理の機能なども備えており，非常に多機能なツールのように思える。しかしその実，あまり重要ではない部分ばかりが強調されているようにも思えなくない。
個人的に不安にさせられるのは，現在 NXN 社は Avid 社の傘下にあるという事実だ。
http://www.avid.com/company/releases/2004/040126_NXN_corp.ht...
無論，XSI との連携は今後強化されていくことになるだろうし， CG プロダクト管理ツールとしての使い勝手も洗練されていくことだろうと思う。しかし，ゲーム制作における汎用的なアセット管理ツールとしての立場は，今後どのように変化していくのだろうかと思うと，一抹の不安を感じないでもない。
もうひとつ，よくバージョン管理ツールの候補として挙げられているのが Perforce Software 社のバージョン管理システム "Perforce" だ。
http://www.perforce.com/perforce/products.html
http://www.toyo.co.jp/ss/perforce/
こちらは，バージョン管理システムとしての安定性や高速性などに関して定評があり，信頼のできるシステムとして薦められていることが多い。見た目の地味なツールだけれど，堅実な作りであると感じる。
一応，ゲーム制作上のツールとしての需要があることも意識しているようで，ゲーム開発者向けの宣伝ページなども存在する。
http://www.perforce.com/perforce/gamedev/index.html
１クライアントあたり約 $700 という価格は決して安くないと感じるものの，それによって安定した管理が実現されるとすれば，決して高過ぎる投資ではないのかもしれない。 Visual Source Safe だって約９万はするわけだし，同じようなものだと考えれば，ね……。
http://www.amazon.co.jp/exec/obidos/ASIN/B00005OI0A
2004-03-31
最近また，ゲーム開発関連の話題を扱ったブログの巡回先がひとつ増えた。 Day 1 Studios の Noel Llopis 氏のブログ "Games from Within" だ。
http://www.gamesfromwithin.com/
Llopis 氏は，同じ Day 1 Studios に所属する Kyle Wilson 氏と並んで，ゲーム開発におけるソフトウェア工学的な話題を扱う技術者として，僕の中では位置づけられている。
いつのまにか本まで書いていたようだ。題名は "C++ for Game Programmers" ……「いかにも」な感じの本だ。
http://www.amazon.com/exec/obidos/ASIN/1584502274
件のブログ "Games from Within" において Llopis 氏は，ゲーム開発におけるソフトウェア工学やプロジェクトマネジメント，それから C++ の話題などを扱っている。更新の頻度はさほど高くないものの，読み応えのある記事をちょくちょくと出している。
とりあえず目を通してみた中でも面白かったのは， "Physical Structure and C++" というシリーズだ。
http://www.gamesfromwithin.com/articles/0403/000011.html
http://www.gamesfromwithin.com/articles/0403/000013.html
この記事の中で氏は， C++ の「物理的構造」について触れている。つまりは， C++ という言語の持つ論理的な構造に着目するのではなく，あくまでも物理的な構造に着目した場合に明らかとなる問題点について検討しようというわけだ。特に，物理的構造に関して複雑かつ曖昧なポリシーを持つ C++ にとって，この手の話題はそれなりの重要性を抱えていると感じる。
これらの話題に関しては， John Lakos の「大規模 C++ ソフトウェアデザイン」の内容と重なっている部分も少なくない。
http://www.amazon.co.jp/exec/obidos/ASIN/4894711249
しかし， Lakos 氏の本は出版されてから８年もの期間が経過しているのに対して， Llopis 氏は最新の話題に触れているところが面白い。例えば， Lakos 氏が件の書籍の中で挙げている「冗長インクルードガード」 (redundant include guard) のテクニックは，最新の環境ではまったく意味の無い行為となってしまっていることが Llopis 氏によって指摘されている。
また氏は，件の記事において，数個の自作 perl スクリプトによってソースコード群の分析を行っているのだけれど，この手法がなかなか面白い。いくら文字列処理の得意な perl と言えども， C++ の構文を直接に解析することは難しいため， Doxygen の XML 出力モードと perl モジュール出力モード (perlmod) を利用することによってこれを解決したとのことだ。
僕はこの Doxygen の perlmod 出力というフィーチャーの存在を知らなかったので，この機会に軽く調べてみたのだけれど，どうやら，整形を施す以前の中間生成情報を perl のモジュールソースとして出力するというもののようだ。通常の使い方では，この中間生成情報をを自分の好きな形式に直してから出力することで，特殊な出力形式に対応させるわけだ。
http://www.stack.nl/~dimitri/doxygen/perlmod.html
Llopis 氏自身も述べているのだけれど， Doxygen を C++ のソース分析を行うためのパーサとして利用することができるという事実は，今回初めて知った。氏はこの機能を使って，自身の提示するガイドラインが守られているかどうかを確認するためのスクリプトを作成している。これはもしかしたら便利かもしれない……しかし，それにしても，意外な所にこういった解答が隠されているものだな，と思う。