ゲームアーキテクチャでMVCとTDDが採用されないのはなぜですか？[閉まっている]

私はこれを序文として、膨大な量のゲームソースを見たことがなく、ゲームのやり方で多くを構築したこともないと言います。

しかし、Webアプリで「エンタープライズ」コーディングプラクティスを採用しようとすると、ゲームのソースコードを真剣に見ると頭が痛くなります。「このビューロジックはビジネスロジックで何をしているのでしょうか。リファクタリングが必要です。 」

これを使用してゲームプロジェクトを開始しようとしているので、これを心配しています。これを使用するゲームの例があまりないので、開発プロセスをmvc / tddしようとしても邪魔されるのか、助けになるのかわかりませんまたは、コミュニティでより良いアーキテクチャの実践を推進します。

以下は、プロトタイピングゲームに関する素晴らしい記事からの抜粋です。しかし、私には、多くのゲーム開発者が本番ゲームコードを記述する際に使用しているように見える態度を正確に感じました。

間違いその4：ゲームではなくシステムを構築する

...あなたが自分の前に直接進まない何かに取り組んでいるのを見つけたら、すぐにそこで止めてください。プログラマーとして、私たちはコードを一般化し、エレガントにし、あらゆる状況に対処できるようにする傾向があります。かゆみはひっかき傷ではなく非常に難しいことがわかりましたが、その方法を学ぶ必要があります。コードではなく、最終的に出荷するゲームであることに気付くまでに何年もかかりました。

エレガントなゲームコンポーネントシステムを記述せず、エディターを完全にスキップしてコード内の状態を固定し、データ駆動型の自己解析的なXMLの狂気を避け、気の毒なことをコーディングするだけです。

...できるだけ早く画面に表示します。

また、「余分な時間をかけてこれを正しい方法で行えば、ゲームでそれを再利用できる」という議論を決して使わないでください。今まで。

ゲームは（ほとんど）視覚指向であるため、コードがビュー内で大きく重み付けされるので、モデル/コントローラーにデータを移動するメリットはほとんどありません。

MVCがパフォーマンスオーバーヘッドを導入するという議論を聞いたことがありますが、これは時期尚早な最適化であり、MVCオーバーヘッドを心配する前に取り組むべきより重要なパフォーマンスの問題があるようです（たとえば、レンダリングパイプライン、AIアルゴリズム、データ構造トラバーサルなど）。

TDDについても同じです。テストケースを採用しているゲームはあまり見られませんが、おそらくこれは上記の設計上の問題（ビューとビジネスの混合）と、視覚的なコンポーネント、または確率的な結果に依存するコンポーネント（物理シミュレーション内で操作するなど）をテストするのが難しいという事実による可能性があります）。

おそらく間違ったソースコードを見ているだけなのに、なぜゲームデザインでこれらの「エンタープライズ」プラクティスが採用されていないのでしょうか？ゲームの要件は本当に大きく異なりますか、それとも人/文化の問題ですか（つまり、ゲーム開発者のバックグラウンドが異なるため、コーディングの習慣も異なります）。

引用にあるように、多くのプログラマーはゲームではなくシステムを構築する（しようとする）ミスを犯します。通常、そのシステムは、理論的には何でも処理できるほど複雑になるまで制御不能になり続けますが、実際には、必要なのはコードの大きな束だけです。より頻繁に、作業段階に達する前に、実行されないコードに非常に絡み合っているため、（最初に何かがあった場合）フォーカスを失い、モチベーション（本当に機能していないため）を失います。

プロトタイプとイテレーションは、はるかによく機能する傾向があります。最終的に、素晴らしいデザインが出てくるかもしれませんが、よりシンプルで洗練されたものが出てくることがよくあります。KISSとYAGNIが思い浮かびます。

私は個人的にはバランスが必要だと信じています。ゲームのコアメカニックがある場合は、それに取り組みます。あなたはまだ反復する必要がありますが、それを改良する必要があります。ヒント：コードの編成は、ゲームのコアメカニックではありません。

