ゲームプログラマが語る。宇宙に意識が生まれる仕組みと、バグテスト 2011-07-05 13:38

降り注ぐ紫外線と暑さに思考力がやられっぱなしではありますが、今年の梅雨はもう明けてしまったのでしょうかね。湿気も雨も苦手ではありますが、こうも早々に退散されるとそれはそれで少し寂しい。自分がまさかの天候プチＭだったなんて知りたくなかったTeamDyquemで御座います。 皆様こんにちは。

日本一、夏が似合わない男と言われ続けて幾星霜。この悪意に満ちた夏の日差しには本当に毎年辟易で御座います。完全に意識がありますねこの季節には。いじわる婆さんも裸足で逃げ出す事でしょう。

「いじわる婆さん」を知らないというジェネギャな方々は、
お父さんにでも聞けばいいさ！


そうそう、アレですよ。意識……と言えば。

我思う故に我在りとか言いますけれど、「我思う」とは何でしょう。
脳髄という有機組織も突き詰めてみれば、コンピューターと同じ様に単なるデバイスの一つに過ぎないわけですから、代わりに、例えば本当にコンピューター内の情報処理として素粒子レベルの相互情報交換をエミュレート演算処理する事が実現出来れば、きっとそこにも所謂「魂」と呼ばれるものは芽生えると確信しています。自我や魂というものは結局のところ、厳密に定められた物理法則の上に生じる副産物であり、であればこそ意志は時空を超えて存在出来る様になり、そう遠くない未来では古くなった肉体という媒体を捨て、自我をコンピューター内に引っ越しさせるというエントヴァース的なライフスタイルが実現している事でありましょう。
その世界における「死」とは純粋な「母体データベースへの帰還」と同義であり、「出産」は「素体再構築」という事になるでしょう。新しい肉体に再生された魂は、前世に処理されたままの素粒子データベースを継承していますから、必然的に記憶も継続していく事になり、あんな事やこんな事等忘れたい程の恥ずかしい失敗談セットを持ったまま生まれ変わるという、ドＭにはたまらない世界となっております。

はい。引かないソコ。
調子に乗って哲学の森に迷い込み、科学を履き違えている場合じゃあ明らかにありませんでした。
申し訳ありませんでした。あと、Ｍじゃありません。




上記の例は極端でありますが、テクノロジーがどんなに進歩しようとも今はまだ結局のところそれを制御しているのは人間であり、であればやはり最大の敵はヒューマンエラーと言えるでしょう。
プログラミングにおけるそれはつまり「バグ」という事であり、プログラマに求められる重要なスキルとしてバグを作らない事、発生してしまったバグの原因を迅速に突き止めるという事の二点が非常に重要になってまいります。

バグと向き合う、バグを生まない、
バグと上手に付き合っていくための話題といたしまして今回は第二弾。

関連エントリといたしまして、
「ゲームプログラマが語る。バグを生まない仕込みと、バルスの例外処理」

上記エントリにおきましては、「Assert」という仕組みの基礎につきまして展開させて頂きました。今回は更にもう一歩、バグに対して歩みを進めてみたいと思います。



簡易リグレッション・テストのススメ

リグレッション・テスト(Regression test)とは一般に、「回帰試験」等の様に扱われる、極めてシステマチック且つ無機質な総当たりテストの様なもので、要するに作った処理の全因果関係を総当たりに実行しテストしてみようという機構です。
但し、その優位性は大きなものですが、実行コストも高く気軽に導入出来る仕組みではありません。よりまして、ここではTeamDyquemが勝手に採用している簡易的な導入例について取り上げてみたいと思います。

例えば、あるアプリが内包する全てのクラスに関してテストを施すという形は採りません。使用頻度の高い汎用的な性質を持つクラスから仕組みを割り当てていく形といたしましょう。ここではまず、算術クラスを例にあげてみます。

対象クラスは、ベクトルを扱う CVector とでもしましょう。

サンプル的な例としまして、以前のエントリー
「iPhoneアプリ作者より、ゲーム制作初心者の方へ小ネタ「２Ｄベクトル」」
も合わせてご覧頂けましたらと思います。

上記の様な算術系クラスによくある不具合と致しまして、浮動小数点のメンバ変数がNaN化してしまう、というシナリオが挙げられます。
NaNとは「Not a Number」の略であり、不正な演算結果として特別に定義された数値です。浮動小数点フォーマットには他にも無限大等を扱う特殊な定数が存在しますが、何れのケースにおきましても、この値が出現した段階でアプリの進行が止まるという事はなく、NaNという値を抱えたイリーガルな状態のまま処理が進行する事が通例です。

NaNとの演算結果は常にNaNであり、例えば

• 1 + NaN = NaN


• 10 * NaN = NaN

この様に、その構造内に一度でもNaNが現れると、以後の計算結果を次々に汚染していく事になるのです。

この手合は、経験上相当やっかいな類のバグと言えるでしょう。アプリの実行が即座に停止する様な事はありませんから、この増殖するNaNを伴って挙動に影響を与え始めます。市販ゲーム等において３Ｄモデルキャラクターの姿勢が奇っ怪な事になってしまうバグを見かけますが、これの原因として階層関節計算の演算仮定にて算術演算クラスの持つ潜在バグにより、関節姿勢が部分的にNaN化しているというシナリオは容疑者として有力でありましょう。



実装

具体的には、上記例のCVector2等における、全ての代入系メソッドにて(const以外の全てのメソッド)、isnanによるNaNチェックAssertを仕込みます。

この上で、static CVector2::RegressionTest() 的なメソッドを用意。

void CVector2::RegressionTest()
{
	CVector2 i0( 12.3f, 45.6f );
	CVector2 i1( 78.9f, 123.4f );
	i0.Distance( i1 );
	i0.Normal();
	i0.DotProduct( i1 );
	i0.CrossProduct( i1 );
}

この様に、Assertを仕込んだ内包するメソッドを全て実行するテストメソッドとして機能させ、これを起動時に毎回、メインの初期化処理から必ず実行させる様にします。

これにより例えば、何かのバグを修正した際にそれまで潜在的に眠っていたNaN化バグ等が呼び覚まされてしまったとしても、その初回の実行にてNaN化の瞬間を捕捉する事が出来、それに気がつかずに開発が進み傷を深めて行く事を防止します。

こういった機構を、よく使うクラスには出来る限り仕込んで置く事で、そのシステムの防衛力強化に貢献していく事になるでしょう。例によって、条件コンパイルによるリリース時コストフリーとする事が可能なので、最初は面倒かもしれませんが、積極的に採用する事をお勧めします。


デバッグとは本来やっかいなものではありますが、タイミング依存系のメモリ破壊系バグ等を追っていると不思議な高揚感に苛まれる事もありますよね。業務が切羽詰まっている等でなければ、実は最高にエキサイティングな思考パズルでもありますよね。

はい。強がりＤＥＡＴＨ！暑いＹＯ！



早く冬が来るといいなと願う。TeamDyquemでした。