タグ付けされた質問 「component-based」

コンポーネントを中心に設計されたゲームで衝突を適切に処理する方法に頭を悩ませようとしています。 多くの例ではPhysicsComponent、エンティティのコンポーネントのリストに何らかの種類の追加が加えられていますが、実際の実装では混乱します。 これPhysicsComponentが機能するためには、周囲の世界にアクセスする必要があります。これは私には直感的な意味がありません。コンポーネントは、そのコンテナ（エンティティ）だけでなく、そのコンテナのコンテナ（世界）を認識すべきではありませんか？ 私には、レベルまたはシーンがこれらのエンティティのリストを維持し、ゲームが更新されるたびに、エンティティをループしてどのコリジョンを決定するように聞こえます。 私の質問は、第一に、これが良い設計であるかどうか、そして第二に、どのエンティティが衝突できるかを決定する方法です。ソリッドエンティティは空のIRigidBodyインターフェイスを実装できるので、レベルはリスト内のどのエンティティが衝突をサポートするかを決定できます。しかし、これはコンポーネントの設計を壊していますか？ 代わりに、空のRigidBodyコンポーネントを含める必要がありますか？常に空であるとは限らず、このアプローチはより将来性があるため、これは実際により良い場合があります。これに関する唯一の問題は複雑さです。シーンは、すべてのエンティティだけでなく、すべてのエンティティのコンポーネントもループして、このRigidBodyコンポーネントがあるかどうかを判断する必要があります。 第三に、それらが衝突した場合、両方のエンティティに何らかの方法で通知する必要があり、これを達成する方法については確信がありません。 両方のエンティティにHealthComponentが含まれていて、衝突すると両方のヘルスが任意の値5減少するとします。2つのエンティティ間の衝突を検出した場合、これを処理するのはシーンの責任です。 しかし、その後、シーンはあまりにも責任がありますか？エンティティがアクセスしてはならない（？）ものの多くをシーンが担当している場合、これが手に負えなくなり、扱いにくくなるのを見ることができました。 編集：詳細が更新された質問。

11 xna  c#  game-design  architecture  component-based 

階層ベースのゲームエンジンからコンポーネントベースのゲームエンジンに切り替えるだけです。私の問題は、メッシュの階層を持つモデルをロードすると、コンポーネントベースのシステムのエンティティは同じタイプの複数のコンポーネントを持つことができないが、それぞれに「meshComponent」が必要になるということです。モデルのメッシュ。だから私はこの問題をどのように解決できますか？ このサイトでは、コンポーネントベースのゲームエンジンを実装しました：http : //cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

11 architecture  component-based 

