Unityプロジェクトを整理するためのベストプラクティス

Unityプロジェクトを整理するための唯一の方法はありませんが、以下の重要な推奨事項があります：

• 命名規則とフォルダー構造を文書化する。スタイルガイドおよび/またはプロジェクトテンプレートは、ファイルを見つけやすく、整理しやすくします。チームに合ったものを選び、全員がそれに賛同していることを確認してください。
• 命名規則を一貫させてください。選択したスタイルガイドやテンプレートから逸脱しないでください。命名ルールを変更する必要がある場合は、影響を受けるアセットを一度に解析して名前を変更してください。変更が多数のファイルに影響する場合は、スクリプトを使用して更新を自動化することを検討してください。
• ファイル名やフォルダー名にスペースを使用しないでください。Unityのコマンドラインツールは、スペースを含むパス名に問題があります。スペースの代わりにCamelCaseを使用してください。
• テストやサンドボックスエリアを分けてください。非生産シーンや実験用の別のフォルダーを作成してください。ユーザー名を含むサブフォルダーは、チームメンバーごとに作業エリアを分けることができます。
• ルートレベルに余分なフォルダーを作成しないでください。一般的に、コンテンツファイルはAssetsフォルダー内に保存してください。プロジェクトのルートレベルに追加のフォルダーを作成しないでください。絶対に必要な場合を除いて。
• 内部アセットをサードパーティのものから分けてください。Asset Storeや他のプラグインからアセットを使用している場合、それらには独自のプロジェクト構造がある可能性があります。自分のアセットを分けておいてください。

注：プロジェクトのためにサードパーティのアセットやプラグインを修正する場合、バージョン管理を使用するとプラグインの最新の更新を取得できます。更新がインポートされると、差分を確認して修正が上書きされている可能性のある場所を見つけ、再実装できます。

設定されたフォルダー構造はありませんが、以下の2つのセクションは、Unityプロジェクトをどのように設定するかの例を示しています。これらの構造は、アセットタイプによってプロジェクトを分割することに基づいています。

アセットタイプマニュアルページでは、最も一般的なアセットについて詳しく説明しています。フォルダー構造を整理する際のさらなるインスピレーションとして、テンプレートまたは学習プロジェクトを使用できます。これらのフォルダー名に制限されるわけではありませんが、良い出発点を提供することができます。

Unity Hubからテンプレートまたはスタータープロジェクトのいずれかをダウンロードすると、サブフォルダーがアセットタイプによって分割されていることに気付くでしょう。選択したテンプレートに応じて、いくつかの一般的なアセットを表すサブフォルダーが表示されるはずです。

最初から強力なプロジェクト構造を定義することで、後でバージョン管理の問題を回避できます。アセットをあるフォルダーから別のフォルダーに移動すると、多くのVCSはこれをファイルを削除して別のファイルを追加することと見なします。これにより、元のファイルの履歴が失われます。

Plastic SCMは、Unity内でのファイル移動を処理し、移動したファイルの履歴を保持できます。ただし、.metaファイルがアセットファイルと一緒に移動するように、エディター内でファイルを移動することが重要です。

プロジェクトのフォルダー構造を決定したら、エディタースクリプトを使用してテンプレートを再利用し、今後のすべてのプロジェクトに同じフォルダー構造を作成します。エディターフォルダーに配置されると、以下のスクリプトは「PROJECT_NAME」変数に一致するアセット内のルートフォルダーを作成します。これを行うことで、自分の作業をサードパーティのパッケージから分離できます。

空のフォルダーはバージョン管理に問題を引き起こすリスクがあるため、本当に必要なものだけのフォルダーを作成するようにしてください。GitやPerforceでは、空のフォルダーはデフォルトで無視されます。そのようなプロジェクトフォルダーが設定されていて、誰かがそれをコミットしようとすると、フォルダーに何かが置かれるまで実際には機能しません。

注：一般的な回避策は、空のフォルダー内に「.keep」ファイルを置くことです。これにより、フォルダーがリポジトリにコミットされるのに十分です。

Plastic SCMは空のフォルダーを扱うことができます。ディレクトリはPlastic SCMによってエンティティとして扱われ、それぞれに独自のバージョン履歴が付随します。

これはUnityで作業する際に留意すべきポイントです。Unityはプロジェクト内のすべてのファイルに対して、フォルダーを含む.metaファイルを生成します。GitやPerforceでは、ユーザーは空のフォルダーのための.metaファイルを簡単にコミットできますが、フォルダー自体はバージョン管理に含まれません。別のユーザーが最新の変更を取得すると、彼らのマシンには存在しないフォルダーのための.metaファイルがあり、Unityはその.metaファイルを削除します。Plastic SCMは空のフォルダーをバージョン管理に含めることで、この問題を完全に回避します。

Unityはプロジェクト内の他のすべてのファイルに対して.metaファイルを生成し、通常は自動生成されたファイルをバージョン管理に含めることは推奨されませんが、.metaファイルは少し異なります。Version ControlウィンドウでVisible Meta Filesモードをオンにする必要があります（ビルトインのPlastic SCMまたはPerforceモードを使用していない限り）。

この.metaファイルは自動生成されますが、それに関連付けられたファイルに関する多くの情報を保持しています。これは、テクスチャ、メッシュ、オーディオクリップなどのインポート設定を持つアセットに共通です。これらのファイルのインポート設定を変更すると、変更は.assetファイルではなく.metaファイルに書き込まれます。だからこそ、あなたは.metaファイルをリポジトリにコミットするのです - すべての人が同じファイル設定で作業できるように。

基準に合意することは、プロジェクトのフォルダー構造で止まりません。すべてのゲームアセットに特定の命名基準を設定することで、チームが互いのファイルで作業する際に物事が容易になります。

