タグ付けされた質問 「design-patterns」

次のような相反する意見を聞いています。 「専任のマネージャークラスはほとんど適切なエンジニアリングツールではありません」 「専用マネージャークラスは（現在）何千ものリソースを持つ大規模プロジェクトを生き残るための最良の方法です」 次の機能を持つ従来のResourceManagerクラスを見てみましょう。 アセット（テクスチャ、オーディオ、3Dモデルなど）をロードします キャッシュを保持することにより、アセットが一度だけロードされるようにします 参照は、資産を割り当て解除できるかどうかを判断するために資産をカウントします 実際の資産の出所を隠します（たとえば、資産ごとに1つのファイル、1つのパッケージファイル内のすべての資産、またはネットワークを介して資産をロードすることもできます） プログラムを再起動せずにアセットをリロードできます。これは、ゲームに取り組んでいるアーティストにとって非常に便利です。 また、これらのResourceManagerオブジェクトがシングルトンではなく、依存性注入を介して渡されるように見せることにより、テーブルから「シングルトンは悪い」引数を取りましょう。 次に、「ファクトリを使用する」または「ファクトリと呼ぶ」引数があります。これに関する私の問題は、はい、それはファクトリーですが、キャッシュとリローダーでもあるということです（より良い言葉がないため）。それをファクトリと呼ぶことはそれを適切に記述しません、そして私がそれを適切なファクトリにするならば、キャッシングとリロードはどこで実装されますか？ 「マネージャー」クラスはしばしば悪いアーキテクチャの症状であることに同意しますが、この特定のケースでは、どのように再構築し、すべての機能を保持できますか？これは、「Manager」クラスが実際に適切な状況ですか？

19 architecture  design-patterns  resource-management 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 私はゲームのデザインを考えていました（ボードゲームをコンピューターに翻訳し、具体的には、この場合に関連していると思います）。 簡単なテキストインターフェイスを使用して、何かをすばやくプロトタイプ化してから、後でそれをきれいにすることができます。また、ゲームを他のメディアに簡単に移植できるようになります。 この種の区分化はゲームで一般的ですか？さらに物事を分解しようとする必要がありますか？行方不明の合併症はありますか？

19 design-patterns 

実際、数週間前にFacebook用の新しいWebベースのゲームをトレースし始めました（命名法の修正についてはDavid Youngに感謝します）。私はターンベース（ヴァンパイア戦争）スタイルのRPGに似たものに取り組んでいます。ゲームをコーディングするスキルはありますが、デザインパターンを正しくし、製品を自分の目に見えるものに一致させようと努力しています。 通常、ウェブサイトを構築するとき、「コードを考える」のが好きで、コード/ HTMLを変更して調整する方が速いと思います。これはおそらく、私がやることに非常に満足しており、何を期待しているのかを知っているからです私は何度も何度もやってきた。ゲーム開発のこの時点で、私は自分が再びウェブサイトで始めたように（ウェブサイトで使っていたように）自分がゲームロジックに焦点を当てず、直観に欠けているだけなのか、それとも考えを広げるのに適切な方法なのかと思いますコーディングの進歩。 この問題を正しく攻撃し、仕事を続ける方法についてのアドバイスをいただければ幸いです。ゲームエンジンが標準のビジネスWebサイトとどれほど違うかをすぐに学んでいます！私が何かを手に入れるたびに、それはただムーシーで不完全であると感じ、それはあきれた欲求不満になりつつあります。 延長 例として、私に非常に多くの問題を与えてきた戦闘エンジンは、最近単純な攻撃スキルを取り、-50％から+ 50％の間でランダムにロールし、元の攻撃スキルにそのパーセントを掛けます。同じことは防衛でも行われ、それからそれらをメッシュ化して、敵の健康に対してダメージが与えられているかどうかを判断します。それが正しい方法なのか、それとも「正しい」方法があるのか​​を自問し始めたとき、頭の上にいることに気付くべきだと思います。私がこれで見つけた1つの大きな欠点は、同じレベルの2人のキャラクターが複数の「ロール」を持つことができ、攻撃が-50％、防御が+ 50％であるため、誰も何もしない非常に長いバトルシーケンスになります。失敗します たぶん、私の投稿は、単純なゲームロジックを説明する推奨リンクを求めていたはずです。 エンドエクステンション よろしくお願いします！

