＜このページで学べる内容＞

Unityは2020年夏に、Unity 2020 LTSのワークフローを加速させるための70以上の時間節約のヒント（Tips）を集めたeブックを公開しました。 https://create.unity3d.com/ebook-improve-workflow こちらのeブックは英語版ですが、Unity for Proではこれの日本語訳を作成しました。第3弾の本記事では、開発者ワークフローに関する部分を紹介します。本記事の一部TipsはすでにUnity Blogでも日本語で公開していますので、そちらもご覧ください。https://blog.unity.com/ja/technology/speed-up-your-programmer-workflows

2021/12/02

開発者ワークフロー

長年Unityを使ってきた開発者でも、これは知らなかったという、ちょっとしたものながら強力で役に立つショートカットやヒントがあるものです。それはスクリプト変数にアタッチされた小さなプロパティ属性だったり、便利なのによく見過ごされるエディター設定だったり、さまざまですが、ここで皆さんにワークフローを高速化するための情報をたくさん見つけていただけると思います。

属性

Unityにはクラス、プロパティ、あるいは関数の上に置いて、特別な振る舞いを表すことのできるさまざまな属性が用意されています。C#では、角かっこ（[]）の中に属性の名前を含めます。ここでは、スクリプトに追加できる属性のうち、よく使われるものをご紹介します。

属性	説明	例
SerializeField	この属性は、Unityに非公開のフィールドをシリアライズして、インスペクターで表示するよう強制させることができます。注意：非公開のフィールドに[SerializeField]を提供すると、0649の警告を受けることがあります。これを回避するには、定義時に変数を初期化するだけです。デフォルトキーワードを使うと便利です。	[SerializeField] private GameObject myObject = default;
Range	この属性を使うと、浮動小数点数型または整数型の変数の値を特定の範囲に制限することができます。インスペクターではフィールドがスライダーとして表示されます。	[Range(1,6)] public int integerRange; [Range(0 2. f, 0 8. f)] public float floatRange;
HideInInspector	この属性を使うと、変数をシリアライズしながら、インスペクターでは非表示にできます。	[HideInInspector] public int p = 5;
RequireComponent	この属性を付けると、必要なコンポーネントを依存として追加し、設定エラーを回避します。注意：この属性はゲームオブジェクトにコンポーネントを追加した瞬間だけチェックを行います。	// PlayerScript はゲームオブジェクトがRigidbody を持つよう要求します[RequireComponent(typeof(Rigidbody))] public class PlayerScript: Monobehaviour { private Rigidbody rBody; void Start() { rBody = GetComponent<Rigidbody>(); } }
Tooltip	この属性を付けると、ユーザーがインスペクターでフィールドにマウスカーソルを合わせた時にツールチップを表示するようになります。	public class PlayerScript: Monobehaviour { [Tooltip(“Health の値は 0 から 100です”)] int health = 0; }
Space	この属性を付けると、フィールド間に小さなスペース（追加のテキストは除く）を入れ、フィールドを視覚的に分割して表示するようにできます。	[Space(10)] // 10 ピクセルのスペースを追加 int p = 5;
Header	この属性を付けると、太字のテキストとスペースが追加して、インスペクター内の変数を整理することができます。ひとまとめにしたい一連のフィールドの最初のフィールドにだけこの属性を追加します。	public class PlayerScript: Monobehaviour { [Header(“Health Settings”)] public int health = 0; public int maxHealth = 100; [Header(“Shield Settings”)] public int shield = 0; public int maxShield = 0; }
Multiline	この属性を付けると、文字列を複数行に分けて編集できるようになります。オプションで整数を渡すことで、行数を指定することができます。ヒント：自分自身や他のユーザーに対するメモをスクリプトに付けておくためにこの属性を使います。	[Multiline] public string textToEdit; [Multiline(20)] public string moreTextToEdit;
SelectionBase	この属性は、それ自体は空だが、子オブジェクトにメッシュが含まれるゲームオブジェクトを選択する場合に便利です。ベースとなるオブジェクトの任意のコンポーネントにこの属性を追加します。エディターでオブジェクトを選択した時、[SelectionBase]属性を持つゲームオブジェクトは子より優先して選択されるようになります。	// これをベースとなるゲームオブジェクトに追加する [SelectionBase] public class PlayerScript: Monobehaviour { }

