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

設計パターンは、ソフトウェア設計の特定のコンテキスト内で一般的に発生する問題に対する一般的な再利用可能なソリューションです。

3
ルールシステムのデザインパターン?
簡単な楽しいプロジェクトとして、ソリティアゲームを作成してみました。しかし、ルールシステムを作成するときに、主にゲームロジックが完全なスパゲッティコードであるため、コードが完全に構造化されておらず、拡張性がないと感じたため、汚いと感じました。 私は以前にこの問題に遭遇しましたが、私のプログラムのこの部分を書くときはいつも気まずい思いをしていましたので、ゲームのルールを定義することに関して、試行されテストされたベストプラクティスはありますか?

2
XBoxコントローラーを抽象化する正しい方法
アプリケーションの入力として使用したいXBox360コントローラーがあります。 私が解決できないのは、インターフェースを介してこれを公開するベストプラクティスの方法です。 舞台裏では、コントローラーを処理するクラスはポーリングボタンの状態に依存しています。 最初に何かリンクを試しました: Event ButtonPressed() as ButtonEnum どこにButtonEnumあったButtonRed、ButtonStartなど これは、ボタンの押下のみをサポートし、ホールド/パターン(2回押すなど)をサポートしないという点で少し制限されています 次のアイデアは、単にボタンの状態をアプリに公開することです Property RedPressed as Boolean Property StartPressed as Boolean Property Thumb1XAxis as Double これは非常に柔軟ですが、実際にはアプリに多くの作業を強制し、アプリにポーリングを要求します-可能であればイベント駆動型を好むでしょう。 たとえば、複数のイベントを追加することを検討しました。 Event ButtonPressed(Button as ButtonEnum) Event ButtonPressedTwice(Button as ButtonEnum) Event ButtonHeldStart(Button as ButtonEnum) Event ButtonHeldEnd(Button as ButtonEnum) しかし、これは少し不格好なようで、「バインドボタン」画面に大きな痛みがありました。 誰かが、コントローラーからの入力を処理する「正しい」方法を教えてください。 注:インターフェイスを実装するクラス内でSlimDXを使用しています。これにより、状態を非常に簡単に読み取ることができます。私の問題を解決する代替品も歓迎します