GameObjectsに対する明確な命名基準はありませんが、上の表を考慮してください。

単一の大きなUnityシーンは、コラボレーションには適していません。アーティストやデザイナーが単一のレベルでスムーズにコラボレーションできるように、レベルをいくつかの小さなシーンに分割し、競合のリスクを最小限に抑えましょう。

ランタイムでは、プロジェクトはSceneManagerを使用してシーンを追加的にロードできます。LoadSceneAsyncを使用してLoadSceneMode.Additiveパラメーターを渡します。

可能な限り作業をPrefabに分割し、ネストされたPrefabの力を活用することがベストプラクティスです。後で変更が必要な場合は、シーンではなくPrefabを変更することで、シーンで作業している他の人との競合を避けることができます。Prefabの変更は、バージョン管理下でのdiffを行う際に、しばしば読みやすくなります。

シーンの競合が発生した場合、UnityにはシーンとPrefabをマージするために使用されるビルトインのYAML（人間が読みやすいデータシリアル化言語）ツールもあります。詳細については、Unityのドキュメントのスマートマージを参照してください。

プリセットを使用すると、Inspector内のほぼすべてのデフォルト状態をカスタマイズできます。プリセットを作成すると、選択したコンポーネントやアセットの設定をコピーし、それらを独自のアセットとして保存し、後で他のアイテムに同じ設定を適用できます。

プリセットを使用して基準を強制したり、新しいアセットに合理的なデフォルトを適用したりします。これにより、チーム全体で一貫した基準を確保し、一般的に見落とされがちな設定がプロジェクトのパフォーマンスに影響を与えないようにできます。

コンポーネントの右上にあるプリセットアイコンをクリックします。プリセットをアセットとして保存するには、現在の保存先…をクリックし、値のセットをロードするために利用可能なプリセットの1つを選択します。

プリセットを使用するための他の便利な方法は次のとおりです：

• デフォルトでGameObjectを作成：プリセットアセットをヒエラルキーにドラッグアンドドロップして、対応するコンポーネントを含む新しいGameObjectを作成します。
• 特定のタイプをプリセットに関連付ける：プリセットマネージャー（プロジェクト設定 > プリセットマネージャー）で、タイプごとに1つ以上のプリセットを指定します。新しいコンポーネントを作成すると、指定されたプリセット値がデフォルトになります。
• ヒント：タイプごとに複数のプリセットを作成し、フィルターを使用して名前で正しいプリセットを関連付けます。
• マネージャー設定の保存とロード：設定を再利用できるようにするために、マネージャウィンドウのプリセットを使用します。例えば、同じタグやレイヤー、物理設定を再適用する予定がある場合、プリセットは次のプロジェクトのセットアップ時間を短縮できます。

コーディング標準は、チームの作業を一貫性のあるものに保ち、開発者がプロジェクトの異なる領域をスワップしやすくします。ここに石に刻まれたルールはありません。チームにとって最適なものを決定する必要がありますが、一度決めたらそれを守るようにしてください。

例として、名前空間はコードをより正確に整理できます。これにより、プロジェクト内のモジュールを分離し、クラス名が重複する可能性のあるサードパーティのアセットとの競合を避けることができます。

注：コード内で名前空間を使用する際は、より良い整理のために名前空間ごとにフォルダー構造を分けてください。

標準ヘッダーも推奨されます。コードテンプレートに標準ヘッダーを含めることで、クラスの目的、作成日、作成者などの情報を文書化するのに役立ちます。これは、バージョン管理を使用していても、プロジェクトの長い履歴の中で簡単に失われる可能性のあるすべての情報です。

Unityは、プロジェクト内で新しいMonoBehaviourを作成する際に読み込むスクリプトテンプレートを使用します。新しいスクリプトやシェーダーを作成するたびに、Unityは%EDITOR_PATH%\Data\Resources\ScriptTemplatesに保存されたテンプレートを使用します。

• Windows：C:\Program Files\Unity\Editor\Data\Resources\ScriptTemplates
• Mac: /Applications/Hub/Editor/[version]/Unity/Unity.app/Contents/Resources/ScriptTemplates

デフォルトのMonoBehaviourテンプレートはこれです：81-C# Script-NewBehaviourScript.cs.txt

シェーダー、他の動作スクリプト、およびアセンブリ定義のためのテンプレートもあります。

プロジェクト固有のスクリプトテンプレートのために、Assets/ScriptTemplatesフォルダーを作成し、このフォルダーにスクリプトテンプレートをコピーしてデフォルトをオーバーライドします。

すべてのプロジェクトのデフォルトスクリプトテンプレートを直接変更することもできますが、変更を加える前に元のバックアップを取ることを忘れないでください。各Unityのバージョンには独自のテンプレートフォルダーがあるため、新しいバージョンに更新するときは、再度テンプレートを置き換える必要があります。以下のコード例は、元の81-C# Script-NewBehaviourScript.cs.txtファイルがどのように見えるかを示しています。

以下の例では、役立つかもしれない2つのキーワードがあります：

• #SCRIPTNAME#は、入力されたファイル名またはデフォルトのファイル名（例えば、NewBehaviourScript）を示します。
• #NOTRIM#は、ブラケット内に空白の行が含まれることを保証します。

独自のキーワードを使用し、それをエディタースクリプトで置き換えてOnWillCreateAsset メソッドを実装できます。

以下のスクリプト例のヘッダーをスクリプトテンプレート内で使用してください。このようにして、すべての新しいスクリプトは、その日付、作成者、元々所属していたプロジェクトを示すヘッダー付きで作成されます。これは、将来のプロジェクトでコードを再利用するのに役立ちます。