インスペクターのフィールドに影響する属性

ここに示したのは多数の属性のほんの一例にすぎません。値を失わずに変数の名前を変えたり、空のゲームオブジェクトを使わずにロジックを発動させたりしたいという方は、スクリプティングAPIのリファレンスで、属性の完全なリストをご覧ください。先に挙げたことも含め、いろいろな仕掛けを作ることが可能です。

また、独自のPropertyAttributeを作って、スクリプトの変数で使うカスタムの属性を定義することもできます。

カスタムウィンドウとインスペクター

Unity の最も強力な機能の 1 つは、拡張可能なエディターです。UI Toolkit パッケージまたは IMGUI モードを使用して、カスタムウィンドウやインスペクターなどのエディター UI を作成します。

UI Toolkit は、標準的な Web 開発と同じようなワークフローを持っています。HTML や XML からヒントを得て作られたマークアップ言語「UXML」を使って、ユーザーインターフェースや再利用可能な UI テンプレートを定義します。その後、Unity Style Sheets（USS）を適用して、UI のビジュアルスタイルや動作を調整します。

また前述のように、即時モードである IMGUI を使うこともできます。Editor を基底クラスとする派生クラスを作り、CustomEditor 属性を使用します。

どちらのやり方でも、カスタムインスペクターを作ることができます。

カスタムエディターでは、インスペクターでの MyPlayer スクリプトの表示方法が変更されています。

UI Toolkit または IMGUI のいずれかを使用してカスタムエディタースクリプトを実装する方法については、「ユーザーインターフェース (UI)」を参照してください。UI Toolkit の簡単な紹介は、動画「Getting started with Editor scripting」チュートリアルでご覧になれます。

カスタムメニュー

Unityにはエディターのメニューとメニューの項目をカスタマイズする簡潔な方法として、MenuItem属性が用意されています。これをスクリプト内の任意の静的メソッドに適用することができます。

プロジェクトでよく使う関数がある場合は、それらをメニュー項目にして整理しましょう。こうすると、PropertyAttribute修飾子1つだけで基本的なユーザーインターフェイスを構築することができます。

再生モードの設定

再生モードに入ると、ビルドと同じようにプロジェクトが実行され始めます。再生モード中にエディターで行った変更は、再生モードを終了するとリセットされます。

エディターで再生モードに入るたびに、Unity は 2 つの重要なアクションを実行します。

Domain Reload（ドメインの再ロード）：Unity が、スクリプトの状態をバックアップ、アンロード、再作成します。
Scene Reload（シーンの再ロード）：Unity はシーンを破棄し、再ロードします。この 2 つのアクションは、スクリプトやシーンが複雑になればなるほど、時間がかかります。

スクリプトを変更する予定がない場合は、Enter Play Mode 設定（Edit > Project Settings > Editor）を活用して、コンパイル時間を短縮してください。Unity には、ドメインの再ロード、シーンの再ロード、またはその両方を無効にするオプションがあります。これにより、再生モードを素早くオン・オフすることができます。

ただし、スクリプトに変更を加える場合は、ドメインの再ロードを再度有効にする必要があることに注意してください。同様に、シーンのヒエラルキーを変更した場合は、シーンの再ロードを再度有効にする必要があります。そうしないと、予期せぬ動作が発生する可能性があります。

ドメイン再ロードとシーン再ロードの設定を無効にすることによる影響

スクリプトテンプレート

