All content in this course uses:

Unity のヒント

Unity の開発をより速く、より便利にするためのヒントとコツのコレクションです。

移動、回転、またはスケーリングするときに、CTRL(PC)またはCMD(Mac)を押しながらオブジェクトをスナップします。また、V を使用して頂点をスナップすることもできます。スナップの設定を変更するには、[Edit] - [Snap Settings] を選択します。

スナップ

Inspector でプレビュー ウィンドウとよく仕事をしていますか?上部のバーを右クリックしてドッキングを解除し、任意の場所に配置して、快適に作業することができます。

プレビュー ウィンドウのドッキングを解除する

カメラをすばやく簡単に配置する方法が必要ですか?[GameObject] - [Align with View] を使ってみてください。

カメラを簡単に配置する

再生モードの場合、Unity はシーン内のゲームオブジェクトのインスタンスへの変更を保存しません。そのため、編集を続けるには、常に再生をオフにする必要があります - 再生中にエディターに色を付けることでこれを行うことを思い出してください。

再生モードのエディターの色合い 

Unity の特定のコンポーネントに関するヘルプを見つける必要がありますか? 各コンポーネントヘッダーの右側にある本のアイコンをクリックするだけです。

ドキュメントのショートカット

微調整のために Inspector の Float変数を公開していますか?スクリプトの変数の上に Range 宣言を追加すると、パブリック変数をすぐにスライダーに変えることができます。

[Range(min, max)] を使用して、パブリック変数をスライダーとして表示します

Hierarchyウィンドウの検索ボックスにて、スクリプトまたはコンポーネントの大文字と小文字を区別する完全な名前を入力すると、その名前がアタッチされているゲームオブジェクトが表示されます。

シーン内のオブジェクトをコンポーネント名で検索する

エディターの任意の int または Float フィールドに直接数学計算を入力します。

数値フィールドでの数学計算

選択されていないときに空のゲームオブジェクトを表示するには、標準またはカスタムのアイコンを割り当てます。

シーンビューの空のゲームオブジェクトにカスタムアイコンを使用する

この簡単なヒントでは、単一のコンポーネントの設定をコピーする方法、または再生モード中に行った変更を復元するためにゲームオブジェクト全体をコピーする方法を示します。

再生モードで行った変更をコピーして復元する方法

Unity で作業する大きな利点の 1つは、エディターのインターフェースと Inspector パネルを簡単かつ素早くで使用できることです。変数は、Inspector で使用するには公開されている必要がある...本当にそうでしょうか？いいえ！Inspector でプライベート変数を公開および操作するには、「Serialize Field」属性を使用します。

Inspector にプライベート変数を表示する

新しいスクリプトの作成とアタッチは、Addコンポーネントボタンメニューの検索フィールドを使用して素早く行うことができます。

Add コンポーネントショートカットで新しいスクリプトを素早く作成する

Unity には、ファイルを整理する方法やゲーム制作の方法が数多く用意されています。この自由度により、迅速なプロトタイピングが可能になりますが、プロジェクトが大きくなったときにプロジェクトを開いたり、ナビゲートしたり、開発したりするのが遅くなる可能性があるという代償が伴います。このガイドでは、それを軽減する方法のヒント、およびプロジェクトを開始する際に考慮すべきヒントを提供します。

Unity プロジェクトの作業を開始する前に、いくつかのステップについて考える必要があります。

ソースコード管理システムを使用することは、どのプロジェクトにとっても非常に重要です。ミスを最小限に抑えるための保護手段を提供し、複数の人との作業を簡素化します。Unity には、

 と呼ばれるソースコード管理がエディターにシームレスに統合されています。

Git、Svn、Mercurial、Perforce などの外部ツールを使用している場合は、いくつかの設定をする必要があります。

 は、他のコンピュータでプロジェクトを開く必要はなく、リポジトリを乱雑にしてストレージを不必要に使用してしまうため、選択したソースコード管理システムから除外してください。

