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

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、ゲーム開発スタック交換のトピックになるようにします。 5年前に閉鎖されました。 私はAndroid（2-8プレイヤー）向けのマルチプレイヤーリアルタイムゲームを作成する予定で、マルチプレイヤー編成に最適なソリューションは次のとおりです。 PCにサーバー、モバイルにクライアントを作成します。すべての通信はサーバーを経由します（ClientA-> PC SERVER-> All Clients） bluetoothを使用します。まだ使用していません。bluetoothでマルチプレーヤーを作成するのが難しいのかわかりません いずれかのデバイスでサーバーを作成し、他のデバイスを接続します（ネットワーク経由ですが、NATを介したデバイスの問題を解決するのが難しいのかどうかはわかりません） 他の解決策？

11 architecture  android  networking  multiplayer  mobile 

イベントとデリゲートを使用したイベントベースの入力処理システムを使用しています。例： InputHander.AddEvent(Keys.LeftArrow, player.MoveLeft); //Very simplified code しかし、「ネストされた」入力を処理する方法について疑問に思い始めました。たとえば、Half-Life 2（または実際には任意のソースゲーム）では、でアイテムをピックアップできますE。アイテムを拾ったら、で発砲することはできませんLeft Mouseが、代わりにオブジェクトを投げます。まだジャンプできSpaceます。 （入れ子になった入力とは、特定のキーを押す場所であり、実行できるアクションが変わるものです。メニューではありません。） 3つのケースは次のとおりです。 以前と同じアクションを実行できる（ジャンプなど） 同じアクションを実行できない（発砲など） 別のアクションを完全に実行する（NetHackのように、ドアを開くキーを押すと、移動せずにドアを開く方向を選択する） 私の最初のアイデアは、入力が受信された後でそれを変更することでした： Register input 'A' to function 'Activate Secret Cloak Mode' In 'Secret Cloak Mode' function: Unregister input 'Fire' Unregister input 'Sprint' ... Register input 'Uncloak' ... これは、大量の結合、反復的なコード、およびその他の悪い設計兆候の影響を受けます。 他のオプションは、ある種の入力状態システムを維持することだと思います-おそらく、レジスタ関数の別のデリゲートが、これらの多数のレジスタ/デレジスタをよりクリーンな場所にリファクタリングして（入力システムにある種のスタックがある場合）、または多分守るべきこととすべきでないこと。 ここの誰かがこの問題に遭遇したに違いない。どのように解決しましたか？ tl; drイベントシステムで特定の入力の後に受信した特定の入力をどのように処理できますか？

11 c#  architecture  input  events 

もちろん状況にもよります。しかし、より低いレベルのオブジェクトまたはシステムがより高いレベルのシステムと通信する場合、より高いレベルのオブジェクトへのポインターを保持するよりも、コールバックまたはイベントを優先する必要がありますか？ たとえばworld、メンバー変数を持つクラスがありますvector<monster> monsters。monsterクラスがと通信するとき、worldコールバック関数を使用する方がいいですかworld、monsterそれともクラス内のクラスへのポインターが必要ですか？

11 architecture  software-engineering 

