タグ付けされた質問 「architecture」

コードの構造。ゲームエンジンの内部設計に関する質問。

4
コンポーネントベースのアーキテクチャに適した粒度レベルは何ですか?
コンポーネントベースのアーキテクチャを使用したゲームに取り組んでいます。Entity一連の所有Componentの組それぞれ有する、インスタンスをSlot格納するとインスタンスを送信し、値を受け取ります。Player必要なコンポーネントとスロット接続を備えたエンティティの生成などの工場機能。 コンポーネントの最適な粒度を決定しようとしています。今、例えばPosition、Velocity、とAcceleration直列に接続された全ての別個の構成要素です。VelocityそしてAcceleration容易に均一に書き換えることができるDelta成分、またはPosition、Velocity、およびAccelerationのような成分と一緒に組み合わせることができるFrictionとGravityモノリシックにPhysicsコンポーネント。 コンポーネントの責任は可能な限り小さくする必要がありますか(相互接続性が犠牲になります)、または関連するコンポーネントを組み合わせてモノリシックコンポーネントにする必要があります(柔軟性が犠牲になります)。前者に傾いていますが、セカンドオピニオンを使用できます。

4
オブジェクト指向言語でゲームエンジンを設計する方法は?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 オブジェクト指向言語でゲームを作成しようとするときはいつも、(どんな種類のゲームを書くかを考えた後に)私が常に直面する最初の問題は、エンジンの設計方法です。SDLのような既存のライブラリまたはフレームワークを使用している場合でも、メニューを管理するためにステートマシンを使用するか、リソースの読み込みに使用するクラスの種類など、すべてのゲームに対して特定の決定を行う必要があります。 優れた設計とは何ですか?どのように実装されますか?行わなければならないトレードオフとその長所/短所は何ですか?

5
AssetManagerの設計方法は?
ゲームのグラフィックス、サウンドなどへの参照を保持するAssestManagerを設計するための最良のアプローチは何ですか? これらのアセットをキー/値のマップペアに保存する必要がありますか?つまり、「バックグラウンド」アセットを要求すると、マップは関連するビットマップを返しますか?もっと良い方法はありますか? 具体的には、Android / Javaゲームを書いていますが、答えは一般的なものです。

4
「ゲームオブジェクト」-およびコンポーネントベースのデザイン
私は過去3〜4年間、趣味のプロジェクトに取り組んでいます。シンプルな2Dおよび3Dゲーム。しかし最近、より大きなプロジェクトを始めました。ここ数か月間、私はすべてのゲームオブジェクトのベースとなるゲームオブジェクトクラスを設計しようとしていました。何度も試行錯誤を繰り返した後、グーグルに目を向けると、すぐにいくつかのGDC PDFおよびPowerPointが示されました。そして今、私はコンポーネントベースのゲームオブジェクトを把握しようとしています。 エンジンはゲームオブジェクトを作成し、その後、健康、物理学、ネットワークなどの処理を行うさまざまなコンポーネントをアタッチすることを理解しています。しかし、私が理解していないのは、コンポーネントXがYがオブジェクトの状態を変更したかどうかを知る方法です。健全性はHealthComponentによって制御されているため、PhysicsComponentはプレーヤーが生きているかどうかをどのように知るのでしょうか。そして、HealthComponentはどのようにして「プレイヤーが死んだアニメーション」を再生しますか? 私はそれが次のようなものであると感じていました(HealthComponent内): if(Health < 0) { AnimationComponent.PlayAnimation("played-died-animation") } しかし、もう一度、HealthComponentは、どのように接続されているゲームオブジェクトにAnimationComponentが接続されていることを知るのでしょうか?私がここで見る唯一の解決策は AnimationComponentがアタッチされているかどうかを確認してください(コンポーネントコード内またはエンジン側) コンポーネントには他のコンポーネントが必要ですが、それはコンポーネント設計全体と戦うようです。 HealthWithAnimationComponent、HealthNoAnimationComponentなどのように書きます。これもコンポーネント設計のアイデア全体と戦うようです。