新しいスクリプトを作成する際に、同じ変更を繰り返してしまうことはありませんか。また、何も考えずに名前空間を追加したり、Update イベント関数を削除したりしていませんか。お好みのスタートポイントにスクリプトテンプレートを設定することで、キー操作を省き、チーム全体で一貫性を保つことができます。

新しいスクリプトやシェーダーを作成するたびに、Unity は以下の場所に保存されているテンプレートを使用します。

%EDITOR_PATH%DataResources%ScriptTemplates

Windows の場合、これは C:Program Files\Unity\Editor\DataResources\ScriptTemplates となります。
Mac の場合、これは /Applications/Hub/Editor/[version]/Unity/Unity.app/ Contents/Resources/ScriptTemplates となります。

デフォルトの MonoBehaviour テンプレートは 81-C# Script-NewBehaviourScript.cs.txt というファイルに格納されています。

また、シェーダーやその他のビヘイビアスクリプト、アセンブリ定義などのテンプレートも用意されています。

プロジェクト固有のスクリプトテンプレートについては、Assets/ScriptTemplates フォルダーを作成し、スクリプトテンプレートをこのフォルダーにコピーしてデフォルトを上書きします。

また、すべてのプロジェクトのデフォルトのスクリプトテンプレートを直接変更することもできますが、変更する前に必ずオリジナルのバックアップを取っておいてください。

オリジナルの 81-C# Script-NewBehaviourScript .cs .txtファイルは次のようになっています。

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

#ROOTNAMESPACEBEGIN#
public class #SCRIPTNAME# : MonoBehaviour
{
    // Start は最初のフレームの更新の前に呼ばれる
    void Start()
    {
        #NOTRIM#
    }

    // Update は毎フレーム1回呼ばれる
    void Update()
    {
        #NOTRIM#
    }
}
#ROOTNAMESPACEEND#

こちらの 2 つのキーワードを覚えておくと便利です。

#SCRIPTNAME# は、入力されたファイル名またはデフォルトのファイル名（例：NewBehaviourScript）を示します。
#NOTRIM# は波括弧の中に一行分の空白が含まれていることを保証します。

たとえば、整理された状態を保つために、デフォルトのMonobehaviourにデフォルトのリージョンを持たせるように設定する場合があるかもしれません。

/*
* Modified template by Unity Support.
*/

using UnityEngine;

public class #SCRIPTNAME# : MonoBehaviour
{
    #region Public Fields #endregion

    #region Unity Methods void Start()
    {
    }

    void Update()
    {
    }
    #endregion

    #region Private Methods #endregion
}

Unity エディターを再起動すると、カスタムの MonoBehaviour を作成するたびに、変更内容が表示されるようになります。

また、他のテンプレートも同様に変更することができます。オリジナルのコピーと修正したものを、Unityプロジェクト以外の場所に保管しておくことを忘れないでください。

Addressables

Addressable アセットシステムは、ゲームを構成するアセットの管理を簡素化します。シーン、プレハブ、テキストアセットなど、あらゆるアセットを「アドレス可能（addressable）」とマークして、一意な名前を与えることができます。このエイリアスはどこからでも呼び出すことができます。

ゲームとそのアセットの間にこのような抽象化された層を挟むことで、個別のダウンロード可能なコンテンツパックを作成するといった作業を効率化することができます。また、このシステムは、ローカル、リモートを問わず、それらのアセットパックを参照することも容易にします。

この例では、Addressables はプレハブの一覧を追跡しています。

Addressables の使用を開始するには、パッケージマネージャーから Addressables パッケージをインストールし、プロジェクトにいくつかの基本的な設定を行います。プロジェクトの各アセットやプレハブには、「addressable」にするためのオプションが必要です。インスペクターのアセット名の下にあるオプションをチェックすると、そのアセットにデフォルトの一意なアドレスが割り当てられます。

Addressable オプションを有効にし、デフォルトの Addressable 名を設定する。

マークすると、対応するアセットが Window > Asset Management > Addressables > Groups を選択して表示されるウィンドウに表示されます。

