【Unity】ログを出力して処理内容を把握しよう【誰がためにログはある】

ブログを書いていると、記事の中で紹介したソースコードの動作を確認する目的でデバッグ用のログを出力することがよくあります。

実際にゲームを作るときにもゲームの内部的な動きを知るためにデバッグの出力処理を仕込みます。

プログラムを実行するとき、意図的に人間に分かるようにログを残さない限りは内部でどんどん計算が進んでいきます。

そうすると、中身の見えないブラックボックスのような感じになるんですよね。

ただ単にゲームを遊んでいるプレイヤーの立場の場合はプログラムの実行に関するログを出力されても困りますが、ソフトウェアを管理する立場の開発者としてはログが問題解決の手がかりになります。

そこでこのページではログの重要性について触れていきます。ログ、大事。

ログの例

割と大きめの会社が作ったゲームとかだと、なんらかのエラーが発生したときには「エラーコード: 810」のように番号と一緒にエラーダイアログが表示されます。コンシューマー向けのゲームだとあまり見かけませんが、スマホゲームだと結構見かける印象です。

多くの場合はそのままエラー内容を送信し、問題解決の手がかりとして使います。

実はこうした情報を準備しておくかどうかでトラブルシューティングの難易度も大きく変わります。

プレイヤーはデバッガーじゃないからログを見る

作ったゲームを遊んでくれているプレイヤーが見たままのエラーを報告してもらうにしても、ITの知識がある人なら「こんな操作をした時にこのエラーが出る、何度か試して同じ状況なので再現性あり」なんて順序立てて説明してくれますが、別の業界の人だと「よく分からないけどエラーになった」と報告してくれれば御の字です。報告してくれるだけで大感謝。

プレイヤーにデバッグさせるなというのはその通りですが、多くの場合、開発者が検知しうるケースについてはリリース前にテストを行っているはずなので、想定していなかったエラーが発生したときにいかにリカバリを早くするかが大切です。目の前でプレイヤーが困っている状況をいち早く解決することを助けてくれるのがログです。

ユーザーの主観に合わせて、客観的なログの内容と一緒に考えることで、実際の見た目とプログラムの内部的な動きの両方を把握でき、ひいては問題解決を早く終わらせることができます。

トラブルから復旧してユーザーがすぐにゲームを遊べるようになれば満足度の低下もある程度防げるはずです。(このあたりの話はアプリやSteamでのリリースを想定しています)

ゲームの配布方法にもよるところはありますが、なるべくログを回収できる形にしておくとサポートがしやすくなるかもしれません。

ログは開発者のため

ログは開発者を助けるためにあります。回り回ってゲームのプレイヤーが快適なゲームプレイを行うためにもなります。

作成したシステムの動きを把握するのは開発者にとってとても大切で、何か不具合があった時にいち早く問題の箇所を特定できるようになります。

完成したシステムで状況を把握するためのログを出すのも大切ですし、作成途中のゲームでも適宜ログを出しておくのは開発を進める上で有効です。

例えばif文による分岐を実装した場合は、ifの条件、あるいはelseの条件のどちらに合致したのかを把握するためにログを出力させることも多いです。以下のようなコードだったら、コンソールに出力されたログの内容によってどちらの分岐を通ったのか把握できます。

変数の中身を出力することも多く、ゲームの実行中に「なんか思ったような数字になってないな？」というときはDebug.Logでintの中身を出力してみると途中の計算式で思わぬ値になっていることもあります。

変数の中身を追うならブレークポイントを設定してその時点の変数の中身を確認する方法もあります。ブレークポイントとは指定した箇所で処理を一時停止させて、その時点での情報を確認する機能です。

例えば上で紹介したコードでif文の分岐判定の行(下の画像だと10行目)にブレークポイントを設定しておいた場合、その時点で一旦処理を一時停止して、左の『変数』の領域に変数の中身を表示してくれます。この例だとmoneyという変数に100が代入されていることがわかります。

開発中はこうしたデバッガーの機能を使っていって、完成したゲームでは「中で何が起きたのか？」を追跡できるログも使うようにするとより解決がしやすくなります。プレイヤーがどんな操作をしたのかが分かるログだと手順の再現もしやすいですからね。

デバッガーを使ってブレークポイントを設定して変数の中身を見る方法については以下の記事で触れているのでこちらもよろしければぜひ。

エクスプラボ

 

1 User

2 Pockets

UnityとVSCodeでブレークポイントを設定して変数をチェックする

https://ekulabo.com/unity-break-point

IDEやコードエディタに搭載されているデバッガーの機能を使ってステップ実行していくことでゲームのシステムの中身が把握しやすくなります。この記事ではブレークポイントを設定してその時点での変数の中身を確認する方法を紹介しています。

ログに出力する情報

ログはテキストなので容量がそこまで大きくならないとはいえ、何でもかんでもログに残すとプレイヤーの端末にちょっと負担がかかります。必要な内容を選択するのも大切なことです。

実はAndroidアプリだとAndroid Studioを繋いで内容を表示できちゃって脆弱性にもつながってしまうので、完成したゲームの場合は全ての処理でログを出すというよりは「どんな情報があれば問題を特定できるか？」という視点で必要なログを残すようにしましょう。

ログは開発者が状況を把握しやすくするためにあり、その先にいるユーザーが安定してゲームを楽しむためにあります。

最初は運用のことは一旦置いてもいいかも

運用についてまで触れましたが、最初に作るゲームでは開発者であるあなた自身が内部の動きを把握するためにDebug.Logを活用してみてください。

最初から運用のことまで考えるとパンクしちゃいますからね。

システムの中身を把握することを念頭にログを出力する癖をつけておくといいと思います。

Debugクラスのメソッドは「Log」の他に「LogWarning」だったり、「LogError」のメソッドがあるので、こうしたログのレベル分けもできるようになっておくと気配りのできる開発者になれます。

まとめ

Unityではログをコンソールに出力する機能としてDebug.Logのメソッドが用意されているので、作ったゲームの処理の中身が分かるように適切にログを出力するようにしてみましょう。

システムの中身が分かるようにすることで、なにか問題が起きた時でも解決までの時間が短くなります。これは開発者にとって助かる点でもありますし、回り回ってゲームのプレイヤーが楽しく遊べるようになるということでもあります。

ちなみにDebug.Logなどのメソッドではリッチテキストのタグが使えます。詳細は以下のページで紹介しているのでこちらもよかったらご覧ください。

エクスプラボ

 

1 Pocket

【Unity】Debug.Logでリッチテキストのタグを使って色分けする

https://ekulabo.com/unity-debug-log-color

Debug.Logでメッセージを出力する際、大量のメッセージがあると必要な部分の判別が難しくなります。そんな時にはリッチテキストのタグを使って色分けすると必要な情報が見分けやすくなり、ゲームのデバッグサイクルが高速化するのでおすすめです。