回答
さて、いくつかの提案を加えて、より軽快な応答を求めます。これらを実装の推奨事項として、より多くの可能な使用例としてとらえないでください。
- ビルダー：データに基づいて、コンポーネントベースのエンティティを一度に1つのコンポーネントに設定します
- ファクトリメソッド：ファイルから読み取った文字列に基づいてNPCまたはGUIウィジェットを作成します
- プロトタイプ：初期プロパティを持つ1つの汎用「Elf」文字を格納し、それをクローン化してElfインスタンスを作成します。
- シングルトン： このスペースは意図的に空白のままにしました。
- アダプター：オプションのサードパーティライブラリをラップして組み込みます既存のコードのように見えるレイヤー。DLLで非常に便利です。
- 複合：レンダリング可能なオブジェクトのシーングラフを作成するか、ウィジェットのツリーからGUIを作成します。
- ファサード：複雑なサードパーティライブラリを簡素化して、後で作業を楽にするシンプルなインターフェイスを提供します。
- フライウェイト：NPCの共有アスペクト（モデル、テクスチャ、アニメーションなど）を個々のアスペクト（例：位置、健康）ほとんど透過的な方法
- プロキシ：サーバー上でより大きく、より複雑なクラスを表す小さなクラスをクライアント上に作成し、ネットワーク経由でリクエストを転送します。
- 責任の連鎖：入力を次のように処理しますハンドラーのチェーン。グローバルキー（例：スクリーンショット用）、次にGUI（例：テキストボックスがフォーカスされている場合やメニューが表示されている場合）、次にゲーム（例：キャラクターの移動用）
- コマンド：ゲームの機能をコマンドとしてカプセル化し、コンソールに入力したり、保存して再生したり、スクリプトを作成してゲームのテストに役立てたりすることもできます。
- メディエーター：ゲームエンティティを、さまざまなコンポーネントで動作する小さなメディエータークラスとして実装します（例： AIコンポーネントにデータを渡すためにヘルスコンポーネントから読み取る）
- オブザーバー：必要に応じて視覚的表現を変更するために、キャラクターのレンダリング可能な表現に論理表現からのイベントをリッスンさせます。コードのレンダリングについて何かを知る必要があるゲームロジック
- 状態：NPCAIをいくつかの状態の1つとして保存します。攻撃、放浪、逃げる。それぞれに独自のupdate（）メソッドと、必要なその他のデータを含めることができます（たとえば、攻撃または逃げるキャラクター、さまようエリアなどを保存する）
- 戦略：切り替える使用している地形の種類に応じて、または同じA *フレームワークを使用してパスファインディングとより一般的な計画の両方を実行するために、A *検索のさまざまなヒューリスティック
- テンプレートメソッド：セットアップ弾薬のデクリメント、ヒットチャンスの計算、ヒットまたはミスの解決、ダメージの計算など、各ステップを処理するさまざまなフック機能を備えた一般的な「戦闘」ルーチン。各タイプの攻撃スキルは、独自の方法でメソッドを実装します。
インスピレーションが不足しているためにいくつかのパターンが省略されています。
コメント
回答
回答
BrandonEichが コーダーで取り上げるのに良識があったことの1つat Work は、パターンがハックと回避策であるということです。 [Patterns]は、言語に何らかの欠陥があることを示しています。これらのパターンは無料ではありません。無料の昼食はありません。したがって、適切なビットを追加する言語の進化を探す必要があります。
コンパイラ設計者ではなくゲームプログラマーとして、言語を進化させるオプションを取得することはめったにありません。私たちは使用していますが、言語や要件に合わせて独自のスタイルを進化させることを学ぶことができます。パターンはその一部ですが、特にブランドンが言うように、パターンがめったに行かないため、パターンを使用しないことも別の部分です。顕著なパフォーマンスやメモリまたはコードの俊敏性のコストがありません。MVCはゲームの多くの点で優れたパターンではありません。シングルトンは不完全なC ++静的初期化ルールの回避策であり、とにかくそれらを行うべきではありません。 Factoryは、複雑なオブジェクトの作成を簡素化します。おそらく、オブジェクトは最初はもっと単純なはずです。人気のあるパターンは、複雑なものを管理するために必要なときに頼るツールであり、最初に複雑なものを構築するために使用したいと思っているツールではありません。
優れた（ゲーム）コードはパターンを使用する場合と使用しない場合があります。パターンを使用している場合は問題ありません。これらは、言語に依存しない高いレベルで他のプログラマーにコード構造を説明するための優れたコミュニケーションツールです。パターンを使用しない方がコードの方が優れていると思われる場合は、殴らないでください。
コメント
回答
もちろん、他の人が言っているように、すべてのパターンは適切な状況で役立ちます。パターンの使用方法を学ぶことの一部は、いつ使用するかを学ぶことです。ただし、Daniel Sanchez-CrespoDalmauによる優れた本 ゲームプログラミングのコアテクニックとアルゴリズム には、6つのプログラミングパターンと6つのユーザビリティパターンが記載されています。ゲームプログラミングで特に役立ちます。
プログラミング：
- シングルトン：多くの人がそうするように、これは嫌いではありません。シングルのようなものに使用できます-プレーヤープレーヤーまたはキーボードリーダー。
- ファクトリ：オブジェクトを効率的に作成および破棄できます。
- 戦略：AI戦略をエレガントに変更できます。
- 空間インデックス：空間データセットに対するクエリの実行を支援します。
- 複合：有用なオブジェクト階層を設定します。
- フライウェイト：同一の敵などを一般化することでメモリを解放します。
使いやすさ：
- シールド：劇的なアクションの偶発的なアクティブ化から保護します。
- 状態：世界/ UIステータスの視覚的な手がかり。
- 自動モードキャンセル：ゲームをより直感的に動作させます。
- マグネットism：自動照準と簡単なユニット選択。
- 焦点：気が散るUI要素を排除します。
- 進捗状況：普遍的に役立ちます。
もちろん本です。 、これらのそれぞれについて詳しく説明します。
コメント
回答
エンティティシステムは良い種類のパターンです。厄介なOOPではないため、正確にはデザインパターンではありません。ただし、OOPと組み合わせることができます。
いくつかの優れたリンク（イントロは上から開始）：
コメント
回答
すべて。シングルトンを除く。 [/ flippancy]
コメント
回答
実際にはパターンについてではなく、その背後にある基本原則についてです。 「デザインパターン：再利用可能なオブジェクト指向ソフトウェアの要素」（1995）では、4人のギャング（ガンマ、エリック、リチャードヘルム、ラルフジョンソン、ジョンVlissides）は、オブジェクト指向設計の2つの原則のみを推奨しています。（1）プログラムは、実装ではなくインターフェイスに、（2）クラス継承よりもオブジェクト構成を優先します。
これらの2つの原則は、ゲームの多くのタスクで非常に役立ちます。開発。たとえば、多くのゲームプログラマーは、ゲームエンティティを表すために深いクラス階層を使用しています。 構成に基づく別のアプローチがあります-コンポーネントベースのゲームオブジェクト。このアプローチに関する記事。 さらに多くのリンク。これは、デコレータパターンの例です。
コメント
回答
不思議なことに繰り返されるテンプレートパターンは、仮想メソッドや仮想関数呼び出しによるパフォーマンスの低下を回避するのに非常に役立ちます。
これ必要なインターフェイスを持つ基本クラスタイプのコンテナを実際に持つ必要はないが、同様の名前の動作とインターフェイスが必要な場合は、適切なパターンにすることができます。
たとえば、コンパイル時に型の変化がわかっている複数のプラットフォームまたはエンジン（dxとopengl）のクラスをコンパイルするときに、これを使用できます。
コメント
回答
私が長年にわたって進化させ、私にとって非常に有用であったデザインパターンは、私が「ブローカー定義セット」と呼んでいるものです。 GOF用語で要約する方法については議論の余地があるようですが、 StackOverflowで書いたこの質問で詳細に説明します。
コアコンセプトは、クリーチャーの種など、モデルの一部のプロパティが設定され、プロパティの可能な各値に、その動作を指定する対応する定義オブジェクト（値ごとに単一の共有オブジェクト）が含まれるようにすることです。 、およびこれらは中央ブローカー（GOFに関しては、レジストリ、ファクトリ、またはその両方）を介してアクセスされます。私の使用法では、これらは通常、実行時の射の目的で弱いバインディングを容易にするために、スカラーキーを介してアクセスされます。
コメント