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

Unity プロジェクトを整理する方法は 1 つではありませんが、いくつかの重要な推奨事項を以下に示します。

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

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

フォルダー構造は決まっていませんが、次の 2 つのセクションでは、Unity プロジェクトを設定する方法の例を示します。これらの構造はどちらも、プロジェクトを資産タイプ別に分割することを基本としています。

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

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

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

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ウィンドウで、表示可能なメタ ファイル モードをオンにする必要があります (組み込みの Plastic SCM モードまたは Perforce モードを使用している場合を除きます)。

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

標準に関する合意は、プロジェクト フォルダー構造で終わるわけではありません。すべてのゲーム アセットに特定の命名標準を設定すると、チームが互いのファイルで作業するときに作業が簡単になります。

GameObject には明確な命名標準はありませんが、上記の表を参考にしてください。

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

実行時に、プロジェクトは LoadSceneMode.Additive パラメータ モードを渡す LoadSceneAsync で SceneManager を使用してシーンを加算的に読み込むことができます。

可能な限り作業をプレハブに分割し、ネストされたプレハブの力を活用するのがベストプラクティスです。後で変更を加える必要が生じた場合は、シーンで作業している他のユーザーとの競合を避けるために、プレハブが含まれているシーンではなくプレハブを変更することができます。多くの場合、バージョン管理下で差分を実行すると、プレハブの変更が読みやすくなります。

シーンの競合が発生した場合に備えて、Unity にはシーンとプレハブをマージするために使用される YAML (人間が読めるデータシリアル化言語) ツールも組み込まれています。詳細については、Unity ドキュメントの 「スマートマージ」 を参照してください。

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

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

コンポーネントの右上にある プリセット アイコン をクリックします。プリセットをアセットとして保存するには、[現在の設定を保存...] をクリックし、使用可能なプリセットの 1 つを選択して値のセットを読み込みます。

プリセットを使用するその他の便利な方法を次に示します。

• デフォルトの 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メソッドを実装できます。

スクリプト テンプレート内で、次のスクリプト例のヘッダーを使用します。この方法では、新しいスクリプトは、日付、作成者、および元々属していたプロジェクトを示すヘッダー付きで作成されます。これは将来のプロジェクトでコードを再利用する場合に役立ちます。