適切な事例：PopCap GamesによるPeggle ゲームのコアメカニックはボール物理学です。彼らはそれを完成させました！彼らはそれがゲームを作るものであるため、絶対に完璧であることを確認するためにかなりの時間を費やしたと確信しています。しかし同時に、ゲームの初期のプロトタイプを完全に想像することができます。おそらく、ゲームのアイデアが楽しいかどうかを確認するために、画面にスプライトを描画し、何らかのプリミティブな衝突検出とバウンスを行うだけです。そして、ボールを撃って跳ね返るのが実際に楽しいことを知った後、彼らはボールの跳ね返りを改良しました。_{（これはもちろん単なる憶測です）}

また、技術要件にも依存しますので、早い段階で特定する必要があります（ゲーム設計ではなく、技術要件のみ）。ゲームを実行するプラットフォームは変更すべきではありません。また、変更を許可する必要がある場合は、変更を許可する予定の範囲を正確に知る必要があります。その上で設計します。OpenGL用のゲームを開発していて、DirectXを気にしないのであれば、本当に気にしないでください。つまり、各エンティティが自分自身を描画し、ファクトリやそのような他のデザインパターンを心配しない方が便利であれば、それを実行します。要件を満たしているため、大丈夫です。自分で言ったことにもかかわらず、後で変更する必要はありません。そして本当に、最悪のシナリオ？後でリファクタリングします。、トースターで同時に自動的に実行できない場合でも、1つのプラットフォームで動作するゲームを取得します。

ただし、テスト駆動設計は、より意見の多いトピックです。私は、ゲーム開発者がより多くのことをすべきだと考えています。また、ゲーム開発者には最も厳格で厳しいスケジュールがいくつかあり、ゲームを始めたいだけのときにはTDDに時間を費やす余裕がないと考えています。また、やる気があるので、TDDの方がずっと遅く、機能しているゲームを（少なくとも最初は）あまり見ることができません。これは、プログラマーの動機に深刻な悪影響を与える可能性があります。

それは知識と実践の一般的な不足でもあると思います。TDDは他の分野でも普及しているとは思いませんが、アジャイル開発のように、広がっていると思います。あなたはそれがその時代に先んじていると言うかもしれません（あるいは、多分そうではないかもしれません、場合によっては数年後かもしれません）。TDDよりも重要なのは、「RDD」-要件駆動型開発です。_{私はそれを作りました。}あなたの目標は何ですか？ゲームを作るために。それ以外はすべて2番目です。TDDが生産性を向上させ、チームが期限に達するのを助けることを証明できれば、誰もがそれを使用すると思いませんか？そして、おそらくそうだろう。しかし、今、私たちの業界はこれまで以上に競争が激しく、締め切りはより厳しく、より早く、仕事は必要なものだけです。建設作業員は最初に足場を構築しません。彼らは基礎を築き、壁や床を上げ、それから足場の選択的なビットを構築して、足場がより便利になる特定のタスクを実行します。同じことがソフトウェア開発にも当てはまると思います。

長い投稿で申し訳ありません。あなたがそれからいくらかの知恵を得たことを願っています。私はただの学生であり、私の観察について話しています。業界の経験は非常に限られていますが、業界の専門家からの多くの読書があります。それで、私の言葉を一粒の塩で取ります。

そして、あなたがうまくいくと思うことをしてください。いつでも変更するか、破棄してやり直すことができます。それは、あらゆる形態のエンジニアリングの素晴らしい点です。最初に成功しない場合は、別の方法を試してください。（またはそのようなもの:-P）あなたはコンクリートを注いでいない。ソフトウェアは順応性があります。

ところで、私はしばらくの間、この同じタイプの質問をし、これらのタイプの設計原則を研究してきました。こことStack Overflowの両方に関連する質問がいくつかあります。

• 「MVCパターンに合わせてゲームのコードをどのように整理できますか？」
• 「単体テストが簡単になるようにゲームのソフトウェアを設計する方法は？」
• 「コンポーネントベースのゲームエンジンの設計」
• 「スケーラブルで「コンポーネント」ベースのゲーム「フレームワーク」を設計する方法を学ぶための優れたチュートリアルやリソースはありますか？」
• 「ゲームとレンダリングのロジックの分離」
• 「単体テストはゲームプログラミングで実行可能ですか？」
• 「商用コンピューターゲームで使用されるMVCデザインパターンは」
• 「テスト駆動開発は、ゲーム開発における通常のアプローチですか？」
• 「ゲーム開発にスクラムを使用している人はいますか？」
• 「ゲームのアーキテクチャ-カップルにするか、しないか？」
• 「OOゲームデザインの質問」

