エンティティコンポーネント
・Unityの開発思想で、必要に応じて機能（コンポーネント）をオブジェクトに付加する。
・従来のゲームオブジェクトで発生しがちな複雑な継承関係も生まれにくい。
AMVCC (Application-Model-View-Controller-Component)
・1.の参考サイトでの設計手法。(一般的なものではない。)
・Unityは参照地獄になりやすく、どこに何がアタッチされているのかが複雑になりやすい。
⇒ それを解決すべくApplicationからすべてのMVCを参照できるようにしてしまえという考え。
・MVCに属さないUtility的な機能はComponentに位置する。
・データの通知は
①View -> Application (onclickなどのアクションをトリガーとして通知する。
②Application -> Controller (viewから受け取った通知をすべてのControllerに伝達する。)
③Controller -> view or model (Controllerで対象となる通知を受け取った際はviewやmodelを更新する。)
MVC設計
・Model, View, Controllerの3層からなる。
・TriggerはControllerの呼び出し。
・ModelからViewへ通知するタイプ
⇒ Model, Viewの依存が発生する
・Controllerを介してModelを更新後Viewへ通知する。
⇒ Model と Viewの仲介を果たすので役割が大きくなる？(と記事にはあるが、あまりその感覚がない。）
MVP設計
・Uni(Rx)と呼ばれるUnityのフレームワークが必要となる。
・Model, View, Presenterの3層からなる。
・PresenterはViewとModelの連動をフレームワークを用いて登録する？
・TriggerはUni(Rx)の機能を使って登録する。（簡単なサンプルを見ただけなのでだいぶ憶測）
現状どうしているか
・現在作成しているカードゲームでは、AMVCCもどきで
ルートのGameManagerに必要なController全て突っ込んでいる。(GetComponentを使えば、ModelとViewも取得できてしまう。)
・イベント通知はせず、必要に応じてGameManagerからデータを取得し、そのコントローラを呼び出している。
(ModelとViewを直接更新しないようにはしている。)
その他問題点があれば随時記載。
・model側で値の編集が必要になった際、modelとcontrollerに値を変更する同一メソッドを二つ定義しなければならないのが手間である。
参考サイト
1.Unity with MVC: How to Level Up Your Game Development
UniRxでMV(R)Pパターンをやってみた
Web出身のUnityエンジニアによる大規模ゲームの基盤設計
若輩エンジニアから見たUniRxを利用したゲーム開発
Webアプリケーション開発者から見たMVCとMVP、そしてMVVMの違い