|
== ゲームのデバッグ ==
* [[ゲームプログラミング/デバッグ]]
=== 総論 ===
ゲームにかぎらず、一般にソフトウェアのバグを取り除く修正のことをデバッグといいます。
ゲームのデバッグのためには、まずバグを発見する必要があります。
しかし、すべての潜在的なバグを発見するのは、人員の限りや時間の限りがあり、ほぼ不可能です。
なので、まず製作者は、プレイヤーのよくやる行動をゲームプレイで再現してみて、そして遭遇したバグから直しましょう。
極端な例を挙げると、例えば、もし、普通のプレイヤ－のやらない行動をしてみてバグを見つけて直しても、
たとえば、RPGで、薬草の使用をキャンセルするのを20000回連続で続けると遭遇するバグがあったとして、もし製作者がそのバグを直しても一般プレイヤーは気づきません。
1960年代のような古いコンピュータのデバッグ方法と、現代のデバッグ方法は違います。
つまり、パソコン黎明期の科学計算のデバッグやファミコン黎明期（1980年代）のゲームのバグの探査方法と、現代の廉価or無料のパソコン用ゲームのバグの探査方法は、微妙に違います。
アセンブラなどをいじくる必要のあったテレビゲーム機の黎明期の時代のバグ発見の方法は、現代では、あまり向いていません。
現代のゲームでは、バグ修正は、ネットワーク通信ゲームなら、公開後にもネット経由でアップデート修正することもできます。
また、有料ゲームでも、販売前に体験版などを配布してプレイヤーにテストプレイしてもらう事で、プレイヤーの遭遇しやすそうなバグを探せます。
一方もしゲームでなく、たとえば自動車用の組み込みプログラムや、あるいは工作機械などの組み込みプログラム組み込みなどのバグ探索ならば、バグが人命の死につながりかねないので、たとえば、電源ケーブルや通信ケーブルなどの抜き差しをしたりとか不安定な状態にしてバグを探したりとか、温度をあげたり下げたりとかまでしたりとか、そういうハードウェアとの関連のありそうなバグも様々な方法で徹底的に探します。
しかし、現代のゲーム開発では、そこまでしてバグを探す必要は無いでしょう。
また、こういったハードウェア関連のバグは、ＯＳメーカーやあるいは業務用の組み込み機器メーカーなどが探すべきバグです。
けっしてPC用ゲームメーカーの探すべきバグではないです。
新発売されたばかりの新ハード用の対応ゲームをハードメーカーやＯＳメーカーが制作しているならともかく、既存のパソコン用の無料ゲームや廉価ゲームなどでは、そこまでしてハード関連のバグを探す必要は無いでしょう。
=== 優先順位づけ ===
ともかく、ゲーム産業にかぎらず一般のIT業界でも、発見されたバグは、修正の優先順位にもとづいて格付けをされます。
医学における、どの患者から先に治療すべきかという概念である「トリアージ」という医学用語になぞらえて、IT業界でもバグの修正対応の優先順位（priority）の格付けのことを外国でも「トリアージ」と言います。
このことは、ゲーム作家の側には「トリアージ」などの用語の暗記は不要ですが、どちらかというとプレイヤーのテスト協力者などに考え方を知ってもらう必要があるでしょう。
もし科学者が科学計算ソフトウェアで世界最先端の開発を目指すのなら、（予算が国から与えられる限り）好奇心や興味のおもむくままに研究して、「トリアージ」の概念を無視するのも可能かもしれません。しかし一般のIT産業やゲーム開発では、予算の制約が厳しく、人員や設備の制約も厳しく、そうはいかないので、「トリアージ」的な優先順位づけが必要になります。
ゲーム業界でも当然、このようなバグ修正の緊急性の格付けは行われております。（参考文献: STUDIO SHIN 著『ゲームプランナーの新しい教科書』）<ref>STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、262ページ</ref>
=== すべての組み合わせの検証は無理 ===
たとえばRPGなら、武器や防具といった装備の組み合わせは、
:もし武器（剣や槍や斧や杖や弓など）が合計で100種類、
:頭防具が合計で50種類（カブトや帽子）、
:胴ヨロイや服が合計で50種類、
だとしたら、組み合わせは装備だけでも合計で 100×50×50 ＝ 250000種類 （25万）にもなってします。
つまり、もしすべての組み合わせを検証しようとすると、作業が指数的に増えてしまいます。
しかし、こんなに多くの組み合わせを検証するのは個人では無理ですし、無駄です。
デバッグ検証はせいぜい、武器なら100種類の装備をすべて装備してみて、装備できるキャラクターが装備しても異常が無いかとか、戦闘で実際に攻撃を見て以上が無いかとか、そういうことを確認すればいいのです。
同様に、防具のデバッグ検証もそうです。
これなら、装備の検証作業は、100＋50＋50＝200種類なので、大幅に作業が減ります。
つまり、足し算、加算的に検証すれば、十分です。
実際の市販のRPGなら、さらに装備の数が多くなるでしょう。
また、どのキャラクターが装備するかとか、どこのエリアで装備するかとか、いろいろな組み合わせが実際のプレイにはありますが、もちろん、そんな検証をすべてするのは無理で無駄です。
上記の例ではRPGの装備システムを例にとりましたが、別にRPGやシミュレーションゲームなどのパラメータの多いジャンルのゲームに限らず、
異なるジャンルのたとえばアクションゲームやアドベンチャーゲームなどのゲーム内の各種システムでも同様です。
なのでデバッグは、ゲーム内の各種のアイテムやコマンドなどのデバッグなら、せいぜい、とりあえず、そのアイテムやコマンドなどを選択したり実行しても異常が無いかを1回だけ試せばいいのです。
そもそも、ゲームのシステムは基本的に、プレイヤーごとに異なる多様なプレイスタイルに対応するために多くのアイテムやパラメータやイベントをゲーム内部に持っていて、そういった組み合わせの意外性などをシミュレートして楽しむものです。
なので、組み合わせは膨大になるのが普通なので、全組み合わせの掛け算的な回数の検証は無理です。
テレビゲーム黎明期の1980年代なら、装備アイテムの数などが少なかったので、もしかしたら組み合わせをすべて試すのも可能だったかもしれませんが、しかし現代では、アイテムの数などは膨大に増えており、もう無理です。
このため、現代の複雑化したゲームではver1.00以降の発表後にも、アップデート修正が必要になる可能性が高いです。なので、ver1.00の発表前に事前にアップデート版の配布が可能な環境を整えておきましょう。
さらに、もし有料ゲームのアップデート配布の場合なら、なるべく
:有料版ソフトを買った人'''だけ'''に、'''無償で'''アップデート適用ずみの'''フルパッケージ版'''を配布できるような環境
があるかを事前に環境準備しておく必要があります（「修正パッチだけ無料公開」とかではなく、すでに修正パッチを適用した状態でのフルパッケージ版という意味。消費者が有料で購入しているのだから、修正パッチ適用などの手間を掛けさせない。そもそも、修正パッチを適用するのにソースファイルが必要な場合が普通なので、普通はメーカー側で修正パッチを適用してから配布する）。
個人でそういう配布の環境を構築するのは困難なので、個人の場合には、ネット上のいくつかの企業がソフトウェア公開・販売環境を提供している企業がいくつかあるので、そのサービスを利用すると良いでしょう。
さらに、アップデート版のソフトウェア内部のシステムでは、過去バージョンの有料ゲームから、最新の修正後バージョンへのプレイデータの引継ぎをできるようにする必要があります（たとえばRPGの場合、プレイヤーにレベル1の序盤から再開させるワケにはいかない）。このデータ引継ぎの工夫は、ソフトウェア販売サービス提供の企業では無理なので。
もし、上述のようなアップデート配布が不可能な環境にあるのなら、そのゲームが個人製作のゲームの場合には、無料ゲームソフトにしておきましょう。
ゲームにかぎらず一般に有料ソフトを販売した場合には、開発元のメーカーは「保証期間」または「アフターサービス」のような社会的責任として、発売開始後から数年ていどは無償で不具合対応などのアップデートをすべきという社会的な責任があります。
食料品やティッシュペーパーのような消耗品でないかぎり、ソフトウェアにかぎらず一般の工業製品などでも企業は商品の有料での販売においては、発売開始後から数年は、「保証期間」などとして無償または低価格の不具合対応などの社会的責任が要求されます。
無料のソフトではそこまで保証する義務は無いですが、まあ実務の練習だと思って「保証期間」的なものも頭の片隅に意識しておいたほうが無難でしょう。
=== ソースファイルにモニター（監視）機能を入れる ===
もうひとつのバグ発見の方法として、
一般にゲーム開発では、作者用のソースファイルと、プレイヤー用のファイルを分けるので、
作者用のソースファイルにデバッグ用の機能をいくつか入れておく方法もあります。
ゲーム内のシステム内部の監視のためのデバッグ用メッセージ（「現在のパラメーター herosPower は 134 です。」のようなメッセージ）を表示するモニター的な機能は、こちらソースファイル側で行うとよいでしょう。
なぜなら、プレイヤーが細かいシステムメッセージを見ても退屈ですので。
;まずテストプレイしよう
まず、バグ発見のためには、モニター機能プログラムを書くよりも先に、まず先に実際にゲームを起動してゲームをプレイしてみることです（いわゆる「テスト プレイ」）。テストプレイで挙動のオカシイ部分があったら、そこで、ソースコードで、挙動のおかしい箇所のプログラムの近辺で、変数の内容を表示する機能のあるモニタープログラムを自分で書きます。
;ブレークポイントは後回し
なお、WindowsのVisual Studio には、ブレークポイントという、デバッグ用にコード中に強制停止するポイントを設定する機能があり目的の箇所でコードを停止させ、変数を表示させる機能がありますが、しかしこの機能（ブレークポイント）をいきなり使うのは、ゲーム製作では、あまりオススメできないです。
なぜなら、ゲームが止まってしまうので、実際のプレイ中でのパラメータの変化が不明です（ブレーク時点での変数の値しか、分かりません。）。
ブレークポイントを使う場合は、起動そのものの不可能なバグとか、ゲームが異常停止していまうようなバグの場合などの、テストプレイそのものが困難な重篤なバグの場合にだけにしましょう。
テストプレイが可能なていどのバグなら、なるべく実際にゲームをテストプレイして、モニタープログラムでバグの性質をさぐったほうが早いです。
;モニタープログラムは最小限にするのがコツ
しかし、まだバグの見つかって無い段階で、モニタープログラムを入れるのは、オススメできません。
なぜなら、ソースファイルが見づらくなるからです。
バグが見つかってから、関連しそうな変数を表示するモニタープログラムを書きましょう。
モニタープログラムは最低限にするのがコツです。
そして、バグが修正し終わったら、そのモニタープログラムのコードは、量が多くなってきたら場合は、さっさとソースコードから該当する変数のモニタープログラムをコメントアウトするなどして、非表示にしてしまいましょう。
なんでもかんでもシステム内メッセージを画面に表示したとしても、メッセージを読みきれないので無理です。
また、あまり、ソースファイル独自の機能を追加しすぎると、一般にソースコードじたいが読みづらくなります。
=== デバッグルームなど ===
==== デバッグルームとは ====
ゲーム内でめったに起きないイベントなどのデバッグは、通常のプレイ方法では、めったに遭遇しないために発見が困難になります。
たとえば、ゲーム内でくじ引きがあり、1000分の1で大当たりが出るとしましょう。
通常のプレイでは、このくじ引きを1回だけしか出来ないとしましょう。
このようなイベントのデバッグ検証の場合、「大当たり」にバグがないかは、デバッグ用に、ゲーム作者だけ、くじびきを何百回も続けてチャレンジできるようにしたりとか、あるいは、ゲーム作者だけ、くじ引きの結果を操作できるようにして強制的に「大当たり」が出たりするようにするとか、
そういう作者だけの特殊システムが必要になります。一般プレイヤーには、デバッグルームには入れないように、対策する必要があります。
このような、デバッグ用の作者専用システムのことを、俗にゲーム業界では「デバッグルーム」とか「デバッグモード」とかいいます。
デバッグルームとは「デバッグの部屋」という意味です。作品によっては、実際にゲーム内に「デバッグルーム」というエリア、ステージを用意する場合もあります。
この機能を作者が使うことを「デバッグルームに入る」とか「デバッグモードをオン（ON）にする」いいます。
名前こそ「デバッグルーム」や「デバッグモード」などというものの、しかし、その場所ではバグそのものの退治・修正はしないですし、そもそも、ゲーム起動中にバグ修正は不可能です。
最終的にバグを修正するには、（ゲームをシャットダウンさせてから）ソースコードを開発ツールなどで直す必要があります。
「デバッグルーム」とは、単にゲーム内でバグ探しの作業をしやすいように、プレイヤーキャラクターを強化したり、あるいは敵を弱体化させるなどの環境を調整するだけなのが、デバッグルームです<ref>STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、264ページ</ref>。
背景として、基本的にはプレイヤーキャラクターが強めのほうが、ゲーム内世界をいろいろと探検しやすいのでバグは発見しやすくなります。
なぜならゲームでは、たとえばRPGでゲーム終盤の強敵を倒したときに発生するバグなどは、主人公がゲーム序盤の弱いキャラクターの状態では無理です。一方、ゲーム序盤の弱い敵に主人公が負けるなら、単に油断したり無防備になればいいだけなので、主人公は強いままでもデバッグ可能です。
「大は小を兼ねる」といいますが、ゲーム内では強めのキャラは弱めのキャラを兼ねます。
しかし、その逆は困難です。
なので、たとえ、デバッグ用の機能の名前に「デバッグルーム」などの名前がついていなくても、もし裏技や隠しアイテムなどでプレイヤーを強化するものがあれば、実質的にデバッグモードでしょう。
また、ゲームクリア後に、初回プレイよりも強い状態でニューゲームを出来る機能があれば（いわゆる「強くてニューゲーム」）これも実質的にデバッグ機能して活用できます。ゲーム序盤～前半のイベントに潜むバグなどを探すには、「強くてニューゲーム」のような機能があれば便利でしょう。
プレイヤーによっては、「デバッグ」などのIT用語を嫌がる人もいるので、そういうのに気をつける必要もあります。
また、ゲームのジャンルによって、近未来SFファンタジーやSFアクションなどでは、ゲーム中のシナリオにもIT用語が出てくるので、そういうのと区別するために「裏技」などの言い換えをしたほうがいいかもしれません。
==== デバッグルームの建築 ====
さて、デバッグルームを建築する際は、なるべく、既にそのゲーム内にあるシステムを流用します。なるべく、一般プレイヤーにも公開されている機能を組み合わせてルームを作る必要があります。そうしないと、デバッグルーム独自機能の検証の手間が増えてしまうので、かえって、メンドウになってしまいます。
デバッグルームの中では、普通のプレイヤーが操作できないものを操作できるようにします。たとえば、RPGなら、プレイヤーキャラのレベルをある程度の上昇させたり下げたりとか、主人公の入手している武器や防具ある程度の範囲でを操作したりとかの機能が必要です（けっして、完全に数値をピッタリ調整する必要はないです。最終目的はあくまでバグ発見です。けっして数値をピッタリと調整することは目的ではないです）。
RPGなら、たとえば、強めの武器や防具をいくつかデバッグルーム内においておいたりとか、あるいは、通常プレイでは商店では非売品の武器・防具をデバッグルーム内では有料（ゲーム内の通貨）だが販売しておくとかすれば、万が一、一般プレイヤーがデバッグルーム内に進入してしまっても安全です。
あるいは、デバッグルーム内に、経験値アップや、レベルアップなどのアイテムとかをいくつか置いておくと、レベル上げの手間が減ります。
このようにデバッグルーム内に強化システムを配置しておくと、ゲーム後半のイベントなどの検証も、ラクになります（キャラクターの育成などに掛かる時間などが短くなるので）。
くじ引きの「大当たり」などのイベントをデバッグ検証で容易にしたいなら、デバッグルーム内に、たとえば「幸運のお守り」のような感じのアイテムを置いておいて、それを装備すると、ゲーム内のくじ引きなどの大当たりの確率が100％になるとか50％になるとかの機能をつけておいて、そういうふうなアイテムを作っておけば、くじ引きなどの検証がラクになります。
さて、一般プレイヤーには、デバッグルームには入れないように、対策する必要があります。
作者のファイルにだけ、デバッグルームに入れるアイテム（「デバッグルームの鍵」など）とかを設置するとかして、実装します。一般プレイヤーに配布するゲームデータには、デバッグルームの鍵などを与えないようにします。デバッグルームの場所は、ゲーム内の中盤や後半に隠して立てておくと安全です。
あるいは隠すのではなく正式な公開機能として、ゲームクリアしたプレイヤーに、デバッグルームの一部を開放するなどする方法もあります。こうすると、あまり気にやまなくても済みます。
または、ゲーム開始のオープニング画面中に、画面には表示されてないが実はパスワード入力を受け付けしている状態を起動させておいて、パスワードが正しければデバッグモードがオンになった状態でゲームを開始できるようにするとか、そういう方法もあります。パスワードの受付をしているのを、プレイヤーには見せないようにします。
アクションゲームなど、あまりRPGのようなアイテム配布をしづらいようなシステムの場合は、この裏技のような方法のほうが便利でしょう。
裏技システムの場合、もし一般のプレイヤーがたまたまデバッグルーム用パスワードと同じキー配列を入力しないように、パスワードは十分に複雑にしておくとかの工夫が必要です。万が一、パスワードを運よく一般プレイヤーが知らずに偶然に入力してしまってゲームを開始した場合でも、プレイヤーがゲームプレイを楽しめるように、「これは裏技モードです」とかとでも冒頭で紹介しておいて、プレイヤーキャラクターの強さを（通常モードと比べて）やや強めに変更するくらいの設定にしときましょう。
1980年代のファミコンなどの市販ゲームで、こういう「裏技」（うらわざ）がよくあります。おそらく、そのソフト開発者がデバッグ用に残した機能だったのでしょう。
=== 個別チェックと通しプレイ ===
==== まずは個別チェック ====
===== 総論 =====
ゲームで新しい機能を追加した場合、たとえばデバッグモードなどの機能を使ったりしてでもいいので、
まず、その追加したばかりの機能が実際に動作しているかを、（デバッグモードでいいので）プログラマー自体がチェックします。
もし集団作業なら、これは、プログラマー本人が、まず率先して、ある程度は自分たちでデバッグモードによるチェックをやる必要があるでしょう。（いちいち他の部署に作業を回すと、かえって時間が掛かってしまう。）
また、集団作業でなく個人製作でも、まずデバッグモードでも何でもいいので、追加したばかりの機能をチェックします。
この個別チェックでは、けっしてバランス調整などをする必要は無いです。
個別チェックと、バランス調整とは、目的が異なります。
個別チェックでは、単に、デバッグモードなどで、その項目だけをチェックします。
もしデバッグモードの機能が無いゲームの場合や、製品に近くデバッグモード不搭載のバージョンの場合には、デバッガーは、なるべくデバッグモード利用時に近いプレイ方法で、個別にチェックしていきます。
===== 各論 =====
;全装備品の装備、全アイテムの使用など
たとえば、RPGの装備品のシステムが正常に動作しているかどうかを確認するためなら、とりあえず、すべての装備品をいったん装備および装備解除してみる、というような作業をします。
これは、一般プレイヤーがゲームを楽しむ方法とは、異なります。
ですが、デバッガーは、こうして確認をしていきます。
たとえばRPGなら他にも、すべての道具をとりあえず最低1回ずつは使ってみるとか、
到達可能なマップチップには、すべてのマップチップの上を歩いてみるとか、そういう事をします。
とはいえ、これらは普通のゲームプレイでも、プレイヤーによっては、アイテム効果確認や隠しエリア探索などのために、よくやる事でもありますので、これはまだ楽しいほうです。
;通行止めの確認
さらに商業ゲームでは、たとえば、すべての壁（かべ）の通行不能の処理が、本当に壁として行き止まりになっているかとか、通行止めであるかとか、そういう行き止まりチェックみたいな事も、します。
ツライ事の一つは、この行き止まりチェックでしょう。
なのでフリーゲームだと、この行き止まりチェックはよく、省略されます。なのでフリーゲームでは、ver1.00公開直後には、よくあるバグで、本来なら行き止まりのハズなのに通行可能になる壁のようなモノの存在するバグが、よくあります。
;選択肢の総確認
他にもデバッガーのすべき事は、たとえば、ゲーム中にもし、なんらかの選択肢の入力がある場合、選択肢すべての（当面の）結果を確認します。
たとえば、もしRPGのストーリー中の重要なシーンでのコマンド選択肢で、善行と悪事との選択肢があった場合、2つのセーブデータを用意して、両方の選択肢とも試してみて、とりあえず数分は動作しているかを確認します。
このように、とりあえず、どちらの選択肢を選んでも、当面の数分はバグの無く、正常に動作しているかを、（デバッグモードや、セーブデータの複数用意などで）なんらかの方法で確認します。
なお、一般ユーザーのプレイ傾向としては、もしゲーム中に選択肢で、善行と悪事の選択肢があったら、なんだかんだで普通のプレイヤ－は善行を選びます。
なので、もし普通のプレイヤーに任せていては、いつまで経ってもゲーム中では、ゲーム中の悪事の確認は、なかなか、できないです。
このためデバッガーは、意識的に、自分のプレイスタイルとは異なる悪事の選択肢でも、デバッグして動作確認する必要があります。
;全滅テスト、自殺テスト
また、一般プレイヤーは、上手にプレイしたがるので、わざとゲームオーバーする自殺プレイを嫌がります。
なので、デバッガーは、ところどころで、自殺プレイをします。ゲームオーバーや全滅などのイベントが正常動作するかを、ときどき確認します。
難易度の高いゲームなら、意図的に自殺プレイしなくてもよく全滅しますが、たとい難易度の低いゲームでも、わざと自殺プレイをします。
特にボス戦などは、ソースコードでは特殊なフラグ処理が入りこんでいるのでバグの混入している可能性も高く、そのため、たとえ弱いボスであっても、ワザと敗北したりする自殺プレイが、デバッガーのすべき事です。
;カウンターストップのチェック
たとえば、RPGのゲームの上限レベルが「99」の場合、きちんとレベル99で止まるかを、とりあえずデバッグモードでチェックします。
こうしたデバッグを短時間で出来る用途のために、やたらと経験値の高い敵でも一体、ゲームのソースファイルにでも混ぜて、作っておきましょう。
レベル98からレベル上げをしてみたりとか、レベル97から一気に2レベル上がったらどうなるかとか、いろいろと確認しましょう。
また、所持金や道具の個数なども同様に、上限できちんと止まることをデバッグモードなどを活用して確認します。
さて、とにかく上述のように個別デバッグをして、まずはデバッグモード（またはデバッグモードに近いプレイスタイル）で正常動作するようになるまで、まずプログラムを修正していきます。
もちろん、デバッグモードで正常動作したからといって、けっして、必ずしも通常起動のモードでも正常とは、かぎりません。
ですが、もしデバッグモードですら異常動作をするなら、これはもう通常起動時にも異常動作をするだろう事は、ほぼ確実です。
なので、まずデバッグモードで正常動作するようになるまで、まずプログラムを修正していきます。
このように、追加した幾つもの機能を、それぞれデバッグモードで即座にチェックしていきます。
また、もし機能を新たに追加したい場合には、まず前の機能のデバッグモードでの正常動作を確認し終えてからにしましょう。なぜなら、こうしないと、集中力が落ちるし、また、もしバグが発生した場合の修正が、とても複雑になってしまいます。
IT業界の格言ですが、「デバッグされてないコードは、（資産ではなく）負債である」という格言があります。
なので、コードを書くことよりも、自分で書いたコードをひとつずつデバッグすることのほうが重要です。
ともかく、このように、機能をひとつずつ、個別的にチェックしていきます。
;ボタン連打や、壁に何度も衝突など
ボタンを1回だけなら押しても異常は無くても、ボタンを何度か押すと異常のあるバグも、ときどきあります<ref>STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、257ページ</ref>。
とはいえ、ゲーム中の全てのシーンで何度もボタンを押していたら、ゲームが進行せずにデバッグも進行しないので、たとえばゲーム中で使用頻度の多いメニュー画面などでボタン連打するとか、あるいはイベント進行などで「ここが、もしかしたらバグが潜んでいる可能性がありそうだな」とか思ったところだけボタン連打するとか、工夫しましょう。
同様に、通行止めの壁などの場所なども、ときどき何度も壁に衝突したりしましょう。
わざと弱めのボス敵などに負ける全滅テストも、ときどき、2回以上はワザと全滅してみましょう。
;壁衝突やボタン連打などのチェック中のデータは、なるべく混ぜない。
セーブ機能のあるRPGやシミュレーションや長いアクションゲームなどで、上述のようなボタン連打や壁衝突などのプレイを確認するとき、原則的にあまりセーブしないようにするほうが効率的でしょう。
なぜなら、もしそのゲームのあとのプレイで何らかのバグが発見された場合、原因として、ボタン連打などの影響を考慮する手間が増えてしまうからです。
1つのセーブデータで、複数の異常プレイの実験をしてしまうと、たといバグが発見できても、その原因が果たしてボタン連打の処理ミスなのか、それとも悪事のフラグミスなのか、ミスの箇所が不明になってしまいます。
なので、まずひとつのセーブデータでは１つの異常プレイだけにします。
もし、複数の異常プレイを一人のデバッガーがする場合には、セーブデータを別々に分ける必要があります。
同様に、ボタン連打にかぎらず、もし何らかのバグが発見された場合でも、たとい報告のためにセーブする必要があっても、そのデータはまだバグを発現していない未発症データとは分けて別データとしてセーブしましょう。
==== 次に、通しプレイ ====
さて、こうして、いくつか機能をデバッグモードで個別チェックしていき追加していくのが完了したら、今度は次に、ゲームを最初から始めて、エンディングまでプレイをします。
このように、ゲームをオープニングからエンディングまでプレイすることを、「通しプレイ」（とおしプレイ）といいます。
通しプレイは時間にかぎりがあるので、たとえば新バージョン公開のたびに直前に行うとか、そういうふうに工夫します。（もし機能の追加のたびに通しプレイすると、時間が不足する。）
さて、商業作品の場合、通しプレイでは、けっして上手にプレイするのが目的ではないのです。
とりあえず、色々なことをそのゲーム中でしてみて、それでもバグが起きないことを確認するためのモノです。
;1回目の通しプレイ
とはいえ、最初の1回目の通しプレイでは、まず普通に、自分のやりたい自分本来のプレイスタイルでプレイするのもイイでしょう。（ｍそいゲームのクリア所要時間が長すぎる場合や、クリア困難な難易度の場合には、とりあえず数時間ほどのプレイで区切るべきだろう。）
なぜなら、世間の他人から見れば、アナタのプレイスタイルも、他人にとっては「色々なプレイスタイル」のひとつですから。
また、そのゲームの中でどういった行動が可能なのかを知るためにも、とりあえず最初の1回は、普通にプレイする必要があります。
;2回目以降の通しプレイ：パターンA
さて、とりあえずの1回目の通しプレイが終わったら、2回目以降の通しプレイでは、プレイスタイルを変えます。
けっして、通しプレイの目的は、「エンディングに最短時間で到達する」（×）とかではないし、「上手にプレイする」（×）とかでもないのです。
自分のプレイスタイルではなく、自分以外のスタイルで、他の多くのプレイヤーがやりそうなプレイをします。
とはいえ、プレイスタイルを変えてみるのも、（自分の性格にもよりますが）そんなにツマラナクは無く、1回目では見過ごしていたイベントを発見できたりとかも出来ますので、さまざまなプレイスタイルを自身で再現してみることで今後の自分のゲームとの付き合い方の勉強にもなります。（というか、コレがツマラナイと感じる人は、そもそも性格的にデバッガーに、向いてないので、別の職種を頼むべきかと。）
また、1回目と同じプレイスタイルでプレイしても、どうせ1回目で見たことある現象と同じ現象しか見られないので、むしろ2回目以降はプレイスタイルを変えたほうが面白くなるでしょう。
;2回目以降の通しプレイ：パターンB
普通のプレイヤーは、ある程度は上手にプレイしようと目指します。
また、ゲーム中の選択肢で、善行と悪事のどちらかを選ばせる選択肢がある場合、たいていの一般人は善行を選びます。
なので、彼ら一般人と同じプレイスタイルでは、たとえばもし、ゲーム序盤のとても弱い敵に負けた際に発生するバグがあったとしても、そういうのは発見されづらくなります。
なので、ときどき意図的にヘタな通しプレイをします。
事前のデバッグモードなどでの個別チェックでも、このような確認はしているハズですが、確認モレがあったり、あるいは通しプレイ時にしか発生しないバグなどもありうるので、念のため通しプレイでも、意図的に下手なプレイをします。
;壁衝突やボタン連打などのチェック中のデータは、混ぜない。
通しプレイでも、ときどき壁衝突のテストや、ボタン連打などの異常プレイのテストは必要ですが、しかしそれらのセーブデータは、なるべく、（自分以外の）通常プレイヤーの行動再現のセーブデータには、混ぜないようにしましょう。
また、さまざまな選択肢を選んでプレイしているセーブデータにも、ボタン連打プレイなどのプレイデータは混ぜないようにしましょう。
もし今後、何らかのバグが発見された場合に、ひとつのセーブデータにて壁衝突・ボタン連打プレイ・通常プレイヤー再現プレイ・選択肢チェックのデータをセーブしてしまうと、せっかくバグ発見できても、想定されるバグ原因としてボタン連打などの影響の可能性などが増えてしまうからです。
ただし、通しプレイの場合、さまざまなプレイスタイルの再現中に、ゲーム中の選択肢などで、やや変わった選択肢をする場合もあるし、ややゲームの苦手なプレイヤーの行動を再現する場合もあるので、（つまり、選択肢プレイと苦手プレイは）そういうのまではセーブデータを分ける必要はないでしょう。（もしそこまでセーブデータを分けると、セーブデータ数が膨大になり、管理しづらくなる。）
よほどの異常プレイでないかぎり、セーブデータを分ける必要は無いでしょう。
しかし、かなり異常なプレイを意図的にする場合には、セーブデータを分けるか、あるいはセーブしないようするなど、工夫しましょう。
バグを発見したときに、原因の特定が容易になるように、セーブデータを分類して管理しましょう。
=== 集団制作におけるソフトでのバグ報告の書式 ===
ゲーム業界に限らず、IT業界ではバグ報告の書式がおおむね、下記のように決まっています。次の情報がバグ報告には必要です。
:・バグの発生方法 :
:・発生の頻度 :
:・バグ発生したソフトのバージョン :
:・バグの症状 :
と言った情報が最低限は必要であり、その報告が『バグ報告』である事とともに伝えます。
個人作業では不要ですが、集団作業の際などに、ご参考に。
ゲーム業界に限らず、リナックスなどのオープンソースのソフトウェアなどのバグ報告サイトでも、こういったバグ管理手法をしています。（というか、そういった海外プログラマーのバグ管理手法を、日本プログラマーが真似たと思われる。）
ゲーム業界でも同様に、こういったバグ管理手法です<ref>STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、258ページ</ref>。
つまり、会社などで業務としてバグ報告をする場合には、ダメな報告の例としては「ゲームが壊れた！ どうにかして！」とか「ゲームが止まった！ どうにかして！」みたいなのは、論外という事です<ref>STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、258ページ</ref>。
下請け仕事でデバッグをする場合、自分は客ではないので、「ゲームが壊れた！ どうにかして！」みたいな報告は論外です。
とはいえ報告の時点では、まだバグの原因が不明ですので、けっして、完全にピンポイントな原因特定をした報告不可能です。
バグ報告の手本として一例を書くと、たとえば
:例
【バグ報告】 ウッキークエスト ver0.87 。ハジメガルド武器屋オヤジの会話時のキャラチップ表示ズレ
・[バグの症状] ゲーム中盤でのハジメガルド武器屋の親父の会話時のキャラチップ位置表示ズレです。
・[発生の頻度] 当の武器屋オヤジに話しかけるたび、毎回バグ発生です。3回、確認しました。
・[添付ファイルの内容] メール添付画像は、バグ発生時のオヤジ画像チップが店の壁に乗ってしまってるナゾ画像です。
・[バグの発生方法] ゲーム序盤の第1章から行ける街・ハジメガルドの武器屋の親父に、
ゲーム中盤の第三章になってからハジメガルドに行き、
自軍パーティ構成が戦士・戦士・僧侶の3人パーティの
味方平均レベル28くらいの状態で武器屋親父に話しかけると、
なぜか親父が話しかけるたびに、
バグによって親父のキャラチップの表示位置が1マスぶん右にズレます。
・[参考情報]
私の今回のテストプレイでは、まだ「伝説の剣」は入手していません。
「伝説の盾」は、このバグ発生の時点で入手しています。
伝説の盾を守っている中ボス・暗黒大王も撃破してあります。
今回のプレイでは、装備はまだハガネ装備です。ミスリル装備は、していない状態です。
ミスリル鉱山の街をすでに帝国軍から解放しましたが、プレイヤー所持金を節約するためハガネ装備のままです。
ハガネ装備のままレベル28まで上げて暗黒大王を倒しています。
みたいな感じでしょうか。
もし、バグ発生時の画面をキャプチャ（「スクリーンショット」ともいう）した画像があると、伝わりやすいです。
ウィンドウズでは、ショートカット・キー <nowiki>[Fn] + [Alt] + [Prt Sc] </nowiki> で選択中のアプリウィンドウごとにキャプチャでき、それをWindows アクセサリ『ペイント』のキャンバスに貼り付けしてセーブ保存すれば、キャプチャ画像が作成できます。
なので、バグ発生中のソフトのキャプチャ画像を作りましょう。
参考情報などで、とりあえずバランス調整に関係ありそうなテストプレイ時の行動も書いておくと、プログラマー側はデバッグついでにバランス調整のための資料にも出来るので、一石二鳥です。また、ひょっとしたら、そのバランス関連の参考情報で書かれたテストプレイの行動も、バグ発生条件に関係しているかもしれない場合もあります。
（ただし、商業作品の場合は、バランス調整はデバッグよりも前のほうに終わらせておく必要がある。）
しかし、あくまでバランス調整に関するテストプレイ報告については、後回しの付属的な情報です。メインに報告すべきは、バグに関係ありそうな情報から優先的に報告です。バランス報告については、せいぜい5行くらいまでで充分でしょう。
また、「バランスがイイ」だの「バランス悪い」だのといった良否の判断は、これはバランス調整者側の判断することでありますので、デバッガーの判断することではないです。
デバッグの ついでのバランス報告では単に「レベルは○○くらいです」「装備は○○くらいです」とか「中ボスの△△戦では負けて1回全滅しました」とかプレイ事実だけを報告するべきであり、良否の判断はプレイヤー側ではしないのがポイントです。
このように、バグの発生方法についての説明は、バグが起きた時やその前にゲーム中で主人公のしていた行動を記述します。
追加情報として、「おそらく、バグの原因はコレだと思われます」という報告があるぶんには、構いません。
また、バグを報告する場合は、けっして即座に報告するのではなく、最低限あと2回は同じ行動をしてみて（つまり合計で3回以上はしてみて）、それから同じバグが発生するかどうかを確認できたら報告します。
もし最初の1回しかバグが起きなかった場合は、もしかしたら、ソフト側ではなくハード側の不調などの原因も考えられますので、その場合にはバグ報告が、相手プログラマーにとって余計な手間になってしまいます。
なので、バグが起きたと思ったら、最低でも合計3回以上は試してみて、それでも同じタイミングで同じようなバグがほぼ毎回起きたら、そこでようやく、どうやらソフト側のバグだという事が絞り込めます。
さて、ゲームのバグ報告の場合、もしバグの再現性が高い事が分かった場合、
バグ発生の直前の行動だけでなく、バグ発生に影響のありそうな行動も報告する事になると思います。
なぜなら、RPGやシミュレーションゲームの場合なら、たとえば、「ゲーム中の中盤ストーリー中でしか起きないバグ」とか「東部地方でしか起きないバグ」のように、発生箇所や発生時点が限定されているバグもあるからです。
つまり、単に「Aボタンを押したら、こういうバグが起きました。」なんてのは論外です。
ゲーム中のどこのストーリー時点のどんな場所（マップやエリア、ステージなど）で、どんな操作キャラクターで、キャラクターに何をさせたらバグが起きたのか、といった、5W1H（いつ、どこで、だれが、なにを、どのように、どうした）のような情報を、バグ報告での発生方法では、書きましょう。
たとえば、
:「ゲーム序盤の第1章から行ける街・ハジメガルドの武器屋の親父に、ゲーム中盤の第三章になってからハジメガルドに行き、自軍パーティ構成が戦士・戦士・僧侶の3人パーティの味方平均レベル28くらいの状態で武器屋親父に話しかけると、なぜか親父が話しかけるたびに、バグによって親父のキャラチップの表示位置が1マスぶん右にズレます。」
みたいに、5W1Hで報告するのです。
バグ発生時の瞬間のプレイヤー行動は単に、に武器屋で話しかけるですが、しかし、発生に影響を与えてるかもしれないと思った行動など、その他の行動も報告します。
なぜなら、バグ発生の条件は、必ずしも1つとは、限りません。複数の条件が満たされた場合にだけ、バグが発生する場合もあるからです。
これがもし、
:（ダメな例）「武器屋の親父に話しかけると、表示が1マス、ズレます」
だと、報告を聞いた側のプログラマーにとってはバグ発生方法がサッパリ不明です。また、ハジメガルド以外の別の街の武器屋の親父では、バグは発生しないかもしれないので、プログラマー側が再現性を確認プレイしても、
ハジメガルド以外の武器屋でプレイしてしまう可能性もあります。その場合、バグ発生を確認できないので、その結果「間違った報告」としてプログラマーに処理されかねません。
また、ダメな例として
:「武器屋の親父に向かって決定ボタンを押すと、表示が1マス、ズレます」
だと、決定ボタンを押した結果、何が起きる状態なのか、やや不明です。親父に話しかけるために決定ボタンなのか、それとも、たまたま親父の前でメニューコマンドで道具を使おうとして決定ボタンなのか、解釈が分かれてしまいます。
つまり、発生方法の操作の説明は、プレイヤーの動作ではなく、なるべくゲーム中のキャラクターの動作で、バグ報告しましょう。
なお、たといこのバグの発生条件で自軍パーティ構成が結果的に無関係だとしても、報告時に「自軍パーティ構成が戦士・戦士・僧侶の3人パーティの味方平均レベル28くらいの状態で武器屋親父に話しかけると、」のような情報があるのは、構いません。
なぜなら、バグ報告の時点では、まだ自軍パーティ構成がバグ発生に影響しているかどうかは不明だから、です。
バグ発生の条件は、必ずしも1つとは限らず、複数の条件が満たされた場合にだけ、バグ発生する場合もありますので、バグ報告では「影響してそう」と思った情報も提示します。
その他、プレイヤーによって行動が分かれそうなゲーム中での過去イベントでどうしたかとか、そういうのも後に追記しましょう。
たとえば、先のバグ報告バグによって親父のキャラチップの表示位置が1マスぶん右にズレます。」の次の文で、
:「私の今回のテストプレイでは、まだ「伝説の剣」は入手していません。「伝説の盾」は、このバグ発生の時点で入手しています。伝説の盾を守っている中ボス・暗黒大王も撃破してあります。」
などのようにです。
もしかしたら結果的には「伝説の剣」や「伝説の盾」の入手の有無はバグには無関係かもしれないですが、しかしバグ報告の時点ではプログラマーにすら一切、原因は不明なので、よって報告の時点では、関係ありそうだと思った追加情報を手短かに5行～10行くらいで、いくつか選んで情報を報告します。
さて、報告する側は、もし時間に余裕があるなら、次からの検証プレイではバグ発生時の行動を少し変えてみて、それでもバグが起きるかどうかを試してみると、プログラマー側の今後の検証がラクになります。
さて、ゲームに限らずパソコンソフトの場合、
たといデバッガー側で何回もバグを再現できる事を確認できたとしても、
それでも、プログラマー側の環境ではバグが起きない場合がある。
このような場合は、たとえば、ＯＳ（オペレーティングシステム）の違いによって起きる場合がある。
たとえば、Windows の特定のバージョンでしか起きないソフトバグもある。
なので、もしプログラマー側ではバグをテストしても確認できない場合、
自分のＯＳを変更してみる等して、確認する必要がある。
;細かな追試プレイは後回しに
バグ報告は、発見しだい、再現性が3回くらい確認できた時点で、なるべく早めに報告したほうが、最終的に効率的です。
再現性が確認できたら、さっさと報告しましょう。
もちろん、バグ発見箇所の周囲にも類似のバグが潜んでないかとかも、今後はチェックするわけですが、
しかしそんなのは、そのときにチェックすればいいのです。
どうせバグ修正後にも、バグが本当に直ってるかを確認するためのチェックプレイするのですから、
だったら早めにバグ報告して、プログラマー側にとりあえず該当部分のバグを直してもらい、
そのあとに周辺箇所をまとめて通しプレイで調べればいいのです。
仕事術としては、おそらくですが、プログラミングやゲーム産業に限らずなにか仕事で、
自社や同僚などの設計ミスのようなものが見つかったら、
再現性が取れた時点で、その後の詳細な調査は後回しにして、ひとまず、
早めに設計担当の部署に報告をするほうが効率的でしょう。
=== バグが無かったという報告もときには必要 ===
もし仕事でデバッグ依頼を受けている際、開発版ソフトウェアがバージョン更新されてデバッガーなどの協力者に限定公開された場合、デバッガーは検査のためにソフトをテスト使用するワケですが、テストの結果、バグが見つからない場合もあります。
もし仕事のデバッグ依頼を受けている場合、たといバグが見つからなかった場合でも、デバッガーからソフトウェア作者に連絡する必要があります。（ただし、仕事でないソフトの場合、いちいちソフト利用の際に報告の必要は無いし、むしろ作者の手間をかけてしまう。なぜなら、もし作者が利用者全員から報告を受けていたら、人気アプリ作者などは、多くの人から報告されてしまうので返事に手間が掛かってしまうので。）
仕事の場合、IT産業にかぎらず何かの検査では、もし検査の結果として異常が見つからなくても、「今回の検査では、ver○○には異常が見つからなかったです」という報告が必要です。
そのように「異常なし」報告しないと、そもそも検査の依頼の連絡がテスト者に行き届いてないのかとか、確認のための手間が、製品の作者側に掛かるからです。
さて、ソフトの「異常なし」報告をする場合、「自分はどういった作業をそのソフトウェアで何時間くらい利用していた所、今のところ、ver○○にはバグが見つかりませんでした」というように報告をする必要があります。
たとえば、一例ですが、
【デバッグ報告】「異常なし」です。
ソフト「□□□□」のver0.85が公開されたので、このver○○で下記の行動をしてみましたが、異常は見られませんでした。今のところ、正常です。
確認した行為
・ △△△
・ ～～～
みたいな感じでしょうか。
他の利用者が別の利用方法をしてたらバグが見つかる場合もあるので、なので、「自分が何をしている限りは、とりあえず、このソフトにはバグが見つからない」という情報が「異常なし」報告に必要です。
こうすることで、もしバグが今後に他の場所で見つかった場合でも、ソフト作者が「異常なし」報告を受けた部分は後回しにできます。
=== 仕様かバクか不明な場合 ===
ゲーム演出のなかには、一見するとバグっぽい演出もあります。
なのでデバッガーが、ゲームのテストプレイをしているときに見つけた現象が、はたしてバグなのか、それとも意図的な演出なのか、悩むこともよくあります。
このような場合でも、とりあえずはデバッガーは念のためバグかもしれないと報告を挙げておくのが、ゲーム業界での通例だと言われています。
たとい結果的にバグではなく意図的な演出だとしても、プログラマー側にとって、ユーザー視点に近い人からの参考意見になります。
もしプログラマー側やクリエイター側は、このような仕様のつもりの部分にバグ報告を受けたら、きちんとデバッガーたちに、「この現象はバグではなく仕様です」ということを説明し、デバッガーたちとプログラマーとで情報共有する必要があります。
=== その他 ===
==== レベル上げは目的ではない ====
プレイするバージョンについては原則、なるべく最新バージョンをプレイします。
なぜなら、今後のプレイヤーがプレイするバージョンに、もっとも近いバージョンは、現時点での最新バージョンだからです。
なので、RPGやシミュレーションなどのデバッグをしている場合、もし最新バージョンが出たら、とりあえずセーブデータを最新版に移行可能なら、さっさと最新版に移行しましょう（念のため、古いほうのセーブデータもしばらくは残しておく）。
なお、レベル上げのバグの有無の確認については、デバッグ初期の段階で、デバッグモードなどでカンスト（カウンターストップ）チェックを行っているハズです。なので、通しプレイでは、レベル上限チェックの確認の優先順位は、低めでしょう。
とはいえ、一度は誰かが通しプレイでもレベル上げの通しプレイで最高レベル近くなどのレベルをチェックする必要がありますが、しかし時間が掛かりすぎるので、もし誰かが既に1度や2度はレベル上げのカンストのチェックしていれば、あとは他の人がレベル上げをチェックするのは不要でしょう。
このように、一応は通しプレイで誰かが最高レベルや最高スコアなどの上限を確認する必要があるので、なので自分のプレイでの最高レベルなどのセーブデータも一応は保管しておくべきでしょう。
ともかく、このようにデバッガーどうしで役割分担をしましょう（複数のデバッガーがいれば、の場合ですが）。
なお、最新バージョンにセーブデータを移行した際は、攻略の前に、まず『更新履歴』などの情報を読んで、そしてその更新したゲーム内環境の周囲に異常のないことを確認するデバッグ的に色々としてみるプレイをしましょう。
いちおうプログラマー側でも、更新箇所についてはデバッグモードなどで簡易的に確認をしているとは思いますので、この段階ではバグはあまり見つからないのが普通ですが（なので正常な動作が見れるのが普通ですが）、しかしデバッガーにとっても、まず正常な更新結果がどういう結果なのかを知る必要があるのです。
なので、まず正常な更新結果を実際にプレイでさっさと確認してから、そのあとで、通しプレイを始めたり、あるいは移行後のデータを攻略してゲームクリアしたりします。
その後にまだ次のバージョンが出てなければ、今度はニューゲームで最初から通しプレイをしましょう。
== セーブとデータベース ==
| 