問題タブ [component-based]

2 つのモデル: AnOwnerと a Dog:

owner.rb

dog.rb

そして、ここにスキーマがあります：

schema.rb

かなりシンプルなセットアップ。

彼を散歩ownerに連れて行きたい。dog散歩が終わると、飼い主の気力が5減り、犬の気力が20減る。

明らかに、このwalk_the_dogアクション/メソッドは、ownerオブジェクトとオブジェクトの 2 つのオブジェクトに影響を与えdogます (もちろん、この犬のオブジェクトはたまたまこの所有者に関連付けられています)。

このコードをどこに置くべきかわかりません。内で単純にアクションを作成できることはわかっていますがowners_controller.rb、それは悪い考えのように思えます。次のようになります。

owners_controller.rb

私が理解しているように、オブジェクトは自分自身の状態のみを変更する必要があり、他のオブジェクトの状態を変更するべきではありません。ownerオーナー コントローラ内でオブジェクトだけでなく、関連付けられたオブジェクトの状態も変更しているため、これは悪い考えのように見えdogます。

サービスについて読みました。walk_the_dog私が理解しているように、サービスはオブジェクト間の相互作用と複数のオブジェクトの状態変更を可能にするため、サービスの優れたケースのようです。私はそれを行う/実装する方法がわかりません。

と呼ばれるサービスオブジェクトが必要walk_the_dogですか? 一連のサービスメソッドを含むサービスディレクトリ内のファイルである必要があります-そのうちの1つが呼び出されwalk_the_dog、owners_controller.rbコントローラーでこのメソッドを使用するだけですか? 次のステップが何かわかりません。

注: 「これが OO 設計を壊すかどうかなんて誰が気にするんだろう。ただそれを実行して、うまくいくならうまくいく」と言っている人を見ることができます。残念ながら、これはオプションではありません。私が今取り組んでいるアプリケーションは、その考え方に従いました。アプリケーションが非常に大きくなり、現在は維持が非常に困難になっています。アプリの大幅なリニューアルでこの状況を打破したい。

モジュラー アプリケーションについて考えるとき、主にコンポーネント ベースのアーキテクチャ アプリケーションを思い浮かべます (必ずしもそうである必要はありません)。

JSF は、コンポーネント Web アプリケーションを実行するように設計されています。Spring の Web フレームワーク (Spring Web MVC) は要求/応答モデルです。主に多層アーキテクチャ アプリケーションを構築するために使用されるため、JSF とは異なる概念であり、その目的とは異なります。

Spring Framework は、コンポーネント化された Web アプリケーションの動作を許可できますか?

いくつかの調査を行ったところ、Spring Dynamic Modules は OSGi フレームワークに基づいていることがわかりましたが、この Spring プロジェクトは Eclipse Foundation に移行されました。OSGi は進むべき道ですか?

複数のゲームで使用されるコンポーネント ベースのエンティティ システム (ECS)フレームワークを実装し、多くのゲーム エンジン (unity、libgdx など)で実装するライブラリを探しています。

scala ( ECS ローグライク) で小さなゲーム プロジェクトを開始していますが、現時点ではashleyという名前の Java ライブラリしか見つかりません。

他の ECS ライブラリ (Scala の) が存在するかどうか、またはこのライブラリを scala (ashley) で使用または再実装するしかないかどうかを知っていますか?

関連するもう 1 つの質問、アクター パラダイムとコンポーネント ベースのエンティティ システムはそれほど離れていませんが、違いは何ですか?

「make」を使用してすべての C++ ファイルをビルドするレガシー コードがあります。ビルド中に含まれるファイルの数を減らそうとしています。これにより、新しいコードを追加するためのスペースが作成されます (新しいコードはシリアル通信をセットアップするためのものです)。ただし、これらのファイルは相互に依存しているようで、どのファイルをビルドから除外するかを判断するのに苦労しています。メイクファイルの形式は次のとおりです。

