ゲーム実行中にオブジェクトの値が意図せず変わってエラーになるバグがあるとします。
「そのオブジェクトを調べても値を更新してる処理は見当たらない。他の誰かが値を変えてるっぽい。でも誰がいつどこで……？」
こういう、不意なタイミングで意図せず値が変わるバグの原因究明作業でいつも時間を取られています。
誰がどのタイミングでどうやってその値を変えたのかを調べるのに、いい方法はないでしょうか？
デバッガでステップを進めて値が変わるタイミングを調べるのもいつもうまくいかず、いつも「デバッガ使うメリット無いな？」となります。延々とステップを進めるボタンをクリックしても結局分からなかったり、ボタン連打しつつ瞬きしたら値が変わってて調査が振り出しに戻ったりで。
（正直、Step In、Step Over、Step Outの使い分けとかも分かってなくて）
結局、コードのあらゆる場所にshow_debug_message($"1) value={value}")という感じのものを埋め込んで、虱潰しに値が変わる箇所を探しています。
なんかいい方法ないですかね～？
複雑な場合は怪しいところの前にブレークポイントを置き、ウォッチウィンドウを開いて見たい値を監視するってことを自分はやっています。
ウォッチウィンドウは現在のブレークポイントのの箇所にある指定した変数の値を見ることができる機能で、ウィンドウに直接変数名を入力するとその値を見ることができます。（デバック実行中Debugger -> Watchからウィンドウを表示可能）
通常の変数だけでなく、配列、構造体などの変数も指定可能です。
基本ステップオーバー（関数飛ばし）で実行をチェックして、値が変化した関数があった場合ステップイン（関数の中に入る）して中身を確認しています。
ただ、そこまで複雑じゃない場合は自分もあさまどさんみたいなやり方もやってますｗ
また、設計の段階では他のインスタンスから直接変数の値を変化させないようにしていたりもします。
インスタンスの変更をする場合はできるだけ関数を介して変更します。
そうすればその関数の中に一つブレークポイントを入れるだけで、値の変化を監視することができます。
そうでない場合、変化のある箇所全部にブレークポイントを入れる必要がでてきてしまいます。
ありがとうございます！
ということですね。
カプセル化と言うんでしょうか、そういうコードを破綻させない設計が大事なんですね。ここらへんがまだ自分は弱いです。