私は現在、コンポーネントベースのエンティティシステムを実装しようとしています。エンティティは基本的に単なるIDであり、いくつかのコンポーネントを束ねてゲームオブジェクトを形成するヘルパーメソッドです。そのいくつかの目標は次のとおりです。 コンポーネントには状態のみが含まれます（例：位置、ヘルス、弾薬数）=>ロジックは「システム」に入り、これらのコンポーネントとその状態（例：PhysicsSystem、RenderSystemなど）を処理します 純粋なC＃とスクリプト（Lua）の両方でコンポーネントとシステムを実装したいと思います。基本的に、C＃ソースを再コンパイルすることなく、完全に新しいコンポーネントとシステムをLuaで直接定義できるようにしたいと考えています。 これを効率的に一貫して処理する方法についてのアイデアを探しているので、たとえば、C＃コンポーネントやLuaコンポーネントにアクセスするために別の構文を使用する必要はありません。 私の現在のアプローチは、通常のパブリックプロパティを使用してC＃コンポーネントを実装することです。おそらく、エディターにデフォルト値などを伝えるいくつかの属性で装飾されています。次に、C＃クラス "ScriptComponent"を作成します。これは、Luaテーブルを内部でラップするだけで、このテーブルはスクリプトによって作成され、特定のコンポーネントタイプのすべての状態を保持します。コンパイル時にはわからないので、C＃側からはその状態にあまりアクセスしたくないのですが、どのScriptComponentsにどのプロパティを使用できるかはわかりません。それでも、エディターはそれにアクセスする必要がありますが、次のような単純なインターフェースで十分です。 public ScriptComponent : IComponent { public T GetProperty<T>(string propertyName) {..} public void SetProperty<T>(string propertyName, T value) {..} } これは単にLuaテーブルにアクセスし、Luaからこれらのプロパティを設定および取得するだけで、純粋なC＃コンポーネントにも簡単に含めることができます（ただし、通常のC＃プロパティをリフレクションなどで使用します）。これはエディターでのみ使用され、通常のゲームコードでは使用されないため、ここではパフォーマンスはそれほど重要ではありません。特定のコンポーネントタイプが実際に提供するプロパティを文書化したコンポーネントの説明を生成または手書きする必要がありますが、それは大きな問題ではなく、十分に自動化できます。 しかし、Lua側からコンポーネントにアクセスする方法は？たとえばgetComponentsFromEntity(ENTITY_ID)、「ScriptComponent」を含むネイティブのC＃コンポーネントの束をユーザーデータとして取得することになるでしょう。ラップされたLuaテーブルから値GetProperty<T>(..)にアクセスすると、他のC＃コンポーネントのようにプロパティに直接アクセスする代わりに、メソッドが呼び出されます。 おそらくgetComponentsFromEntity()、Luaからのみ呼び出される特別なメソッドを記述します。これは、代わりにラップされたテーブルを返す「ScriptComponent」を除いて、すべてのネイティブC＃コンポーネントをユーザーデータとして返します。しかし、他のコンポーネント関連のメソッドがあるので、C＃コードまたはLuaスクリプトから呼び出されるために、これらのメソッドをすべて複製したくありません。 最終的な目標は、ネイティブコンポーネントとLuaコンポーネントを区別する特別なケース構文なしで、特にLua側から、すべてのタイプのコンポーネントを同じように処理することです。たとえば、次のようなLuaスクリプトを記述できるようにしたいと思います。 entity = getEntity(1); nativeComponent = getComponent(entity, "SomeNativeComponent") scriptComponent = getComponent(entity, "SomeScriptComponent") nativeComponent.NativeProperty = 5 scriptComponent.ScriptedProperty = 3 スクリプトは、実際に取得したコンポーネントの種類を気にする必要はありません。C＃側から使用するのと同じメソッドを使用して、コンポーネントを取得、追加、または削除します。 たぶん、そのようなエンティティシステムとスクリプトを統合するいくつかのサンプル実装がありますか？

11 c#  component-based  entity-system  scripting  lua 

スクリプトファイルでエンティティコンポーネントを定義する多くのゲームを見てきましたが、各エンティティを構成し、そのエンティティが持つコンポーネントを指定するとき、他のファイル形式（XMLなど）を使用します。なぜ彼らはそれをするのですか？ 私は主に他の人の根拠がこれについて何であったかを確認するように求めています。私はまた、（私はXML JSONを選択しなかったが）外のスクリプトの私のエンティティを設定します。これを行う理由は、セーブゲームを簡単に実装できるようにするためです。また、この種の構成はXMLやJSONのようなものに整理するほうがよいと思うからです。 @ クリストファーラーセンの答え： コメントとして投稿するには長すぎる 質問の主題から少し逸脱しているのではないかと思います。あなたが説明している問題は、階層ベースのエンティティにより関連しています。私の質問では、コンポーネントベースのエンティティについて話していることを述べました。 これが私が聞きたかった例です。以下は、エンティティを構成する2つの代替方法です。スクリプトを使用する方法と外部JSONファイルを使用する方法です。私の質問は、なぜ多くの人がスクリプトの外でエンティティを構成することを好むのかということでした。 基本エンティティクラス： class Entity: def __init__(self, name): pass def addComponent(self, comp): pass スクリプトのアプローチ： orc = Entity('Orc') orc.addComponent(PositionComponent(3.4, 7.9)) JSONアプローチ： { "name" : "Orc", "components": { "PositionComponent": { "x" : 3.4, "y" : 7.9 } } } このアプローチを使用する理由は既に述べましたが、これは技術的で組織的なものです。なぜこれほど多くの他の人（私が見たものから）がこれを使用するのか知りたいと思いました。

