Visual Studio便利機能の備忘録 + おまけ
この記事は、Unityゲーム開発者ギルド Advent Calender2021 12月12日の記事です。
Unityゲーム開発者ギルドはいいぞ。
ご無沙汰しておりました。
中々開発周りのことはtwitterですぐ呟いて満足してしまい、
このブログにまで手が回らずでしたが、今回アドカレに参加することで
やっと更新する理由をこじつけました。
ここ最近はtwitterすら更新していませんが、開発については静かに動いています。
その中で今更ながら知った便利な機能がありましたので、
備忘録代わりに書き留めておこうと思います。
この備忘録が誰かの役に立てば嬉しいです。
では、目次です。
注意
この記事ではVisual Studio for Macでの手順を解説しています。
基本的にWin版との差異はほとんどないはずですが、
完全に同じであることは保証できませんのでご了承ください。
バージョンは8.10.11(build 8)です。
便利機能その1：ブレークポイント
ブレークポイントとはなにか
既にご存知の方も多いと思いますが、
今回は「そんなもの知らない、初めて聞いた」という方を想定して書きます。
ブレークポイントは、開発者が利用できる重要なデバッグ手法の 1 つです。
デバッガーの実行を一時停止したい任意の場所に、ブレークポイントを設定します。 たとえば、特定のブレークポイントで、コードの変数の状態を確認したり、呼び出し履歴を調べたりすることができます。
この機能ですが、使用する上で特別なことをする必要はありません。
Visual Studioに標準で入っているので、任意の箇所にブレークポイントを設定し、
実行すればOKです。
なぜブレークポイントがいいのか
UnityではDebug.Log()というものが用意されているので、
これでバグを探したり、挙動確認をすることも多いと思います。
しかし、Debug.Log()の場合、このメソッドを入れた箇所しか挙動を見れないことと、
変数の値まで見ることはできません。
その点において、ブレークポイントは任意の行で設定して実行するだけで、
変数の値を確認することができます。
これにより非常に見えづらいプログラムの動きを確認しやすくなり、
バグの発見をしやすいばかりではなく学習も捗ります。
実際、神岡はこのブレークポイントを活用してから、学習効率が飛躍的に上がりました。
何よりいちいちDebug.Log()なんて余計なコードを書かなくて済みます。
Debug.Log()も使いようによっては有効な場合もありますが、
純粋にプログラムの挙動を確認したいとか、不具合の原因を探るのであれば
ブレークポイントを使う方が早いし、抜けも起こりにくいかと思います。
思い当たる箇所を片っ端から設定して実行すればいいだけなので。
使い方
ブレークポイントの良さが分かったら、早速使ってみましょう。
使い方はとても簡単です。
ブレークポイントを設定する
任意の行で、画面左側のグレーの部分をクリックして、
赤い◎が表示されたらブレークポイントの設定は完了です。
もしくは、ブレークポイントを設定したい行にカーソルを合わせ、
F9押下でも設定可能です。お好みでどうぞ。
逆に設定を外したい場合は、赤い◎をクリックすると消えます。
これで実行時の対象行から外れます。
実行する
Visual Studioの場合は画面左上の実行ボタン▶︎をクリックすれば
プログラムが実行されるので、そのまましばらく待てばOKです。
簡単ですね。
右側にある「続けて実行する」ボタンをクリックすると、
次のブレークポイントに飛べます。
当然、プログラムの実行順に進んでいきますので、
逐次変数の中身を確認することができます。
for構文などを使ったものだと、
実行する度に値が変化していくので見ていてとても楽しいです。
最後のブレークポイントまで進み、処理が完了すると自動的に停止します。
もしくは、左上の実行ボタンを再度クリックでも停止できます。
プログラムを実行中かどうかは実行ボタンの状態で見分けがつきます。
赤丸で囲ったボタンが■になっている場合は実行中です。
逆に▶︎になっている時は実行していない(停止)状態です。
慣れないうちは戸惑いますが、これで見分けがつきます。
ちなみに、先述の「続けて実行する」ボタンは、
Debug > Defaultの右隣にある▶︎ボタンです。
プログラム実行中のみ表示されます(青丸で囲った部分)。
プログラムが実行されていない状態。続けて実行やステップオーバーなどのボタンが非表示。
Unity上で使用する場合
前提条件：Unity Version 2020.3.2f1以降
Unity上で使用する場合は、
まず「デバッグモード」に切り替える必要があります。
初期状態ではリリースモードになっているため、デバッグモードに切り替えましょう。
エディタ画面右下の虫のアイコン(赤丸)があるので、クリックします。
ダイアログのようなものが出てくるので、
「デバッグモードに切り替える」(赤丸)をクリックします。
右端にインジケーターのようなアイコンが表示され、
くるくるアニメーションが表示されるので、
それが終われば自動的にデバッグモードに切り替わっています。
虫アイコンが黄色になっていたら、デバッグモード有効状態です。
次に、Visual Studio側で実行▶︎ボタンをクリックします。
ビルドが完了したらUnityのエディタ画面に戻り、
Gameビューの再生ボタンをクリックします。
適宜操作し、ブレークポイントに到達するとGameが一時停止状態になり、
Visual Studioの画面に切り替わり、中断箇所で一旦停止します。
続けて続行や、ステップイン/ステップアウトの操作方法は、
Visual Studioと同様です。
終了したい場合は、Visual Studio側の停止ボタンをクリックすると、
Visual Studio側の処理が停止状態になります。
Unity側のGameビューでは、一旦停止状態が解除され再生されます。
処理が重くなることがありますが、基本的にしばらく待っていれば問題ありません。
但しフリーズしてしまう可能性もゼロではないので、保存はこまめに...。
実行中の変数の値を確認する
実行中に変数名の部分をマウスオーバーすると、
画像のように値を確認することができます。
return文でメソッドの計算結果を返した値などももちろん確認できます。
簡単なプログラムであれば比較的すぐに変数の値を推測することは可能ですが、
Unityなどのように予めお膳立てしてくれている場合は
変数の中身を確認することが難しく、
これにより不具合の原因が中々掴めない場合もあります。
そういう時にブレークポイントを設定し、
実行すると設定されている値を確認できるため、
不具合の原因を特定しやすくなります。
例えば、下記の画像は現在開発中のゲームのあるオブジェクトの情報なのですが、
当たり判定周りの挙動が意図通りにならず困っていました。
結論から書くとtagの部分が"Untagged"となっており、
当たり判定となる条件から外れていたことが原因でした。
この場合はInspectorからも確認できた内容ではありましたが、
誰かに相談したい場合、現象を説明することは可能でも、
プログラム的にどういう挙動になっているのかは分かりません。
しかし、ブレークポイントを利用することで実行中の設定が
どのようになっているか分かるため、原因も掴みやすくなります。
この場合も画像を見せて一発で特定されました。ありがたや。
「なぜブレークポイントがいいのか」でも触れましたが、
Unity側で用意してくれているDebug.Log()ではこれを検出するのは難しいでしょう。
ブレークポイントを使えば手間もかからず原因を特定できるので、
使わない手はないと思います。
便利機能その2：F12でメソッドなどの定義を見る
この機能は開発支援というよりは学習寄りな気もしますが、
個人的にすごく便利だと思ったので書き留めておきます。
C#(に限らずですが)は、実に便利でさまざまなメソッドを用意してくれています。
中身を知らなくても使い方さえ知っていれば事足りる場面がほとんどだと思いますが、
それでも応用的な使い方をしたい場合は用意してくれているものがどんなものかを
理解しておくことが不可避となる場合も多くなりますね。
メソッド名+言語名で検索したり、公式のドキュメントを見るのもいい方法なのですが、
正直ちょっと面倒だし、引数の型を見たいのになぁなんていう時は情報が多すぎる...
というような時に、メソッドにカーソルを合わせてF12を押すと、
「アセンブリブラウザー」というタブが出てきて中身を確認することができます。
調べたいメソッドにカーソルを合わせた状態で、
F12キーを押下すると別タブでアセンブリブラウザーが出てくる。
メソッドの仮引数の型を確認したい時なんかはとても便利です。
公式ドキュメントをひっくり返して調べる際に、補助的に使うといいと思います。
もちろん自分で定義したクラスやメソッドにも使えます。
おまけ：神岡的によかったプログラムの勉強方法
最後におまけ的に神岡的勉強方法を書いておきます。
「プログラムはとにかく書きまくることが一番の早道」とはよく言われますが、
個人的に闇雲に書きまくってもあんまり捗りませんでした。
これは私の学習や理解の仕方の癖もあるのかも知れません。
私は割と些細なことにも「なんでこうなるんだ？」とつまずいてしまうような
要領の悪い頭なので、他の人が難なく通り過ぎることにも詰まるんですね。
ということでやってみたのが、
実際に書いているコードに何をしているのかコメントを残しまくること。
44、45行目のコメントが私が残したもの。他は本のまま書いたコメント。
27行目のコメントが自分で残したもの。
こんな調子で些細なことでも何でもかんでもコメントを残しまくっています。
この辺は独習C#に沿って書いているコードなのでまだまだ複雑ではないはずですが、
やっぱりただ本の通りに書いているだけ、
ブレークポイントを使って挙動を確認しても覚えられなかったり、
理解が曖昧なことも多く、明確にする目的でコメントを残しています。
あとは前にやったはずでも定着していないことも結構あるので、
これまでの学習の再確認的な意味でもやっています。
私的にはこれでより明確に理解できるようになったなと思いました。
誰かの役に立つか不明ですが、
自分的に嬉しかったことなのでおまけ的に書き残しておきます。
本当に、一年前と比べると段違いに理解が深まり、
何をしているのかすぐにイメージがつくようになったのは成長を感じますね。
去年は「ふ〜ん...？」という感じだったので、C#と仲良くなれる自信がなかった。
おわりに
誰かに向けたものというよりは本当にただの備忘録になってしまったのですが、
それでも困っていてたまたまこのブログに辿り着いた人とか、
本当にただの通りすがりな人でも役に立つようなことがあれば嬉しいです。
もっとも、そういうことがなくても読んでもらえただけでも嬉しいですけどね。
次回は今年の振り返り記事でも書こうと思います。
去年も濃厚でしたけど、今年も色々ありました。
そういう話になると思います。
余裕があれば、もしかしたらUnityもくもく会レポートになるかも知れません。
では。