3
ALT-TABが「迷惑」/遅い/グリッチになる原因は何ですか?
これはより自由な質問ですが、この問題を回避する方法についての良い洞察を得たいと思います。 Windowsでゲームをプレイするとき、Altキーを押しながらTabキーを押して外したい場合があります。問題のないゲームもあれば、それほど簡単ではないゲームもあります。AGESを使用してスイッチを入れたり戻したりする場合もあります。 この動作の原因は何だろうか?これはDirectXまたはOpenGLのどちらですか?ゲームが「巧妙」であり、画面設定が変更されるたびにキャッシュをキャッシュ/ワイプすることが原因ですか?(Altキーを押しながらTabキーを押すと、何らかの信号が表示されると思いますか?) 私自身の問題はありませんが、何を避けるべきか、どのような「賢い」トリックがこの種の恐ろしい顧客体験を引き起こす可能性があるのか​​知りたいのですが?

4
単体テストが簡単になるようにゲームのソフトウェアを設計する方法は?
ゲーム開発の状況でJUnitのようなテストフレームワークを使用することは実用的ですか?ゲームをよりテストしやすくするために、どのような設計上の考慮事項に従うことができますか?ゲームのどの部分をテストできる/すべきであり、どの部分を人間のテストに委ねるべきである/すべきですか? たとえば、ゲームループが1つの関数にカプセル化されている場合、テストするのは非常に難しいようです。私は、時間の差分をとり、ゲームロジックを進める「更新」機能をリファクタリングするのが好きです。これにより、偽のより遅い時間差を与えることでゲームを遅くする機能など、いくつかの興味深いトリックが可能になります。

3
有限状態マシンをコンポーネントベースのアーキテクチャに配線する方法は?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 閉じた3年前。 ステートマシンは、コンポーネントベースのアーキテクチャで有害な依存関係を引き起こすようです。 具体的には、状態マシンと状態関連の動作を実行するコンポーネントとの間の通信はどのように処理されますか? 私がいる場所: コンポーネントベースのアーキテクチャは初めてです。 私は格闘ゲームを作っていますが、それは重要ではないと思います。ステートマシンを使用して、「クラウチング」、「ダッシュ」、「ブロッキング」などの状態を切り替えることを想定しています。 この状態管理手法は、コンポーネントベースのアーキテクチャにとって最も自然なシステムであることがわかりましたが、これまでに読んだ手法とは矛盾しています: 可変動作文字の動的ゲームオブジェクトコンポーネントシステムすべてのコンポーネントをアクティブ化/非アクティブ化することをお勧めしますアクティベーションの条件を継続的にチェックすることにより、自分自身。 「実行中」または「ウォーキング」などのアクションは状態として理にかなっていると思います。これは、https://gamedev.stackexchange.com/a/7934で受け入れられている応答とは一致しません。 これは便利ですが、あいまいです。コンポーネントベースのゲームアーキテクチャに動作を実装する方法は?ステートマシンのみを含む別のコンポーネントを使用することをお勧めします。ただし、これには、ステートマシンコンポーネントと他のほぼすべてのコンポーネントとの間に何らかの結合が必要です。このカップリングがどのように処理されるべきか理解できません。これらはいくつかの推測です: A. コンポーネントはステートマシンに依存します。コンポーネントは、列挙定数を返す ステートマシンコンポーネントへの参照を受け取りますgetState()。コンポーネントは定期的に自身を更新し、必要に応じてこれを確認します。 B. ステートマシンはコンポーネントに依存します。 ステートマシンコンポーネントは、監視しているすべてのコンポーネントへの参照を受け取ります。getState()メソッドを照会して、どこにいるかを確認します。 C. それらの間のいくつかの抽象化 イベントハブを使用しますか?コマンドパターン? D. コンポーネントを参照する個別の状態オブジェクト状態 パターンが使用されます。コンポーネントのセットをアクティブ化/非アクティブ化する個別の状態オブジェクトが作成されます。状態マシンは状態オブジェクトを切り替えます。 アスペクトの実装としてコンポーネントを見ています。彼らはその側面を実現するために内部的に必要なすべてを行います。コンポーネントは、他のコンポーネントに依存せずに、単独で機能する必要があるようです。いくつかの依存関係が必要であることは知っていますが、ステートマシンはすべてのコンポーネントを制御したいようです。