11 component-based  scripting  entity-system  xml  configuration 

シングルプレイヤーゲームで、外部スクリプトで指定されたコンポーネントからエンティティを構築しようとする場合、コンポーネントの1つが不正な形式である場合に何が望ましいと思いますか。 エンジンはそのコンポーネントをスキップして、適切に記述されたコンポーネントのみを使用してエンティティをゲームの世界に住まわせる必要がありますか？ または、コンポーネントの1つが不正な形式である場合、エンティティを世界に追加しないでください。 エラーをログに記録することについては話していないことに注意してください。これは言うまでもなく、エンティティに何が起こるかについてだけです。

11 component-based  validation 

コンポーネントベースのゲームオブジェクトシステムを作成しています。いくつかのヒント： 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 

ここで説明するように、コンポーネント間の通信にシステムを使用するエンティティコンポーネントパラダイムで設計されたゲームを作成しています。開発の段階で、ゲームの状態（一時停止、再生、レベルスタート、ラウンドスタート、ゲームオーバーなど）を追加する必要がありますが、フレームワークでそれを行う方法がわかりません。私は誰もが参照していると思われるゲームの状態に関するこのコード例を見てきましたが、私のフレームワークに適合しないと思います。各州が独自の描画と更新を処理しているようです。私のフレームワークには、システムを使用してすべての更新を処理する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 

私は「Learning LibGDX Game Development」の本に従ってシンプルなゲームを作成しています。私は、ステージを作成してデバッグ境界線でレンダリングするメニュー作成セクションにいます。 本は使用するように言っていますTable.drawDebug(stage)が、この静的メソッドはフレームワークTableクラスから完全に削除されたようです。 インポートしていcom.badlogic.gdx.scenes.scene2d.ui.Tableます。以下は私のコードです： @Override public void render(float deltaTime) { Gdx.gl.glClearColor(0.0f, 0.0f, 0.0f, 1.0f); Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT); if (debugEnabled) { debugRebuildStage -= deltaTime; if (debugRebuildStage <= 0) { debugRebuildStage = DEBUG_REBUILD_INTERVAL; rebuildStage(); } } stage.act(deltaTime); stage.draw(); Table.drawDebug(stage); } 最後の行にTable.drawDebug(stage);はコンパイルエラーがあります"The method drawDebug(ShapeRenderer) in the type Table is not applicable for the …

10 libgdx  unity  android  orientation  bug  rotate  game-design  ios  copyright  c++  rpg  statistics  java  android  andengine  music  eclipse  c++  directx  quaternion  shaders  lighting  java  libgdx  game-mechanics  unity  component-based  unityscript 

通常の継承の重いゲームエンジンの代わりに、よりコンポーネントベースのアプローチをいじっています。ただし、コンポーネントに機能させる場所を正当化するのに苦労します。 コンポーネントのリストを持つ単純なエンティティがあるとします。もちろん、エンティティはこれらのコンポーネントが何であるかを知りません。画面上のエンティティに位置を与えるコンポーネントが存在する場合もあれば、画面上にエンティティを描画するためのコンポーネントが存在する場合もあります。 これらのコンポーネントが機能するためには、フレームごとに更新する必要があります。これを行う最も簡単な方法は、シーンツリーをウォークスルーし、エンティティごとに各コンポーネントを更新することです。ただし、コンポーネントによっては、もう少し管理が必要になる場合があります。たとえば、エンティティを衝突可能にするコンポーネントは、すべての衝突可能コンポーネントを監視できる何かによって管理される必要があります。エンティティを描画可能にするコンポーネントは、他のすべての描画可能コンポーネントを監視して、描画順序などを把握する必要があります。 だから私の質問は、どこでコンポーネントを更新するのですか、それらをマネージャーに届けるクリーンな方法は何ですか？ コンポーネントタイプごとにシングルトンマネージャーオブジェクトを使用することを考えましたが、シングルトンを使用するという通常の欠点があります。これを緩和する方法は、依存関係の注入を使用することですが、この問題に対して過剰に聞こえます。また、シーンツリーをウォークスルーして、ある種のオブザーバーパターンを使用してさまざまなコンポーネントをリストにまとめることもできますが、すべてのフレームを実行するのは少し無駄です。

