ゲームデバッグのやり方

こんにちは、さいです。
ゲームのリリースが間近に迫り、ゲームの開発が一通り終了して、バグを洗い出す期間のことを、デバッグ期間と呼びます(テスト期間・QA期間と呼ぶところもあります)。

デバッグ専任のQAエンジニアや、あるいはソフトウェアエンジニア向けのプログラムデバッグの記事はネット上にあるものの、ゲーム開発がはじめての人向けや、プログラマー以外の人向けの記事はなかったので、まとめます。

前提

本記事では、以下の前提で書かれています。

・同人・インディーゲーム開発
・チームのメンバーは2~5人程度
・チームメンバーはデバッグに詳しくない

デバッグとは

ゲームが仕様通りに動くかどうか検証してバグを発見・報告し、正しい挙動になるようバグを取り除いて製品の品質を高めていく作業のことを「デバッグ」と言います。

デバッグとはゲームを自由にプレイすることではない

デバッグについてよく勘違いされがちなのは、デバッグとは「自由にプレイしてみて、それの結果出たバグを報告する」ということではないことです。

"あらゆるパターンをプレイ"してみて、それの結果出たバグを報告するということです。

このためデバッグ作業というのは、細かい条件が違うだけの、同じプレイを何度も繰り返す作業になります。めちゃつまらないです。地道です。
でもこれは仕方ないことなのです。覚悟を持ってやっていくことが大切です。

プログラマーだけの仕事ではない

プログラマーはデバッグ期間に限らず、開発中にもよくデバッグをします。よってデバッグはプログラマーだけの仕事だと勘違いされがちですが、そうではありません。

なぜかというと、ゲーム全体をデバッグするには大量の人手が必要であり、プログラマーだけではその人手をカバーすることが難しいからです。

前述の通り、デバッグは細かい条件が違うだけの、同じプレイを何度も繰り返す作業になります。とにかくプレイする項目が多いです。

またプログラマーは、発見したデバッグを修正する作業もあります。これはプログラマーにしかできません。

効率的なチーム内での分業のためにも、デバッグは外部のテスターや、チーム全員で行い、プログラマーはバグの修正に専念するのがオススメです。

なお同人やインディーゲーム開発で、デバッグ知識についてもっとも詳しいのはおそらくプログラマーであるはずです。チームメンバーのデバッグ作業についてはプログラマーが主導し、またサポートしてあげるのが良いと思います。

デバッグ作業の具体的な内容

1. プレイヤー目線で一通りまずゲームを一通りクリアする
まずゲームを通常プレイしてみて、進行不能バグがないことを確認します。
進行不能バグがあると、デバッグできない箇所が発生してデバッグ作業が止まるので、まずはそれを潰します。

2. 実装した内容を一通り確認する

サウンド、セリフ、アニメーション、イラスト、スクリプト etc.. ゲームに組み込んだアセットを一通りゲーム上で確認します。アセットの製作者が、実際にゲーム上でアセットを確認の担当をするのが良いでしょう。

これによって、アセットの組み込み忘れや、特定のアセット再生時のバグを一通り潰します。

3. パターンを網羅する
例えば合成が存在するなら、「すべてのアイテム×アイテムで合成を実行する」「すべてのキャラクターにすべてのアイテムを使用する」などをすべてのパターン試していきます。

どのようなパターンを網羅すべきか、非プログラマーにはイメージが付きづらいので、プログラマーが主導して、どのようなパターンを網羅すべきか、内容を決めると良いと思います。

4. 負荷テスト
ゲームを72時間起動しつづける、アイテムを可能な限り最大獲得してみる、といったことを行い、ゲームがクラッシュしないことを確認します。

5. モンキーテスト
1~4 までで、同人やインディーゲームに求められるデバッグはできていると思います。それらの修正が一通り終わったら、デバッグ作業者が、思いついたことを手当たり次第に実施しましょう。意図せぬ問題がないかを確認します。

デバッグ期間の最終日などに行うと良いでしょう。

役割

以降の説明のために、デバッグの際には3つの役割があるんだよ〜ってことを解説しておきます。

報告者：ゲームをデバッグし、それを修正する人へ報告する人。
チケット管理する人：報告されたバグを、適切な修正者へ渡す人。
修正者：報告されたバグを修正する人。

チケット管理する人は1人でそれ以外は1人の場合もあれば複数の場合もあります。それぞれが役割を兼務することもあります。

チケット管理ツールを用意する

デバッグを報告する人と、それを修正する人のコミュニケーションを円滑にするためにも、チケット管理ツールを利用することをオススメします。

チケット管理ツールは、JIRAやRedmine、Trelloや Google Spread Sheet など、チームメンバーが使いやすいものを選定しましょう。

チケット管理ツールを導入しないと、報告したバグの修正漏れが発生したり、報告内容の粒度が人によって異なるため、修正作業が困難になったりという事態が発生します。

チケットには以下を書くのがオススメです。

