Unityでのプロジェクト間アクセスの基礎(MonoBehaviourを継承しないクラス + 外部DLLの利用)
この資料では、Unityでのスクリプト間アクセス方法、アクセス修飾子 internal
および public
の使い方、MonoBehaviour
を継承しないクラスの使用方法、また外部DLLの利用について解説します。UnityのC#スクリプトにおけるアクセス範囲やクラスの再利用方法を理解するための資料です。
前提条件
- Unity の基本的な使い方を知っている
- C# プログラミングの基礎知識
- 複数のスクリプトファイルを使用する
MonoBehaviour
を継承しないクラスの使い方に慣れている
Unity内でのスクリプト間アクセス(MonoBehaviour
を継承しないクラス)
Unityでは、通常のC#プロジェクトと同様に、スクリプト間でクラスやメソッドを共有することができます。ただし、MonoBehaviour
のライフサイクルを利用しない場合は、MonoBehaviour
を継承しない通常のC#クラスとしてクラスを定義し、new
でインスタンス化することができます。
ステップ 1: Unityプロジェクトの作成
- Unity Hub から新しい3Dまたは2Dプロジェクトを作成します。
Assets
フォルダー内に2つのスクリプトを作成します。
InternalClassExample.cs
PublicClassExample.cs
InternalClassExample.cs
(アクセス範囲が internal
)
namespace MyNamespace
{
// internal クラスは同じアセンブリ(通常は同じプロジェクト)内でのみアクセス可能
internal class InternalClassExample
{
public string GetInternalMessage()
{
return "これは internal クラスです!";
}
}
}
PublicClassExample.cs
(アクセス範囲が public
)
namespace MyNamespace
{
// public クラスは他のプロジェクトやスクリプトからアクセス可能
public class PublicClassExample
{
public string GetPublicMessage()
{
return "これは public クラスです!";
}
}
}
ステップ 2: クラスの利用
Unityのスクリプト間でこれらのクラスを使用します。PublicClassExample
は他のスクリプトからアクセスできますが、InternalClassExample
は同じ名前空間やアセンブリ内でのみ使用可能です。
UseClasses.cs
(new
でインスタンス化)
using UnityEngine;
using MyNamespace;
public class UseClasses : MonoBehaviour
{
void Start()
{
// MonoBehaviourを継承していないクラスは new でインスタンス化できる
PublicClassExample publicClass = new PublicClassExample();
Debug.Log(publicClass.GetPublicMessage());
// InternalClassExampleはinternalなのでアクセスできない(エラーになります)
// InternalClassExample internalClass = new InternalClassExample(); // エラー: InternalClassExampleにアクセスできない
}
}
結果
Unityのコンソールに次のメッセージが表示されます。
これは public クラスです!
一方、InternalClassExample
にアクセスしようとすると、コンパイルエラーが発生します。これは、internal
修飾子によってクラスのアクセスがプロジェクト内に制限されているためです。
アクセス修飾子の違い(Unity版)
public
- 他のスクリプトからアクセス可能:
public
修飾子がついているクラスやメンバーは、同じアセンブリ内だけでなく、他のスクリプトからもアクセス可能です。 - 例:
PublicClassExample
は、他のスクリプトやアセットから使用できます。
internal
- 同じアセンブリ内でのみアクセス可能:
internal
修飾子は、そのクラスやメンバーを同じアセンブリ(通常は同じプロジェクトや名前空間)内でのみアクセス可能に制限します。他のプロジェクトやスクリプトからはアクセスできません。 - 例:
InternalClassExample
は、同じ名前空間・アセンブリ内でのみ使用可能です。
外部DLLの利用
Unityでは、C#のプロジェクトで生成したDLLを使用することが可能です。ここでは、外部DLLをUnityプロジェクトで利用する方法について説明します。
ステップ 1: 外部DLLを準備
- Visual Studioなどを使って、クラスライブラリ(.NET)を作成します。ここでは、前述の
ClassLibrary1
を例にします。
MyClass.cs
(DLLの中身)
namespace ClassLibrary1
{
public class PublicClass
{
public string GetMessage()
{
return "これは DLL の public クラスです!";
}
}
}
- このプロジェクトをビルドして、
ClassLibrary1.dll
を生成します。
ステップ 2: UnityにDLLをインポート
- Unity のプロジェクトの
Assets
フォルダーに、ビルドしたClassLibrary1.dll
をドラッグ&ドロップします。 - UnityがDLLを認識し、スクリプト内でそのクラスを使用できるようになります。
ステップ 3: DLLクラスの利用
Unityのスクリプト内で、DLLからインポートしたクラスを使用します。
UseDLLClass.cs
using UnityEngine;
using ClassLibrary1; // DLLからのクラスを参照
public class UseDLLClass : MonoBehaviour
{
void Start()
{
// 外部DLLのクラスで、MonoBehaviourを継承していないクラスは new でインスタンス化可能
PublicClass publicClass = new PublicClass();
Debug.Log(publicClass.GetMessage());
}
}
結果
Unityのコンソールに次のメッセージが表示されます。
これは DLL の public クラスです!
このように、外部のC# DLLをUnityプロジェクトにインポートすることで、クラスや機能を再利用することができます。
フォルダー構成(DLLをインポートした後)
UnityプロジェクトにDLLをインポートした後のフォルダー構成は以下のようになります。
/Assets
│
├── /Scripts
│ ├── InternalClassExample.cs
│ ├── PublicClassExample.cs
│ ├── UseClasses.cs
│ └── UseDLLClass.cs
│
├── /Plugins
│ └── ClassLibrary1.dll <-- インポートされたDLLファイル
│
└── /Scenes
└── SampleScene.unity
Plugins
フォルダーについて
- Pluginsフォルダー: Unityでは、外部DLLやネイティブライブラリを使用する際に
Plugins
フォルダーがよく使われます。ここにDLLを置くことで、UnityはそのDLLをスクリプトから使用できるようにします。
まとめ
MonoBehaviour
を継承しないクラスは、通常のC#クラスと同様にnew
でインスタンス化できます。これにより、Unityのコンポーネントシステムに依存せずに、クラスのインスタンスを作成して使用することが可能です。- 外部DLLをUnityにインポートすることで、他のC#プロジェクトで作成した機能やクラスを再利用できます。
public
とinternal
のアクセス修飾子を使い分けることで、スクリプト間やプロジェクト間でのクラスの可視性を制御できます。
これにより、Unityでのプロジェクト間アクセスや、外部DLLの利用に関するガイドラインが理解でき、実際のプロジェクトでの適用も容易になります。
DLL化のメリット・デメリット
Unityにおいて、外部ライブラリをDLL化して利用することは可能ですが、必ずしも推奨されるアプローチではありません。具体的には、DLL化のメリットとデメリットがあるため、プロジェクトの規模やニーズに応じて判断する必要があります。
DLL化のメリット
- 再利用性:
- 他のプロジェクトやチームメンバーとコードを共有する場合、DLLとして提供することで、コードを簡単に再利用できます。
- セキュリティと隠蔽:
- ソースコードを公開せずに、バイナリ形式(DLL)で提供することができるため、コードを外部に隠蔽したい場合に有効です。
- ビルド時間の短縮:
- 大規模なプロジェクトでは、ソースコードをすべてビルドするのに時間がかかる場合があります。DLLを利用することで、特定の部分を事前にビルドしておき、全体のビルド時間を短縮することができます。
- プラットフォームごとの柔軟な対応:
- 特定のプラットフォーム(例: iOS, Android)に合わせたDLLを用意し、条件付きで使用することができます。
DLL化のデメリット
- デバッグの難易度が上がる:
- DLLは事前にビルドされたバイナリであり、デバッグ時に中身を追うことができません。Unity内でDLLを使用する際、バグが発生した場合のトラブルシューティングが難しくなることがあります。ソースコードをプロジェクト内に保持していれば、Unityエディター内でのデバッグが容易です。
- プラットフォーム依存:
- DLLが特定のプラットフォーム(例: Windows用)に依存している場合、異なるプラットフォーム(例: macOS、Android)にビルドするときに問題が発生することがあります。特にUnityでは、クロスプラットフォーム対応が重要なので、DLLがすべてのターゲットプラットフォームで動作することを確認する必要があります。
- メンテナンスが複雑:
- プロジェクトが進化するにつれて、DLL化された部分の更新が必要になる場合がありますが、その度にDLLをビルドし直す必要があります。プロジェクト内でソースコードとして管理していれば、修正も簡単です。
- Unity特有のAPIとの整合性:
- UnityのAPIは頻繁にアップデートされるため、DLL化されたコードが古くなってしまうことがあります。Unityのバージョンアップにより、DLL内のコードが使っているAPIが変更され、互換性に問題が出る可能性もあります。
DLL化が有効な場合
- 外部ライブラリの統合: 他のC#プロジェクトからUnityにライブラリを持ち込む場合や、サードパーティ製ライブラリを利用する場合は、DLL化が効果的です。特に、ゲームエンジンやサーバーサイドのコードをUnityで利用する際には便利です。
- 特定のプラットフォームに向けた最適化: プラットフォームごとの最適化や機能をDLLとしてまとめ、Unityプロジェクトに組み込むことで、異なるプラットフォームごとに異なるDLLを使用できます。
Unityで推奨される構成
一般的に、Unityでは以下のアプローチが推奨されることが多いです。
- スクリプトをそのままプロジェクトに含める: UnityのC#スクリプトは簡単に編集、デバッグ、更新できるため、プロジェクトに含めておくのが最もシンプルで効果的な方法です。
- パッケージマネージャーの利用: Unityのパッケージマネージャー(UPM)を使用して、ライブラリやコードを管理する方法もあります。これにより、コードをパッケージとして共有し、依存関係を簡単に管理できます。
- サードパーティ製のツールの利用: Unity Asset Store などで提供される外部のツールやライブラリは、Unityに特化しており、DLL化された形で提供されることもありますが、これらは検証済みのため、安心して利用できる場合が多いです。
まとめ
UnityでのDLL化は、再利用性やセキュリティの観点でメリットがあるものの、デバッグの難しさやプラットフォーム依存性など、プロジェクトによってはデメリットもあります。Unity特有のAPIを頻繁に使用するスクリプトやデバッグを頻繁に行うコードは、可能な限りプロジェクト内にソースコードとして保持し、DLL化は慎重に判断することが推奨されます。
ディスカッション
コメント一覧
まだ、コメントがありません