コンポーネントベースのゲームオブジェクトシステムを作成しています。いくつかのヒント： GameObjectは単にのリストですComponents。 ありますGameSubsystems。たとえば、レンダリング、物理などです。それぞれにGameSubsystemは、のいくつかへのポインタが含まれていますComponents。GameSubsystem非常に強力で柔軟な抽象化です。ゲームの世界のあらゆるスライス（または側面）を表します。 登録の仕組みでは必要ありComponentsでGameSubsystems（ときGameObjectに作成および構成されているが）。4つのアプローチがあります。 1：一連の責任パターン。すべてComponentがすべてに提供されますGameSubsystem。GameSubsystemどちらComponentsを登録するか（およびそれらを整理する方法）を決定します。たとえば、GameSubsystemRenderはレンダリング可能コンポーネントを登録できます。 プロ。Componentsそれらがどのように使用されるかについては何も知りません。低カップリング。A.新しいを追加できGameSubsystemます。たとえば、すべてのComponentTitleを登録し、すべてのタイトルが一意であり、タイトルごとにオブジェクトをクエリするためのインターフェイスを提供することを保証するGameSubsystemTitlesを追加しましょう。もちろん、この場合、ComponentTitleを書き換えたり継承したりしないでください。B.既存のを再編成できGameSubsystemsます。たとえば、GameSubsystemAudio、GameSubsystemRender、GameSubsystemParticleEmmiterをGameSubsystemSpatialにマージできます（すべてのオーディオ、エミッターを配置Componentsし、同じ階層にレンダリングし、親相対変換を使用します）。 詐欺。すべてのチェック。非常に非効率的です。 詐欺。Subsystemsについて知っていComponentsます。 2：それぞれが特定のタイプをSubsystem検索しComponentsます。 プロ。よりも優れたパフォーマンスApproach 1。 詐欺。Subsystemsまだ知っていComponentsます。 3：Component自身をに登録しGameSubsystem(s)ます。コンパイル時にGameSubsystemRendererがあることがわかっているので、ComponentImageRenderはGameSubsystemRenderer :: register（ComponentRenderBase *）のようなものを呼び出します。 プロ。パフォーマンス。のように不要なチェックはありませんApproach 1。 詐欺。Componentsとうまく結合されていませんGameSubsystems。 4：メディエーターパターン。GameState（を含むGameSubsystems）registerComponent（Component *）を実装できます。 プロ。ComponentsそしてGameSubystemsお互いについて何も知りません。 詐欺。C ++では、醜くて遅いtypeid-switchのように見えます。 質問： どのアプローチがより優れており、コンポーネントベースの設計で主に使用されていますか 練習は何を言いますか？の実装に関する提案はありApproach 4ますか？ ありがとうございました。

11 c++  architecture  component-based 

ゲーム開発者はどのようにして複数のプラットフォーム（Xbox 360、PS3、PCおよびLinux）をターゲットにするのかに対する回答の一部ですか？しかし、主にゲームを公開している人がいるため、クロスプラットフォームは、ビジネスに侵入しようとする開発者にとって最初の要件/機能である必要がありますか？私は常に（完全に先延ばしのような方法で）「ニッチ」または「マスマーケット」プラットフォームのいずれかを選択し、需要が正当化する場合は後で移植することを信じてきました。クロスプラットフォームは常に、参入に対する人工的な障壁のように感じられました。誰もがiPhone、Windows、またはブラウザゲームを作成すべきではないのですか？

11 architecture  cross-platform 

時には、グラフィックスやサウンドファイルなどを使用するのではなく、人々がそれを推奨するのを見るでしょう。このような... // Game code Image myImage = new Image("path/to/image.png"); ... 代わりにマニフェストファイルを間接参照のレベルとして使用する必要があります。 // Manifest file MY_IMAGE: path/to/image.png // Game code Manifest myManifest = new Manifest("path/to/manifest"); Image myImage = myManifest.getImage("MY_IMAGE"); このようなアプローチを取る理由は何ですか？コンパイルされた言語を使用していない場合でも、これを行う理由はありますか？

11 architecture  assets 

