読者です 読者をやめる 読者になる 読者になる

MRが楽しい

MRやVRについて学習したことを書き残す

Unityに設計おけるクラス設計を考える その2(MVP設計)

前回の続きとなります。
・Unityに設計おけるクラス設計を考える その1(アプリの現状)
 http://bluebirdofoz.hatenablog.com/entry/2017/04/26/013327

昨日は気付いたらベッドで眠っていました。
でも折角続けている1日1記事ペースを止めたくないので今回はほぼ文字だけですが設計検討を行います。
(因みに夢は地球がUFOに侵略される夢でした…その中でも頑張って仕事に行ってました。偉い…のか?)

調査したMVP設計を考慮して、まずはオブジェクトの構成について検討してみました。
・Web出身のUnityエンジニアによる大規模ゲームの基盤設計
 https://developers.cyberagent.co.jp/blog/archives/4262/
・昨今のUnity開発におけるMVP設計思想についてと、それの適用可否の話
 http://yutakaseda3216.hatenablog.com/entry/2017/02/22/151204


以下、試そうと考えているオブジェクトの構成。

・GameLogic:ロジック統合オブジェクト
 └MainLogic:メインロジック
・GameInformation:ゲームデータ統合オブジェクト
 └Database:ゲーム情報
・Camera:カメラ統合オブジェクト
 └MainCamera:メインカメラ
・Light:ライト統合オブジェクト
 └Lights:通常ライト
・GameUI:ゲームUI統合オブジェクト
 ├Keyboard:キーボードUI
 ├Speech:音声認識UI
 └Gesture:ジェスチャ認識UI
・HeadUpDisplay:画面表示UI統合オブジェクト
 ├FixedUI:位置固定の表示UI(input,output)
 └FollowingUI:追従(ディスプレイ位置固定)の表示UI(output)
・MainCharactor:メインキャラクタ統合オブジェクト
 ├ControlLogic:コントロールロジック
 │├ManualMode:マニュアル操作モードロジック
 │├CatchMode:追いかけっこ(追)モードロジック
 │└RunMode:追いかけっこ(逃)モードロジック
 └ModelManager:モデルマネージャ
  ├unitychan_dynamic:キャラクタオブジェクト
  │├FaseController:表情変更スクリプト
  │├MotionController:動作変更スクリプト
  │└Status:状態保持スクリプト
  ├Effect:効果オブジェクト
  └ColliderObject:アタリ判定オブジェクト
・Field:フィールド統合オブジェクト
 ├SpatialMapping:空間マッピング
 └TestField:テスト用フィールド
  ├TestStopCube
  ├TestJumpCube
  └TestPlane

MVP設計において各オブジェクトがそれぞれの役割を持つイメージです。
f:id:bluebirdofoz:20170427093156j:plain
Model:GameInformation(ゲームデータ統合オブジェクト)のオブジェクト
Presenter:GameLogic(ロジック統合オブジェクト)のオブジェクト
View:上記以外のオブジェクト全て

その他、実装時の各オブジェクトの関係については以下の決まりとします。

最上位層のオブジェクトが下位オブジェクトへのインタフェースを保持する。
PresenterはModelと各Viewの最上位オブジェクトのインタフェースのみ知っている。
ModelとViewはPresenterへの状態変更またはイベントの通知を投げる。
ただしModelとViewはPresenterの実体を知らない。

視点とハンドジェスチャーは別UIと考える。
ゲームUI統合オブジェクトで視点、ハンドジェスチャー音声認識を統合して一つのアクションを通知する。
(特定のオブジェクトを選択するなど)

視点操作などでUI外のオブジェクトが通知される場合、オブジェクトをそのままPresenterに通知する。
そのオブジェクトが何であるかはPresenterが解釈を行う。
(画面表示UIをGameUIに含めないのはこの為。画面表示UIは選択可能なゲームオブジェクトの一つとして考える)


以上です。まだ検討段階で、実際に試してはいないため、色々問題はあるかも。