Addressables Groups ウィンドウでは、各アセットのカスタムアドレスをその場所を組にして確認できる。

使いやすいように、アセットの各アドレスの名前を変更できます。アセットごとに Address フィールドでアドレスの名前を変更することもできますし、すべてのアセットのアドレスを一度に簡略化することもできます。

メニュー操作ひとつで Addressable の名前を簡略化したり、個別に名前を変更したりすることができる。

デフォルトのビルドスクリプトを使って、Addressable グループのアセットバンドルを生成する。

これらのアセットをバンドルにして別の場所にあるサーバーでホスティングしたり、プロジェクト内でローカルに配布したりすることができます。各アセットがどこにあっても、システムは Addressable Name に入っている文字列を使ってアセットを見つけることができます。

Addressable API を使って、Addressable アセットを利用できるようになりました。

たとえば、Addressables がない場合、プレハブをシーンにインスタンス化するためには、以下のコードを実行する必要があります。

public GameObject prefabToCreate;

public void CreatePrefab()
{
    GameObject.Instantiate(prefabToCreate);
}

この方法の欠点は、参照されたプレハブ（上記の例では prefabToCreate）が、シーンで必要ではなくてもメモリにロードされてしまうことです。

Addressables を使う場合はこのようになります。

public string prefabByAddress;
…
public void CreatePrefabWithAddress()
{
    Addressables.Instantiate(prefabByAddress, instantiationParameters, bool);
}

この方法では、必要になるまで（CreatedPrefabWithAddress の中でAddressables.Instantiateを呼び出すまで）、プレハブはメモリにロードされません。さらに、Addressables を使用して高レベルの参照カウントを行い、使用されなくなったバンドルとその関連アセットを自動的にアンロードすることができます。

ブログ記事「最適化の最前線から：Addressables を使ってメモリを節約する」では、Addressables グループを整理してメモリ効率を上げる方法の例を示しています。また「Addressables: Introduction to concepts」チュートリアルは、Addressable アセットシステムが皆さんのプロジェクトでどのように機能するかを簡潔にまとめた内容となっています。

ライブゲームの運営：Addressables と Cloud Content Delivery の併用

ライブゲームを運営しているのであれば、Unity の Cloud Content Delivery（CCD）ソリューションと Addressables の併用を検討してみてはいかがでしょうか。Addressables システムは、ゲームアセットを保存し、カタログ化することで、ゲームアセットを自動的に見つけ、呼び出すことができます。そして、CCD はそのアセットを、コードとは完全に切り離して、プレイヤーに直接プッシュします。

これにより、ビルドサイズが小さくなり、アップデートのたびにプレイヤーが新しいゲームバージョンをダウンロードしてインストールする必要がなくなります。詳しくは、Addressables と Cloud Content Delivery の統合について書いたこちらのブログ記事をご覧ください。

プリプロセッサディレクティブ

プラットフォーム依存コンパイル機能を使用すると、スクリプトを分割して、特定の対象プラットフォーム向けにコードをコンパイルおよび実行することができます。

こちらの例では、既存のプラットフォーム #define ディレクティブと #if コンパイラーディレクティブを利用しています。

using UnityEngine;
using System.Collections;

public class PlatformDefines : MonoBehaviour
{
    void Start ()
    {
        #if UNITY_EDITOR
            Debug.Log("Unity Editor");
        #endif
        #if UNITY_IOS
            Debug.Log("Iphone");
        #endif
        #if UNITY_STANDALONE_OSX
            Debug.Log("Stand Alone OSX");
        #endif
        #if UNITY_STANDALONE_WIN
            Debug.Log("Stand Alone Windows");
        #endif
    }
}

DEVELOPMENT_BUILD #define を使用して、スクリプトが Development Build オプション付きでビルドされたプレイヤーで実行されているかどうかを識別します。