ゲームのロジックを再コード化する必要なしに、ゲームを2Dと3Dの両方のグラフィックスで（別々に）使用できるようにする抽象化/プログラム設計のコード哲学/構造は何ですか？ 同じコードを取り、最小限の変更（たとえば、2Dアセットのファイル名を3Dアセットのファイル名に交換するなど）を行い、ジェネリック/テンプレートごとに基本クラスのいくつかの特殊化をプラグインしている可能性があります。 意味のある現実的な状況に置くために、いくつかの非常に優れたゲーマーリグを備えたプレーヤー用の1つの一流の、パフォーマンスを要求する3Dクライアントと、古いもののためのより控えめな2DクライアントがあるLANマルチプレーヤーゲームを想像してください。誰かが屋根裏で見つけたほこりっぽい箱。しかし、それでも同じゲームです。同じイベントが登録され（誰かがコインを拾った）、同じネットワークプロトコルが使用され、世界は比例します。 MVCコンテキストに配置するには：コントローラーはまったく同じ（「上」キーを押すとプレーヤーの加速が3.5単位/秒に設定されます）、ビューはまったく異なり（2Dと3D）、モデルは同じですグラフィックに直接関連するものを除いて（環境の衝突チェックは5秒ごとに実行され、同じアルゴリズムを使用します。これは、2DバージョンのすべてのゲームオブジェクトにZ座標があることを意味しますが、無視するか、別の方法でユーザーに表示します（たとえば、プレイヤーが空中にいるときにさらに左に表示される影によって）。 これをこのような魅力的なトピックにしているのは、開発者が自分のデータがどのように構造化され、制御がどのように流れるかについて非常に明確な考えを持つことを強制することです。これは、SDL、D3DX、OpenGLなどのグラフィックライブラリ以外の使用を意味するものではないことに注意してください。ゲームエンジンはありません。 これはほとんど理論的な問題なので、プログラミング言語は省略しますが、例を挙げたい場合は、好きな言語を使用できます。C++を使いたいなら、Brainfuckでもいいと思います。課題まで（具体的な回答はもちろん、抽象的な回答も歓迎します！）

11 architecture 

ここで何が質問されているのかを理解することは困難です。この質問は、あいまいで、あいまいで、不完全で、過度に広い、または修辞的であり、現在の形では合理的に回答することができません。再開できるようにこの質問を明確にするヘルプについては、ヘルプセンターに アクセスしてください。 6年前に閉鎖されました。 これまでは、有限状態機械（FSM）や階層型FSMなどの単純なシステムを使用してAIの動作を制御してきました。このパターンは、非常に迅速に、または複雑なシステムで崩壊します。 行動ツリーについて聞いたことがあります。それらは次の明白なステップのように見えますが、動作する実装を見たことがないか、実際に実際に試したことはありません。 複雑なAIの動作を管理しやすくする他のパターンは何ですか？

11 architecture  ai  behavior 

