「ゲームプログラミング」の版間の差分
削除された内容 追加された内容
編集の要約なし |
|||
817 行
;
セーブ機能のあるRPGやシミュレーションや長いアクションゲームなどで、上述のようなボタン連打や壁衝突などのプレイを確認するとき、原則的にあまりセーブしないようにするほうが効率的でしょう。
なぜなら、もしそのゲームのあとのプレイで何らかのバグが発見された場合、原因として、ボタン連打などの影響を考慮する手間が増えてしまうからです。
1つのセーブデータで、複数の異常プレイの実験をしてしまうと、たといバグが発見できても、その原因が果たしてボタン連打の処理ミスなのか、それとも悪事のフラグミスなのか、ミスの箇所が不明になってしまいます。
なので、まずひとつのセーブデータでは１つの異常プレイだけにします。
もし、複数の異常プレイを一人のデバッガーがする場合には、セーブデータを別々に分ける必要があります。
876 ⟶ 881行目:
事前のデバッグモードなどでの個別チェックでも、このような確認はしているハズですが、確認モレがあったり、あるいは通しプレイ時にしか発生しないバグなどもありうるので、念のため通しプレイでも、意図的に下手なプレイをします。
;壁衝突やボタン連打などのチェック中のデータは、混ぜない。
通しプレイでも、ときどき壁衝突のテストや、ボタン連打などのテストは必要ですが、しかしそれらのセーブデータは、なるべく１つのセーブデータには、混ぜないようにしましょう。
もし今後、何らかのバグが発見された場合に、ひとつのセーブデータにて壁衝突・ボタン連打プレイのデータをセーブしてしまうと、想定されるバグ原因としてボタン連打などの影響の可能性などが増えてしまうからです。
バグを発見したときに、原因の特定が容易になるように、セーブデータを分類して管理しましょう。
=== 集団制作におけるソフトでのバグ報告の書式 ===
| |||