19 design-patterns  prototyping 

トップダウンの2Dゲームを作成しています。さまざまな種類の攻撃が必要です。The Binding of Isaacが機能するように、攻撃を非常に柔軟で組み合わせ可能にしたいと思います。ゲーム内のすべてのグッズのリストを次に示します。良い例を見つけるために、スプーンベンダーのアイテムを見てみましょう。 スプーンベンダーは、Isaacにホーミング涙を放つ能力を与えます。 「相乗効果」セクションを見ると、興味深いが直感的な効果を得るために他の収集品と組み合わせることができることがわかります。たとえば、Inner Eyeと組み合わせると、「Isaacが複数のホーミングショットを一度に発射できるようになります」。これは理にかなっています アイザックにトリプルショットを与える このようなものを設計するのに適したアーキテクチャは何ですか？これがブルートフォースソリューションです。 if not spoon bender and not the inner eye then ... if spoon bender and not the inner eye then ... if not spoon bender and the inner eye then ... if spoon bender and the inner eye then ... しかし、それは非常に早く手に負えなくなります。このようなシステムを設計するより良い方法は何ですか？

17 game-design  architecture  design-patterns 

趣味のゲームエンジン用に中央のResourceManager / ResourceCacheクラスを作成することにしましたが、キャッシュスキームの設計に問題があります。 ResourceManagerには、ゲームのすべてのリソースを組み合わせて使用​​される合計メモリのソフトターゲットがあります。他のクラスは、リソースオブジェクトを作成します。リソースオブジェクトはアンロード状態になり、ResourceManagerに渡します。次にResourceManagerは、ソフト制限を念頭に置いて、特定のリソースをいつロード/アンロードするかを決定します。 別のクラスがリソースを必要とする場合、そのリクエストはResourceManagerに送信されます（文字列IDまたは一意の識別子を使用）。リソースがロードされると、リソースへの読み取り専用の参照が呼び出し元の関数に渡されます（参照カウントされたweak_ptrにラップされます）。リソースがロードされていない場合、マネージャーは次の機会（通常はフレームの描画の最後）にロードするオブジェクトをマークします。 私のシステムはいくつかの参照カウントを行いますが、リソースが読み取られているときにのみカウントします（したがって、参照カウントは0かもしれませんが、エンティティはまだそのuidを追跡している可能性があります）。 初めて使用する前にリソースをロード用にマークすることもできます。以下は、私が使用しているクラスのスケッチです。 typedef unsigned int ResourceId; // Resource is an abstract data type. class Resource { Resource(); virtual ~Resource(); virtual bool load() = 0; virtual bool unload() = 0; virtual size_t getSize() = 0; // Used in determining how much memory is // being used. …

17 c++  design-patterns  resource-management 

私はシングルトンが悪いことを知っています。私の古いゲームエンジンは、すべてのデータを保持してから実際のゲームループまですべてを処理するシングルトン「ゲーム」オブジェクトを使用していました。今、私は新しいものを作っています。 問題は、window.draw(sprite)ウィンドウがである場所で使用するSFMLで何かを描画することですsf::RenderWindow。ここに表示される2つのオプションがあります。 ゲーム内のすべてのエンティティが取得するシングルトンゲームオブジェクトを作成します（以前使用したもの） これをエンティティのコンストラクタにします：（Entity(x, y, window, view, ...etc)これはばかげて面倒です） エンティティのコンストラクタをxとyだけに保ちながらこれを行う適切な方法は何ですか？ メインのゲームループで作成したすべてを追跡して、ゲームループでスプライトを手動で描画することもできますが、それも面倒で、エンティティの描画機能全体を完全に完全に制御したいと考えています。

16 c++  design-patterns  oop 

この投稿を改善したいですか？引用や回答が正しい理由の説明など、この質問に対する詳細な回答を提供します。十分な詳細のない回答は、編集または削除できます。 UMLなど：一般的なコンピュータサイエンスでは、「言語」（標準作図テクニックを読んで）モデリングがある1、2 ERDのようなものがあるデータベースでは、3をビジネスにBPMNなどの他の種類があり、4、5。ゲームデザイン固有のこれらのようなものはありますか？