新しいコード行を追加する際に改ざんする必要があるファイルは 1 つだけです。ビルド時にその特定のファイルのみを保持しようとしています。依存関係を把握する方法はありますか?

現在「Entity Component System」について学んでいます。多くのチュートリアルやフォーラム スレッドを読んだ後でも、レンダリング ロジックはどこに行くべきなのか疑問に思っています。たとえば、スプライトを取得してレンダリングする実際の OpenGL/DirectX レンダリング コードについて話しているわけではありません。つまり、どのスプライトをレンダリングするかを決定するロジックです。

目に見えるエンティティには、次の 3 つの側面が必要です。

1. AI の評価 (位置、状態の変更など)
2. レンダリング状態の評価。たとえば、エンティティが歩いたり、よじ登ったり、殴られたりするときにどのスプライト サイクルを使用するか...
3. 実際にスプライトをレンダリングする

ほとんどのチュートリアルでは、ロジックに AISystem (1.) を使用し、RenderComponent で定義されたスプライト (サイクル) を表示するために RenderSystem (3.) を使用することを提案しています。彼らが言わないのは、RenderComponent が更新される場所です。(2.) を (1.) に入れるだけで、キャラクター ロジックとレンダリング ロジックを混在させることは、悪い設計になると私は理解しています。

簡単な解決策は、敵ごとに特定のレンダリング ロジック システムを追加することです。たとえば、Gumba の場合、GumbaLogicSystem、GumbaRenderLogicSystem を追加し、実際のレンダリングでは、すべてのスプライト ベースのエンティティが使用する汎用 SpriteRenderSystem を追加できます。ただし、これはエンティティ タイプごとに 2 つのコンポーネント*と 2 つのシステムを作成することを意味し、良い解決策とは思えません。

システムの数を少なく保ちながら、キャラクターロジックとレンダリングロジックを分離する良い解決策はありますか?

ありがとうございました

(* = 簡単なアプローチでは、システムはそのコンポーネントに応じてエンティティを処理します。GumbaRenderLogicSystem をエンティティで機能させるには、このシステムによって認識されるために GumbaRenderingLogicComponent が必要です。文字ロジックについても同じことが言えます。 .)

Edit1: ECS が抽象的なパターンであることは承知しています。私の質問は、システムの数を少なく保つ方法に関するベスト プラクティスを目的としています。私の例はゲーム プログラミングから動機付けられていますが、この分野に限定されません。より抽象的な例で説明しましょう。

目に見えるエンティティがあると想像してください。階層ベースのアーキテクチャでは、次のようなものがあります。

• SomeModel (AbstractModel から継承)
• SomeController (AbstractController から継承)
• SomeRenderer (PixelRenderer から継承し、PixelRenderer は AbstractRenderer から継承します)。

ECS では、たくさんの新しいクラスが必要になります。

• SomeModelSpecificDataComponent (つまり、このセマンティック エンティティに固有のデータ)
• SomeModelSystem (ロジックを実行する)
• SomeModelSpecificRenderComponent (つまり、このセマンティック エンティティに固有のレンダリング データ)
• SomeModelSpecificRendererLogicSystem (レンダリング方法を決定するシステム)
• PixelRendererSystem

導入が必要な新しいシステムの数を減らす方法はありますか? 1 つの解決策は、「エージェント」または「動作オブジェクト」を追加することです。一般的な RenderingComponent は、RenderSystem で呼び出される単一のメソッド「Update」を持つ「RenderingAgent」クラスのインスタンスにアタッチされます。したがって、技術的には、コンポーネントにはロジック自体は含まれていません。ただし、これは過剰に設計されているのではないかと心配しています。

コンポーネントベースのゲームエンジンで、ゲームオブジェクト/コンポーネント間の関係に困っています。

リレーションをどこに保存し、どのように削除しますか?

簡単にするために、ここに例を示します。

