MRが楽しい

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

Unityに設計おけるクラス設計を考える その8(ゲーム通知の仕組み)

おいかけっこアプリの修正枠です。
ひとまずPresenterによってゲーム全体のオブジェクト間通信が成功したので、一部リファクタリングを実施しました。
bluebirdofoz.hatenablog.com


本日、再設計を実施したのはPresenterを介してのユーザ操作の通知の仕組みです。
前回の記事では「キーボードのBを押したとき、キャラクタが休憩動作をする」という動作例をお見せしました。
bluebirdofoz.hatenablog.com


このとき、「キーボードの B がキャラクタの休憩動作である」という判定をゲームUI側オブジェクトが行うのか。
それともキャラクター操作側のオブジェクトが行うかという設計の悩みが発生します。

Viewは通知先の実体を知らないべきという考えから、キャラクター操作側のオブジェクトでこの判定を行うよう修正を行いました。
修正後は下記のような処理の流れが発生します。

「ゲームUIオブジェクトがキーボードの B の押下を検出したとき、Presenterが Bear というシグナルを受け取る」

「Presenterが Bear というシグナルをキャラクター操作オブジェクトに送る」

「キャラクター操作オブジェクトは Bear というシグナルを休憩動作の実行と解釈する」

これならばView同士はお互いの実体を全く知らないため、ゲームUIの差し替えも、キャラクターロジックの差し替えも容易に実施できます。
f:id:bluebirdofoz:20170602012039j:plain


一方でゲームUI上に「休憩」ボタン、「ジャンプ」ボタンなどのゲームの実体を知っている前提の画面UIを出すことが難しくなるというデメリットもあります。
この辺りはメリット、デメリットの綱引きですが、とりあえずは当初の設計思想を守ることを優先していきます。