少なくともあなたの質問のMVC部分に関して、SOに関する同様の質問に対する私の元の答えはここにあります：

ゲームではめったに使用されません。理由を理解するにはしばらく時間がかかりましたが、私の考えは次のとおりです。

MVCは、2つの表現を区別するために存在します。モデルは、データの抽象的な表現です。マシンがアプリケーションの状態を表示する方法です。ビュー（およびコントローラー）は、人間にとって意味のある方法で、そのシステムのより具体的な目に見えるインスタンス化を表します。

ほとんどのビジネスアプリでは、これらの2つの世界はかなり異なります。たとえば、スプレッドシートのモデルは、単に値の2Dグリッドです。セルのピクセル単位の幅、スクロールバーの位置などを考慮する必要はありません。同時に、スプレッドシートビューでは、セル値の計算方法や格納方法がわかりません。

ゲームでは、これらの2つの世界は互いにはるかに近いものです。通常、ゲームワールド（モデル）は、仮想空間に配置されたエンティティのセットです。ゲームビューは、仮想空間に配置されたエンティティのセットでもあります。境界ボリューム、アニメーション、位置など、「ビュー」の一部とみなされるすべてのものは「モデル」によっても直接使用されます。アニメーションは物理学やAIなどに影響を与える可能性があります。

最終的な結果は、ゲーム内のモデルとビューの間の線がarbitrary意的であり、役に立たないということです。それらの間で多くの状態を複製することになります。

代わりに、ゲームはドメイン境界に沿って物事を分離する傾向があります。AI、物理学、オーディオ、レンダリングなどは可能な限り分離されます。

MVCはゲームのアーキテクチャに適合しないためです。ゲームのデータフローは、イベント駆動型ではなく、多くの場合、これらの操作を実行するための（非常に）厳しいミリ秒の予算があるため、エンタープライズアプリケーションのデータフローとはまったく異なります。16.6ミリ秒で行う必要のあるものがたくさんあります。そのため、画面上で必要なデータを正確にその時間で処理する「固定」の厳格なデータパイプラインを用意する方がより有益です。

また、分離があります。ほとんどの場合、MVCパターンと同じように配線されていません。レンダリングエンジン（ビュー）、ユーザー入力処理（コントローラー）、およびゲームプレイロジック、ai、物理学（モデル）などの残りがあります。それについて考えてください。ユーザー入力を取得し、aiを実行して1秒間に60回画像をレンダリングする場合、モデルとビューの間に何が変更されたかを知らせるためにオブザーバーが必要なのはなぜですか？これをゲームでObserverパターンは必要ないと言っていると解釈しないでください。しかし、この場合は本当に必要ありません。とにかく、すべてのフレーム、すべての作業を行っています。

TDDは開発スタジオで使用されることはほとんどありませんが、ソフトウェア開発にアジャイルプラクティスを使用しており、少なくともヨーロッパではSCRUMが人気のある選択肢のようです。その理由は簡単です。変化はどこからでも生じます。アーティストはより多くのテクスチャ予算、より大きな世界、より多くの木を望み、デザイナーはより豊かなストーリー（ディスク上のより多くのコンテンツ）、ストリーミングの世界を望み、パブリッシャーはあなたが時間通りに予算内で仕上げたいと望み、マーケティング部門も同様です。それとは別に、「最先端」は急速に変化し続けています。

だからと言って、私たちもテストを行わないということではありません。ほとんどのスタジオには大規模なQ＆A部門があり、回帰テストを定期的に実行し、単体テストを行っています。ただし、バグの大部分は、ユニットテストではカバーできないアート/グラフィックス関連（コリジョンメッシュの穴、間違ったテクスチャ、フィールドシェーダーの深さのグリッチ）であるため、ユニットテストを事前に行うポイントはほとんどありません。そして、動作するコードに加えて、どのゲームでも最も重要な要素は、それが楽しいことであり、それを単体でテストすることはありません。

