テストプレイ、これだけはやっておけリスト
選択肢を選んでシナリオが分岐するオーソドックスなノベルゲームを想定していますが、それ以外のゲームにも応用はできるんじゃないかな
予防線
ゲームを作ったはいいものの、テストプレイって何をしたらいいの…？という方に向けて書いています。
やらないよりはやりすぎるくらいでいい、という考え方のもと書かれています。
いやここまでしなくていいでしょ、と判断ができる方は既にテストプレイのやり方がわかっている方です、自分のやるべきテストをしてください。
途中、テストというよりデザインとかも含めた話になってしまっているけどこれは私の構成力が足りないせいだよ
はじめに
あなたがオリジナリティを出せば出すほどテスト箇所は増えます。
選択肢の数を増やせば増やすほどテストパターンは指数関数的に増えていきます。
画面遷移系
画面の例
タイトル画面
メインストーリー
セーブ画面
ロード画面
コンフィグ画面
CGモード画面
回想モード画面
バッジ取得画面
クレジット画面
思いつく限り挙げてみたけど他にも画面を作っているならそれら全て
極論を言えば同じ背景の上に同じキャラが並んでいようと「あはははは」というセリフが表示された画面と「うふふふふ」というセリフが表示された画面は全くの別物だと思ってください。
それらの全ての画面に
アクセス可能な全てのルートから
想定したとおりにアクセスできる
そしてもとの画面に戻ってくることができる
（一方通行の場合は、「戻ってくることができない」、そしてそのことがプレイヤーにも直感的に理解できる）
少なくとも上記の四点＋一点は確認してください。
例：セーブ・ロード画面）
タイトル画面からの遷移
メインストーリーからの遷移
他、メニューボタン（右下の歯車ボタン）を表示しているなら、メニューボタンが表示されるすべての画面からの遷移
他、システムボタン（メッセージ枠と一緒に表示されるセーブ・ロード等のボタン）を表示している場合は、システムボタンが表示されるすべての画面からの遷移
回想モードがあるなら、回想モード中でもセーブ・ロード画面に遷移できる／できないのは仕様どおりか
回想モード中はセーブいらないよ派・できてもいいよ派などなど宗旨に応じて想定したとおりの動きになっていることを確認してください。
分岐系
ここで言う分岐は「プレイヤーが選択肢を選ぶ」ことを指します。
全ての分岐を通過する全てのパターンを網羅して検証しましょう。
二択の選択肢が三回発生するなら2x2x2=8パターンです。
入力系
名前変換とかコンフィグ画面での音量調整とか
プレイヤーの入力した値を変数に格納してゲームに反映させる系
の処理です。
ここで知っておいてほしいのは、プレイヤーはあなたが想像もつかないことを平気でやってのけるということです。
なので、主人公の名前入力画面で百文字を超える名前を入力してきますし、あるいは何も入力しないで決定ボタンを押します。
さらに絵文字やあなたが苦心して設定したフォントでは表示できない文字を何の悪意もなく入力します。
文字入力
まあ絵文字とか環境依存文字は対策するコストと効果が見合っていないので今回は無視しましょう、相手が悪すぎる。
入力されてはまずいデータは絶対に入力できないようにする。
入力可能なデータは実際に入力して検証する。
これだけでもやらないよりはだいぶましです。
入力可能なデータの例、名前入力の場合
最少文字数
最大文字数
空白
全角文字
半角文字（アルファベット、数字、記号）
特に最大文字数のテストは絶対にやっておきましょう。
ギリギリページに収まらなくて変なタイミングで改ページが発生することがあります。
変数操作
コンフィグ画面での音量操作
変数によるシナリオの分岐
など、プレイヤーの操作によって変化する変数の値に応じて処理を行うものです。
これも基本は入力系のテストパターンと考え方は同じです。
（数値の場合）最大値
（数値の場合）最小値
分岐が発生する場合、その境界となる値
入力されてはまずい値がある場合、その値が絶対に入力できないこと
これくらいは確認しておきましょう。
境界となる値の例
変数f.hensuが3以上の場合はシナリオAに、3未満の場合はシナリオBに分岐する場合なら、f.hensuが3の場合と2の場合のテストが必要です。
入力されてはまずい値を入力できないようにする
たとえば、ランダムな値を変数に格納して後続の処理を行う場合
ランダム値の値によって不具合が出る、など
不具合が出る値をランダム値の範囲に含めないなど工夫が必要
もし不都合な値が入力されてしまっても、不具合が出ないよう辻褄を合わせる
辻褄を合わせたことで別のエラーが出ることもなくはない
例：シミュレーション系ゲーム）
プレイヤーキャラクター
HP=20
敵の攻撃（1〜50のランダム値）
プレイヤーキャラクターのHPに25のダメージ
敵の攻撃後のプレイヤーキャラクターのHP=-5
HPがマイナスの値となることはゲームの仕様上正しいのか？
マイナスの値を有効に活用できるなら、ありだと思います。
そうでないのなら、HPが0以下になる場合一律で現在のHPは「0」とした方がプレイヤー（中の人の方ね）の混乱を招かない
例：コンフィグ画面）
BGMの音量設定
10〜100までの10段階に変化させるボタンと、ミュート（音量0）ボタンがある
ミュートボタンを押した場合、音量は0になる
音量0の場合、音量の段階表示も連動して変化しているか
もう一度ミュートボタンを押した場合はどうなるのか
何もしない。ミュートボタンには音量を0にする機能のみを持たせる
音量0の場合に再度ミュートボタンを押した場合は、音量を復元させる
その場合、ミュートする前の音量をどこに保持しておくのか
ティラノ固有系
ティラノ固有のバグ 仕様の話
テストはした、それからどうする？
テストプレイ中にエラーが出た！
エラーがでなくなるまで修正してください
エラーは出ていないけど、ゲームが途中で止まる…
それをエラーといいます。修正しましょう
エラーはない、最後まで遊べる。でも特定の操作をするとゲームが止まる／止まらないけど変な動きをする
それをエラーが残っているといいます。特定の操作をして挙動がおかしくならないよう修正するか、そもそも特定の操作ができないようにしましょう。
エラーもない、最後まで遊べる、変な不具合もない。でもテストプレイをした人が、ゲームの仕様をバグだと勘違いしてる
プレイヤーは「自分が操作した結果、想定したとおりの効果が表れない＝バグ」と思いがちです。
「パンチ」と書いてあるボタンを押して、操作するキャラクターが「キック」をしたら、それがプログラム的には正しい動きであっても「バグ」ではないかと考えます。
ここまで極端な例ではないにしろ、たとえばメインストーリーをプレイ中にコンフィグ画面に行く→「戻る」ボタンを押す→先程まで進めていたメインストーリーではなく、タイトル画面に戻った
プレイヤーの感覚とすれば、「戻る」ボタンを押したときに想定する動きは「コンフィグの直前の画面＝メインストーリーに戻る」ことです。
とすれば、たとえ製作者が意図したとおりの動きであっても、プレイヤー視点では「これはバグではないか？」となります。
プレイヤーに勘違いをさせない、製作者の意図が可能な限りそのまま伝わるゲーム作りを心がけたいですね（自戒）