自己紹介

Unity DOTSでVRゲーム作ればまぁそれなりに戦えるだろうと思った大学生。
グラフィックがボトルネックになるのは待ったなしだし、言っちゃいけない。

前置き

そもそも、MVP(Model View Presenter)もECS(Entity Component System)もアーキテクチャの一種であるため共存させようとした私がおかしいという話は一旦置いておくとして、失敗談を話す過程でECSの設計上の特徴を話せればなと…

MVPはロジックを純粋なC#に起こせることと、UniRxなどを用いれば階層をいい感じに分けれることを特徴としているアーキテクチャ。
保守性に軸を置いている。
階層上の奴。

今回は、UniRxとVContainerを採用して構築していた。

ECSはデータ指向のアーキテクチャ。
保守性というよりもメモリを中心としたパフォーマンスを軸においている。

これらを合体すればいいじゃない。保守性も、パフォーマンスも！！

結論から言えば、まぁ無理。

ここからはアーキテクチャが破綻する理由を書いていく

ここが一番大きいが、MonoBehaviourは表に出るもの、MVPでいうとViewの部分のみを司る。
しかし、ECSではデータ（Entity）の管理もUnityが担うことになる。

つまり、MVPのModelの部分もUnityが持ってしまう状況になります。
これはPresenterの役割が全く持ってなくなることを意味します。
ModelとViewが同じ場所にあるのですから…

私がMVPアーキテクチャを学ぶときに読ませていただいた以下の記事には

Unity依存レイアと非Unity依存レイアを分けることは言っていない。
過度な期待だ

という用に記されています。

つまり、Unityが担うことになってもMVPパターンは破綻しないということです。
確かに、これはそうだと思います。
MonoBehaviourの場合でもどうしてもUnityが提供するクラスは使うことになります。

しかし、例えばModelにロジックを司るSystemを持たせ、Viewに表示などを任せるSystemを置くということをするとPresenterが全くの意味をなしません。
つまり、MVPアーキテクチャが破綻するということになります。

この記事を書いている途中に思ったのですが、これECSとMonoBehaviourの役割が明確に違うため発生している問題のなのではないかと思いました。
実態は、ECSはあくまでMVPにおけるModelでありViewではないということです。

これを前提とするとViewはUI関連のMonoBehaviourだけを格納する層となります。

これは今ECSがアニメーションやパーティクルなどを管理できないから成り立つ前提な気がします。
アップデートでこれらが追加されればMVPでは分けれなくなります。

どういった形で追加されるかも気になるところですが、実際ECSの設計でSystemをView系とModel系で分けるのは普通に良さそうですよね。

結論は、ECSはECS層とMonoBehaviourのUI層で分けるのが良さそうということでした。

まぁ、アーキテクチャを勉強し始めてまだまだ浅いためこの結論が間違っている可能性は十分あります。
ただMVPパターンの限界をちょっと垣間見れたような気がしてよかったです。

ちなみに、今回ECSでVRゲームを作ろうと思って少し触っていました。
1~2ヶ月を目途にサクッとなにかを作ろうと思っているのでまたお楽しみに。

リポジトリでは、VContainerのECSを使っていたりしますよ…！