4
再起動しないテストワールドを実装する方法
次のことを行う方法についてのアイデアを探しています。Javaで単純な「世界」を書きたいです。既存のオブジェクト間のさまざまな動作をシミュレート/観察するために、後から新しいオブジェクトを開始してから追加できるもの。その後、古いオブジェクトをしばらく見てから新しいオブジェクトをコーディングし、それらを既存の世界にロード/ドロップします。問題は、一度世界を開始または停止して再起動したくない、数週間実行したいが、オブジェクトをドロップして、やり直し/書き換え/削除/作成/変更する機能が必要なことです再起動を必要とせずに時間をかけて。世界は、世界を視覚的に表すタイルマップGUIを使用して、X / Yロケーションの100 x 100配列のようにシンプルにすることができます。オブジェクトを監視し、それぞれに「行動するチャンス」を与えるために、何らかの種類のティックタイマープロセスが必要であることを知っています 例:月曜日にWorld.javaをコーディングし、実行したままにします。それから火曜日に、Rock.javaと呼ばれる新しいクラスを作成します(動かない)。次に、既に実行中のワールドにロード/ドロップします(ワールドアレイ内のランダムな場所にドロップし、移動することはありません)。それから水曜日にCat.javaという新しいクラスを作成し、再びランダムに配置して世界にドロップしますが、この新しいオブジェクトは(時間単位で)世界中を移動でき、木曜日にDogというクラスを作成します。また、移動しますが、隣の場所にある場合は別のオブジェクトに「作用」することができ、逆もまた同様です。 ここにあります。将来の(および現在存在しない)オブジェクトを検出/ロード/追跡する方法を知るために、実際のワールドクラスをコーディングするのにどのような構造/設計が必要かはわかりません。 Javaを使用してこのようなことをどのように行うかについてのアイデアはありますか?

6
ユーザーフレンドリーでありながら柔軟なコンポーネントベースのエンティティシステムにはどのような設計がありますか?
私はしばらくの間、コンポーネントベースのエンティティシステムに興味があり、その上で数え切れないほどの記事を読んでいます(Insomiacゲーム、かなり標準的なEvolve Your Hierarchy、T-Machine、Chronoclast ...など)。 それらはすべて、次のようなものの外側に構造を持っているようです。 Entity e = Entity.Create(); e.AddComponent(RenderComponent, ...); //do lots of stuff e.GetComponent<PositionComponent>(...).SetPos(4, 5, 6); そして、共有データのアイデアを取り入れると(これは、どこでもデータを複製しないという点で、これまで見た中で最高の設計です) e.GetProperty<string>("Name").Value = "blah"; はい、これは非常に効率的です。ただし、読み取りまたは書き込みが最も簡単なわけではありません。それはとても不格好で、あなたに対して働いているように感じます。 私は個人的に次のようなことをしたいと思います: e.SetPosition(4, 5, 6); e.Name = "Blah"; もちろん、この種の設計に到達する唯一の方法は、Entity-> NPC-> Enemy-> FlyingEnemy-> FlyingEnemyWithAHatOnのような階層に戻ることですが、この設計は回避しようとします。 この種のコンポーネントシステムの設計を見たことがありますが、これはまだ柔軟性がありますが、ユーザーフレンドリーなレベルを維持していますか?それに、データストレージ(おそらく最も難しい問題)を良い方法で回避できますか? ユーザーフレンドリーでありながら柔軟なコンポーネントベースのエンティティシステムにはどのような設計がありますか?

6
テスト駆動開発はゲーム開発で実行可能ですか?
スクラム認定を受けているため、システムの開発中にアジャイル手法を採用する傾向があり、スクラムフレームワークのキャンバスを使用して日々の作業を管理することもあります。 それに、TDDが実行可能な場合、ゲーム開発のオプションであるかどうか疑問に思っていますか? このGDの質問を信じるなら、TDDはゲーム開発であまり使用されません。 ゲームアーキテクチャでMVCとTDDが採用されないのはなぜですか? コードを徹底的にテストしないと壊滅的なシナリオが発生する可能性があるため、大きな予算の大きなプロジェクトが完璧に機能する必要がある産業用プログラミングから来ています。 さらに、スクラムのルールに従うことにより、スクラムのすべてのアクションがタイムボックス化されている間、作業の期日を満たすことが奨励されます!ですから、上記の質問で彼らがシステムを構築しようとするのをやめて、ゲームを書き始めると言ったとき、私は同意します。完璧なシステムを構築しないように、最初に:スプリントの終わりまでに機能させるように、スクラムが言っていることはまったく同じです。次に、必要に応じて2番目のスプリントで作業しながらコードをリファクタリングします! ゲーム開発を担当するすべての部門がスクラムを使用しないと、スクラムが役に立たなくなることを理解しています。しかし、少しの間、すべての部門がスクラムを使用していることを考えてみましょう...「完璧な」システム/ゲームを作成したくない場合でも、TDDはバグのないコードを作成するのに適していると思います。 私の質問は次のとおりです。 とにかくゲーム開発でTDDは実行可能ですか?

