「ゲームプログラミング/デバッグ」の版間の差分
削除された内容 追加された内容
1,134 行
ただし、小規模なサークルでは、こういった社内サーバーの設置は難しいでしょう。とにかく、なんらかの方法で、バグ報告があまり重複しないようにしてください。このため、あまりにも開発初期の段階では、あえてデバッグメンバーを少数に限って、メールでやり取りする事もありえます。（いちおうメールにも、CC(カーボンコピー)などの機能がある。）
とはいえ、サーバ無しに他のテスターの報告状況なんて分からないので、ある程度はバグ報告が重複するのは、やむをえません。
さて、サーバを使う場合、自分がバグ調査して得た情報のうち、まだ報告されていない情報があれば、サーバーのバグ記入欄に追加の情報を記入するぶんには、構いません。（ゲームに限らず、GitHubなどのバグ報告欄でも同様の慣習です。）
べつに特許や発明ではないので、最初の一人だけが名誉と権限を独占する必要は無く、みんなで協力しあってバグ解決という問題解決するのが仕事です。
1,217 ⟶ 1,221行目:
また、バグを報告する場合は、けっして即座に報告するのではなく、できれば最低限あと2回は同じ行動をしてみて（つまり合計で3回以上はしてみて）、それから同じバグが発生するかどうかを確認できたら報告します。
もし最初の1回しかバグが起きなかった場合は、もしかしたら、ソフト側ではなくハード側のその瞬間での不調などの原因も考えられますので、
ただし、ランダム性の高いバグなどの場合、本当はソフト側のバグなのに、2回目に試しても発生しない場合もあります。
1,294 ⟶ 1,298行目:
なので、もしプログラマー側ではバグをテストしても確認できない場合、
自分のＯＳを変更してみる等して、確認する必要がある。
1,310 ⟶ 1,312行目:
どうせバグ修正後にも、バグが本当に直ってるかを確認するためのチェックプレイするのですから、
だったら早めにバグ報告して、プログラマー側にとりあえず該当部分のバグを直してもらい、
1,318 ⟶ 1,319行目:
仕事術としては、おそらくですが、プログラミングやゲーム産業に限らずなにか仕事で、
:自社や同僚などの設計ミスのようなものが見つかったら、
:再現性が取れた時点で、その後の詳細な調査は後回しにして、ひとまず、
:早めに設計担当の部署に報告をするほうが効率的でしょう。
| |||