Unity1週間ゲームジャムで制作したもじもじフラグメンツ というゲームのソースコードです
- 名前空間はCleanArchitecture (のサンプルレイヤー) っぽいですが、MVPに近そうです。この辺りあんまり自信ないです
- 何かあれば色々ご意見いただけたらと思います (リプでもコメントでも)
- View
- Unityからのイベントを受け取って通知したり、Unity側の描画情報を更新する
- ViewはUseCase/Entityのことを知らず、複雑な計算やゲーム内処理は行わない (UnityAPIを叩くだけ)
- MonoBahaviourもしくはUIBehaviourを継承する
- UseCase
- Viewから通知を受け取りEntityを更新したり、Entityから通知を受け取りViewに描画命令を投げたりする中間層
- ビジネスロジック (更新や判定) をUseCaseに寄せている
- UseCaseは他のUseCaseを知らず、Entityを介して処理を伝搬する
- Entity
- 情報を保持/精査/更新する
- 状態の更新を通知する
- EntityはView/UseCaseのことを知らず、他のEntityのことも知らない
このゲームではキーボードのUIボタンを選択すると、フォームに文字が入力されます。
- Viewでは どういう処理でイベントを通知するか のみを定義しています
- UseCaseにて、通知を受けた時にどういう処理をするか を記載しています
- 今回の場合は Entityの中に情報を格納し、フォームに描画する という処理が実行されています
- 実際のEntityの中では Validateしつつ文字を追加 しています
- メッセージを送信するタイミングで 更新されたEntity を参照するようにしています。
- 画面下部のインフォメーションを更新するタイミングで InfoEntity にテキストを渡します
- InfoEntity が テキストを更新し、更新されたことを通知 します
- InfoUseCase が 通知を受け取り、Viewに描画命令を投げます
- ✨ メリット
- どこにコードを書けばいいか迷わない
- ゲーム内処理多めなクイズやカードゲームなどでは良い感じに整理出来そう
- イベントの流れがシンプルで追いやすい
- どこにコードを書けばいいか迷わない
- 😭 デメリット
- コード量が増えて正直ゲームジャム向きではない、慣れないと本質(ゲームの面白さや完成)でないところで疲弊する
- 特にMonoBehaviourに処理を寄せがちなアクションやシューティングゲームにはそこまで利点がないかも
- 一方ゲームジャムの目的を何にするか、ということにも依存し、例えば「アーキテクチャを学習する」を主目的にするのであれば、あり
- コード量が増えて正直ゲームジャム向きではない、慣れないと本質(ゲームの面白さや完成)でないところで疲弊する
- マルチプレイの実装に PUN2 を使用しています
- 初めて実装しましたが、意外とすんなり対応できました
- @o8que さんの 資料が神掛かっていた おかげです、Photon使ってみたい人は全員読みましょう
- イベントを監視するために UniRx を使用しています。
- PureC#クラスの生成・レイヤー間の依存関係の解消 (UseCaseがViewやEntityを認知している状態にする) に VContainer を使用しています