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

最近、私は自分のフレームワークのためにエンティティシステムを調査し、実装しています。私は見つけることができるほとんどの記事、reddits、およびそれについての質問を読んだと思います。 ただし、全体的なC ++の動作、エンティティシステムを実装する言語、およびユーザビリティの問題についていくつかの疑問が生じました。 したがって、1つのアプローチは、エンティティにコンポーネントの配列を直接格納することです。これは、データを反復処理するときにキャッシュの局所性を損なうため、実行しませんでした。このため、コンポーネントタイプごとに1つの配列を作成することにしました。そのため、同じタイプのすべてのコンポーネントがメモリ内で連続しており、迅速な反復に最適なソリューションになります。 しかし、実際のゲームプレイ実装のシステムからコンポーネント配列を繰り返し処理する場合、ほとんどの場合、一度に2つ以上のコンポーネントタイプを使用しています。たとえば、レンダリングシステムはTransformとModelコンポーネントを一緒に使用して、実際にレンダリング呼び出しを行います。私の質問は、これらのケースでは一度に1つの連続した配列を直線的に反復していないので、この方法でコンポーネントを割り当てることによるパフォーマンスの向上をすぐに犠牲にするのですか？C ++で2つの異なる連続した配列を繰り返し、各サイクルで両方のデータを使用する場合、問題がありますか？ 私が質問したい別のことは、コンポーネントまたはエンティティへの参照をどのように保持する必要があるかです。コンポーネントがメモリに配置される方法の性質は、配列内の位置を簡単に切り替えることができるか、配列が拡張またはコンポーネントポインターまたはハンドルが無効のままになります。フレームごとに変換や他のコンポーネントを操作したいことがよくあり、ハンドルまたはポインターが無効な場合は、フレームごとに検索するのが非常に面倒なので、これらのケースをどのように処理することをお勧めしますか？

18 c++  performance  entity 

32x32ボックスに分割されたタイルを使用した上記の画像を考慮すると、近くにいる近くのプレイヤーに「aggro」とマークされたエンティティがあります。このモンスターに理想的にはプレイヤーを追いかけたい（そしてしばらくの間プレイヤーを追い続けたい）。現在、私の唯一の動きは、リモートエンティティの単純な補間器で行われます。これは、動きの更新間のギャップがかなり小さいために機能します。 モンスターがいる位置に移動したいことをクライアントに伝えることができません。それはエンティティが本来よりもはるかに速く移動するためです（これはおそらく補間coに数学を使用して解決できます） -効果的）しかし、もっと重要なのは、現実的に見えず、壁をクリップする可能性があることです！回避できる場合は、サーバー上の動き全体をシミュレートしたくありません...できると思いますが、それでもクリッピングの問題は解決しません。解決策には、定期的なノード更新をパス検索および送信し、それらに動きをシミュレートさせることが必要ですが、確信はありません。 ありがとう！

12 ai  networking  path-finding  movement  entity 

これまでのところ、私が使用したエンティティコンポーネントシステムは、ほとんどがJavaのアルテミスのように機能しています。 コンポーネント内のすべてのデータ ステートレスな独立したシステム（少なくとも初期化時に入力を必要としない程度）は、特定のシステムが関心のあるコンポーネントのみを含む各エンティティを反復します。 すべてのシステムはエンティティを1ティック処理し、その後すべてをやり直します。 今、私はこれをターンベースのゲームに初めて適用しようとしています。ゲームを進める前に、相互に設定された順序で発生しなければならない大量のイベントと応答があります。例： プレイヤーAは剣からダメージを受けます。これに応じて、Aの鎧はキックインし、受けるダメージを減らします。Ａが弱まる結果、Ａの移動速度も低下します。 受けたダメージは相互作用全体を開始するものです ダメージがプレイヤーに適用される前に、鎧を計算して、受けたダメージに適用する必要があります 移動速度低下は、最終的なダメージ量に依存するため、実際にダメージが与えられるまでは適用できません。 イベントは他のイベントをトリガーすることもできます。鎧を使用して刀のダメージを軽減すると、刀が粉砕され（これはダメージの軽減が完了する前に行う必要があります）、次に、それに応じて追加のイベントが発生し、本質的にはイベントの再帰的な評価が発生します。 全体として、これはいくつかの問題につながるようです： 多くの無駄な処理サイクル：ほとんどのシステム（レンダリングのように常に実行されるもののために保存）は、「自分の番」が機能しない場合に実行する価値のあることは何もなく、ほとんどの時間はゲームの開始を待機しています。有効な作業状態。これにより、そのようなすべてのシステムに、ゲームに追加される状態が増えるにつれてサイズが大きくなり続けるチェックが散らばっています。 システムがゲームに存在するエンティティを処理できるかどうかを確認するには、他の無関係なエンティティ/システムの状態を監視する何らかの方法が必要です（ダメージの処理を担当するシステムは、鎧が適用されているかどうかを知る必要があります）。これは、複数の責任でシステムを混乱させるか、または各処理サイクルの後にエンティティコレクションをスキャンし、何かをする準備ができていることを通知することによって一連のリスナーと通信する以外に目的のない追加のシステムの必要性を生み出します。 上記の2つのポイントは、システムが同じエンティティセットで動作し、コンポーネントのフラグを使用して状態が変化することを前提としています。 それを解決する別の方法は、単一のシステムがゲームの状態を進行させるために動作する結果として、コンポーネントを追加/削除する（または完全に新しいエンティティを作成する）ことです。これは、システムが実際に一致するエンティティを持っている場合はいつでも、処理が許可されていることを認識していることを意味します。 ただし、これにより、システムは後続のシステムのトリガーを担当し、単一のシステムの相互作用の結果としてバグが表示されないため、プログラムの動作を推論することが難しくなります。新しいシステムを追加することは、他のシステムにどのように影響するかを正確に把握しないと実装できないため（そして以前のシステムを変更して、新しいシステムが関心のある状態をトリガーする必要がある場合があるため）、さらに難しくなります。単一のタスクで。 これは私と一緒に暮らす必要があるでしょうか？私が見たすべてのECSの例はすべてリアルタイムであり、そのような場合にこのゲームごとの1回の繰り返しがどのように機能するかを確認するのは非常に簡単です。そして、私はまだレンダリングにそれを必要とします、何かが起こるたびにそれ自身のほとんどの側面を一時停止するシステムには本当に不適当に思えます。 これに適したゲームの状態を進めるためのデザインパターンはありますか？それとも、すべてのロジックをループの外に移動し、代わりに必要なときにのみトリガーする必要がありますか？

9 turn-based  entity