Unity開発における最適アーキテクチャー

Unityが3Dや2Dのゲーム開発に適した開発環境であることは周知のとおりですが、 Unityに適したシステム開発の手法(システムアーキテクチャー、システムフレームワーク)が語られることはあまりありません。

それは以下のような要因があるかと思います。

  • Unityの開発規模が小さいためアーキテクチャーを考える必要がない
  • Unityの開発者(リーダー)がゲーム開発しか行ったことがなくアーキテクチャーって何という状態
  • 作業役割が完全に分かれてしまっているために、各担当に実装方法を任せてしまっている

他にもいくつか思いつく要因はありますが、それはここでは割愛します。

さて本題に入りますが、Unity開発に適したシステムアーキテクチャーとは何でしょう?

私が導いた現時点での結論は、プレゼンター (Presenter) を軸に、ビュー (View)、ビューモデル (ViweModel)、おまけでモデル (Model) を用いるアーキテクチャーです。

Unity システム アーキテクチャー

一般的な概念としてはMVPに結構近い形です。

さて、このアーキテクチャーを用いる理由ですが、ゲームオブジェクト (GameObject) に付与したビヘイビアー (Behaviour) を疎結合とすることにあります。

特徴(メリット)は以下のようになります。

  • 構造的役割と範囲が明確になる
  • ビューモデル(VM)とモデル(M)部分を Unity IDE から分離できる
  • DLLが分離できる
  • テストがしやすい
  • プレゼンター(P)を介したビューと(V)とビューモデル(VM)の双方向バインディングを実現できる
  • デザイン側で生じた変更への対応労力が減少する

ただ、双方向バインディングを実現するためにはMVVMを実装可能にしなけらばならず、そのためには ReactiveProperty の実装が必要不可欠です。

そうすることによる課題(デメリット)は以下のようになります。

  • 標準のUnityの作りがなんの参考にもならなくなる
  • 開発難易度が上がる
  • 問題が発生した場合の解決難易度が上がる
  • 既存のシステムからの変更は新規開発と同じくらいの開発工数がかかる

ただし、こういったデメリットを考慮しても、得られるメリットのほうが断然大きいと思います。 (特に開発終盤、さらに開発完了後に受けられる恩恵が)

一度このアーキテクチャー(フレームワーク)を経験したら、アーキテクチャーなしのUnityには戻れないなと私自身は感じていますので、これから本格的にUnity開発を行ってみたいという方は、是非ともこのアーキテクチャーの構築に挑戦してみてはいかがでしょうか?

 |