architecture - こねねこ Wiki - こねねこ

3Dのゲーム、又はそれに類するシステムの設計(基本形)

前もって書きますが これが常に正しい選択ではありません、選択肢は無数にあります。 これは選択肢の一つです。 さらに、私は知識や経験に乏しいので、これはものすごくダメな設計であるかもしれません。 そのときは修正します。

3Dのpresentation layerの複雑さは実装した人には理解できますが、 これに余計なコードを入れてさらに複雑にするのは避けたいです。 なので、presentation layerとdomain layerは独立して存在させたい。 独立することで最小限の実装に抑えることができます。 混ぜたら複雑になりすぎです。

domain layerが無視できるほど小さい場合や、全体の規模が小さいものには向いていません。 分割しないで実装した方がコード量が少なくなるからです。

三層に分ける

• presentation layer (キー入力、マウス入力、画面出力など)
• application layer (presentation layerとdomain layerを繋ぐ)
• domain layer (計算したりする)

これらの依存関係

presentation layer <- application layer -> domain layer

presentation layerとdomain layerが独立して存在、application layerがこれらを用いる。

メリット

• 目的の分割
• 複雑さの膨張を防ぐ

デメリット

• 初期コードが多い
• コードの重複が発生する場合がある

実装
presentation layer, domain layerはできる限りシンプルに実装する。 application layerは雑になってもなんとかなるだろう。 wiki:scenegraph はpresentation layerで用いる。

リソース
resourceはpresentation layerで使うもの、domain layerで使うもの、その両方で使うものがある。 使いまわしを考えると余計な依存関係が発生して複雑になるかもしれない。 そういう場合は二重に存在してもいいから分けた方が単純になるかもしれない。 同じデータが二つ三つメモリ上に存在することを気にするほどメモリ制限があるわけじゃないなら、何の問題もない。

presentation layerでのScene, Window

ウィンドウが一つ、シーンが複数なら。 Scene has Windowでシーンごとにクラスを実装するのがいいと思う。 Windowは必要ならsingletonにできる。 Sceneの切り替えはapplication layerで行う。 Sceneで完結できるコードを多く書けるなら、domain layer実装の負担は減る。

application layerのMapper

presentation layerとdomain layer間の通信にはMapperを使うのがいいと思う。 MapperはSceneのデータをdomain layerに渡し、domain layerのデータをSceneに渡す。 Mapperの数はSceneの数と同じだけ必要になる。

追記

少し試行錯誤した

application layerの役割

input controllerとしての役割、シーン切り替えの役割、view mapperとしての役割の三つ。 規模が大きくなったり複雑になるなら分割を考える。 最初から分けることを考えるとコードが増えて無意味に複雑になる。 presentation layerからcontrollerとしての役割を移動する。 場合によってはview has windowの関係も削除できる。

追記8723

もう少し考えた

View.draw(Model)のメリットデメリット

Modelへの依存をdrawメソッドだけにしてViewを実装する。 結論を先に書くと、使っても使わなくてもそれぞれのメリットがある。 Modelの規模が大きくなるほどModel Stubでのテストが面倒になる。 代わりにdraw抜きでViewのテストを行うと簡単になる。 ModelからViewへ直接値を入れることができるので実装は減る。 Viewの描画メソッドをpublicにしなくても動くので実装を少なくできる。 Modelを意識して実装することになるので、Modelの影響は受けやすくなる。 Modelの変更が複数のView.drawに影響を与える。 Viewの実装目的がModelを描画することになる、Viewの完成の前提条件がModelの完成になる。 置き換えるほど魅力的な選択ではないので、選択肢の一つとして。

Application Controller

追加、差し替えに強い。 可読性は高くないのでグラフを描いたほうがわかりやすい。 コードの重複を排除できる。 ツールとの相性は良さそう。 Modelを介さず入力に反応しなければならない場合は、 Domain CommandにView向けのコマンドを追加するか、Viewから入力処理を開始する。 Application Controllerを使うよりも、ThreadやFiber等を使う方が可読性は高いと思う。

ThreadやFiberの利用

直感的に書けて可読性が高い。 入力はControllerから開始する、必要ならViewを呼び出す。 Threadは同期を取るのが難しく、場合によっては致命的なバグを生む。 できればtango.core.Fiberを使いたい。 シーン数と入力パターンを全て把握できるならApplication Controllerではなくこちらの方がいいかも。 gotoを毛嫌いしない。