ゲーム開発ひいてはクライアントサイドの開発において「クリーン」かどうかは正直けっこうどうでもよく、設計すべき一番のポイントは「制御フロー」にあります。
ところがゲーム開発の場合は、こういった特徴を一般化してフレームワークに追いやれるか? というと そういうわけでもない。
「ゲーム」と一口に言っても色々で、アクションゲーム的なものとRPG的なものではかなり中身の性格は違っているし、 ゲームでは「ドメインロジックが主」というよりもむしろ、「プロジェクト固有のViewコンポネを自前でつくっていく」ことの方にどう考えても重みがある。
ゲ開発で、そのゲーム固有の色々なものをつくる、ということは、imgタグそのものを実装する、という姿が近いとおもっている。つまり、人間に理解しやすい抽象化されたデータよりも、もっと細かくて複雑なフレーム毎の見た目の変化をプログラムしていくことになることが多い。
Viewコンポネの実装の詳細はいつも複雑なので、それを外から見るともっと抽象的で扱いやすいインターフェイスにしていく必要がある(imgタグしかり) のはゲームも別に変わらない。違うのは 部品そのものを自作することがゲーム開発の主な関心事になってくること。HTMLであれば基本は 標準化されたパーツを組み合わせて集約させたものを扱うのだけど。
「ドメインロジックとプレゼンテーションの分離」はゲームであっても普通にやっといた方が良いであろう。抽象的なデータと Viewの境界は疎結合になっていないとまじで困る。 「キャラクターのデータ」 と、「画面に適用させたい対象」との関連性は、1:1 ではないし、まだ画面には出てないけどデータを参照したい、みたいなケースは死ぬほどあるからである。 つまるところMVCが言っている「Model」というのは、遷移する状態全てではなくて、「アプリケーション固有の状態」のことだからである。
しかし、なんか強力なフレームワークとか足回りを前提とした設計パターンをあてはめることはゲームでは単に手間になる。
Viewへのマッピングの自動化はあきらめた方が生産性も保守性も柔軟性も高い。
重要なことは、MとVを分けること。それからイベント発火からの制御フローを明確にすること。