Knowledgeゲーム制作に関するプログラミング等を主に書き溜めていきます。どちらかと言えば日記的な書き方が続くと思いますが、そこは温かい目で見て頂ければ。あと、ちょっとしたサンプルやツールのダウンロードも出来るようにしておきます。05:00デバッグ報告は、伝える側が正しい報告をしないと、現場が混乱します。必要な情報のみを簡潔に報告するのが肝要となります。ここでは、どのようにデバッグを行い、どう報告して、最後にどう決着するのかまでを解説します。名前だけは有名になり、誰もがバグバグと叫ぶ世の中ですが、このバグ、簡単に言えば制作者が意図しない動作を指します。問題なく動いていたとしても、制作者が意図していなければ、それはバグなのです。そのため、バグの発見には対象のシステムの仕様を正しく理解する必要があります。事前に何を調査するのか、表にまとめておくと良いでしょう。行き当たりばったりでバグを探しても、最初は出るかもしれませんが、そのうちバグが見つからなくなっていきます。100個のアイテムがあったとして、99個まで正常でも、最後の1個で問題が出る、それがバグなのです。...寧ろその最後の1個はバグが出やすいです。バグが出やすい箇所はあります。それはリミットチェックと呼ばれる方法であぶり出します。相当する、アイテム数が変化するタイミングを確認する方法です。このように下限値と上限値の数値近辺が最もバグが出やすいのです。時間によるバグも出やすいです。エージングチェックと呼ばれる方法です。デバッグ方法も単純で、電源を入れてから長時間ぶっ通しでプレーし続ける等です。メモリの限界を超えて暴走する系のバグは、このエージングチェックで発見されます。このようにバグの発見にはいくつかのやり方があります。慣れてくると、動いているゲームを見ているだけで匂うようになってきます。なるとシメたものです。マーブルナイトシティ)(株)プラザクリエイト※本屋で見かけて以来、めっちゃ気になってます。バグを報告するバグ報告で大切なのは客観的事実だけを報告する事に他なりません。ここに、報告者の意見や感想や想像を入れないように意識するのが大切です。ここにバグがあるかどうかは、最終的にはプログラマじゃないと分かりません。しても自分の意見を入れたければ、それをちゃんと明記してください。私はここにこういうバグがあると思いますとか。それを読み取るプログラマには余分な誘因になる可能性がある事は理解してください。客観的事実でプログラマが欲しい情報は以下の通りです。影響範囲(深刻度)報告者毎に形式がバラバラだと、プログラマの確認時に余計な時間を使ってしまいますので、通常は何かしらのデバッグ報告ツールを使用します。いうツールを使う事でしょうか。いうフォルダを作って、そのフォルダ内を1テキスト1バグ報告としてファイルコピーしながら、経過を記入していくなんて方法もあります。バージョン番号がアプリにない場合は、そのデバッグしているアプリの作成年月日-時間をバージョン番号の代わりとします。バージョン番号は、プログラマが既に手元では直しているのに、もう一度チェックする時間的な無駄を省くために必要です。再現手順と再現率は最重要です。言ってしまえば、プログラマの手元で再現出来るのであれば、そのバグはほぼ取れたも同然です。時間を掛ければ必ず取れるバグという事になります。厄介なのは再現する方法がないバグ報告です。これは、バグ修正が困難な上に、修正出来たとしてもそれを確認する方法がありません。このような再現不能なバグを防ぐため、デバッグする人は自分のデバッグをフルタイムでビデオ撮影するのがベストだと言えます。プログラマなら見れば分かる事も多々あるためです。深刻度は報告者の感性で最初は付与されます。私は以下のような区分としています。ディレクターやプログラマも確認変更します。ディレクターは好きに弄れますが、プログラマは深刻度を深くする変更だけとする等のローカルルールが存在する事があります。最後に状況報告ですが、感覚的な内容は避けて、客観的情報を元にします。「高速スクロールが遅い」という報告は、件名であれば良いのですが、報告内容に記載するには情報が曖昧です。15FPS前後まで処理が落ち込む」等と記載します。重いと言われても実際どうなのかと分からないものなのです。こいつ...動くぞ!バグを修正する報告を受けたプログラマがバグを修正します。複数のバグ報告が、実は原因が同じという事も多々あります。報告者はバグの客観的事実だけを元にしてますので、これは当然と言えます。逆に言えば、報告者はこれは以前の報告とバグと同じだと安易に決めつけてはいけません。同じと確信出来たとしても、先に報告した内容に追記してどのような形であれ報告するべきです。すると致命的な問題を見逃す事にもなりかねません。プログラマは、バグ報告の再現手順を自分の環境で再発するか確認するところから始めます。再現した場合は、ほぼ間違いなく同時にデバッガで内容を追っていますので、バグの原因はその時点で大方判明する事になります。厄介なのは、バグが出た時点で、既に何かが壊れていた等です。これは、バグがしばらく潜在化していたことを意味します。本当の発生源を見つけるのは容易ではありません。このような場合は、プログラマはテストケースをいくつか用意して、その結果の違いからバグの場所を推察する方法を採ります。それでもダメな場合は、バグが置きそうな場所にトラップやログを仕掛けたりと、プログラマの技量が試される事になります。...と、創意工夫でバグの場所を探し出して、見つけた時は単純なタイピングミスというのもよくある話ですバグを修正したら、次の更新タイミングでバージョンを更新の上、再度修正が正しく行われたかどうかを、バグ情報システムから依頼します。このとき、同時にチェックして欲しい事項もデバッガー向けに記載する事もあります。バグが修正されたか確認する修正済み確認依頼となった場合は、デバッガーは以前の再現手順で再発するか確認します。問題が起きてしまった場合は再発として、プログラマに状況報告します。問題が無かったとしても、すぐさま修正OKにはしません。関連するであろう別の手順であるとか、別の機種であるとか等、デバッガーの想像力が試される事になります。それでもバグが出ないと確信して、始めて完了として、このバグ報告は終了となります。バグと称して報告する事例が後を絶ちません。バグなんだろうと、今では私は諦めて、プログラマにバグ報告を見せる前に、私がフィルタリングしてから渡すようにしています。要望に本物のバグ報告が混じっている事もありますし...。23:0430年ほど前、某社のデバッグ体制を整えることに奔走しました。箇条書きにしてまとめる報告書の書式を作ったことを思い出します。11:06>>1私も、デバッグ報告がエクセルでヅラヅラ書いてあるだけのファイルがあってスタッフ全員の共有で困ったので、そのファイルをネットワーク共有フォルダに入れて、リアルタイムに読み込んで最新情報が反映されるデバッグ管理ツールを開発してたりしました。タグクラウドAILZ80ASMAndroidBASICC#C言語C言語講座DIYJsonMarkdownMZ80CNASNewシティヒーローPC6001PC8001PC8001mk2PCG8100PS2RPGVS2022VSCodeWindowsXperiaZ80お祝いお買い物ちらつきアイテムアセンブラアルゴリズムエミュレータオーダリングテーブルガスレンジガス器具ゲームゲームデザインゲーム制作ゴルフサウンドシリアライズタスクトレイツールテストデザインデバッグデータ圧縮データ構造トレーニングパソコンミニパーツフリーフリーズプログラミングプロジェクト管理プロトタイプ宣言ポインタマップエディタメモリ空間モニターアームラズパイリスト構造リフォームルーターループレトロPCレトロPC開発でカセットにデータを記録する環境を作ります。sapm防止のため手入力してください。リンで利用することは禁止いたします。各記事に直接飛んでくるのはOKです。何かございましたら、上記メアド宛にお気軽にお問い合わせください。レトロPCゲーム制作に使って頂く分には、ドンドンご自由にお使いください。