基本的なシステム、コンポーネント、エンティティのアプローチから始めます。 コンポーネントのタイプに関する情報だけから集合（この記事から派生した用語）を作成しましょう。これは、エンティティにコンポーネントを1つずつ追加/削除するのと同じように、実行時に動的に行われますが、タイプ情報のみを対象としているため、より正確に名前を付けましょう。 次に、それらすべての集合を指定するエンティティを作成します。エンティティを作成すると、その組み合わせは不変です。つまり、その場で直接変更することはできませんが、ローカルコピーへの既存のエンティティの署名を（コンテンツとともに）取得し、適切に変更して、新しいエンティティを作成できます。それの。 ここで重要な概念について説明します。エンティティが作成されると、それは常にassemblage bucketというオブジェクトに割り当てられます。つまり、同じ署名のすべてのエンティティが同じコンテナ（例：std :: vector）に置かれます。 現在、システムは関心のあるすべてのバケットを反復処理し、その仕事をしています。 このアプローチにはいくつかの利点があります。 コンポーネントは少数（正確にはバケット数）の連続したメモリチャンクに格納されます-これによりメモリの使いやすさが向上し、ゲーム全体の状態をダンプするのが簡単になります システムはコンポーネントを線形的に処理します。つまり、キャッシュの一貫性が向上します。さようなら辞書とランダムメモリジャンプ 新しいエンティティの作成は、アセンブリをバケットにマッピングし、必要なコンポーネントをそのベクトルにプッシュバックするのと同じくらい簡単です エンティティの削除は、std :: moveを1回呼び出して最後の要素を削除された要素と交換するのと同じくらい簡単です。現時点では順序は関係ないためです。 完全に異なるシグネチャを持つ多くのエンティティがある場合、キャッシュコヒーレンシの利点はある程度減少しますが、ほとんどのアプリケーションでは発生しないと思います。 ベクトルが再割り当てされると、ポインターの無効化にも問題があります。これは、次のような構造を導入することで解決できます。 struct assemblage_bucket { struct entity_watcher { assemblage_bucket* owner; entity_id real_index_in_vector; }; std::unordered_map<entity_id, std::vector<entity_watcher*>> subscribers; //... }; そのため、ゲームロジックの何らかの理由で、新しく作成されたエンティティを追跡したいときはいつでも、バケット内にentity_watcherを登録し、エンティティを削除中にstd :: moveする必要がある場合は、そのウォッチャーをルックアップして更新しますそれらreal_index_in_vectorを新しい値に。ほとんどの場合、これはエンティティの削除ごとに1回の辞書検索を課します。 このアプローチには他に不利な点はありますか？ なぜ明白なのに、なぜ解決策がどこにも言及されていないのですか 編集：コメントが不十分であるため、「回答に答える」ために質問を編集しています。 静的なクラスの構築を回避するために特別に作成された、プラグ可能なコンポーネントの動的な性質を失います。 私はしません。多分私はそれを十分に明確に説明しなかった： auto signature = world.get_signature(entity_id); // this would just return …

11 architecture  performance  entity-system  entity-component 

ここで説明するように、コンポーネント間の通信にシステムを使用するエンティティコンポーネントパラダイムで設計されたゲームを作成しています。開発の段階で、ゲームの状態（一時停止、再生、レベルスタート、ラウンドスタート、ゲームオーバーなど）を追加する必要がありますが、フレームワークでそれを行う方法がわかりません。私は誰もが参照していると思われるゲームの状態に関するこのコード例を見てきましたが、私のフレームワークに適合しないと思います。各州が独自の描画と更新を処理しているようです。私のフレームワークには、システムを使用してすべての更新を処理するSystemManagerがあります。たとえば、次は私のRenderingSystemクラスです。 public class RenderingSystem extends GameSystem { private GameView gameView_; /** * Constructor * Creates a new RenderingSystem. * @param gameManager The game manager. Used to get the game components. */ public RenderingSystem(GameManager gameManager) { super(gameManager); } /** * Method: registerGameView * Registers gameView into the RenderingSystem. * @param gameView …

11 architecture  component-based  entity-system  state 

システムの抽象化を作成する場合、プラットフォームのさまざまなAPIを、意味のある最低レベルの共通インターフェースによって非表示にすることをお勧めします。 さまざまな最新（固定関数パイプラインなし）のネイティブグラフィックAPIを考慮に入れる：OpenGLES 2.0 +、OpengGL 3.0 +、DirectX 10.0 +、Xbox DirectX 9、LibGCM ステートレスな低レベルグラフィックAPI を作成してそれらすべての上に配置する場合、それを可能な限り薄く、高速にするために最適な方法は何でしょうか。

11 architecture  software-engineering  graphics  cross-platform 

伝統的なゲームデザインは、私はそれを知っているように、使用する多型と仮想関数を更新ゲームオブジェクトの状態に。言い換えると、ゲーム内のすべてのオブジェクトで、同じ一連の仮想関数が定期的（例：フレームごと）に呼び出されます。 最近、もう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はメッセージを受信し、それに応じて処理します

11 game-design  architecture  design-patterns  events  patterns 

私が取り組んでいるゲームで問題に遭遇しましたが、それはおそらく多くのゲームで登場するかなり基本的なことのようです。 私のゲームでは、キャラクターアニメーションの特定の時点でゲームプレイ機能を実行する必要があります。そして、タイトルが示すように、ゲームプレイ関連のイベント/機能/アクションをキャラクターのアニメーションの特定のポイントに同期するためのいくつかの優れたテクニックと基本的な戦略は何なのかと思っています。 ここでは、さまざまな種類のゲームで私が話していることの簡単な例をいくつか示します。 あなたのキャラクターはシューティングゲームで彼らの銃をリロードします。キャラクターは「リロード」アニメーションを再生しますが、currentAmmo変数を設定する関数は、マガジンが交換されて銃がコックされた直後にのみ呼び出されることが重要です。これは、リロードアニメーションの途中の可能性があります。 では、ターンベースのRPGあなたのキャラクターは敵のラインが直面しているラインに立ちます。攻撃するように命じられると、キャラクターの1人が敵の1人まで走ったりジャンプしたり、立っている場所に走ったりジャンプしたりする前に巨大な剣を斬ったりします。スラッシュアニメーションが再生される正確なタイミングで敵がダメージを受けていることを確認する必要があります。 ではステルスゲーム、あなたのキャラクターがこっそりすることができ、世界でコンピューターとボタンと対話します。多分あなたが浸透している前哨のライトへの電力供給をオフにするボタンがあるでしょう。アクションボタンを押すと、キャラクターが手を伸ばしてボタンを押し、アイドル状態に戻ります。ボタンが押されたときに、「push_button」アニメーションの正確なポイントでライトをオフにしたい。 確かに、私の特定のケースは2番目の例に最も似ています。この例では、攻撃中にターンベースのキャラクターが前方に突進するアニメーションを作成し、アニメーションが接触していると思われる瞬間にダメージを適用したいと考えています。 。私のゲームはターンベースのシステム（ファイナルファンタジーやファイアーエンブレムのようなものを想像してください）を使用しているので、ダメージ/ヒーリング/マジックなどが必要です。実際にコリジョン/ヒットボックスを使用していなくても、各キャラクターアニメーションの正しいタイミングで適用されます。 私は人気のあるゲームエンジンでゲームを作成していること、そして今はアニメーションイベントまたは通知を使用してこれを処理し、望ましい結果に近い何かを達成することを言及しなければなりません-キャラクターが特定のコマンドを実行してトリガーしますコマンド固有のアニメーション（つまり、「attack_command」）と各コマンドのアニメーションアセットには、アニメーションイベントを含める/キャラクターのExecuteCommand関数に「コールバック」を通知する必要があります。言い換えると、キャラクターは攻撃アニメーションに再生を指示し、攻撃アニメーションはダメージが与えられるべきアニメーションの正確な瞬間にイベント/通知コールバックをキャラクターに送信します。 正直なところ、これは今のところ機能しますが、ここでは全体像の一部が欠けているように感じられます。このメソッドが間違っていると感じる理由の1つは、ゲームロジックとアニメーションアセットを結合することです。アニメーションアセットにExecuteCommand（）イベント/コールバックを含めるのを忘れた場合、コマンドは正しく実行されず、コマンドを実行せずにコマンドアニメーションが終了したかどうかを確認するには追加のコードが必要です。それは乱雑で、私のゲームプレイがそのアセットに奇妙な依存関係を持っていることを意味します。もちろん、攻撃アニメーションの特定の時点でダメージが発生するようにしたいのですが、アニメーションアセット内のゲームプレイコードを呼び出すのはとても変です。 だから私はここで見落としているものは何ですか？アニメーション中に特定の時間に特定の重要なゲームプレイアクションを発生させたい場合に、このようなタイプの状況を処理するための優れた一般的なテクニックは何ですか？ 編集：明確にするために、これはエンジン固有の質問ではなく、エンジン固有の設計/手法も探していません。使用しているテクノロジーに関係なく、ゲームプロジェクトで使用できる一般的なアニメーション/ゲームプレイ同期手法に興味があります。

10 architecture  animation  events  timer 

バックグラウンド： 私は、C ++とOpenGLを使用して、エンティティコンポーネントシステムタイプアーキテクチャ用のシンプルな3Dレンダリングシステムを設計しています。システムは、レンダラーとシーングラフで構成されています。レンダラーの最初の反復を終えたら、シーングラフをECSアーキテクチャーに配布します。今のところ、それは何らかの方法でプレースホルダーです。可能であれば、レンダラーの目標は次のとおりです。 シンプルさ。これは研究プロジェクト用であり、システムを簡単に変更および拡張できるようにしたい（したがって、ECSアプローチ）。 パフォーマンス。私のシーンには、多くの小さなモデルと、多くのジオメトリを持つ大きなボリュームがあるかもしれません。OGLコンテキストからオブジェクトを取得し、レンダリングフレームごとにジオメトリをバッファリングすることはできません。キャッシュミスを回避するために、データの局所性を目指しています。 柔軟性。スプライト、モデル、ボリューム（ボクセル）をレンダリングできる必要があります。 分離。レンダラーを作成した後、シーングラフがコアECSアーキテクチャにリファクタリングされる場合があります。 モジュラー。シーングラフを変更せずに、さまざまなレンダラーを入れ替えることができると便利です。 参照透明度、つまり、いつでも有効なシーンを指定できるため、そのシーンでは常に同じ画像がレンダリングされます。特にこの目標は必ずしも必要ではありません。シーンのシリアル化を簡略化し（シーンの保存と読み込みができるようにする必要があります）、テスト/実験の目的で実行時に異なるシーンを入れ替える柔軟性が得られると思いました。 問題とアイデア： 私はいくつかの異なるアプローチを考え出しましたが、各レンダリングノードのOGLリソース（VAO、VBO、シェーダーなど）をキャッシュする方法に苦労しています。以下は、これまでに考えてきたさまざまなキャッシングの概念です。 一元化されたキャッシュ。各シーンノードにはIDがあり、レンダラーにはIDをレンダリングノードにマップするキャッシュがあります。各レンダーノードには、ジオメトリに関連付けられたVAOとVBOが含まれています。キャッシュミスはリソースを取得し、ジオメトリをキャッシュ内のレンダーノードにマップします。ジオメトリが変更されると、ダーティフラグが設定されます。レンダラーがシーンノードを反復処理しているときにダーティジオメトリフラグを確認すると、レンダラーを使用してデータを再バッファーします。シーンノードが削除されると、イベントがブロードキャストされ、レンダラーは関連するレンダーノードをキャッシュから削除し、リソースを解放します。または、ノードに削除のマークが付けられており、レンダラーがノードを削除する責任があります。このアプローチは、4と5も考慮しながら、最も厳密に目標6を達成すると思います。2は、配列アクセスの代わりにマップルックアップを使用すると、複雑さが増し、データの局所性が失われます。 分散キャッシュ。上記と同様ですが、各シーンノードにはレンダーノードがあります。これにより、マップルックアップがバイパスされます。データの局所性に対処するために、レンダーノードをレンダラーに保存できます。その場合、シーンノードは代わりにレンダリングノードへのポインターを持つことができ、レンダラーはポインターをキャッシュミスに設定します。この種のエンティティコンポーネントアプローチを模倣しているので、アーキテクチャの他の部分と一貫性があると思います。ここでの問題は、シーンノードがレンダラー実装固有のデータを保持することです。レンダラでのレンダリング方法を変更する場合（スプライトとボリュームのレンダリングなど）、レンダーノードを変更するか、シーンノードに「コンポーネント」を追加する必要があります（つまり、シーングラフも変更します）。プラス面では、これは、最初の反復レンダラーを起動して実行する最も簡単な方法のようです。 分散メタデータ。レンダラーキャッシュメタデータコンポーネントは、各シーンノードに格納されます。このデータは実装固有ではなく、ID、タイプ、およびキャッシュに必要なその他の関連データを保持しています。次に、IDを使用して配列内で直接キャッシュルックアップを実行できます。タイプは、使用するレンダリングアプローチのタイプ（スプライトとボリュームなど）を示します。 訪問者+分散マッピング。レンダラーはビジターであり、シーンノードはビジターパターンの要素です。各シーンノードは、レンダラーのみが操作するキャッシュキー（メタデータのようにIDのみ）を保持します。IDは、一般化されたマップ検索の代わりに配列に使用できます。レンダラーを使用すると、シーンノードのタイプに基づいてシーンノードが異なるレンダリング関数をディスパッチでき、IDは任意のキャッシュで使用できます。デフォルトまたは範囲外のIDは、キャッシュミスを示します。 この問題をどのように解決しますか？それとも何か提案はありますか？私のテキストの壁を読んでくれてありがとう！

10 architecture  rendering  entity-system  scene-graph 

私のシーンには複数のオブジェクトが含まれています。（3つの立方体、1つの円柱、8つの球体としましょう。）それぞれに頂点シェーダーを作成する必要があると仮定します。いくつのプログラムが必要ですか？ 代替案： オブジェクトごとに1つのプログラム すべてのキューブ用のプログラムと、すべての球用のプログラム（同じシェーダーを使用する場合） すべてのための1つの大きなプログラム 正しいアプローチは何ですか？

10 opengl  shaders  architecture