1
堅牢なアイテムシステムの作成
私の目的は、次のようなものを処理できる、可能な限り一般的なアイテムシステムを作成することです。 アップグレード可能なアイテム(+6カタナ) ステータス修飾子(+15器用さ) アイテムモディファイア(Yダメージを与える確率%X、フリーズする確率) 充電アイテム(30回使用の魔法使い) セットアイテム(4セットのXセットを装備してY機能を有効化) レアリティ(共通、ユニーク、伝説) 劣化(一部のクラフト材料に分割) 製作可能(特定の材料で製作可能) 消耗品(5%%X攻撃力、回復+15 hp) ※以下の設定で太字になっている機能は解決できました。 今、私は私が考えていることを反映するために多くのオプションを追加しようとしました。必要な機能をすべて追加するつもりはありませんが、必要に応じて実装できるようにしたいと考えています。これらは、在庫システムおよびデータのシリアル化とも互換性がある必要があります。 私は継承をまったく使用せず、エンティティコンポーネント/データ主導のアプローチを使用することを計画しています。最初は、次のようなシステムについて考えました。 BaseStat:外出先で統計を保持する汎用クラス(アイテムとキャラクターの統計にも使用できます) 項目:リスト、名前、項目タイプ、およびui、actionName、説明などに関連するものなどのデータを保持するクラス。 IWeapon:武器のインターフェース。すべての武器には、IWeaponが実装された独自のクラスがあります。これには、Attackとキャラクター統計への参照があります。武器が装備されている場合、そのデータ(アイテムクラスのstat)がキャラクターstatに挿入されます(BaseStatが何であれ、それはStatボーナスとしてキャラクタークラスに追加されます)したがって、たとえば、剣( jsonを使用してアイテムクラスを作成する)ため、剣はキャラクターのステータスに5攻撃を追加します したがって、BaseStatは( "Attack"、5)になります(enumも使用できます)。このステータスは、装備するとBonusStat(別のクラスになる)としてキャラクターの "攻撃"ステータスに追加されます。したがって、SwordはIWeaponを実装するという名前のクラスが作成されます。アイテムクラスが作成されます。そのため、この剣にキャラクターのステータスを挿入し、攻撃するときに、キャラクターのステータスから合計の攻撃ステータスを取得し、攻撃方法でダメージを与えることができます。 BonusStat:BaseStatに触れずに統計をボーナスとして追加する方法です。 IConsumable:IWeaponと同じロジック。直接統計の追加はかなり簡単(+15 hp)ですが、この設定で一時的な武器を追加するかどうかはわかりません(%xで5分間攻撃する)。 IUpgradeable:これは、このセットアップで実装できます。私は武器をアップグレードするときに増加する基本ステータスとしてUpgradeLevelを考えています。アップグレードすると、武器のBaseStatを再計算して、アップグレードレベルに一致させることができます。 この時点まで、システムはかなり良いと思います。しかし、他の機能については、他に何かが必要だと思います。たとえば、BaseStatはこの機能を処理できず、これが行き詰まったため、Craftable機能をこれに実装できないからです。すべての材料をスタットとして追加できますが、それは意味がありません。 これを簡単に投稿できるようにするために、次の質問を参考にしてください。 このセットアップを続行して他の機能を実装する必要がありますか?継承なしでそれは可能でしょうか? 継承なしでこれらの機能をすべて実装するために、あなたが考えることができる方法はありますか? アイテムモディファイアについて、どうすればそれを達成できますか?それはその性質上非常に一般的だからです。 この種のアーキテクチャを構築するプロセスを容易にするために何ができるか、推奨事項はありますか? この問題に関連する掘り出し物はありますか? 私は本当に継承を避けようとしていますが、継承をかなり維持できるように維持しながら、継承によって簡単に解決/達成できると思いますか? さまざまな側面や人から知識を得ることができるように質問を非常に広くしているので、1つの質問に自由に答えてください。 編集 @ jjimenezg93の答えに従って、C#でテストするための非常に基本的なシステムを作成しました。あなたがそれに何かを追加できるかどうかを確認してください: public interface IItem { List<IAttribute> Components { get; set; } void ReceiveMessage<T>(T message); …

3
make-everything-static-and-globalデザインパターンを取り除きたいのですが、どうすればいいですか?
私は宇宙で小さなダンジョンクローラーを作っています。エンジンのバックエンドをより良くする方法についてのアドバイスを聞きたいです。基本的に、現在はすべてが管理者のがらくたに基づいています: BackgroundManager:AddBackground(image, parallax)クールな背景効果を作成するためのメソッドがあります。 ConfigManager:構成ファイルを読み取り/作成し、その構成ファイルから読み取ったデータも保持します。 DrawManager:持っているDraw(sprite)画面にコンテンツを描画する方法を、そして物事が好きSetView(view)、GetView()など EntityManager:すべてのアクティブなエンティティを保持し、エンティティを追加、削除、検索するためのメソッドを備えています。 DungeonManager(実際GridManagerと呼ばれるが、これは簡単にするためである):のようなメソッドがありGenerateDungeon()、PlaceEnemies()、PlaceFinish()など 現在、私はすべてのマネージャーをリストアップしているわけではないので、これは変化しなければならないと思います。私のゲームもスクリーンに基づいていますが、メインメニューなど、マネージャーが管理しているものの半分が必要ないため、面倒です(メインメニューには物理学/エンティティ/ダンジョンは必要ありません!) ここで、マネージャーを静的ではなく、ScreenMainGameにすべてのゲーム固有マネージャーのインスタンスを与えることを考えました。しかし、それはマネージャーに関連するものを呼び出したり取得したりするのを巨大な混乱にScreenMainGame.Draw()させます... ((ScreenMainGame)ScreenManager.CurrentScreen).GridManager.Draw() それは本当にいです。 それで、仲間のゲーム開発者は、この混乱を解決する方法を知っていますか?ありがたいです!

