自分では見つけられなかった不具合から学んだゲームテストの考え方

Unityで制作しているスマートフォン向けゲーム「おはじきバトル（仮）」を友人に遊んでもらったところ、自分の確認では見つけられなかった不具合が見つかりました。

今回、事前に用意したテスト項目はありません。

細かな操作手順も指定せず、現在できている部分を自由に触ってもらいました。その結果、開発者である自分が無意識に避けていた操作が行われ、必殺技とWave遷移が重なったときの問題を発見できました。

この記事では、自由に遊んでもらう第三者テストでなぜ不具合を見つけられたのか、自分だけで確認すると何を見落としやすいのか、今後どのようにテストしていくかをまとめます。

見つかった不具合

問題が発生したのは、範囲型必殺技を選択したままキャラクターを移動させ、接触ダメージによってWave内の最後の敵を倒したときです。

当時の操作は、次のような流れでした。

1. 範囲型必殺技を選択する
2. キャラクターを引っ張って移動させる
3. 必殺技を発動する前に、移動中の接触で最後の敵を倒す
4. 敵の全滅によって次のWaveへ進む

演出を有効にしている場合、前のWaveで選択した必殺技の処理が残り、次のWaveに出現した敵へダメージを与えてしまいました。

一方、演出を無効にすると、同じ操作でも必殺技は発動せずに次のWaveへ進みました。

演出設定によって結果が変わっていたことから、必殺技のダメージ計算だけではなく、演出の完了を待つ処理とWave遷移の順番にも問題があると分かりました。

この不具合の詳しい原因と修正内容は、前回の記事でまとめています。

Unityで必殺技が次のWaveへ持ち越される不具合を修正した記録

テスト項目を用意せず、自由に触ってもらった

今回は「このボタンを押した後に、この操作をしてください」といったテスト項目を渡していません。

ゲームの基本的な遊び方だけを伝え、あとは好きなように操作してもらいました。

この方法では、特定機能の結果を細かく確認することには向いていません。しかし、開発者が想定していなかった操作や、説明が不足している部分、操作しにくい部分を見つけやすいという利点があります。

今回の不具合も、必殺技だけを確認するテストや、Wave遷移だけを確認するテストでは見つからなかった可能性があります。

「必殺技を選択している途中」と「最後の敵を倒してWaveが切り替わる瞬間」が重なったことで発生しており、二つの機能の境界にある問題だったからです。

自分では想定どおりに操作してしまう

開発者は、ゲームの仕様と内部処理を知っています。

そのため、自分では自由に操作しているつもりでも、無意識に想定した順番で操作しがちです。

範囲型必殺技であれば、わたしは次のように操作していました。

1. 必殺技を選択する
2. キャラクターを移動させる
3. 発動したい位置で画面をタップする
4. 演出と効果を確認する

この流れで確認する限り、必殺技は正常に発動していました。

しかし実際のプレイヤーは、必ずしも機能を一つずつ完了させるとは限りません。必殺技を選んだまま敵を倒したり、移動中に別の場所を触ったり、説明を読む前に操作したりします。

開発者にとっては想定外でも、プレイヤーにとっては自然な操作である場合があります。

今回の経験から、正常な手順だけを繰り返す確認では、ゲーム全体で発生する問題を十分に見つけられないと感じました。

機能単体ではなく、機能の境界で問題が起きる

必殺技だけを確認すると、選択、ゲージ消費、演出、ダメージ処理は正常に動いていました。

Wave遷移だけを確認しても、敵を全滅させた後に次の敵が出現する処理は正常でした。

それでも、二つの機能が同時に動くと不具合が発生しました。

今回重なった主な処理は、次のとおりです。

• キャラクターの移動
• 敵への接触ダメージ
• 最後の敵の撃破
• 敵全滅の判定
• Wave遷移
• 必殺技の待機状態
• 必殺技演出の完了通知
• 必殺技効果の適用

それぞれが単独で正しく動いていても、実行される順番やタイミングが変われば、ゲーム全体として正しく動くとは限りません。

特に演出、一定時間後の処理、コールバックなどを使う場合は、処理が完了する前に場面や対象が変わる可能性を考える必要があります。

演出ON・OFFの両方を確認する必要がある

今回の不具合では、演出を有効にした場合と無効にした場合で結果が異なりました。

演出ONでは、演出の終了を待ってから必殺技効果が適用されます。その待ち時間の間にWaveが切り替わり、次のWaveの敵が対象になっていました。

演出OFFでは、完了処理がすぐに呼ばれるため、異なる順番で処理が進んでいました。

本来、演出設定は見た目だけを変え、ゲーム上の結果には影響しないことが理想です。

そのため修正後は、演出の有無にかかわらず同じ行動処理を通し、完了通知のタイミングだけを変える構成にしました。

今後は、演出を追加した機能について、少なくとも次の両方を確認します。

• 演出ONでも正しい結果になるか
• 演出OFFでも同じ結果になるか

設定によって処理速度が変化する機能は、両方を確認しなければ気づけない問題があると学びました。

自由に触ってもらうテストで確認できること

自由に操作してもらう方法では、不具合だけでなく、さまざまな問題を見つけられます。

想定していなかった操作

開発者が決めた手順に縛られないため、連続入力、途中でのキャンセル、複数機能の同時使用などが自然に行われます。

分かりにくい操作

説明しなければ使われない機能や、押せることに気づかれないボタンがあれば、画面設計や案内を見直すきっかけになります。

プレイヤーが期待する挙動

