ゲーム開発におけるテストについて

自分はテストコードを書くのが嫌いだし、ほとんどの場合テストコードを書くのは効果に見合わないと考えているので偏見は入っていると思う。そのうえで、ゲーム開発とテストコードについて考えてみる事にする。

テストコードを書かない理由

すでにゲーム業界に来て3年半ほど経つが、テストコードを書いている人は見たことがない。
波動拳がちゃんと出るか確認するテストなんてどうやって書くんだ、と言っている人がいたが、確かに想像しにくい。
ゲーム開発でテストコードを書かないのは開発手法が遅れているわけではなく、いくつか合理的な理由があると思う。思いつく理由を書き出してみよう。

ゲームはマルチメディアである

ゲームはグラフィックやサウンドなど、数値やテキスト以外の要素を多く含んでいる。これらの複雑な情報をテストの予期結果として準備しておくのは現実的ではない。

また、様々なタイプのコントローラによる操作がリアルタイムに行われ、それによって結果が複雑に変動するので、テストケースを作るのは難しい。

所謂MVC的な見方をした場合のModelに対するテストは比較的書きやすいと思うが、Modelの関係性が複雑だったり、ModelとControllerの結合度が高かったりすることも多い。

開発環境が貧弱な場合がある

ハードによっては、品質の保証された高レベルのAPIがそろっていない事がある。低レベルのAPIからテストを書くのは大変。
XBox360iPhoneはほとんどPCなので、開発しやすいと思う。WiiAPIやライブラリが充実している。ソニーのハードに関しては、コメントを自重する。

ゲームプログラムは定型化しにくい

ゲームは色々なジャンルがあり、ジャンルが同じでもタイトル毎にゲームシステムはかなり違う。定型化できないものはテストのノウハウが溜めにくいのではないだろうか。

ゲームプログラムは書き捨てである

テストは保守のときにコードの変更が他に影響を与えないかチェックする役割も大きいと思うが、保守がなければテストの目的が1つ減る事になる。 
ネットゲームはこれには当てはまらないが、昔ながらのゲームタイトルには保守フェーズがない。最近は据え置き型ゲーム機でもネットワーク経由でタイトル固有のアップデートがなされるが、それでも保守作業量は比較的少ない。

ゲームは最後まで仕様が変わる

ゲームは面白くなければならず、作ってみるまで面白いかどうかわからないので、仕様が最後まで決まらない。開発期間中にテストコードを追随させていくコストは、Webや業務系のプログラムよりも大変ではないかと思う。

ゲームプログラマの本音

ユニットテストを書くのは楽しくない。正面切って言うと怒られそうだが、乱暴なのを承知で言ってみる。これは気分の問題だが、気分は生産性に直結するので理由の1つとして挙げるのは至極正当な事だと主張する!!
おそらく、ゲームプログラマはその他のプログラマより嫌いな事をやりたがらない傾向があるんじゃないだろうか。それがいい事か悪い事かは判断が分かれるところだが…。

もっともらしいことを書いてはいるが、結局テストが嫌いというのが一番の理由なんじゃないかという話。

ゲームのテスト方法

ゲームもお金を出して買っていただく物であるからには、当然品質を保証する必要がある。ユニットテストをしない分、どこかで埋め合わせが必要になる。ではどこで品質を上げるのか?
ゲーム開発では主にベータ版(機能全部入りの状態)以降で「デバッグ会社」(テスト会社)にテストをお願いすることが多い。業務システム業界に居た頃は、こういう会社にお願いするやり方は聞いたことがなかった。
デバッグ会社のテスターの厳しさは本物で、例えば、いくつもある広いマップの隅から隅まで探索するとか、メニューをものすごい速度で何百回も開け閉めするとか、255以上1Upするとか、そんな作業を延々と(頼めば24時間体制で)やってくれる。
前にあるタイトルでデバッグ会社からバグ報告があがってきたとき、再現条件に「あるボタンを押してからキャラクターをつかむ操作をすばやく繰り返し行う」とあった。
再現しようとしたが、30分やっても1〜2回しか発生しなかった。後からわかった事だが、その操作が行えるようにキャラクタを上手く配置した上で、連続したフレームでその操作を行わないと発生しないバグなのだ。そのゲームは1フレーム1/60秒だから、相当なコントローラーさばきが必要だった。よくそんなバグ見つけてくれたな、と感心した。
バグレポートが来た瞬間は「ウェ〜」っとなるが、バグだしの時間を減らしてバグつぶしやコーディングに費やせる時間が増えるのだから、有り難い事だ。