また、コンソールの世界では、これはまだ異なっていることを覚えておいてください。なぜなら、あなたは他のものよりもハードウェアのためにより多くプログラミングしているからです。これは一般的に（PS2 / PS3）、データのフローがほぼすべての場合のコードのフローよりもはるかに重要であることを意味します。パフォーマンスの考慮事項による。ほとんどの場合、アーキテクチャツールとしてのTDDの使用は無効になります。通常、優れたOOPコードにはデータフローが悪いため、ベクトル化と並列化が困難です。

ゲームアーキテクチャでMVCとTDDが採用されないのはなぜですか？

警告：意見は先です。

MVCは（多く）使用されません：

1. MVCは比較的新しいアプローチであり、ゲームは通常、古いコードに基づいて構築されます。MVCアプリを作成するほとんどの人は、毎回何もないところから作成しています。（MVC自体は実際には何十年も前のことです。新しいのは、本質的にRoRなどのWebアプリからもたらされた広範な関心です。）私が取り組んだビジネスソフトウェアでは、レガシーコードに基づいていましたが、MVCも使用できませんでした。これは文化的なものですが、ゲーム固有のものではありません。
2. MVCは、本質的にイベント駆動型プログラムのGUIパターンです。ゲームはGUI主体でもイベント駆動型でもないため、Webアプリやその他のフォームベースのアプリケーションほど適用性は高くありません。MVCは通常、いくつかの有名な役割を持つObserverパターンであり、ゲームは興味深いものを観察するのを待つ余裕がないことがよくあります-誰かが何かをクリックしたかどうかにかかわらず、すべてのフレーム（またはそのバリエーション）をすべて更新する必要があります。

ゲームがMVCから多くを学べないということではありません。私はいつも自分の作るゲームのモデルをビューから分離しようとしています。ビューとコントローラが同じ（ウィジェット）オブジェクトの2つの部分であるという従来の考え方は実際には機能しません。そのため、もう少し抽象的にする必要があります。ここでは、パフォーマンスが実際の問題になることはほとんどありません。キャッシュのコヒーレンシ、並列処理などに適しているため、ビジュアルとロジックを別々に保つことでパフォーマンスが向上する場合があります。

TDDは使用されません（多く）。

1. ゲームで使用するのは本当に厄介です。繰り返しになりますが、入力が入り、出力が出るイベント駆動型のソフトウェアでは問題ありません。見たものを期待したものと比較し、正しいものとしてチェックすることができます。大量の共有状態を使用したシミュレーションでは、非常に厄介です。
2. それが何かを助けるという明白な証拠はありません。多くの主張、およびしばしば自己報告と権威への訴えに基づくいくつかの数字。おそらく、貧しいプログラマーが平凡になるのを助けますが、良いプログラマーを抑えます。おそらく、テストの記述に費やした時間は、SOLID原則の学習、またはそもそも正しいインターフェースの設計に費やした方が良いかもしれません。おそらく、オブジェクトが正しいことを確認するのに十分なテストがあるという本当の証拠なしに合格するテストを持つことは、誤ったセキュリティの感覚を与えます。

繰り返しになりますが、警告として、ユニットテストは素晴らしいと思いますが、「テストファースト」は有益でも良識でもないと思います。また、1秒間に何度も変更される共有状態が非常に多い場合、メインシミュレーションをテストすることは実用的ではないと思います。一般に、テストを低レベルおよびライブラリコードに制限します。

ただし、ご想像のとおり、タイムスケールと予算の超過で企業がよく知られているため、私は「エンタープライズ」コーディング慣行に大きく偏っています。「ゲーム開発者もそうです！」私はあなたが言うのを聞きます-まあ、はい。今のところソフトウェアを開発する最善の方法を本当に知っている人はいないと思いますし、主流のソフトウェアで規則的な慣行を採用することは、エンターテインメントソフトウェアのより自由な慣行から一歩進んだとは思いません。実際、これらのアプローチがより高いところに登るための梯子ではなく、それらが低くなりすぎるのを防ぐためのセーフティネットである、汎用Javaプログラマーに依存している人々にとっては、主に利益があると思います。

