2005-06-24
http://www.jp.playstation.com/Item/2/6174608.html
長く続いた仕事にようやくひとつの区切りが訪れた。
今回の仕事では，最終的に前回にも増して厳しい展開を強いられることになった。この数日の精神的なプレッシャーと言ったら，皆相当なものであったに違いない。
ゲーム制作の現場における締め切り間際の雰囲気は，雑誌編集や漫画家のそれとは大きく異なることだろうと思う。完成した製品をＱＡに提出し，その結果報告を待ち続けながら，自らも不具合を探し出すためのテストプレイを繰り返す。品質に影響を与えるような不具合が見つかれば，それを即座に修正し，またＱＡに提出する。たとえ細かな不具合が見つかったとしても，迂闊にその修正を行えば，更に深刻な不具合を新たに生み出してしまう危険性があるため，本当に深刻な不具合以外は修正を行うことはできない（どのようなコードも確率的にバグを生み出すという事実を常に覚えておくべきだ……特にプログラマが疲弊している状態においては，その確率は飛躍的に高まる）。そのような悶々とした生殺しの状態が，１週間前後も続くことになる。
今回の仕事においても，終盤になってから色々と後悔することや，泣く泣く諦めることが多くあった。また，ほんの少しの判断の誤りから，非常に多くの人々に対して多大な迷惑をかけてしまうこともあった。思い始めれば本当にきりが無い。これらの思いは決して忘れること無く，今後の仕事における糧にしていきたいと心から思う。
しかし，制作の仕事において，完璧に満足のいく結末など有り得ないというのも，また一つの真実であるはずだ。芸術において作品とは，創造物が変化していく過程の一側面を切り出したものであり，何かをもって完全であるとか，最終形であると言うことはできない。今回の製品も，会社側から提示された期間と費用と，それにスタッフの資質が掛け合わされた上でのひとつの回答であり，またひとつの成果してあるべき姿なのだろうと思う。
こんなときは，松本零士の銀河鉄道を思い出すべきかもしれない。たとえ悔いが残ると分かっていても，限られた時間の中であるからこそ，精一杯ひたむきに打ち込むことができる。終わりの見えない制作などは，恐らくは非常に怠惰なものとなってしまうだろう。
様々な思いが駆け巡るものの，ともかく，今この瞬間だけは，制作が完了したことを素直に喜び，そして自ら祝福したいと思う。その程度の楽観さは常に備えていて許されるはずだ。おめでとう，みんな！ おめでとう，自分！
2005-06-27
自分が "Long Tail" という単語を始めて目にしたのは， 2004 年 10 月の Wired の記事 "The Long Tail" だった。
http://www.wired.com/wired/archive/12.10/tail.html
この "Long Tail" という単語は，ここしばらくの間に急速に広まりつつあるようで，日本語の Google 検索でも既に 5,000 件近くヒットさせることができる。
http://www.google.co.jp/search?hl=ja&q=%22long+tail%22&lr=la...
では， "Long Tail" とは一体何なのか……詳しくは他の記事に譲るとして，要点となるのは，インターネットの普及によって，これまでの流通構造に付随していた様々な制約を取り払うことが可能となり，幅広いニッチの拾い上げが可能になるという点だ。そしてその広大なニッチ ― つまり "Long Tail" は，マスと同等，あるいはそれ以上の価値を持っているかもしれないということで，注目が集められている。
ところで，Ｅ３等で発表された各種次世代ゲーム機の内容を目にしていて，なんとなく連想したのが，この "Long Tail" だった。任天堂の次世代機における「過去のゲームタイトルのダウンロード」や， Xbox Live の新機能である "Marketplace" などが，それを連想させるものだ。
http://www.nintendo.co.jp/n10/e3_2005/revo/
http://www.watch.impress.co.jp/game/docs/20050310/gdc_xb.htm
任天堂の次世代機における「過去のゲームタイトルのダウンロード」の機能は，ネットワークの導入数が制約条件となるものの，それさえクリアできれば，希薄かつ広大なニッチを拾い上げることが可能になると思われる。懐疑的に見るならば，果たしてどれだけの数のユーザが，これらの過去のゲームタイトルを購入するだろうかと思うかもしれない。しかし，過去のゲームソフトをイメージファイルに変換しサーバ上に保管するコストなどは，同等のタイトルを制作するコストと比較すれば，ほとんど無いに等しいレベルのものとなる。選別はさておき，とにかくサーバ上に置いて，長い時間をかけて継続的に売っていくのが "Long Tail" 流だ。そういった形でのニッチに対するアプローチが，ようやく可能になるということだと思う。
"Marketplace" の方は，ニッチを対象にするという点では類似を感じるものの，よくよく考えてみると少し扱いの難しいシステムかもしれない。あるゲームに対応するコンテントを販売するには，まずそのゲームが相当数売れなければならないから，実は「売れているゲームほどますます利益が上げやすくなる」という構造であることが分かる。 Marketplace の存在を前提として売り方を変えることも考えられるものの，これも成功させるにはやや巧妙な戦略が必要とされることだろうと思う。
2005-06-28
例えば，あるシーケンスが開始されてからの経過秒数を計測する変数 x が存在すると仮定する。そのシーケンスは 1/60 秒毎に１ステップ進行するため，変数の型は float としておき，１ステップ毎に 1.0f / 60 を加算していくことにする。
もし，このシーケンスを２日間以上正常に動かしたいのならば，ここで間違いに気付くべきだ。実際にこのようなプログラムを動かしてみると， 2^17 秒 ＝ 約 1.5 日の辺りから演算誤差のために非常に怪しい挙動を見せ始める。 2^19 秒付近にもなると，桁落ちのためにステップ毎の加算が無効となり，まったく時間が進まなくなってしまう。
これは，浮動小数点演算の誤差が生み出すバグの中でも，非常に分かりやすい例のうちのひとつであり，しかも簡単な回避方法が存在するものだ（この場合は進行回数を整数でカウントするか，適切な固定小数点形式を用いるのが望ましい）。むしろ現場において浮動小数点演算の誤差が深刻な問題を引き起こすのは，幾何的な演算を扱う場面であることが多い。それが描画に関連するものであれば，最悪でも「見た目の不具合」で済ますことができるものの，衝突判定や物理挙動の類である場合は，不自然な挙動や仕様の破綻へと繋がることが多く，結果的に品質に対して深刻な影響を与えてしまう危険性が高い。
Francisco J. Santistive 氏の論文 "Robust Geometric Computation (RGC), State of the Art" は，幾何演算の分野における浮動小数点演算の安定性について扱っている。
http://citeseer.ist.psu.edu/santisteve99robust.html
この論文の導入部分において，浮動小数点演算の誤差が非常に深刻な事態を招いた例が，二件ほど紹介されている。
最初の例は， 1991 年の湾岸戦争での出来事だ。米軍の兵舎を狙って発射されたスカッドミサイルをパトリオットミサイルによって迎撃しようとしたところ失敗し，結果として 28 名の兵士の命が失われた。米国会計監査院 (GAO) の調査によれば，起動からの経過時間を計測する部分に演算誤差が混じっていたために迎撃に失敗したとされている。
もうひとつの例は， 1996 年に起こったアリアン５ロケットの事故だ。
http://www.around.com/ariane.html
http://www.cas.mcmaster.ca/~baber/TechnicalReports/Ariane5/A...
アリアン５ロケットは，欧州宇宙機構 (ESA) が１０年近くの歳月と約７０億ドルの費用を投入して開発した待望の商用ロケットだった。しかし，このロケットは離陸から１分も経たぬうちに，約５億ドル相当もの機器を積載したまま，爆発して塵屑と化してしまった。
記事によれば，事故の原因は，慣性基準装置 (IRS) 内にあるソフトウェアが，水平方向の速度値を 64 bit 倍精度浮動小数点から 16 bit 整数値へ変換していた（！）ことにあるとされている。この変換は離陸から約 30 秒後にオーバーフローを引き起こし，装置を停止させてしまった。慣性基準装置の停止はブースターの制御を失わせ，制御の破綻は機体の崩壊を引き起こし，最終的にはそれを検知した自爆装置が作動し，爆発という最悪の結末を迎えることになってしまった。
これらの出来事から学ぶことのできる教訓とは一体何だろうか？ ひとつ言えるのは，一見正常に動いてしまっているシステムから誤差の問題を探し出すことは難しいということだ。ある程度の失敗を積み重ねれば，プログラムを書いている間にも誤差のことが頭をよぎるようになるかもしれない。そのようなときに，「問題が起きてから修正すればいいや」ではなく，作業を一旦停止させてでも，誤差のことを考えてみる態度が必要かもしれない。その変数の値域はどの程度だろうか？ 演算順序は適切なものだろうか？ 危険な除算を行ってしまってはいないだろうか？ たとえそのプログラムが人命を奪うことや血税を無に帰すようなことが無いとしても，敢えて踏みとどまる慎重さを備えていて欲しいと思う。