エンティティ/コンポーネントシステムとUI「エンティティ」

エンティティ/コンポーネントシステムにはまだグリーンです。私はスプライト（またはスプライトシート）を描画し、入力（マウス/タッチクリック）を処理するための便利なコンポーネントを持っているので、当然これらを再利用してUIコンポーネント（レベル選択画面などのボタンなど）を作成したいと思います。

これは非常に奇妙に思えます。エンティティは、プレイヤー、敵、パワーアップなどの「ゲームモデル」として常に理解されていました。一方、コード再利用の観点からは、UIのコンポーネントを再利用することは理にかなっています。

UI / GUIの懸念はどのように（そしてどこで）エンティティ/コンポーネントシステムに適合しますか？

（注：この質問は、複数のプラットフォーム/言語に適用されるため、プラットフォームに依存しません）

いくつかのエンティティコンポーネントシステム、特にCraftyJSを使用した後、多かれ少なかれ私の質問に対する答えが得られました。はい、コンポーネント（特に2Dゲームのスプライトまたは画像およびマウスクリックハンドラー）をGUIに再利用できます。

多くの場合、あなたはECSにのみアクセスでき、基礎となるシステム（描画システムなど）にはアクセスできません。この場合、他に選択肢がないので、コンポーネントを使用してもかまいません。

基礎となるシステム（例：Cursesに直接アクセスするRubyローグライク）にアクセスできる場合、そのシステムで直接描画/レンダリングすることは、多くのコードを使用するよりも効果的です（コードが少なく、壊れにくく、自然です）エンティティとコンポーネント。

2Dまたは3Dでは、エンティティコンポーネントシステム（ECS）は、少なくとも同じECSの一部でない場合、GUIシステムにアクセスできる必要があります。

個人的には、この2つを混ぜることはしません。GUIのコードの再利用性は、実際にはトップレベルでのみ発生します。マウス/キーボード、レンダリングなどへの応答。さまざまなボタンがとる機能、または特定のリストに表示される情報は、実際には、再利用できるほど汎用的にできるものではありません。

たとえば、GUIエンティティのコンポーネントはposition、renderおよびのようなものになると思いguiます。GUIコンポーネントがGUIエンティティが実行するアクションのタイプを定義する場所。ただし、そのアクションは非常にユニークでコンテキスト固有のものになります。これにより、GUIコンポーネントを処理するシステムが非常に大きくなり、基本的に各GUI機能（ゲームのロード、ゲームの保存、サーバーの検索など）を処理するように設計されます。乱雑に聞こえます。

GUIの「画面」ごとに標準クラスファイルを作成したいと思います。その画面のすべての機能を1つの場所に（共通の機能クラスへの参照とともに）持っている。すっきりと管理しやすいです。

ただし、前述したように、ECSはGUIシステムにアクセスできる必要があります。システムのエンティティに基づいてGUIに情報を提供できる必要があります。たとえば、味方ユニットにカーソルを合わせると、そのユニットに関するすべての情報を含むGUIウィンドウがポップアップ表示されます。敵の団結の上にホバリングすると、情報が限られたGUIウィンドウがポップアップします。2つの違いを知るためにGUIをプログラミングしたくない場合、エンティティに情報を表示するように要求したい場合があります。

そのため、エンティティにはおそらく何らかのGUIコンポーネントがありますが、GUIエンティティではなく「ゲーム内」のエンティティになります。このコンポーネントは、外部GUIシステムを使用してGUIインターフェイスを作成します。