Kylotanが指摘しているように、「ゲームでは、プレゼンテーションの側面を、HTMLやCSSのような取り外し可能で置き換え可能な概念として扱うことはできません。これはWebアプリ用です」。単純なMVCパターン（巨大なフレームワークではない）を使用していくつかのゲームを構築したので、大きな問題はモデルがビューについて知る必要があることです。アートアセットのスプライトビットマップデータ、ヒットボックスデータ、または3Dジオメトリデータのいずれかを使用して、衝突検出（または別の同様のタスク）を実行する必要がある可能性が非常に高くなります。これは、各モデルがそのビューへの参照を必要とすることを意味します。これにより、従来のMVCパターンが壊れます。たとえば、既存のモデルなどに新しいビューを作成できなくなります。

たとえばUnity3Dに表示されるコンポーネントモデルは、ゲームコードを整理する最適な方法です。

MVCは、いくつかのレベルで、既にゲーム開発で使用されています。入力とグラフィックス用の異なるインターフェイスを備えたOSによって強制されます。ほとんどのゲームには、物理​​学とレンダリングと入力スレッドの分離など、MVCのインスタンスがいくつかあります。これは正常に機能します。MVCの最新の考え方は、誰もコードを理解できなくなるまで、フラクタルに繰り返す必要があるということです。ありがたいことに、ゲームはそれをしません。

TDDは、プロトタイプを何度も反復する前にゲームが「実行される」ことがほとんど知られていないため、使用されません。継続的なテストや統合テストなどのTDDのプラクティスは、多くの場合、ゲーム開発で使用されます。

ゲームシステムは徐々により良いプラクティスに移行しています。XNAのようなフレームワークは、設計や実行時間に過度のオーバーヘッドを追加することなく、コードをより一般化/クリーンにするための洞察を提供します。しかし、一般に、ゲームシステムはすべて、複雑な開発のスケジュールとモチベーションを維持しながら、複雑さと実行速度を最適化することを目的としています。このような環境では、ソフトウェアエンジニアリングの概念とシステム設計を適用することは優先順位1になりません。

私の個人的なゲームプロジェクトでは、コードをコメント化するか、少なくともコードを読みやすくしようとします。ゲームを前に進めていないので、気分が悪いだけです。

また、通常、ゲームを終了するまでに、その「再利用可能な」コードがほとんどないような方法で、基盤となるメカニックス、コアシステムなどを改善する方法について少なくとも1000のアイデアを持っています。本当に使えます。私は日ごとに通常のSEの仕事をしており、私たちが取り組んでいるシステムは大規模かもしれませんが、正直なところ、ゲームの複雑さに比べて見劣りすると思います。

ビューは、レンダリングループがいくつかのハードウェアを処理するための束をパッケージ化するという単純な事実によってロジックからしばしば分離されるという事実以外、MVCについて特に意見はありません。ロジック」が同時に発生します。「コントローラー」もハードウェアによって分離されていますが、残念ながら、ほとんどのゲーム開発者はコントローラーハンドラーで「興味深い」作業を行います。（IMOはコントローラーハンドラーがボタンとスティックを読み取り、表示するゲームの「プレゼンテーション」を作成する必要がありますが、私のsoapboxはそれほど強力ではありません。）

一方、TDDは非常に強い意見を持っています。それは、開発をより簡単に構築できるように開発を変更するだけです。それは間違いなく難しいことです。もちろん、実行するのは難しいので、実行されていません。「ゲームはテストである」ため、TDD（またはより一般的には単体テスト）に価値がないことを嘆く人もいますが、TDDではテストはほとんど無関係です。TDDのポイントは、プロセスから出てくるソフトウェアの設計とアーキテクチャです。

TDDを採用することで、プログラミングに対するアプローチが本当に変わります。TDDの道を歩き始める前に、何が間違っていて何が間違っていたかについていくつかの感情を抱きましたが、両足で飛び込んだ後、自分がやっていることが将来の開発をどのように助けているのか、それとも妨げているのかについて、より多くを理解するようになりました。確かに、これはコードルームポスト、tのないTDDの背後にある種のポイントです。

なぜそれがゲームでもっと使われないのか、ハードであるだけでなく、過去にそれを常に行っていた方法が不必要に自分の仕事を難しくしていることを人々に気付かせます。特にプログラマーにとっては、見ても苦い薬です、はるかに少ないツバメ。

私は、TDDを受け入れることを拒否する人々は、単に優れたプログラマーになりたくないと確信しています。彼らは、プログラミングや設計、アーキテクチャが「優れている」と既に考えていますが、実際には、コードはまったく異なることを言っています。