スタッフBLOG

１０月も折り返して、大阪はずいぶん寒くなりましたね。
夏から一気に秋を通り越して冬物を出そうか悩み中の本日の当番、プログラマーのH.Kです。

こう寒いと外に出る足取りも重くて、部屋から出たくないってことで
引きこもってすることといえば、やっぱりネトゲーだね（ネットゲーム）

部屋にいるにもかかわらず、ネットを介してみんなと繋がれる、
ゲームってなんてすばらしいんだろう！！

そんなわけで最近、とあるネットゲームを始めました。

アクション要素のあるゲームなんですが、アクションなんて久しぶりに
するもんだから、画面の動きに指が追いついていきません...！

いつもゆっくり考えて遊ぶ×シュミレーション、○シミュレーションばかり
プレイしていたもんだから、アクションってこんなに大変なのね、と
しみじみ感じました。

ただ、こうプレイしていくとだんだんデバッグしている感覚になってくるんです。

マップの角に強引に突っ込んで当たり判定を確認したり、
回復ポイント付近で闘い続けると簡単にパワーレベリングできてしまわないか、とか
ついやってみたくなるんです。

まあ、プレイデバッグは開発途中のデバッグのひとつとして挙げられますが
他にもいくつかデバッグを行っています。

その中に開発メンバーでしか行えないデバッグとして、ソースデバッグがあります。

一般的には、ホワイト（ブラック）ボックステストといわれるものですが、
ホワイトボックステストでは、あるプログラムを全て動作させて正常な結果が得られるか
ブラックボックステストでは、あるモジュールに対して入力データを与えることで
正常な出力を返しているかをチェックします。

起こりうる全ての入力データを与えて、全ての出力データをチェックすれば、
ブラックボックステストだけでもデバッグはほぼ満たされるのですが、
ホワイトボックステストをすることにより、潜在的なバグを発見し、
より安心、安全なプログラムに進化することができます。

どこまでのテストを行うかは、プロジェクトの規模や期間にもよりますが
１プログラマーとしては可能な限りバグをなくせるよう、テスト用の
チェックシートやテストケースを用意しておき、いつでもデバッグに入れるよう
準備を心がけています。

今、プレイしているネットゲームはストーリークリア後も楽しめる
とってもボリューミーな内容になってます。（むしろクリア後が本番）
テストケースもすっごい数あったんだろうなあと思わず遠い目をしてしまいました…。