特定の Unity のバージョンやスクリプトバックエンドに合わせて選択的にコンパイルしたり、エディターでテストする際に独自のカスタム #define ディレクティブを指定することもできます。 Other Settings パネル（Player 設定の一部）を開き、Scripting Define Symbols に移動します。

Unity のプリプロセッサディレクティブの詳細については、「プラットフォーム依存コンパイル」を参照してください。

ScriptableObjects

ScriptableObject はクラスのインスタンスから独立した形で大容量のデータを保存するデータコンテナーです。ScriptableObjectを使うと値のコピーを避けることができ、プロジェクトのメモリ使用量を抑えることができます。

これはプロジェクトでアタッチされたMonoBehaviourスクリプトに変更のないデータを格納するプレハブを使う場合に便利です。MonoBehaviourと違って、ScriptableObjectに保存されたデータはアセットとしてディスクに書き込まれ、ゲームオブジェクトにアタッチされません。そのため、セッションをまたいでデータを維持することができます。

『Dragon Crashers』では典型的なユースケースが示されています。UnitInfoDataクラスはScriptableObjectを継承しています。このクラスのインスタンスはそれぞれユニット名、スプライト、ライフの設定を持ちます。このデータはゲームプレイを通して一定なので、ScriptableObjectの中に格納するデータとして特に適しています。

ScriptableObject はデータコンテナーオブジェクトを定義する。

CreateAssetMenu属性でコンテキストメニューの項目を生成し、ディスクにアセットを作成しやすくする。各ユニットにはサウンドエフェクトや特殊能力のための追加のScriptableObjectが追加されている。

プロジェクトウィンドウでアセットを作成した後に、インスペクターでUnit Name、Unit Avatar (Sprite)、Total Healthに正しい値を設定することができます。

インスペクターを使ってScriptableObjectアセットの値を設定する。

下の画像のようにしてゲームオブジェクト（この場合、UnityControllerなど）がScriptableObjectアセットを参照できるようにします。シーンに突然ユニットが大量に出現した場合も、ScriptableObjectアセットのデータはコピーされず、メモリ消費を抑えられます。

Monobehaviourオブジェクト（上の画像のUnitController）はプロジェクト内のScriptableObjectデータアセットを参照している。

ScriptableObjectを使ってメモリを節約し、データが整理された状態を保とう。ゲームオブジェクトが多数あっても、プロジェクト内のアセットの静的なデータと設定は一度だけ設定するようにしよう。

シーンにプレハブのインスタンスを数千個追加したとしても、それらのインスタンスはすべてアセット内に格納された同じデータを参照します。値のセットを一度だけ設定すれば、一貫性をもってその値を使うことができます。

ゲームがスケールアップしてユニットの種類が増えてきた時は、単にScriptableObjectの数を増やして、適切に入れ替えながら使えば問題ありません。ゲームプレイのデータを1つのアセットに格納して、データを変える時はそのアセットだけを調整するようにして、データを管理しましょう。

ScriptableObjectはゲームプレイ中にデータが変化することがある、アプリケーションのセーブファイルの残りの部分のために永続的なデータを維持する操作を置き換えるものではありません。ScriptableObjectを使う方法は、静的なゲームプレイの設定や値を格納する上で、より適切なワークフローです。JSONまたはXMLからデータをパースするのとは異なり、ScriptableObjectアセットを読むことでゴミは発生しません（また、おまけとしてパースするより高速です）。

アプリケーションでのScriptableObjectの仕様に関する詳細な情報については、ScriptableObjectのドキュメンテーションをご覧ください。また、分かりやすい導入として動画「Better Data with Scriptables Objects in Unity」を、ScriptableObjectをシーン管理でどのように役立てるかについてはブログ記事「ScriptableObject を使ってシーンワークフローを改善しよう」をご覧ください。

最適化のヒント

