「ゲームプログラミング」の版間の差分
削除された内容 追加された内容
815 行
わざと弱めのボス敵などに負ける全滅テストも、ときどき、2回以上はワザと全滅してみましょう。
;悪事モードや壁衝突などのチェック中のデータは、なるべくセーブしない。
セーブ機能のあるRPGやシミュレーションや長いアクションゲームなどで、上述のようなボタン連打や壁衝突などのプレイを確認するとき、原則的にあまりセーブしないようにするほうが効率的でしょう。
なぜなら、もしそのゲームのあとのプレイで何らかのバグが発見された場合、原因として、ボタン連打などの影響を考慮する手間が増えてしまうからです。
1つのセーブデータで、実験をしてしまうと、たといバグが発見できても、その原因が果たしてボタン連打の処理ミスなのか、それとも悪事のフラグミスなのか、ミスの箇所が不明になってしまいます。
同様に、ボタン連打にかぎらず、もし何らかのバグが発見された場合でも、たとい報告のためにセーブする必要があっても、そのデータはまだバグを発現していない未発症データとは分けて別データとしてセーブしましょう。
859 ⟶ 870行目:
なので、彼ら一般人と同じプレイスタイルでは、たとえばもし、ゲーム序盤のとても弱い敵に負けた際に発生するバグがあったとしても、そういうのは発見
865 ⟶ 876行目:
事前のデバッグモードなどでの個別チェックでも、このような確認はしているハズですが、確認モレがあったり、あるいは通しプレイ時にしか発生しないバグなどもありうるので、念のため通しプレイでも、意図的に下手なプレイをします。
=== 集団制作におけるソフトでのバグ報告の書式 ===
| |||