ゲームアーキテクチャでMVCとTDDが採用されないのはなぜですか？[閉まっている]
私はこれを序文として、膨大な量のゲームソースを見たことがなく、ゲームのやり方で多くを構築したこともないと言います。 しかし、Webアプリで「エンタープライズ」コーディングプラクティスを採用しようとすると、ゲームのソースコードを真剣に見ると頭が痛くなります。「このビューロジックはビジネスロジックで何をしているのでしょうか。リファクタリングが必要です。 」 これを使用してゲームプロジェクトを開始しようとしているので、これを心配しています。これを使用するゲームの例があまりないので、開発プロセスをmvc / tddしようとしても邪魔されるのか、助けになるのかわかりませんまたは、コミュニティでより良いアーキテクチャの実践を推進します。 以下は、プロトタイピングゲームに関する素晴らしい記事からの抜粋です。しかし、私には、多くのゲーム開発者が本番ゲームコードを記述する際に使用しているように見える態度を正確に感じました。 間違いその4：ゲームではなくシステムを構築する ...あなたが自分の前に直接進まない何かに取り組んでいるのを見つけたら、すぐにそこで止めてください。プログラマーとして、私たちはコードを一般化し、エレガントにし、あらゆる状況に対処できるようにする傾向があります。かゆみはひっかき傷ではなく非常に難しいことがわかりましたが、その方法を学ぶ必要があります。コードではなく、最終的に出荷するゲームであることに気付くまでに何年もかかりました。 エレガントなゲームコンポーネントシステムを記述せず、エディターを完全にスキップしてコード内の状態を固定し、データ駆動型の自己解析的なXMLの狂気を避け、気の毒なことをコーディングするだけです。 ...できるだけ早く画面に表示します。 また、「余分な時間をかけてこれを正しい方法で行えば、ゲームでそれを再利用できる」という議論を決して使わないでください。今まで。 ゲームは（ほとんど）視覚指向であるため、コードがビュー内で大きく重み付けされるので、モデル/コントローラーにデータを移動するメリットはほとんどありません。 MVCがパフォーマンスオーバーヘッドを導入するという議論を聞いたことがありますが、これは時期尚早な最適化であり、MVCオーバーヘッドを心配する前に取り組むべきより重要なパフォーマンスの問題があるようです（たとえば、レンダリングパイプライン、AIアルゴリズム、データ構造トラバーサルなど）。 TDDについても同じです。テストケースを採用しているゲームはあまり見られませんが、おそらくこれは上記の設計上の問題（ビューとビジネスの混合）と、視覚的なコンポーネント、または確率的な結果に依存するコンポーネント（物理シミュレーション内で操作するなど）をテストするのが難しいという事実による可能性があります）。 おそらく間違ったソースコードを見ているだけなのに、なぜゲームデザインでこれらの「エンタープライズ」プラクティスが採用されていないのでしょうか？ゲームの要件は本当に大きく異なりますか、それとも人/文化の問題ですか（つまり、ゲーム開発者のバックグラウンドが異なるため、コーディングの習慣も異なります）。