保存するデータは、JSON や XML などのテキストベースのものではなく、MessagePack や Protocol Buffers などのバイナリ形式のシリアル化フォーマットを推奨します。プロジェクトレビューにおいて、これらのバイナリ形式のシリアル化フォーマットは、テキストベースのフォーマットにありがちなメモリやパフォーマンスの問題を軽減します。

アセンブリの管理

アセンブリとは、C# のコードライブラリであり、組み合わせて動作し、機能の論理的な単位を形成するように構築された、型とリソースのコレクションです。デフォルトでは、Unity はほぼすべてのゲームスクリプトを定義済みのアセンブリ、Assembly-CSharp .dllにコンパイルします。これは小さなプロジェクトには有効ですが、いくつかの欠点があります。

あるスクリプトを変更すると、そのたびに Unity は他のスクリプトも含めて全部のスクリプトを再コンパイルします。

あるスクリプトは、他のスクリプトで定義された型にアクセスできます。すべてのスクリプトがすべてのプラットフォーム用にコンパイルされます。

スクリプトをカスタムアセンブリに整理することで、モジュール性と再利用性が向上します。これにより、デフォルトのアセンブリに自動的に追加されなくなり、あるスクリプトからアクセスできるスクリプトに制限をかけることができます。

上の図のように、コードを複数のアセンブリに分割することがあります。この場合、Main のコードを変更しても Stuff のコードには影響しません。同様に、Library は他のアセンブリに依存しないため、Library のコードを他のプロジェクトで簡単に再利用することができます。

「.NET のアセンブリ」には、C# のアセンブリに関する一般的な情報があります。Unity で独自のアセンブリを定義する方法については、Unity ドキュメンテーションの「Assembly Definitions」を参照してください。

IDE サポート

Unity は、以下の統合開発環境（IDE）をサポートしています。

Visual Studio：Windows および macOS のデフォルトの IDE
Visual Studio Code（VS Code）：Windows、macOS、Linux に対応
JetBrains Rider：Windows、macOS、Linux に対応

これら 3 つの環境に対応した IDE 統合は、パッケージマネージャーにパッケージとして表示されます。

パッケージとしての IDE 統合

Windows や macOS に Unity をインストールすると、デフォルトで Visual Studio がインストールされます。

他の IDE を使用したい場合、Unity > Preferences > External Tools > External Script Editor でエディターを指定するだけで使うことができます。

Rider は ReSharper を基礎にして作られており、ReSharper のほとんどの機能を含んでいます。Unity の .NET 4.6 スクリプトランタイムでの C# デバッグをサポートしています（C# 8.0）。詳細については、JetBrains 社の Rider for Unity に関するドキュメンテーションを参照してください。

VS Code は、デバッグ、タスク実行、バージョン管理をサポートする、無料の合理化されたコードエディターです。なお、Unity では、VS Codeを使用する場合、Mono（macOS および Linux）、Visual Studio Code C# 、Visual Studio Code Debugger for Unity（公式にはサポートされていません）が必要です。

IDE にはそれぞれの良さがあります。皆さんのニーズに合った IDE の選択については、統合開発環境（IDE）サポートをご参照ください。

デバッグ

Unity Debugger を使うと、Unity のエンティティが再生モードになっている間に C# コードをデバッグすることができます。コードエディター内にブレークポイントをアタッチし、実行時にスクリプトコードの状態や現在の変数を検査することができます。

Unity エディターのステータスバーの右下にある Code Optimization モードをDebug に設定します。起動時のこのモードの設定を、Edit > Preferences > General > Code Optimization On Startup で変更することもできます。

デバッグモード

コードエディターで、デバッガーの実行を一時停止させたい箇所にブレークポイントを設定します。ブレークポイントを置きたいところの左余白（溝）の部分をクリックするだけです（またはそこを右クリックして、他のオプションを含むコンテキストメニューを表示することもできます）。ハイライトされた行の行番号の横に赤い丸が表示されます（下図参照）。

ブレークポイントのオン・オフ切り替え

