MVC（Model-View-Controller）ゲームエンジンアーキテクチャ-はい、いいえ？[閉まっている]

Game Coding Completeという素晴らしい本を読んでいます。その本は、MVC（Model-View-Controller）アプローチを使用することを強く推奨しています。

1. ゲームアプリケーションレイヤー
2. ゲームロジック
3. ゲームビュー

私にとって、このアプローチはモバイルコンピュータゲームにとってはやり過ぎのように見えます。

あなたの意見はどうですか？モジュール間に余分な通信が必要になっても、このアーキテクチャを実装する価値はありますか？この設計は非常に多くのCPUパワーを消費する可能性があり、最終的には、実装されていない場合よりも結果が大幅に遅くなりますか？

単純なモバイルゲームであっても、MVC構造の使用をある程度サポートしています。何もしなければ、それは十分に何度も噛まれていない開発者を悩ます問題に役立ちます：ディスプレイコードをゲームロジックから分離します。

ただし、MVCはすべてのデザインパターンと同様に、あなたの生活を楽にするために存在していることを忘れないでください。つまり、MVCを使用するときに行うべきこととすべきでないことに関する規則のセット内に留まることが、あなたの人生をより難しくしている場合、それを無視します。次の2つのいずれかが発生します。1）後で噛まれ、最初に別の方法でそれを行うと、実際には長い目で見れば人生が楽になった理由を理解するか、2）結果がまったくない。

コンピュータープログラミングは、その性質上、実際に何かを成し遂げるよりもエレガントな原則を堅持することを重視する多くのルールフォロワーを獲得します。彼らにあなたを彼らの一人にさせないでください。あなたのゲームで起こりうる最も重要なことは、それを出荷することです。

コンパイル時のデザインは、信じられないほどひどいコンパイラーがない限り、CPUパワーを消費しません。オブジェクト指向の言語またはアプローチは、手続き型とパフォーマンス特性に違いはありません。MVCを使用するための追加のオーバーヘッドは発生しません。モジュール性は、ランタイムではなくコンパイル時に存在します。コードがインライン化および最適化されると、まったく違いは生じません。

多くの最新のゲームは、実際にはモデルとビューを別々のスレッドで実行し、ほとんどのプラットフォームで大きなパフォーマンス上の利点を獲得しています。

最終的に、MVCは優れた設計であり、メンテナンスを増やし、バグなどを無料で減らすことができます。使用しない理由はありません。for手書きgotoのsの代わりにループを使用する理由を尋ねるようなものです。優れたデザインを念頭に置いていない限り、何よりも優れていることは間違いありません。

編集：コンパイル時のデザインはCPUパワーを消費しません。継承のような実行時設計は明らかにそうです。

ほとんどの場合、コードの明瞭さとプログラムの技術的要件（速度、メモリなど）の間にはトレードオフがあります。オブジェクト指向言語は手続き型言語と比較してオーバーヘッドがありますが、特にコードの長期的なメンテナンス（バグなど）で、手続き型言語よりも多くの利点があり、多くの場合、開発速度も向上することが示されています。

それを念頭に置いて、ゲームプログラマーとしてMVCを実装する価値があると提案します。あなたのコードはオブジェクト指向の原則、特にカプセル化によりよく従い、それを維持するのがずっと簡単になるでしょう（バグの修正や新機能の追加）。

一方、ゲームを実際に終了し、「エンジン」での作業に時間を費やさないようにしてください。

詳細については、「ゲームアーキテクチャでMVCおよびTDDが採用されないのはなぜですか」という質問をお読みください。そして私の本当に長い答え。