10 component-based 

学習目的で（後で一部のゲームで使用するため）コンポーネントベースのエンティティシステムを設計しようとしていますが、エンティティの状態の更新に関して問題が発生しています。 コンポーネント間の依存関係を防ぐために、コンポーネント内にupdate（）メソッドを含めたくありません。 私が現在考えているのは、コンポーネントがデータを保持し、システムがコンポーネントを更新することです。 したがって、Transform、Movement、State、Animation、Renderingの各コンポーネントを持ついくつかのエンティティ（たとえば、player、enemy1、enemy2）を含む単純な2Dゲームがある場合、次のようにする必要があります。 すべてのMovementコンポーネントを移動し、Stateコンポーネントを更新するMovementSystem また、アニメーションコンポーネントを更新するRenderSystem（アニメーションコンポーネントは、状態ごとに1つのアニメーション（つまり、フレーム/テクスチャのセット）を持つ必要があり、それを更新することは、現在の状態に対応するアニメーション（jumping、moving_leftなど）を選択することを意味します。フレームインデックスの更新）。次に、RenderSystemは、Renderコンポーネントを各エンティティのアニメーションの現在のフレームに対応するテクスチャで更新し、すべてを画面にレンダリングします。 Artemisフレームワークのようないくつかの実装を見てきましたが、この状況を解決する方法がわかりません。 私のゲームに次のエンティティがあるとします。各エンティティには、一連の状態と、状態ごとに1つのアニメーションがあります。 プレーヤー：「アイドル」、「移動」、「ジャンプ」 enemy1：「moving_up」、「moving_down」 enemy2： "moving_left"、 "moving_right" 各エンティティの現在の状態を更新するために最も受け入れられているアプローチは何ですか？考えられる唯一のことは、エンティティのグループごとに個別のシステムを持ち、状態コンポーネントとアニメーションコンポーネントを個別に持つことです。そのため、PlayerState、PlayerAnimation、Enemy1State、Enemy1Animation ... PlayerMovementSystem、PlayerRenderingSystem ...がありますが、これは悪いことだと思いますソリューションとコンポーネントベースのシステムを持つ目的を壊します。 ご覧のように、私はここでかなり迷っていますので、どんな助けにも感謝します。 編集：私が意図したとおりにこの作業を行うための解決策はこれです： すべてのエンティティに使用できるように、statecomponentとanimationcomponentを十分に汎用的にします。それらに含まれるデータは、再生されるアニメーションや使用可能な状態などを変更するための修飾子になります。–バイト56 今、私はこれらの2つのコンポーネントを再利用できるように十分に汎用的に設計する方法を理解しようとしています。各状態（ウォーキング、ランニングなど）のUIDを持ち、この識別子でキー設定されたAnimationComponentにマップ内のアニメーションを格納することは良いソリューションでしょうか？

10 animation  entity-system  component-based  state 