3
ゲームエンジンでハードコーディングを回避する方法
私の質問はコーディングの質問ではありません。一般的にすべてのゲームエンジンの設計に適用されます。 ハードコーディングをどのように回避しますか? この質問は思ったよりもずっと深いです。操作に必要なファイルをロードするゲームを実行したい場合load specificfile.wad、エンジンのコードのようなものを言わないようにするにはどうすればよいでしょうか?また、ファイルがロードされたときに、どうやって言うのを避けるのload aspecificmap in specificfile.wadですか? この質問は、ほとんどすべてのエンジン設計に当てはまり、可能な限り少ないエンジンをハードコーディングする必要があります。それを達成する最良の方法は何ですか?

3
ドワーフ要塞の命令順序アーキテクチャ
AI用のコマンドオーダーシステムを実装する最もエレガントな方法は何ですか?たとえば、小人の要塞では、森林伐採エリアに木材の切断をマークすると、小人は次のシーケンスを実行します。 木に行く 木を切る 備蓄に木材を届ける 別の木に行く 等々.. 私はすでにスタックコマンドが動作していません。アイドル状態からツリーの宛先タイルに到達する1。 私が恐れているのは、このような注文をさらに作成すると、これがどのように面倒になるかです: 家を建てる 備蓄に行く 建設エリアに木材を持ち込む 備蓄に戻る 建設エリアに石を持参 建物のスプライトをアニメートする 植付 備蓄に行く 種を農場に持ち込む 醸造 備蓄に行く 植物を静止させる 醸造スプライトをアニメートする だから私の質問は、ドワーフ要塞のようなコマンド順序システムをどのように実装し、同時にスパゲッティコードを回避するのですか?調査する必要があるデータ構造はありますか?コマンドシーケンスを別のxmlファイルに配置する必要がありますか?

3
ゲームエンジンとデータ駆動設計
データ駆動設計について聞いたことがあり、しばらくの間それについて研究を続けてきました。そのため、概念を理解するためにいくつかの記事を読みました。 記事の1つは、Kyle Wilsonが作成したData Driven Designです。。彼が説明したように、アプリケーションコード(メモリ、ネットワークなどのリソースを制御するためのコード)とゲームロジックコードを分離し、ゲームロジックコードを外部データソースによって駆動する必要があるように思えます。この時点で、開発者はゲーム内オブジェクトに関する外部データ(キャラクター情報、武器情報、マップ情報など)を受け入れる何らかの種類のゲームエディターを作成することを想像できます。シナリオ設計は、プログラマーが作成したカスタム言語/ツールによってスクリプト化され、ゲームデザイナーがゲームオブジェクト間の相互作用を作成できるようにします。ゲームデザイナーは、既存/カスタムスクリプト言語を使用してゲームのスクリプトを記述するか、ツールをドラッグアンドドロップしてゲームワールドを作成します。私が考えることができるツールのアプローチの例は、通常Bliizardのゲームと一緒にパッケージ化されたWorld Editorです。 ただし、別の記事では、データドリブンデザインの使用、データドリブンデザインに対するケースに反対しています。ゲームの設計者にはプログラミングの負担があるため、ゲームの開発に時間がかかるため、著者はゲームの設計をデータで駆動させないことをお勧めします。代わりに、スケッチデザインからゲームを自由にプログラムするゲームプログラマーが存在し、ゲームプログラミングの終了後にゲーム設計者によって検証されます。彼はこれがプログラマー主導であると呼んでいます。この方法について私が思うことは、私がかつて行った方法に似ています:ゲームロジックは、上記のアイデアと同様に、アプリケーション自体であり、アプリケーションはゲームエディターであり、実際のゲームはツールに基づいて設計されています。 ゲームコンポーネントは多くのプロジェクトで再利用できるため、私にとっては、最初の方法の方が合理的だと思われます。データ駆動設計に反対する2番目の方法では、ゲームコードはそのゲームにのみ属します。これが、WarcraftにはオリジナルのWarcraftやさまざまなカスタムマップなど、非常に多くのゲームジャンルがあり、最も有名なものの1つである、実際に新しいジャンルを定義するDOTAがあると思う理由です。このため、World Editorをゲームエンジンと呼ぶ人がいると聞きました。これはゲームエンジンがどうあるべきか本当ですか? したがって、これらすべての後、これらのアイデア(データ駆動型、プログラマー駆動型、スクリプト作成など)についての私の理解に欠陥があることを確認したいだけです。