コードエディターで「Attach to Unity」を選択し、Unity エディターでプロジェクトを実行します。

Unity にデバッガーをアタッチする

再生モードでは、ブレークポイントでアプリケーションが一時停止するので、変数を調べたり、意図しない動作について調べたりすることができます。

変数のデバッグ

上記のように、実行中にリストの項目が 1 つずつ積み重なっていく様子を見ていくことで、デバッグにおいて変数を検査することができます。

デバッグ制御：続行、ステップオーバー、ステップイン、ステップアウト

続行、ステップオーバー、ステップイン、ステップアウトの各制御ボタンを使って制御フロー内を行き来します。

デバッグ制御：停止

停止ボタンを押すと、デバッグを中止してエディターでの実行を再開します。

Unity プレイヤーでもスクリプトコードのデバッグが可能です。ただ、プレイヤーをビルドする前に File > Build Settings を開き、Development Build と Script Debugging の両方が有効になっていることを確認してください。Wait for Managed Debugger をチェックし、プレイヤーがスクリプトコードを実行するまでデバッガーを待機します。

コードエディターを Unity プレイヤーにアタッチするには、プレイヤーの IP アドレス（またはマシン名）とポートを選択します。その後、Visual Studio で Attach To Unity オプションを使用して通常の作業を行います。

デバッグに関する追加のヒント

Unity では、実行中のエディターの情報を視覚化するために、Debug クラスを提供しています。Console ウィンドウにメッセージや警告を表示する方法、シーンビューやゲームビューに視覚化のための線を描く方法、エディターの再生モードをスクリプトから一時停止する方法などをご確認ください。以下、ヒントを 2、3 個ご紹介します。

1. Debug.Break で実行を一時停止できます。これは、アプリケーションを手動で一時停止するのが難しいが、インスペクターで特定の値を確認したいという時に便利です。

2. コンソールメッセージを表示するためのコマンドとして、Debug.Log、Debug.LogWarning、Debug.LogErrorはよくご存じかと思います。Debug.Assertも便利です。これは条件をアサートし、失敗時にはエラーをログに記録します。ただし、UNITY_ASSERTIONS シンボルが定義されている場合にのみ動作することに注意してください。

メッセージ、警告、エラーのログをコンソールに表示する。

3. Debug.Log を使用する際には、コンテキストとしてオブジェクトを渡すことができます。コンソールのメッセージをクリックすると、Unity は Hierarchy ウィンドウのゲームオブジェクトをハイライトします。

4. Rich Text を使って、Debug.Logの内容をマークアップします。これにより、コンソールでのエラーレポートを見やすくすることができます。

5. Unity は、開発用ではないビルドから Debug ロギング API を自動的に取り除きません。

Debug.Log 呼び出しをカスタムメソッドでラップし、[Conditional] 属性でデコレーションします。

すべての Debug.Log を一度にコンパイルの対象から外すには、対応する Scripting Define Symbol を Player Settings から削除します。

これは、#if . . . #end の if プリプロセッサブロックでラップするのと同じです。詳細はこちらの「一般的な最適化」ガイドをご覧ください。

6. 物理演算のトラブルシューティングを行う時は、Debug.DrawLine と Debug.DrawRay を使えば、レイキャストの可視化を行うことができます。

Debug.DrawLine

7. Development Build が有効になっている間だけコードを実行したい場合は、Debug.isDebugBuild が true を返すかどうかを確認します。

8. Application.SetStackTraceLogType、または Player Settings の対応するチェックボックスを使って、スタックトレースを含むログメッセージの種類を決定します。スタックトレースは便利ですが、時間がかかりますし、ゴミも出ます。

Visual Studio ショートカット

IDEにVisual Studioを使っている場合は、以下のショートカットが便利です。

