ゲーム開発に役立つプログラミングデザインパターンは何ですか？[閉まっている]

私はデザインパターンに関する書籍をいくつか持っており、いくつかの記事を読みましたが、どのプログラミングデザインパターンがゲーム開発に役立つかを直感的に理解することはできません。

たとえば、モデルビューコントローラー、シングルトン、ファクトリー、コマンドなどのいくつかのデザインパターンを詳しく説明したデザインパターンを含むActionScript 3という本があります。

これを初めて知った人として、これらのどれが役立つか、または実際、これらのどれが私が学び、使用しようとしている設計パターンであるかを理解できません。おそらく、私が気づいていないゲームプログラミング固有のデザインパターンが他にありますか？

ゲーム開発で特定のデザインパターンを使用した経験がある場合は、ぜひ聞いてください。それが使用された理由、コードサンプル、またはオンラインリソースについての推論は、それらがあれば非常に役立ちます。私は現在、ActionScript 3とC ++の実装に最も興味を持っていますが、あらゆる言語の経験と例から間違いなく恩恵を受けることができます。

ありがとう！

いくつかの提案とともに、より軽快な応答のために。これらを実装の推奨事項としてではなく、可能な使用例として受け取らないでください。

• ビルダー：データに基づいて、コンポーネントベースのエンティティを一度に1つのコンポーネントに設定します
• ファクトリメソッド：ファイルから読み取られた文字列に基づいてNPCまたはGUIウィジェットを作成する
• プロトタイプ：初期プロパティとともに1つの汎用「Elf」文字を保存し、それを複製してElfインスタンスを作成します。
• シングルトン：このスペースは意図的に空白のままにします。
• アダプター：既存のコードのように見えるレイヤーにラップすることにより、オプションのサードパーティライブラリを組み込みます。DLLで非常に便利です。
• 合成：レンダリング可能なオブジェクトのシーングラフを作成するか、ウィジェットのツリーからGUIを作成します
• ファサード：シンプルなインターフェースを提供することで、複雑なサードパーティライブラリを簡素化して、後の生活を楽にします。
• フライウェイト：NPCの共有アスペクト（モデル、テクスチャ、アニメーションなど）を個々のアスペクト（位置、健康など）とは別に、ほとんど透明な方法で保存します。
• プロキシ：サーバー上でより大きく複雑なクラスを表す小さなクラスをクライアント上に作成し、ネットワーク経由でリクエストを転送します。
• 責任の連鎖：入力をハンドラの連鎖として処理します。グローバルキー（例：スクリーンショット用）、次にGUI（例：テキストボックスにフォーカスがある場合、またはメニューが表示されている場合）、ゲーム（例：キャラクターを移動するため）
• コマンド：ゲーム機能をカプセル化して、コンソールに入力したり、保存および再生したり、ゲームのテストに役立つスクリプトを作成したりできます。
• メディエーター：さまざまなコンポーネントで動作する小さなメディエータークラスとしてゲームエンティティを実装します（たとえば、AIコンポーネントにデータを渡すためにヘルスコンポーネントから読み取る）
• オブザーバー：ゲームロジックがコードのレンダリングに関する知識を必要とせずに、必要に応じて視覚表現を変更するために、キャラクターのレンダリング可能な表現に論理表現からのイベントをリッスンさせます
• 状態：NPC AIをいくつかの状態の1つとして保存します。攻撃、放浪、逃亡。それぞれが独自のupdate（）メソッドと、必要な他のデータ（たとえば、攻撃または逃げるキャラクターの保存、さまよう場所など）を持つことができます。
• 戦略：使用している地形の種類に応じて、A *検索のヒューリスティックを切り替えるか、同じA *フレームワークを使用して経路探索とより一般的な計画の両方を行うこともできます。
• テンプレートメソッド：一般的な「戦闘」ルーチンをセットアップし、各ステップを処理するためのさまざまなフック関数を使用します。弾薬を減らし、ヒット率を計算し、ヒットまたはミスを解決し、ダメージを計算します。攻撃スキルの各タイプは、独自の方法でメソッドを実装します

いくつかのパターンは、インスピレーションの欠如のために除外されました。

私はまさにそのトピックに関する本を書きました：ゲームプログラミングパターン。そこにある章はあなたに役立つかもしれません。

Brandon EichがCoders at Workで提唱する意味があったことの1つは、パターンがハッキングと回避策であるということです。[パターン]は、言語に何らかの欠陥を示しています。これらのパターンは無料ではありません。無料のランチはありません。したがって、適切なビットを追加する言語の進化を探している必要があります。