4
コンポーネントベースのゲームアーキテクチャに動作を実装する方法
プレイヤーと敵のAIをゲームに実装し始めていますが、これをコンポーネントベースのゲームアーキテクチャに最適に実装する方法について混乱しています。 次のプレイヤーキャラクターがいて、静止したり、走ったり、剣を振ったりできるとします。プレイヤーは、静止状態とランニング状態の両方からスイングソード状態に移行できますが、プレイヤーが立ち上がったり走り回ったりする前にスイングを完了する必要があります。スイング中、プレーヤーは歩き回ることができません。 ご覧のとおり、2つの実装アプローチがあります。 すべてのプレーヤーロジックを含む単一のAIコンポーネントを作成します(実際のコンポーネントから切り離されるか、PlayerAIComponentとして埋め込まれます)。プレーヤーエンティティを構成する個々のコンポーネント間の結合を作成せずに、状態制限を強制する方法を簡単に実行できます。ただし、AIコンポーネントは分割できません。たとえば、立ち上がって歩き回るだけの敵や、歩き回って剣を振り回すだけの敵がいる場合、新しいAIコンポーネントを作成する必要があります。 動作をコンポーネントに分割し、それぞれが特定の状態を識別します。次に、SandComponent、WalkComponent、SwingComponentを取得します。移行ルールを実施するには、各コンポーネントを結合する必要があります。SwingComponentは、スイングの間、StandComponentとWalkComponentを無効にする必要があります。たまに剣を振り回すだけの敵がいる場合、SwingComponentが存在する場合にのみWalkComponentを無効にする必要があります。これにより、より良いコンポーネントの組み合わせが可能になりますが、依存関係が追加されるたびに保守性の悪夢につながる可能性があります。既存のコンポーネントは、依存関係がキャラクターに課す新しい要件でうまく動作するように更新する必要があります。 理想的な状況は、エンジンやスクリプトコードの1行に触れることなく、コンポーネントをコンテナにドラッグすることで、デザイナーが新しい敵/プレイヤーを構築できることです。スクリプトのコーディングを回避できるかどうかはわかりませんが、できるだけシンプルに保ちたいと思います。 すべてをまとめる:すべてのAIロジックを1つのコンポーネントに分割するか、各ロジック状態を個別のコンポーネントに分割して、エンティティバリアントをより簡単に作成する必要がありますか? 編集:私は私が最初と2番目の状況で何を意味したかについていくつかの混乱があると思う。以下の図で説明しようとしました。 個々の状態とエンティティ間の関係に注意してください。最初の状況では、AIコンポーネントはエンティティに配置される前に事前に構築されます。デザイナーが選択できるのは、プログラマーが利用できるAIComponentsの異なるセットからのみです。2番目の状況には、他のコンポーネントと同じレベルの異なる状態があります。設計者は、プログラマーの干渉なしに、独自のAIでエンティティを作成できるようになりました。 問題は、これらがコンポーネントベースのエンティティでAIを構築するための2つのオプションであり、もしそうなら、最大の柔軟性を与えるものは何ですか?

2
カメラ/ビューポートを2Dゲームに実装する
カメラ/ビューポートを2Dゲームに実装する最も実用的な方法は何ですか? 画面を基準とした位置ではなく、オブジェクトの世界の位置を保存する必要があることを読みましたか? 現在の状況: XMLファイルからオブジェクトとレベルを読み込む単純な2Dゲームを実装しました。現在、レベルXMLファイルは次のようになっています。 <map> <tile obj="ground" x="0" y="555" /> <tile obj="ground" x="16" y="555" /> <tile obj="ground" x="32" y="555" /> ... </map> すべてのオブジェクトには、画面上の現在の場所を格納する2Dベクトル「位置」があります。 私が望むもの: 写真の中の: カメラは800x600または640x480です ブロックとスプライトは16x16ピクセルです。 世界のサイズは異なる場合があります 座標はおそらく画面ではなく世界に対して正規化されるべきでしょうか? プレーヤーのx、yに対するビューポートの位置。プレーヤーがカメラのデッドゾーンに到達したときに移動します(このビデオと同様)。 私は擬似的な例/記事を求めていますが、開発に使用しているものを知る必要がある場合:SDL&C / C ++。
20 c++  2d  architecture  camera 

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