Edit > Project Settings > Version Control

:これにより、アセットの隣にメタファイルが配置され、そこにパラメータとインポート設定が保存されます。これにより、インポート設定と参照を共有して、これらのファイルをバージョン管理に含めることができます。それ以外の場合、これらの設定はライブラリ フォルダーに格納され、チームのメンバー間で共有できません。

 と進み、次のように設定します。

: すべてのUnityファイル（ScriptableObjects、Scenes、Prefabs、その他多数）がバイナリ表現の代わりにテキスト表現を使用するようにします。これにより、ソース管理システムは、ファイルの新しいコピーではなく、これらのファイルが変更されたときに変更を保存するだけで、コンフリクトを手動でマージできます

（非常に大きなプロジェクトでは、テキストアセットのインポートに必要な追加の時間がバイナリアセットに対して非常に顕著な違いを生む可能性があります。ほとんどのプロジェクトは、バイナリに対するテキストの利点がインポート時に克服されるサイズのしきい値に達しないため、最初にテキストに設定することをお勧めします)

Perforce ワークスペースの設定で、「revert unchanged files」を使用します。これにより、変更されていないファイルの不要なコミットを防ぐことができます。

プロジェクトの標準を決定して、プロジェクトに取り組む全員が同じ標準を使用するようにします。

 : Unityの1つの単位が何であるかを決めましょう。そうしないとモデルやスプライトは統一されたスケールで作成されません。オブジェクトごとに異なるスケーリングを導入すると、あらゆる問題を引き起こす可能性があります。

Rigidbody コンポーネントを使用するほとんどの3Dゲームでは、物理演算システムが適切なシミュレーションのためにそれを必要とするため、1単位 = 1メートルを使用してください

Rigidbodyコンポーネントを使用する2Dゲームの場合、1メートルと1単位に等しい「基本スプライトサイズ」定義する。たとえば、32px = 1メートル, 1単位などです。すべてのスプライトの 

をその値に設定すると、高さ64px、PPUが32の場合は、物理演算システムでは2単位、つまり2メートルの高さになります。

 あなたのアセットはすべて命名規則に従うべきです。接尾辞 (テクスチャの例では 

法線マップは N 、アンビエントオクルージョンマップは _AO

) または接尾辞 (バリエーションにおける LowRes, HighRes_ など) を追加するなどです。検索を通じてフィルターをかけることができ、カスタムインポーター設定値を自動的に書き込むこともできます。

Unity エディターの Project ウィンドウを使用して、アセットを整理します。Unity は、アセットのインポート設定を保存する各アセットファイルの隣にメタファイル (有効になっている場合は、ソースコード管理システムを参照) を保持します。つまり、

OSファイルエクスプローラーでファイルを移動するのを避け

、必ず Unity エディター内でそれらを移動するようにしてください。エディターの外部に移動する必要がある場合は、 

 それらと一緒にメタファイルを移動することを忘れないでください

、そうしないと参照とインポート設定が失われます。

プロジェクトをナビゲートしやすくするために、Assetsフォルダーのルートにファイルを配置しないでください。サブフォルダーを使用しましょう。これらのサブフォルダをどのように整理するかは、通常プロジェクトによって異なりますが、それを行う主な方法は次のとおりです。