コンパイラデザイナーではなくゲームプログラマーとして、使用する言語を進化させるオプションはほとんどありませんが、言語や要件に合わせて独自のスタイルを進化させることを学ぶことができます。パターンはこれの一部ですが、特にブランドンが言うように、パターンが顕著なパフォーマンス、メモリ、またはコードの俊敏性のコストを失うことはめったにないため、パターンを使用しないことは別の部分です。MVCは、ゲームの多くの要素に適したパターンではありません。シングルトンは、不完全なC ++静的初期化ルールの回避策であり、おそらくこれらを行うべきではありません。ファクトリは複雑なオブジェクトの作成を単純化します-オブジェクトは最初からもっとシンプルにすべきかもしれません。人気のあるパターンは、必要なときに頼るツールです 最初は複雑なものを構築するために使用したいツールではなく、複雑なものを管理します。

優れた（ゲーム）コードはパターンを使用する場合と使用しない場合があります。パターンを使用する場合は問題ありません。言語に依存しない高度なレベルで他のプログラマーにコード構造を説明するための優れたコミュニケーションツールです。パターンを使用せずにコードの方が優れていると思う場合は、パターンに勝てないでください。

もちろん、他の人が言ったように、すべてのパターンは適切な状況で有用であり、それらの使用方法を学ぶことの一部は、いつ使用するかを学ぶことです。しかし、Daniel Sanchez-Crespo Dalmauによる優れた書籍 『Core Techniques and Algorithms in Game Programming』には、ゲームプログラミングで特に役立つ6つのプログラミングパターンと6つのユーザビリティパターンがリストされています。

プログラミング：

• シングルトン：多くの人がそうするように、私はこれを嫌いではありません。シングルプレイヤープレーヤーやキーボードリーダーなどに使用できます。
• ファクトリ：オブジェクトを効率的に作成および破棄できます。
• 戦略：AI戦略をエレガントに変更できます。
• 空間インデックス：空間データセットでクエリを実行できます。
• Composite：便利なオブジェクト階層を設定します。
• フライウェイト：同一の敵のようなものを一般化することにより、メモリを解放します。

使いやすさ：

• シールド：劇的なアクションの偶発的な起動から保護します。
• 状態：世界/ UIステータスの視覚的な合図。
• 自動モードキャンセル：ゲームをより直感的に機能させます。
• 磁気：自動照準と簡単なユニット選択。
• フォーカス：気を散らすUI要素を排除します。
• 進捗状況：広く有用です。

この本は、もちろん、これらのそれぞれについてさらに詳しく説明しています。

エンティティシステムは、すばらしい種類のパターンです。それは、OOPのトリックではないので、厳密にはデザインパターンではありません。ただし、OOPと組み合わせることができます。

いくつかの良いリンク（イントロの先頭から開始）：

• http://www.csharpfriends.com/Articles/getArticle.aspx?articleID=387
• http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/
• http://games.fh-hagenberg.at/wiki/index.php?title=Componentbased_entity_systems

それらのすべて。シングルトンを除く。[/ flippancy]

パターンについてではなく、その背後にある基本原則についてです。では、「デザインパターン：オブジェクト指向における再利用のための」（1995） ;：、4（ガンマ、エーリッヒ・リチャードヘルム、ラルフ・ジョンソン、およびジョン・ブリシディース）のギャングは、オブジェクト指向設計のための唯一の2つの原則をお勧めします（1）プログラムへの実装ではなくインターフェイスであり、（2）クラスの継承よりもオブジェクトの構成を優先します。

これら2つの原則は、ゲーム開発の多くのタスクで非常に役立ちます。たとえば、多くのゲームプログラマーは、深いクラス階層を使用してゲームエンティティを表現しています。構成に基づく別のアプローチがあります-コンポーネントベースのゲームオブジェクト。このアプローチに関する記事。さらにリンク。これは、デコレータパターンの例です。

不思議定期的なテンプレートパターンは、仮想メソッドと仮想関数呼び出しから来ることができ、パフォーマンスの低下を避けるために本当に便利です。

これは、必要なインターフェイスを持つ基本クラスタイプのコンテナを実際に持つ必要はないが、同様の名前の動作とインターフェイスが必要な場合に適切なパターンになります。

たとえば、コンパイル時に型の違いがわかっている複数のプラットフォームまたはエンジン（dxとopengl）のクラスをコンパイルするときにこれを使用できます。

私が長年にわたって進化させたデザインパターンは、私にとって非常に有用でしたが、「ブローカー定義セット」と呼ぶものです。GOFの用語でそれを要約する方法は議論の余地があるように見えますが、StackOverflowでそれについて書いたこの質問は、それについていくらか詳しく説明します。

コアコンセプトは、クリーチャーの種のようなモデルの一部のプロパティを設定し、プロパティの可能な値ごとに対応する定義オブジェクト（値ごとに1つの共有オブジェクト）を設定し、その動作を指定することです。そして、これらは中央ブローカー（GOFに関しては、レジストリ、ファクトリー、またはその両方かもしれません）を介してアクセスされます。私の使用法では、ランタイムモーフィズムの目的で弱いバインディングを容易にするために、通常はスカラーキーを介してアクセスされます。