2
キャラクターのスキルと能力をコマンドとして作成することは良い習慣ですか?
私は、ユニークな攻撃スキルと、構築、修復などの他の能力を持つキャラクターで構成されるゲームを設計しています。プレイヤーは、そのようなキャラクターの複数を制御できます。 そのようなスキルや能力をすべて個別のコマンドに組み込むことを考えています。静的コントローラーは、これらすべてのコマンドを静的コマンドリストに登録します。静的リストは、ゲーム内のすべてのキャラクターの利用可能なすべてのスキルと能力で構成されます。そのため、プレイヤーがいずれかのキャラクターを選択し、UIのボタンをクリックして呪文を唱えたり能力を実行したりすると、ビューは静的コントローラーを呼び出して、リストから目的のコマンドをフェッチして実行します。 Unityでゲームを構築しているので、これが良いデザインであるかどうかはわかりません。すべてのスキルと能力を個別のコンポーネントとして作成し、それをゲーム内のキャラクターを表すGameObjectsに関連付けることができると思います。次に、UIはキャラクターのGameObject を保持してからコマンドを実行する必要があります。 私がデザインしているゲームのデザインと練習は何がいいですか?

1
ゲームアクションを実行するためのパターン
ゲーム内でさまざまなアクションを実行するための一般的に受け入れられているパターンはありますか?プレーヤーがアクションを実行する方法、およびAIが移動、攻撃、自己破壊などのアクションを実行する方法。 現在、.NETジェネリックを使用してさまざまなアクションによって返されるさまざまなオブジェクトを指定する抽象BaseActionがあります。これはすべて、コマンドと同様のパターンで実装され、各アクションはそれ自体に責任を持ち、必要なすべてのことを行います。 私が抽象的である理由は、単一のActionHandlerを使用できるようにするためであり、AIはbaseActionを実装するさまざまなアクションをキューに入れることができます。そしてそれが一般的である理由は、いくつかの一般的なbeforeActionとafterActionの実装とともに、さまざまなアクションがアクションに関連する結果情報を返すことができるようにするためです(さまざまなアクションはゲーム内でまったく異なる結果をもたらす可能性があります)。 それで...これを行うためのより受け入れられた方法はありますか、またはこの音は大丈夫ですか?

7
ゲームにおける描画とロジックの分離
私は今、ゲーム開発をいじり始めている開発者です。私は.Netの男なので、XNAをいじり、iPhone用のCocos2dで遊んでいます。私の質問は本当にもっと一般的です。 簡単なPongゲームを作成しているとしましょう。私が持っていると思いますBallクラスとPaddleクラスを。ビジネスの世界の開発から来た私の最初の本能は、これらのクラスのいずれにも描画または入力処理コードがないことです。 //pseudo code class Ball { Vector2D position; Vector2D velocity; Color color; void Move(){} } ballクラスでは、入力を処理したり、描画を処理したりするものはありません。次に、別のクラス、私のGameクラス、またはScene.m(Cocos2dの)私がボールを新しくし、ゲームループ中に必要に応じてボールを操作します。 ただし、XNAとCocos2dの両方の多くのチュートリアルで、次のようなパターンが見られます。 //pseudo code class Ball : SomeUpdatableComponent { Vector2D position; Vector2D velocity; Color color; void Update(){} void Draw(){} void HandleInput(){} } 私の質問は、これは正しいですか?これは、人々がゲーム開発で使用するパターンですか?Ballクラスにすべてをやらせることは、私が慣れ親しんだことすべてに何らかの形で反します。さらに、この2番目の例では、Ball移動方法がわかっているので、Paddle?のBall知識が必要Paddleですか?私の最初の例では、Gameクラスは、両方への参照であろうBallとPaddle、その後、いくつかにそれらのオフの両方を出荷CollisionDetectionマネージャか何かが、各個々のコンポーネントは、それ自体で、すべてをしなければどのように私は、さまざまなコンポーネントの複雑さに対処するのですか?(私は私が理にかなっていると思います...)