・チケットのステータス
完了／未完了／見送り／仕様通り／重複辺りがあると便利

未完了：チケットの初期状態。報告者が記載
完了：チケットのバグの修正が完了したこと。修正者が記載
見送り：バグではあるが、対応できないので修正しない。修正者が記載
仕様通り：バグではないので修正いない。修正者が記載。
重複：他の人も報告してたので、チケット一本化のため記載。チケット管理者が記載。

・担当者
そのチケットの修正を担当する人は誰か。チケット管理者が記載。

・画面キャプチャ
バグが発生した際のゲーム画面のキャプチャ
文字で書くより何倍もバグの情報がプログラマーに伝わるので、
チケットを起票する際は、画面キャプチャを含めることをオススメします。
(むしろ画面キャプチャを必須にしてもいいくらい)

チケットの報告者が記載します。

・起票日
実は別の修正によって、既にチケットが解決している可能性があります。
起票日があれば、バグが既に直ってたということが証明できるので、起票日を記入しておくと便利です。

チケットの報告者が記載します。

・ゲームのバージョン
これも起票日と同様に、既にチケットが解決していた場合に、そのバージョンのバグが既に直ってたということが証明できます。

チケットの報告者が記載します。

・優先度
あまりにもチケットが多い場合に、どれから修正するかの優先度を書きます。

チケット管理者が記載します。

・バグの内容
バグの内容は以下のフォーマットに沿って書くことを薦めます。

■ シーン名
→ ゲーム中のどのシーンで発生したか
→ 例：アイテム合成画面、第○章の☓☓のイベント

■ 発生手順
→ どのような操作やゲームの遷移で発生したか
→ 例：Aボタン押下後、Bを押してCを押したら発生した
→ 例：○○のイベント後、☓☓に行かずに△△に戻ると発生した

■ 期待する動作
→ 本来どうあるべきかを書きます。
→ 例：エラーが発生しないこと
→ 例：☓☓のキャラは登場しないはずなので登場しないこと
→ 例：○○のイベントが発生すること

■ 現状の動作
→ 今現状どうなっているかを書きます。
→ 例：エラーが発生する
→ 例：☓☓のキャラが登場しないはずなのに登場する
→ 例：○○のイベントが発生しない

チケットの報告者が記載します。

気づいたことはまず報告することが大事

デバッグをする際に、報告したほうが良いのか悪いのか迷うときがあります。一番良くないのは、「これは報告する意味はないだろう」と勝手にジャッジしてしまい、実は重大なバグであることが見過ごされることです。

これはバグなのではと思ったことは積極的に報告しましょう。
それが実はバグでなくとも、報告された側は見送ることや、仕様通りとして修正しないことができます。それは無意味な報告ではなく、意味のある報告なのです。

バグが修正されたことは必ずゲームで確認する

バグを修正したにもかかわらず、誰も修正されたことを確認しないことが往々にしてあります。

このせいで、修正したつもりが実は直ってなかったり、あるいは別のバグを引き起こしている事態になったりします。

バグを修正したあとは、修正を担当したプログラマーでもバグを報告した人でもいいので、必ずバグが修正されたことをゲーム上で確認しましょう。

加えて、プログラマーはエンバグを防ぐため、プログラムの修正後は、影響範囲も確認しましょう。

発生手順はちゃんと書こう

エンジニアがバグの再現方法がわからないため、デバッグ自体の修正より、再現に時間がかかることがよくあります。

単純にコミュニケーションミスであることの方が多いため、発生手順が想像付く場合は、起票者は詳細に書きましょう。エンジニアはバグの内容を見るだけでは、どうしてそのバグが発生したかはわかりません。

エラーメッセージが出た場合も、必ずエラーメッセージをコピペするかキャプチャして貼りましょう。エンジニアにとって原因特定のための極めて貴重な資料です。

テスト終盤は、見送りを検討しよう

エンバグでバグが増えるくらいなら、些細なバグは修正を見送ることも検討しましょう。

FAQ

Q. どこまで細かくデバッグすればいいですか？
A. デバッグ作業とは「ゲームのバグを０にすること」です。文字通り 0 が目標です。

まずは可能な限り細かくデバッグしまくるといいと思います。
おそらく、デバッグが期間内に終わらないことが見えてくると思います。

そのときに、どこを妥協してデバッグしないかを検討して進めるのが良いと思います。

Q. 仕様かバグかわからない
A. 報告します。バグを仕様だとして見逃してしまうのが一番良くないので、バグとしてチケットを起票し、チケット管理者の判断に任せるのが一番良いです。

Q. 要望や改善点は書くべきか
A. 書かないほうがいいです。デバッグ期間はバグを取る期間であり、要望や改善といったことは、デバッグ期間より前にやるべきです。

Q. 他の人が同一チケットを報告しているかもしれない...
A. 気にせず起票しましょう。内容が重複していればチケット管理者が重複している分を区別してチケットをクローズしてくれます。