実装上は仕様どおりでも、操作した人が「なぜこうなるのか分からない」と感じれば、表示やフィードバックが不足している可能性があります。

遊び方の偏り

よく使われるキャラクターや機能、反対に使われない要素を見ることで、ゲームバランスや導線を考える材料になります。

決められた項目を確認するテストとは目的が異なりますが、開発者の想定そのものを見直すために役立つと感じました。

自由なテストだけでは確認しきれない

今回、自由に遊んでもらったことで重要な不具合を発見できました。ただし、この方法だけですべてを確認できるわけではありません。

自由な操作では、毎回同じ機能が使われるとは限らず、確認されない条件も残ります。また、不具合を発見しても、どの操作で発生したのかを正確に再現できない場合があります。

そのため、今後は次の二つを組み合わせる方針です。

自由に遊んでもらう確認

操作方法を細かく指定せず、想定外の使い方、分かりにくさ、遊びにくさを見つけます。

修正後の確認項目

発見した問題について再現手順を整理し、同じ問題が起きないことと、周辺機能が壊れていないことを確認します。

最初から大量のテスト項目を作るのではなく、開発中に見つかった問題や重要な仕様から、必要な確認項目を少しずつ蓄積していきます。

今回の不具合から追加する確認項目

今回の経験をもとに、必殺技とWave遷移について、次の条件を確認していくことにしました。

必殺技の状態

• 必殺技を選択した直後
• キャラクターの移動中
• 発動位置を決める前
• 演出の再生中
• 効果を適用している途中
• 必殺技が完了した後

戦闘状況

• 敵が複数残っている場合
• 最後の敵を通常攻撃で倒した場合
• 最後の敵を必殺技で倒した場合
• 必殺技を発動する前に敵が全滅した場合
• 必殺技の効果中に敵が全滅した場合
• 最終Waveで同じ操作をした場合

設定や中断操作

• 演出ONの場合
• 演出OFFの場合
• 必殺技の待機中にポーズした場合
• リタイアやリトライを行った場合
• 画面を連続してタップした場合

すべての組み合わせを毎回確認するのは難しいため、変更した機能に関係する条件を優先します。

たとえば必殺技の演出処理を変更した場合は、演出ON・OFF、Wave遷移、ポーズを重点的に確認します。

修正後は周辺機能も確認する

不具合を修正するときは、問題が起きた操作だけでなく、同じ処理を利用する周辺機能も確認する必要があります。

今回はWave遷移と必殺技の完了管理を変更したため、次の点も確認しました。

• 通常どおり必殺技を発動できるか
• 必殺技ゲージが一度だけ消費されるか
• 最後の敵を倒してもゲージが返却されないか
• 範囲ダメージが発動時に確定した対象へ適用されるか
• 回復、吹き飛ばし、追加ダメージの途中でWaveが切り替わらないか
• 古いWaveの処理が次のWaveへ影響しないか
• 勝利、敗北、リトライ、リタイア時に効果が残らないか
• 演出ON・OFFで戦闘結果が変わらないか

修正箇所だけを確認すると、別の機能へ影響が出ていても見落とす可能性があります。

変更した処理がどこから使われているかを確認し、関連する動作まで見ることを意識します。

不具合を報告してもらうために必要な情報

自由に遊んでもらう場合、不具合を見つけたときの情報を残しやすくすることも重要です。

今後は、可能な範囲で次の内容を確認する予定です。

• 不具合が起きる直前に何をしていたか
• 使用していたキャラクターと必殺技
• どのWaveで発生したか
• 演出設定がONかOFFか
• 同じ操作で再現するか
• 画面録画やスクリーンショットが残っているか

細かなログをすべて相手に確認してもらうのではなく、開発側で後から調査できる情報をゲーム内に残す方法も検討したいです。

第三者に触ってもらって分かったこと

今回もっとも大きかったのは、自分と他の人ではゲームの触り方が違うと実感できたことです。

開発者は仕様を知っているため、正しい操作へ自然に誘導されます。一方、初めて遊ぶ人は画面から得られる情報だけを頼りに操作します。

その違いによって、次のような開発者の思い込みを見つけられます。

• この順番で操作するはず
• この状態では別の操作をしないはず
• この表示なら意味が伝わるはず
• この待ち時間なら問題にならないはず
• この機能は説明しなくても使えるはず

不具合の発見だけでなく、こうした思い込みを減らせることが、第三者に触ってもらう大きな価値だと感じました。

今後のテスト方針

今後は、開発中の確認を次の流れで進めます。

1. 実装した機能の基本動作を自分で確認する
2. 機能同士が重なる条件を確認する
3. 演出ON・OFFや中断操作を試す
4. 第三者に自由に遊んでもらう
5. 見つかった問題を再現手順として整理する
6. 修正後に周辺機能を含めて再確認する
7. 重要な確認内容を今後のテスト項目として残す

まだ開発中のため、最初から完全なテスト項目を作ることよりも、仕様変更に合わせて更新できる形で残していきたいと考えています。

まとめ

今回の不具合は、用意したテスト項目によって見つかったものではありません。

友人に好きなように遊んでもらい、自分が普段行わない操作が行われたことで発見できました。

自分での確認は、仕様どおりに動くことを効率よく確かめられる一方、無意識に正しい手順を選びやすいという弱点があります。

第三者による自由な操作と、再現手順に基づく確認項目は、どちらか一方を選ぶものではありません。

自由な操作で想定外の問題を見つけ、見つかった問題を確認項目として残し、今後の修正で再発していないかを確認する。この流れを繰り返すことで、少しずつ安心して遊べるゲームにしていきます。