アセットの種類ごとのフォルダーと、オブジェクトやゾーンごとのサブフォルダー (例えば

オブジェクトまたはゾーンごとのフォルダー (

Assets/Level1/Enemies/Archer, Assets/Shared/UI, Assets/Forest/Trees

) には、フォルダー内のアセットに関連するすべてのアセット(

を使用する予定がある場合に役立ちます。特定のバンドルに親フォルダーを追加するだけで、コンテンツテーマごとにバンドルを作成し、関連するアセットを異なるバンドルに簡単に分割できるためです。

プロトタイプまたはプレースホルダーに関連するすべてのものを別のフォルダー階層に保持し、それらのフォルダーと本番用のアセット/コードを含むフォルダー間での相互参照を避けてください。たとえば、「通常の」ファイル階層内にあるキャラクタープレハブは、プロトタイプフォルダ内のテストマテリアルを参照してはいけません。プロトタイプ フォルダーにプロトタイプ キャラクタープレハブを作成し、プロトタイプ以外のシーンでそのプレハブを使用しないようにします (プロトタイプ フォルダー内のオブジェクトが使用する参照をチェックするエディタースクリプトを作成して、このルールが実行されるようにすることもできます)。

Resources フォルダーの使用はできるだけ避けてください。

Resources は Unity の特別なフォルダー名で、コード内にて 

 で配置されたアセットを動的に読み込むことができます。一部のゲームでは動的にロードされたアセットが必要とされますが、Unity はそこにある未使用のアセットを取り除けない (コードでロードしたかどうかを判別できない) ため、そのフォルダー内のすべてが最終的なビルドに含まれます。そのため、できるだけ最小化するようにしてください。

コード内でアセットをパスとファイル名で読み込むため、コード内でパスやファイル名を手動で変更する必要があり、リファクタリング (ファイルの移動や名前の変更) が難しくなり、エラーが発生しやすくなります。

直接参照 (Monobehaviour のパブリック変数) を使用して、エディターを通じて割り当てる。これにより、ファイルの移動や名前の変更もサポートされます。

 を使用する必要がある、もしくは使用したい場合は、

 を使用して、実行をブロックしないようにしてください (一部のデバイスでは、読み込みに時間がかかる場合があります)。この関数は 

 を返すため、更新のたびにポーリングして終了したかどうかをチェックすることもできるし、このようにcompletedイベントを使うこともできます: 

Assets フォルダー内のソースアセットを避ける

Unityは、さまざまなソフトウェア (Photoshop、3DS Studio Max、Blenderなど) から直接ソースファイルをインポートする方法を提供しています。迅速なテストやプロトタイピングに使用する場合、 

プロトタイピングやテストの段階を過ぎたアセットをソース管理システムにコミットしたり、Assets フォルダーに保持したりしないでください

通常、これらのファイルはエクスポートされたファイルよりも大きくなります。ファイルが大きいとソース管理履歴が乱雑になり、1つのファイルを変更するたびにソース管理システムは新しいバージョンを保存し、リポジトリのサイズが爆発的に大きくなります。

これらのファイルは、Unityプロジェクトを開くマシンにインストールされているソフトウェアに依存しています。適切なソフトウェアをインストールしていない共同作業者やビルドマシンは、プロジェクトを開くことができません。

これらのファイルは、別のソース管理ソフトウェア (バイナリファイルにより適している) に保存するか、それができない場合は、Unity がそれらをインポートしないように Assets フォルダーの外に保存し、Unity がインポートしないようにして、アセットを Unity と互換性のある 形式でエクスポートして Assets フォルダーに配置し、ゲームで使用することをお勧めします。

アセットのサイズを小さく保つ

アセットのサイズをできるだけ小さくするようにしてください (悪い例は、テーブル上のコーヒーマグの 2048x2048 テクスチャをエクスポートすることです)。Unity のインポート設定でテクスチャのサイズを減らすできますが、それではテクスチャのインポート時間は短縮されず、プロジェクトの新しいバージョンでの初期設定にかかる時間が大幅に長くなります。

どの形式でもローカルでテストしますが、一旦決めたら、オーディオファイルと画像ファイルには圧縮形式を使用してください。画像の場合は .png/.tga/.tiff (画像ソフトウェアがエクスポートをサポートしている場合は .dds でも可)、オーディオの場合は .ogg です。Unity はインポート (または単にそのまま使用) をはるかに速く行い、プロジェクトの元のインポートサイズを削減します。

Assembly Definition Files (ADF) は、フォルダーとそのサブフォルダー内のすべてのスクリプトを個別の DLL にコンパイルします。これにより、変更されたスクリプトファイルが属する dll のみに分割されるため、コンパイル時間が短縮されます。たとえば、すべての Enemies スクリプトに ADF がある場合、enemy スクリプトを変更しても、すべてのヘルパー、プレイヤー、ゲーム システム、または UI スクリプトが再コンパイルされるわけではなく、Enemies に関連するスクリプトのみが再コンパイルされます。

複数人のチームでは、ゾーン/アセット/フィーチャーの所有権を定義しましょう。シーンやプレハブなどの一部のアセットは、複数のユーザーによる同時変更をうまくハンドルできないため、競合が発生します。特定の資産を変更できる(または変更する権利を与える)ことができる人が1人いると、その問題を回避できます。

プレハブを使用しましょう。たくさん。プレハブは、ゲーム内のオブジェクトの設定を変更することができる単一のポイントです。元のプレハブの変更は、それをネストしたものにはプッシュされないので 

Scriptable Objects を使用しましょう。たくさん。プレハブと同様に、シーンやオブジェクト間で共有できる設定を変更できる単一の場所を提供します。Scriptable Objects が他の Scriptable Objects またはプレハブを参照し、シーン内のゲームオブジェクトがその Scriptable Objects を参照している場合、シーンのゲームオブジェクトがロードされると、再帰的に Scriptable Objects とオブジェクトへのすべての参照のロードがトリガーされることに注意してください。これにより、他の多くのオブジェクトやコンテンツを参照する Scriptable Objects の読み込み時間が長くなる可能性があります。ただし、プロジェクトがシーンロード時にオブジェクトを 1 回の大きなロードで読み込むことを好む場合は、これを有利に利用することもできます。

階層の深度を最小に保ちましょう。一般的なルールとして、1 つの大きな階層よりも、複数の小さな階層をルートに配置する方が望ましいです。

階層の深さを最小にする理由は、Unity Transform システムは、Transform が変更されたときにすべての子に通知するために、その階層を辿る必要があるためです。

複数の階層がある場合は、変更が階層ごとに追跡されます。したがって、ルートに 100 の階層があり、その中の 1 つのオブジェクトを変更すると、1 つの階層だけが Transform 走査の対象となります。ただし、ルートに 1 つの大きな階層がある場合、どのオブジェクトに変更を加えても、すべてのオブジェクトに階層の変更を引き起こすことになります。さらに、Unity は ルートゲームオブジェクト階層の Transform 変更チェックをマルチスレッド化します。階層が多ければ多いほど、Unity はマルチスレッド化し、フレームごとに複数の Transform の変更をスピードアップできます。

 (静的環境メッシュ、ライト、サウンド) を 1 つの階層で作成することで、シーンナビゲーション/整理が簡素化されます。これらは Transform が変更されることがないため、上記の欠点は適用されません。

階層の深さを保ち、ルートに階層を分散させるには、次のようにします。

純粋なゲームプレイオブジェクトをグラフィックス、物理演算、オーディオ表現と一緒にネストしないでください。キャラクターと一緒に動く必要がないものがあれば、その子にしないでください。たとえば、ナビメッシュエージェントのキャラクターのパトロールポイントを扱うゲームオブジェクトを持つのは、そのキャラクターの子になります。すべての純粋なゲームプレイゲームオブジェクトは、できるだけルートに近づける必要があります。

同様に、ゲームオブジェクトを動的に作成する場合は、そのオブジェクトと一緒に移動する必要がある場合を除き、オブジェクトを作成したオブジェクトの子にしないでください

階層の深さを減らすことは、エンジンの性能だけでなく、プロジェクトに取り組む人の使いやすさと快適さにも有益です。階層が浅いほど、理解しやすく、走査するのも簡単です。

アニメーションインポート設定の Rig タブで 

 を使用します。これにより、Rig の「skeleton」ゲームオブジェクトが作成されなくなり、階層が減ります。まだいくつか公開する必要がある場合 (キャラクターに装備を取り付けるためのターゲットとして 1つ 使用するなど)、手動で選択して、この1つだけ公開にすることができます。

空のゲームオブジェクトを使用して、Hierarchy を整理します。たとえば、名前ゲームオブジェクト「

」は、ライトの上に配置します。

上記の「階層の深さと数」で説明されている理由により、

それをライトの親にするのではなく、単に Hierarchy 内でライトの上に置くべきであることに注意してください

もし作業を容易にするために、ライトの「header」の下にあるすべてのライトを親にして、全てを折りたためるようにしたい場合は、ビルドや再生モードに入る前に、すべてのライトの親を解除するエディタースクリプトを作成する必要があります。そうしないと、大きなシーンでパフォーマンスが低下する可能性があります。

エディターの動的オブジェクト

、エディターで作成および実行される動的オブジェクトがある場合 (たとえば、シーンビューのカメラに合わせて動くリフレクションカメラや、マテリアルに割り当てられたシーンビューで更新されるレンダーターゲットなど) は、必ず

 (または、編集するために Hierarchy で表示されたままにしたい場合は 

) に設定してください。そうしないと、位置やコンテンツの変更によってすべてシーンが汚れてしまい、毎回保存するように求められます。これにより、誰かがシーンを保存して誤ってソースコード管理にコミットした場合、これは常に誰にでも起こるため、コンフリクトが発生する可能性が高くなります。

開発/テスト/改善サイクルのスピードを向上させるためには、さまざまな機能に「チート」機能をできるだけ早く追加してください。例としては、プロジェクトに通貨がある場合は、大量の通貨を取得するためのチートを作成します。ドアを開けるためにアイテムを入手する必要がある場合は、そのアイテムを即座に付与するチートを作成します。レベルが長い場合には、プレイヤーをレベルポイントにてテレポートする方法を作成します。QAとデバッグがはるかに簡単になります。これを行うには、複数の方法があります。

[MenuItem("Cheat/MyCheat")] を使用してチートを実装する静的関数を使用すると、エディターでプレイするときにトップメニューエントリーからチートを行うことができます。

特定の順序でキーを押したり、キーボードのF1 / F2 ファンクションキーを使用したりすることに基づく古き良き「チートコード」。

キーを押すだけで開くことができ、コマンドを入力して解釈してチートを行うことができるゲーム内コンソールをコーディングする。

 定義のコードで囲むと、ビルドウィンドウの 

 チェックボックスがオフになっている状態でビルドされた場合、すべてのビルドでそれらが削除され、ゲームにチートが含まれることはありません。これには、次の 2 つの方法があります。

これにより、コンパイラーは非開発ビルドでその関数を無視することができるため、その関数への呼び出しは無視されます。

または、チート関連するコードを関数内で囲む

これにより、最終ビルドから確実に削除されます。これらの間に関数をラップすると、その関数へのすべての呼び出しがコンパイラーの存在しない関数を呼び出すことになり、ビルドが失敗することに注意してください。関数には上記の Conditional 属性を使用することをお勧めします。

小さな機能のテストシーンを使う

1 つの機能のみをテストするためだけに作成された小さなシーンを作成し、別々に保持します。例としては、戦闘をテストするための敵でいっぱいのシーン、移動をテストするための障害物コースのホワイトボックス、　インタラクション可能なオブジェクトがあるシーンなどがあります。これにより、新しい機能によって機能が壊れないように開発、改善、および検証できます。また、テスターが「完全な」ゲームで見つけた問題をより簡単に切り分けることもできます。たとえば、時々棚につかまらないキャラクターがいますか?これは、問題が発生するポイントに到達するためにゲームの最初の 5 分間を 20 回再生するよりも、小さなシーンで再現する方がはるかに簡単です。

Unity Version 2022.2