「ゲームプログラミング/デバッグ」の版間の差分

削除された内容 追加された内容
→‎バグが無かったという報告: Linuxゲーマーのバグ報告の外部記事が見つかったので出典に追加。Gigazine『「Linuxゲーマーのバグ報告率は平均の6倍以上」とゲーム開発者が明かす』
→‎バランス調整との関係: ==== バランス調整されてからテストプレイが望ましい ====
480 行
テスト用語で、ゲーム中の壁のバグなどの「通行設定ミス」という言葉がありますが、裏を返せば、壁については通行設定さえミスしてなければ、少しくらい壁にキャラが めり込んだりしてしていても、構わないわけです。
 
=== バランス調整との違い関係 ===
==== バランス調整との違い ====
敵の強さなどの設定のバランス調整も、デバッグのためのテストプレイも、一見すると似ていて、ゲームを延々とプレイしたり、問題点を発見したら場合によってはレポートを書いたりして開発チームとコミュニケーションする場合もあるので、似ているかもしれません。
 
524 ⟶ 525行目:
 
なので、もし同人サークルなどチームでゲーム製作している場合、なるべくチームメンバーの多くでデバッグしたほうが、より簡単に見つかるでしょう。
 
==== バランス調整されてからテストプレイが望ましい ====
β版などのゲームのテストプレイをしていると、作者がまだバランス調整を終わってないエリアが、そのエリアの(バグ発見などの)テストもまだ終わってない場面もあります。
 
このようなバランス調整の終わってないエリアの存在する場合、できるだけバランス調整が終わったエリアから優先的にテストしたほうが効率的です。
 
というのも、せっかく仮に、ゲーム中にあるバランス調整が終わってないエリアをテストプレイをしても、バランス調整後にそのエリアにおかしな所が追加されてないかをチェックする二度手間が発生してしまうからです。
 
 
;若干の例外
ただし、バランス調整前のテストプレイにも若干の利点もあります。作者がバランス調整すら終わってない、ほぼ未検証のエリアなので、もしかしたら大きなバグがある場合があります。そのような大バグがあるかないかを知れるのは、情報としては若干の価値があります。
 
とはいえ、やはり上述のように未調整エリアのテストプレイは二度手間になってしまうので、できるならば、なるべくバランス調整が終わった箇所からテストプレイでチェックしていくほうが効率的です。
 
無料ゲームならば、もし、なにかの締切などまでに間に合わず、バランス調整の追いつかないエリアが締切日に残ってしまったとしても、対応としては、単にその未調整エリアを一時的に封鎖する仕様にして対処すればいいだけなのです。(そして後日のアップデートで、バランス調整の終わったエリアを公開していく仕様に更新するなどの対応すれば済むので。)
 
なので、やはり、バランス調整しおわったエリアから順番にテストプレイするほうが、二度手間が無くなるので、効率的ではあります。
 
=== すべての組み合わせの検証は無理 ===