グラディウス クローン ゲームは、2 種類のゲーム オブジェクトで構成されます。

1. ロケット＝本体部品＋砲塔部品
2. フローティング タレット= タレット コンポーネント (単体)

コンポーネントの詳細は次のとおりです。

1. メイン ボディ コンポーネント= 1 つの物理的なボディ + 1 つのグラフィック ボディ
2. タレット コンポーネント= 1 つの物理的なボディ + 1 つのグラフィック ボディ

砲塔コンポーネントは、本体コンポーネントとの関係(物理的制約または所有権) を持つように設計されています。

両方のコンポーネントの前にリレーションを削除する必要があります。

• たとえば、この場合のリレーションには、Bullet Physics などの外部の物理ライブラリによって実装された物理的な制約も含まれています。

これらは非常に例に特化した説明であり、念のため....

ロケットを削除する手順は、次の順序で行う必要があります:-

1. 制約を削除
2. 本体部品と砲塔部品を削除（順番は任意）

メインボディ コンポーネントが削除されたときにリレーションも削除され、タレット コンポーネントだけが残されるので、フローティング タレットにします。

リレーションはどこに保存する必要がありますか? （すべて問題ないようですが、次の質問に関連しています。）

1. 新しい専用ゲーム オブジェクト (新しいエンティティ) の新しいコンポーネント内
2. Rocketと同じエンティティ内の新しいコンポーネント内
3. この特定の種類の関係のリストを保持する新しい管理システム内

関係を削除するにはどうすればよいですか? （どちらも悪い考えのようです。）

1. Main Body ComponentまたはRocketの差し迫った削除をチェックするフラグを作成し、他のコンポーネントを削除する直前に新しい専用システムを呼び出してリレーションを削除します。これは、タイム ステップごとに他のマネージャー システムの前に呼び出す必要があります。

2. 本体コンポーネントやロケットを削除したい場合は、他の既存の管理者が新しい専用システムを呼び出しましょう

関係の種類が多い一般的な場合の答えを期待していました。(ゲームオブジェクトまたはコンポーネント間)

編集 1 : ロケットのデストラクタに直接所有権を付与し、コードを追加することに関する提案されたソリューションは、コンポーネント ベースの設計にまったく反します。

• これにより、3 つのコンポーネント (制約を含む) が非常に結合されます。
• さらに、コンポーネントは重要な機能を持つべきではありません。
  デストラクタはその1つであり、避けるべきだと思います。
  (私はかつていくつかのオブジェクトの肥大化したデストラクタを持っていました.それはすべての良いモジュール性を破壊します.)

シミュレーション用のエンティティ コンポーネント システム設計を行おうとしています。これが今私を混乱させているものです。エンティティクラスを作成しようとしています

コンポーネントクラスは次のようになります

私が使いたい方法GetComponent()はUnity3Dと同じです

しかし、ご覧のとおり、私はまだそれを行う方法を見つけることができません。私がかつて行っていた方法は、

そして、私はそれを次のようにしか使用できませんでした

明らかに面倒です。

だから私の質問は、これとして何らかのフォームを使用できますか?

すべてのコンポーネント ポインターを格納するために使用し続けるためのクリーンさと速度を感じstd::vector<>ますが、それも有効な設計ですか?

エンティティ ベース コンポーネント システムを使用しています。

私は多くの種類のstationary objects例 を持っています

1. 壁＝ブロック
2. 火の塔 = ブロック + 射手
3. ウォーター タレット = ブロック + シューター
4. バンカー = ブロック + スポナー

ここにの工場がありstationary objectsます:-

それは本当にうまくいきます。

質問:
100 種類の を作成したいのですがStationary objects、どこに保存すればよいですか?
それらをすべてクラスに格納するとStationaryObject、クラスが大きくなりすぎます（？）。

オブジェクトの各タイプには、小さいながらも固有のロジックがあることに注意してください。