コンポーネントがすべてのフレームを更新できるようにする（そしてこの機能を必要のないコンポーネントから除外する）ために、UpdateComponentコンポーネントを作成するというアイデアを得ました。MovableComponent（速度を保持する）などの他のコンポーネントは、IUpdatable抽象クラスを継承します。これによりMovableComponent、Update(gametime dt)メソッドへのポインタとへのポインタをRegisterWithUpdater()提供するメソッドの実装が強制されUpdateComponentますMovableComponent。多くのコンポーネントがこれを実行し、誰が何であるかを気にすることなくUpdateComponent、すべてのUpdate(gametime dt)メソッドを呼び出すことができます。 私の質問は： これは、正常または誰かが使用しているもののように見えますか？この件については何も見つかりません。 物理学などのコンポーネントの順序を変更してから位置を変更するにはどうすればよいですか？これも必要ですか？ フレームごとに処理する必要があるコンポーネントが実際に処理されることを保証する他の方法は何ですか？ 編集 私はエンティティマネージャに更新可能なタイプのリストを与える方法を検討していると思います。次に、そのタイプのすべてのコンポーネントを、エンティティごとに管理するのではなく更新できます（とにかく、私のシステムのインデックスにすぎません）。 まだ。私の質問は引き続き有効です。これが理にかなっているのか、通常のことなのか、他の人が何をする傾向があるのか​​はわかりません。 また、不眠症の人々は素晴らしいです！ /編集 前の例のコードを煮詰めました： class IUpdatable { public: virtual void Update(float dt) = 0; protected: virtual void RegisterAsUpdatable() = 0; }; class Component { ... }; class MovableComponent: public Component, public IUpdatable { public: ... virtual void Update(float dt); private: ... …

10 c++  component-based  entity-system 

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

10 c#  architecture  design-patterns  component-based  entity-system 

私の質問はこれです： グローバルコンテキストデータをどのように保存しますか。エンティティコンポーネントシステムの世界データ情報、現在の世界時間など？ ドワーフフォートレススタイルのオープンエンドの世界シミュレーションゲームをC ++で構築することを考えています。私は楽しみのためにエンティティコンポーネントスタイルのゲームエンジンを構築しました。現在、必要なすべての機能でどのように機能するかを考えています。標準のゲームプレイ（レンダリング、物理、エンティティ固有のコンポーネントデータなど）に加えて、関連するすべてのシステムがアクセスできるグローバルコンテキストデータ（つまり、現在の年などの世界データ）も必要です、地球温暖化が起こっているかどうか、世界のシミュレーションに関連するあらゆる種類の事柄）。私はもともと「ワールド」コンポーネントを作ることを考えていましたが、多くの異なるシステムがこの論理的に「グローバル」なデータにアクセスする必要がある場合、これは無意味で難しいように見えます。 「ワールド」コンポーネントがあるのは理にかなっているでしょうか、それともこのデータを他の方法で保存すべきでしょうか？ また、このデータを単にグローバルにして、それを使用したいすべてのシステムにアクセスできるようにすることも考えました。一般的にはエンティティコンポーネントの原則に違反しているように見えますが、他の理由で混乱しているようですが、実際に機能する可能性があると思いました。 私が考えたもう1つのことは、関連するワールドコンテキストデータをシステム自体に直接埋め込むことです。たとえばAgeSystem、getsWeakerAsTimePassesコンポーネントがあるかどうかに関係なく、すべてのエンティティが「古くなった」場合、おそらくこのシステムは、世界の関連する時間データをメンバーデータとして直接保存し、時間の経過とその量を計算するために使用できます。この3つ目のオプションは、私のお気に入りではありませんでしたが、ブレーンストーミングで思いついたことがあります。 誰かアドバイスできますか？

10 c++  entity-system  component-based 

現在、私は次の問題に直面しています： エンティティコンポーネントシステム（ECS）を使用してポンクローンを作成しようとしています。「フレームワーク」はすべて自分で書きました。したがって、すべてのコンポーネントでエンティティを管理するクラスがあります。次に、コンポーネントクラス自体があります。そして最後に、システムが必要とするコンポーネントを持つすべてのエンティティを取得する私のシステムがあります。 たとえば、私の移動システムは、位置コンポーネントと移動コンポーネントを持つすべてのエンティティを探します。位置コンポーネントは位置を保持し、移動コンポーネントは速度を保持します。 しかし、実際の問題は私の衝突システムです。このクラスは論理ブロブのようなものです。このクラスには特別なケースがたくさんあります。 例：パドルがボーダーと衝突する可能性があります。この場合、速度はゼロに設定されます。私のボールも国境にぶつかることがあります。しかし、この場合、その速度は境界線の法線でミラーリングされるだけなので、反映されます。これを行うために、私はボールに追加の物理コンポーネントを与えました。したがって、実際には、物理​​コンポーネントには実際のデータはありません。これは、オブジェクトが反射または停止したかどうかをシステムに通知するために存在する空のクラスです。 次に、これが発生します。ボールがパドルまたは境界に衝突したときに、いくつかのパーティクルをレンダリングしたいと思います。したがって、ボールは、衝突時にパーティクルを作成するように衝突システムに指示する別のコンポーネントを取得する必要があると思います。 次に、パドルと衝突するが境界とは衝突しないパワーアップが必要です。それが起こった場合、パワーアップは消えなければなりません。したがって、さらに多くのケースとコンポーネントが必要になります（一部のエンティティは特定のエンティティとのみ衝突できることをシステムに伝えるために、他の一部が実際に衝突できるとしても、すべてではなくボット、さらに衝突システムはパワーアップを適用する必要がありましたパドルなどなど）。 エンティティコンポーネントシステムは柔軟性があり、継承に問題がないので、良いことだと思います。しかし、私は現在完全に行き詰まっています。 複雑すぎると思いますか？この問題にどのように対処すればよいですか？ もちろん、私は実際に「衝突後」の原因となるシステムを作成する必要があります。そのため、衝突システムは「はい、最後のフレームに衝突があります」とだけ表示し、次に「衝突後」システムがたくさんあります。すべて異なるコンポーネント（の組み合わせ）を必要とし、コンポーネントを変更します。たとえば、衝突が発生したときに停止する必要があるものを停止する衝突後移動システムがあります。次に、物事を反映する物理衝突後システムなど。 しかし、これは私にとっても適切な解決策ではないようです。たとえば、 私の移動後衝突システムには、位置コンポーネント、移動コンポーネント、および衝突コンポーネントを持つエンティティが必要です。次に、エンティティの速度をゼロに設定します。 物理衝突後システムには、位置コンポーネント、移動コンポーネント、衝突コンポーネント、および物理コンポーネントを持つエンティティが必要です。次に、速度ベクトルを反映します。 問題は明白です。衝突後の動きには、物理​​衝突後システムのエンティティのサブセットであるエンティティが必要です。したがって、2つの衝突後システムは同じデータで動作し、その効果は次のとおりです。エンティティには物理コンポーネントがありますが、衝突後の速度はゼロです。 これらの問題は、エンティティコンポーネントシステムで一般的にどのように解決されますか？それらの問題はいつものことですか？それとも私は何か間違っていますか？はいの場合、代わりに何をどのように行う必要がありますか？

10 architecture  component-based  entity-system 

コンポーネントベースのゲームオブジェクトを使用するゲームを作成していますが、各コンポーネントがゲームオブジェクトと通信する方法を実装するのに苦労しています。すべてを一度に説明するのではなく、関連するサンプルコードの各部分について説明します。 class GameObjectManager { public: //Updates all the game objects void update(Time dt); //Sends a message to all game objects void sendMessage(Message m); private: //Vector of all the game objects std::vector<GameObject> gameObjects; //vectors of the different types of components std::vector<InputComponent> input; std::vector<PhysicsComponent> ai; ... std::vector<RenderComponent> render; } GameObjectManagerすべてのゲームオブジェクトとそのコンポーネントを保持しています。また、ゲームオブジェクトの更新も行います。これは、コンポーネントベクトルを特定の順序で更新することによって行われます。配列の代わりにベクトルを使用するので、一度に存在できるゲームオブジェクトの数に実質的に制限はありません。 class GameObject …

9 c++  entity-system  component-based