「ゲームプログラミング」の版間の差分
削除された内容 追加された内容
693 行
=== 個別チェックと通しプレイ ===
==== まずは個別チェック ====
===== 総論 =====
ゲームで新しい機能を追加した場合、たとえばデバッグモードなどの機能を使ったりしてでもいいので、
710 ⟶ 711行目:
もしデバッグモードの機能が無いゲームの場合や、製品に近くデバッグモード不搭載のバージョンの場合には、デバッガーは、なるべくデバッグモード利用時に近いプレイ方法で、個別にチェックしていきます。
===== 各論 =====
;全装備品の装備、全アイテムの使用など
たとえば、RPGの装備品のシステムが正常に動作しているかどうかを確認するためなら、とりあえず、すべての装備品をいったん装備および装備解除してみる、というような作業をします。
725 ⟶ 727行目:
とはいえ、これらは普通のゲームプレイでも、プレイヤーによっては、アイテム効果確認や隠しエリア探索などのために、よくやる事でもありますので、これはまだ楽しいほうです。
;通行止めの確認
さらに商業ゲームでは、たとえば、すべての壁（かべ）の通行不能の処理が、本当に壁として行き止まりになっているかとか、通行止めであるかとか、そういう行き止まりチェックみたいな事も、します。
ツライ事の一つは、この行き止まりチェックでしょう。
733 ⟶ 735行目:
;選択肢の総確認
他にもデバッガーのすべき事は、たとえば、ゲーム中にもし、なんらかの選択肢の入力がある場合、選択肢すべての（当面の）結果を確認します。
738 ⟶ 741行目:
このように、とりあえず、どちらの選択肢を選んでも、当面の数分はバグの無く、正常に動作しているかを、（デバッグモードや、セーブデータの複数用意などで）なんらかの方法で確認します。
747 ⟶ 751行目:
;全滅テスト、自殺テスト
また、一般プレイヤーは、上手にプレイしたがるので、わざとゲームオーバーする自殺プレイを嫌がります。
753 ⟶ 758行目:
難易度の高いゲームなら、意図的に自殺プレイしなくてもよく全滅しますが、たとい難易度の低いゲームでも、わざと自殺プレイをします。
特にボス戦などは、ソースコードでは特殊なフラグ処理が入りこんでいるのでバグの混入している可能性も高く、そのため、たとえ弱いボスであっても、ワザと敗北したりする自殺プレイが、デバッガーのすべき事です。
;カウンターストップのチェック
たとえば、RPGのゲームの上限レベルが「99」の場合、きちんとレベル99で止まるかを、とりあえずデバッグモードでチェックします。
こうしたデバッグを短時間で出来る用途のために、やたらと経験値の高い敵でも一体、ゲームのソースファイルにでも混ぜて、作っておきましょう。
レベル98からレベル上げをしてみたりとか、レベル97から一気に2レベル上がったらどうなるかとか、いろいろと確認しましょう。
また、所持金や道具の個数なども同様に、上限できちんと止まることをデバッグモードなどを活用して確認します。
779 ⟶ 801行目:
ともかく、このように、機能をひとつずつ、個別的にチェックしていきます。
;ボタン連打や、壁に何度も衝突など
ボタンを1回だけなら押しても異常は無くても、ボタンを何度か押すと異常のあるバグも、ときどきあります<ref>STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、257ページ</ref>。
とはいえ、ゲーム中の全てのシーンで何度もボタンを押していたら、ゲームが進行せずにデバッグも進行しないので、たとえばゲーム中で使用頻度の多いメニュー画面などでボタン連打するとか、あるいはイベント進行などで「ここが、もしかしたらバグが潜んでいる可能性がありそうだな」とか思ったところだけボタン連打するとか、工夫しましょう。
同様に、通行止めの壁などの場所なども、ときどき何度も壁に衝突したりしましょう。
わざと弱めのボス敵などに負ける全滅テストも、ときどき、2回以上はワザと全滅してみましょう。
954 ⟶ 991行目:
バグ発生の条件は、必ずしも1つとは限
1,024 ⟶ 1,061行目:
このような場合でも、とりあえずはデバッガーは念のためバグかもしれないと報告を挙げておくのが、ゲーム業界での通例だと言われています。
たとい結果的にバグではなく意図的な演出だとしても、プログラマー側にとって、ユーザー視点に近い人からの参考意見になります。
=== その他 ===
==== レベル上げは目的ではない ====
プレイするバージョンについては原則、なるべく最新バージョンをプレイします。
なぜなら、今後のプレイヤーがプレイするバージョンに、もっとも近いバージョンは、現時点での最新バージョンだからです。
なので、RPGやシミュレーションなどのデバッグをしている場合、もし最新バージョンが出たら、とりあえずセーブデータを最新版に移行可能なら、さっさと最新版に移行しましょう（念のため、古いほうのセーブデータもしばらくは残しておく）。
なお、レベル上げのバグの有無の確認については、デバッグ初期の段階で、デバッグモードなどでカンスト（カウンターストップ）チェックを行っているハズです。なので、通しプレイでは、レベル上限チェックの確認の優先順位は、低めでしょう。
とはいえ、一度は誰かが通しプレイでもレベル上げの通しプレイで最高レベル近くなどのレベルをチェックする必要がありますが、しかし時間が掛かりすぎるので、もし誰かが既に1度や2度はレベル上げのカンストのチェックしていれば、あとは他の人がレベル上げをチェックするのは不要でしょう。
このように、一応は通しプレイで誰かが最高レベルや最高スコアなどの上限を確認する必要があるので、なので自分のプレイでの最高レベルなどのセーブデータも一応は保管しておくべきでしょう。
ともかく、このようにデバッガーどうしで役割分担をしましょう（複数のデバッガーがいれば、の場合ですが）。
なお、最新バージョンにセーブデータを移行した際は、攻略の前に、まず『更新履歴』などの情報を読んで、そしてその更新したゲーム内環境の周囲に異常のないことを確認するデバッグ的に色々としてみるプレイをしましょう。
そのあと、移行したあとのバージョンを、なんらかのプレイスタイルで（ただし、あまり時間を掛けすぎないプレイスタイルで）、とりあえずクリアしましょう。
その後にまだ次のバージョンが出てなければ、今度はニューゲームで最初から通しプレイをしましょう。
== セーブとデータベース ==
| |||