16 game-design  design-patterns  documentation  design-document 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または詳細な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 6年前に閉鎖されました。 私は、ゲームに固有の用語の一般的な辞書を探しています（デザインパターンが物事がどのように相互作用するかについて共通の言語を持っているように）。 たとえば、複雑さの高いピンポンのゲームを作成している場合、それに応じて名前を付けたいと思います。 私は、ユーザーがウィジェットと呼ばれる対話可能なビジュアルオブジェクト、doodadと呼ばれる非インタラクティブなオブジェクトを見ました（とにかくスタークラフトマップエディターで遊んだとき）。フレームレートクロックに適切な名前はありますか？ゲームの時計に適切な名前はありますか（時計は世界のオブジェクトの動きに関するもので、視覚的な描画ではありません）？ 辞書が欲しいので、同じ言語を話せるようになります。私は、doodads、whosits、whatsists、flim-flamsと名付けられたものを作成することを懸念しています...そして、私はそれをしたくありません。

16 architecture  design-patterns 

私はシューティングゲーム（1942、クラシック2Dグラフィックスなど）を書いていますが、コンポーネントベースのアプローチを使用したいと思います。これまでのところ、次の設計について考えました。 各ゲーム要素（飛行船、発射物、パワーアップ、敵）はエンティティです 各エンティティは、実行時に追加または削除できるコンポーネントのセットです。例には、Position、Sprite、Health、IA、Damage、BoundingBoxなどがあります。 飛行船、発射物、敵、パワーアップはゲームクラスではないという考え方です。エンティティは、所有するコンポーネントによってのみ定義されます（時間の経過とともに変化する可能性があります）。そのため、プレイヤーの飛行船は、スプライト、位置、ヘルス、および入力コンポーネントから始まります。パワーアップには、Sprite、Position、BoundingBoxがあります。等々。 メインループは、ゲームの「物理」、つまりコンポーネントの相互作用を管理します。 foreach(entity (let it be entity1) with a Damage component) foreach(entity (let it be entity2) with a Health component) if(the entity1.BoundingBox collides with entity2.BoundingBox) { entity2.Health.decrease(entity1.Damage.amount()); } foreach(entity with a IA component) entity.IA.update(); foreach(entity with a Sprite component) draw(entity.Sprite.surface()); ... コンポーネントは、メインC ++アプリケーションにハードコーディングされています。エンティティはXMLファイル（luaまたはpythonファイルのIAパーツ）で定義できます。 メインループはエンティティをあまり気にしません。コンポーネントを管理するだけです。ソフトウェア設計では、次のことを許可する必要があります。 コンポーネントを指定して、それが属するエンティティを取得します エンティティを指定すると、タイプ「type」のコンポーネントを取得します すべてのエンティティについて、何かをする …

16 c++  design-patterns  component-based 

他のバージョンでは辞退したいゲームが完成しました。これらは、ほぼ同じ種類のデザインの類似したゲームになりますが、常にではなく、基本的に物事が変化する場合があります。 コアコードをゲームとは別にバージョン管理して、ゲームAで見つかったバグを修正した場合、その修正がゲームBに存在するようにします。 私はそれを管理する最良の方法を見つけようとしています。私の最初のアイデアはこれです： engine一般化できるすべてを含み、ゲームの他の部分から完全に独立したモジュール/フォルダー/何でも作成します。これにはいくつかのコードが含まれますが、ゲーム間で共有される汎用アセットも含まれます。 このエンジンを独自のgitリポジトリに配置します。これはゲームに含まれますgit submodule 私が苦労しているのは、残りのコードの管理方法です。メニューシーンがあるとしましょう。このコードはゲーム固有ですが、ほとんどのコードは汎用的な傾向があり、他のゲームで再利用できます。に入れることはできませんがengine、ゲームごとに再コーディングするのは非効率です。 ある種のgitブランチのバリエーションを使用すると、それを管理するのに効果的かもしれませんが、これが最善の方法だとは思いません。 誰にもアイデアや共有する経験、またはそれについて何かありますか？