12
グローバル/シングルレットがゲーム開発に役立つケースはありますか?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 グローバル変数またはシングルトンクラスがあると、テスト/管理が困難なケースが作成されることはわかっています。コードでこれらのパターンを使用することで逮捕されましたが、しばしば出荷されました。 では、グローバル変数やシングルトンが実際にゲーム開発に役立つケースはありますか?

4
ゲームデザインでのフレームごとの関数呼び出しとイベント駆動型メッセージング
伝統的なゲームデザインは、私はそれを知っているように、使用する多型と仮想関数を更新ゲームオブジェクトの状態に。言い換えると、ゲーム内のすべてのオブジェクトで、同じ一連の仮想関数が定期的(例:フレームごと)に呼び出されます。 最近、もう1つ、ゲームオブジェクトの状態を更新するためのイベント駆動型メッセージングシステムがあることを発見しました。ここでは、オブジェクトは通常フレームごとに更新されません。代わりに、非常に効率的なイベントメッセージングシステムが構築され、ゲームオブジェクトは有効なイベントメッセージを受信した後にのみ更新されます。 イベント駆動型ゲームアーキテクチャについては、Mike McShaffryによる「Game Coding Complete」で詳しく説明されています。 以下の質問について、親切にお願いできますか? 両方のアプローチの長所と短所は何ですか? どちらが他より優れているのですか? イベント駆動型ゲームデザインは、すべての分野で普遍的で優れていますか?したがって、モバイルプラットフォームでも使用することをお勧めしますか? どちらがより効率的で、どちらが開発が難しいですか? 明確にするために、私の質問はゲームデザインから完全に多態性を取り除くことについてではありません。私は単に、イベント駆動型メッセージングと仮想関数への通常の(フレームごとの)呼び出しを使用してゲームの状態を更新することの違いとメリットを理解したいと思っています。 例: この質問はここで少し論争を引き起こしたので、例を挙げましょう。MVCによると、ゲームエンジンは3つの主要な部分に分かれています。 アプリケーション層(ハードウェアおよびOS通信) ゲームロジック ゲームビュー レーシングゲームでは、ゲームビューは画面をできるだけ速く、少なくとも30fpsでレンダリングする責任があります。ゲームビューもプレイヤーの入力をリッスンします。今これが起こります: プレーヤーが燃料ペダルを80%まで押した GameViewは「Car 2 Fuel Pedal Pressed to 80%」というメッセージを作成し、それをGame Logicに送信します。 Game Logicはメッセージを取得し、評価し、新しい車の位置と動作を計算し、GameView用に次のメッセージを作成します: "Draw Car 2 Fuel Pedal Pressed 80%"、 "Car 2 Sound Acceleration"、 "Car 2 Coordinates X、Y" .. 。 GameViewはメッセージを受信し、それに応じて処理します

2
管理された言語でパーティクルプールを使用する価値はありますか?
パーティクルシステムのオブジェクトプールをJavaで実装するつもりでしたが、ウィキペディアでこれを見つけました。言い換えると、JavaやC#などのマネージ言語ではオブジェクトプールを使用する価値がないとあります。これは、C ++などの非マネージ言語では数百の操作に比べて、割り当てには数十の操作しか必要ないためです。 しかし、誰もが知っているように、すべての命令はゲームのパフォーマンスを損なう可能性があります。たとえば、MMO内のクライアントのプール:クライアントがプールに入ったり出たりする速度が速すぎません。しかし、粒子は一秒間に数十回更新される可能性があります。 問題は、マネージ言語でパーティクル(具体的には、死んですぐに再作成されるもの)のオブジェクトプールを使用する価値があるかどうかです。

3
エンティティを集約として作成する
私は最近、エンティティを動作から分離する方法と、この記事にリンクされている主な回答について尋ねました:http : //cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ ここで書かれている究極のコンセプトは、純粋な集合体としてのオブジェクトです。 C#を使用してゲームエンティティを純粋な集約として作成する方法を知りたいのですが。これがどのように機能するかという概念はまだよく理解していません。(おそらく、エンティティは特定のインターフェースまたは基本タイプを実装するオブジェクトの配列ですか?) 私の現在の考え方には、関連するインターフェイス(IMoveable、ICollectable、ISpeakableなど)を実装する各エンティティタイプの具象クラスがまだ含まれています。 エンティティの具体的なタイプを持たずに、純粋に集約としてエンティティを作成するにはどうすればよいですか?