アクション	Windows	Mac
プロジェクト内の任意のものを検索する	Ctrl + T	Cmd + .
Unityメッセージを実装する（ボイラープレートのコード）	Ctrl + Shift + M	Cmd + Shift + M
コードブロックをコメントアウトする	Ctrl + K / Ctrl + C	Cmd + /
コードブロックのコメントを解除する	Ctrl + K / Ctrl + U	Cmd + /
クリップコードの履歴からコピーする	Ctrl + Shift + V
タスクリストを表示する	Ctrl + T	デフォルトのキーバインドなし（設定可能）
名前空間などの枠のスニペットを挿入する	Ctrl + K + S	デフォルトのキーバインドなし（設定可能）
変数の名前を変更し、すべての参照を更新する	Ctrl + R	Cmd + R
コードをコンパイルする	Ctrl + Shift + B	Cmd + Shift + B

Visual Studio でのワークフローの改善については、動画「Visual Studio Tips and tricks to boost your productivity」をご覧ください。

JetBrains Rider についてもっと触れてみたいという方は、動画「Fast C# scripting in Unity with JetBrains Rider」や、「Unity で JetBrains Rider をコードエディターとして使用するためのヒント」をご覧ください。

デバイスシミュレーター

モバイル向け開発を行っているなら、デバイスシミュレーター（現在、プレビュー版パッケージを提供中）を使って、さまざまなデバイスでのアプリケーションの実行シミュレーションを行うことができます。すべてのターゲットハードウェアを実機で持っていても、デバイス別にコンテンツをビルドするのは時間がかかります。

デバイスシミュレーター

デバイスシミュレーターを使って、実際にビルドを作る前に手早くプレビューを実行しましょう。特定の解像度やハードウェアの設定をシミュレーションし、ゲームビューでUIを物理的なノッチやカットアウトに合うように調整することができます。

UIをデバイスの物理スクリーンに合わせて調整する。

デバイスシミュレーターはハードウェアのパフォーマンスも近似的に再現します。品質設定をRAM、チップセットなどのハードウェア仕様に合わせて設定しておくと、ゲームコードがプラットフォーム上で実行された時の挙動のシミュレーションを行うことができます。

事前定義済みのスマートフォンやタブレットのリストはパッケージ（com. unity.device-simulator/com.unity.device-simulator フォルダー内）に収録されています。デバイス定義はJSONファイルに格納されており、デバイスのリストはパッケージがアップデートされるにしたがって拡張されます。ブログ記事「新機能『Device Simulator』でモバイル開発のイテレーションを加速させよう」を読んだり、デバイスシミュレーターを動作させているこちらのデモ動画を視聴したりして、さらに多くのヒントに触れてください。

コンソールログのエントリ

デフォルトでは、コンソールログのエントリは2行で表示されます。これを1行にまとめてもっと読みやすくするようにできます（画像をご覧ください）。

コンソールログエントリのオプション

1行にまとめる他に、より長いエントリを表示するために2行より多い行数に設定することもできます。

カスタムのコンパイラーステータス

Unityでコンパイルが行われる時に表示される右下角のアイコンが見づらいという方もいらっしゃると思います。以下のカスタムエディタースクリプトを使って、EditorApplication.isCompiling を呼びます。こうすると、コンパイラーステータスをフロートさせたウィンドウに表示してもっと見やすくすることができます。 MenuItemを立ち上げてウィンドウを初期化します。オプションで、新しいGUIStyleを使い、好みの見た目に変更することもできます。

using UnityEditor;
using UnityEngine;
public class CustomCompileWindow : EditorWindow
{
    [MenuItem("Examples/CustomCompileWindow")]
    static void Init()
    {
        EditorWindow window = GetWindowWithRect(typeof(CustomCompileW- indow), new Rect(0, 0, 200, 200));
        window.Show();
    }

    void OnGUI()
    {
        EditorGUILayout.LabelField(“Compiling:”, EditorApplication.isCompiling ? "Yes" : "No");
        this.Repaint();
    }
}

この記事はいかがでしたか？