15 architecture  software-engineering  design-patterns 

私は、コンポーネントベースのエンティティ設計に頭を悩ませようとしています。 私の最初のステップは、オブジェクトに追加できるさまざまなコンポーネントを作成することでした。すべてのコンポーネントタイプに対して、iにはマネージャーがあり、マネージャーはすべてのコンポーネントの更新機能を呼び出し、必要に応じてキーボードの状態などを渡します。 次にしたことは、オブジェクトを削除し、各コンポーネントにIDを持たせることでした。したがって、オブジェクトは同じIDを持つコンポーネントによって定義されます。 今、私はすべてのコンポーネントのマネージャーは必要ないと考えています。たとえばSizeComponent、Sizeプロパティを持っているだけです。結果としてSizeComponent更新メソッドはなく、マネージャーの更新メソッドは何もしません。 私の最初の考えはObjectProperty、コンポーネントをコンポーネントのプロパティとして持つのではなく、コンポーネントがクエリできるクラスを持つことでした。だから、オブジェクトが多数を持っているでしょうObjectPropertyし、ObjectComponentます。コンポーネントには、オブジェクトのプロパティを照会する更新ロジックがあります。マネージャーは、コンポーネントの更新メソッドの呼び出しを管理します。 これはオーバーエンジニアリングのように思えますが、マネージャーがどのオブジェクトにどのコンポーネントロジックを実行する必要があるかを知る方法が必要なので、コンポーネントを取り除くことができるとは思いません（そうでなければコンポーネントを削除するだけです更新ロジックを完全にマネージャーにプッシュします）。 この（持っているObjectProperty、ObjectComponentとComponentManagerオーバーエンジニアリングクラス）？ 良い選択肢は何でしょうか？

15 architecture  component-based  design-patterns 

単純な標準のクライアント/サーバーゲームを想定しています。サーバーの場合、クライアントからの接続とメッセージをリッスンし、ローカルソケットまたはstdinを介して実際のゲームサーバーを実行する別のプロセスにデータを送信する別のプロセスを用意する価値がありますか？ 他のオプションは、両方のことを単一のプロセスで実行することです。着信メッセージをキューに入れ、正しい順序で実行することで、問題が停止することはありません。 2つの「アクティビティ」を分離するための追加リソースが実際に価値があるかどうか疑問に思っています。どのように決定すればよいですか？賛否両論を聞きたい。

14 architecture  server  design-patterns  client-server 

私がやっているプレゼンテーションの一環として、「ガラガ」に似たシンプルな固定シューティングゲームを作成しています。宇宙船から発射されたレーザーのような発射体を追跡するために人々がどのような戦略とデータ構造を使用するのだろうかと思っています。以前に使用した非常にシンプルな実装は、各発射物をポイントとして表現し、シーン内のすべてのオブジェクトとの衝突をチェックすることです。 ただし、これは多くの発射物がある大きなシーンではコストがかかるようです。このタイプのユースケースには、他のタイプの戦略や実装がどのように使用されているのでしょうか。FPSのようなゲームは、発射体（弾丸、戦車の砲弾など）の追跡に何を使用しますか？

14 game-design  design-patterns 

ゲームのイベントスケジューラを作成したいのですが、基本的にはゲームイベントのトリガーをスケジュールできるようにしたいのです。これは、1回限りのトリガー、または定期的なトリガー（5秒ごとにトリガーイベント "E_BIG_EXPLOSION" ...）になります。 これはシングルトンを使用するのに適した場所かもしれないと思われがちですが、シングルトンは非常に邪悪で、病気のように広がる傾向があります... この場合、シングルトンの使用を避けるためにどのような設計を提案しますか？

13 architecture  design-patterns  events 

XxxManagerゲームエンジンプログラミングでスタイルクラスを使用することは悪い考えですが、使用を避けようとしても、常にすべてのアクター/エンティティ/ゲームワールドの場所を保持し、それらに作用するものになります。Manager別の名前ではifになります。 これは本当に悪いパターンですか？もしそうなら、選択肢は何ですか？

13 architecture  software-engineering  design-patterns