4
ドメイン駆動設計はゲームに適していますか?
ドメインモデルについて読んだところですが、データのみを保持するクラス(ビヘイビア/メソッドが少ない)を持つゲームを開発して以来、それは私を啓蒙しました。これらのクラスを処理する仕事をマネージャーに割り当てました...そして今私のマネージャーは神のオブジェクトのように見えます。ロジックを処理することになっている私のゲームオブジェクトは、貧血ドメインモデルです。 私の現在のデザインパターンはシングルトンであり、これを実現するためにいくつかの再コーディングを行いたいと思います。(今のところ)ゲームでDDDを見たことがありませんが、これは良いアプローチですか?私はただの初心者プログラマーです(ゲーム開発者に傾倒しています)ので、ゲームを再設計するには肥大化する前に、優れたアーキテクチャーについてもっと学びたいです。

4
ソースのようなエンジンはエンティティをどのように処理しますか?
ソースエンジン(およびその前任者、goldsrc、quake's)では、ゲームオブジェクトは2つのタイプ(ワールドとエンティティ)に分かれています。世界はマップジオメトリで、エンティティはプレーヤー、パーティクル、サウンド、スコアなどです(ソースエンジンの場合)。 すべてのエンティティには、そのエンティティのすべてのロジックを実行するthink関数があります。 したがって、処理する必要のあるものがすべてthink関数を含む基本クラスからのものである場合、ゲームエンジンはリストにすべてを格納し、すべてのフレームでループしてその関数を呼び出すことができます。 一見すると、このアイデアは合理的ですが、ゲームに多くのエンティティがある場合は、リソースが多すぎる可能性があります。 では、Sourceなどのエンジンは、ゲームオブジェクトの処理(処理、更新、描画など)をどのように行うのでしょうか。

3
ゲームロジックをアニメーションや描画ループから分離する方法は何ですか?
私は以前Flashゲームを作成したことがありましたが、MovieClipsなどを使用して、アニメーションをゲームロジックから分離しました。今、私はAndroid向けのゲームを作ることに挑戦していますが、これらを分離することに関するゲームプログラミング理論はまだ混乱しています。私はゲーム以外のWebアプリケーション開発のバックグラウンドを持っているので、MVCのようなパターンに精通していて、ゲームプログラミングに近づくにつれてその考え方にとらわれています。 たとえば、タイルグリッドのデータを含むゲームボードクラスに、それぞれプロパティを含むタイルクラスのインスタンスを含めることで、ゲームを抽象化するようなことをしたいと思います。ドローループにこれへのアクセスを許可し、ゲームボード上の各タイルのプロパティに基づいてゲームボードを描画させることができますが、アニメーションがどこに行くべきか正確にはわかりません。私の知る限り、アニメーションは抽象化されたゲームロジック(モデル)と描画ループ(ビュー)の間に位置しています。私のMVCの考え方では、アニメーションが実際にどこに行くことになっているのかを判断しようとするのは面倒です。モデルのようにかなりのデータが関連付けられますが、フレームに依存しないアニメーションなどを実現するには、描画ループと密接に結合する必要があるようです。 この考え方から抜け出し、ゲームにとってより意味のあるパターンについて考え始めるにはどうすればよいですか?

3
これはどのようなパターンですか、それを行う必要がありますか?
私はフラッシュ開発とフラッシュcs5を使用してas3でゲームを作っています。すべてがオブジェクト指向です。他のクラスのすべてのインスタンス化へのプロパティ参照を持つ1つの「ゲートウェイ」クラスがあり、このゲートウェイクラスを新しいオブジェクトに渡すだけで、すべてのクラスにアクセスできるのではないかと思っていました。そのようです: var block:Block = new Block(gateway); //In the block class: this.gateway.player.setHealth(100); //Or: this.gateway.input.lock(); これはシングルトンパターンのようなものですか?これを行う必要がありますか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.