Adam Martin（t-machine）に触発されたEntity Systemのアイデアはすでに得ていると思います。次のプロジェクトでこれを使い始めたいです。
エンティティ、コンポーネント、システムの基本をすでに知っています。私の問題は、UI / HUDの処理方法です。たとえば、クエストウィンドウ、スキルウィンドウ、キャラクター情報ウィンドウなど。UIイベントをどのように処理しますか（ボタンを押すなど）。これらは、すべてのフレームを処理する必要がないものです。現在、UIをコーディングするためにMVCを使用していますが、Entity Systemとの互換性はないと思います。
Entity Systemはより大きなOOPに埋め込まれていることを読みました。UIがESの外にあるかどうかはわかりません。これにどのようにアプローチしますか？
回答:
エンティティシステムについて考えすぎているのかもしれません。エンティティは、キャラクター、敵、スクリプト、弾丸、トリガーなど、ゲーム内のオブジェクトをスコープするためのものです。
たぶん、UIを分離すれば、ずっと良くて簡単になるでしょう。エンティティのスコープ内ですべてを作成する必要はありません。
エンティティ/コンポーネントUIは機能するかもしれませんが、そうするのは難しいでしょう。さらに、ゲームエンティティを処理するために必要なコンポーネントとシステムから十分に削除されています。本質的には、ゲーム内の別のエンティティ/コンポーネントシステムになります。この2つの間に多くの重複があるとは想像できません。
エンティティシステムは優れており、あらゆる場所で使用したくなるかもしれません。結局、本当に甘いハンマーを手に入れると、あなたはすべての問題を爪のように扱うようになります。ただし、ECシステムはプログラミングバッグの別のツールにすぎません。それを解決するために使用される問題については本当にうまく機能しますが、UIのような問題のためのより良いツールがあります。
継承構造は、GUIで非常にうまく機能します。UIコンポーネントを作成するためだけでなく、それらをレイアウトするためにも。UIコンポーネントを他のコンポーネントの子にして、位置、スケール、不透明度などのプロパティを継承できるようにすることは本当に素晴らしいことです。ECシステムでそれをセットアップしようとすると、ECシステムのいくつかのルールを破る必要があります。
UI / HUDが描画されるたびに呼び出される新しいインターフェイス関数を作成し、カスタム/スクリプトコンポーネントがその関数を実装できるようにすることができます。これを使用するには、IMGUIシステム（Googleには多くのチュートリアルがありますが、これは単なるオリジナルのプレゼンテーションです）を使用する必要があります。これにより、独自のUI構築コンポーネントとウィンドウフレームレンダラーコンポーネントを含むエンティティとしてウィンドウを作成できます。
このすべてのフレームをすべて処理しないことに関しては、すべての種類の入力/データイベントでのみ更新する別のバッファーにすべてのUIをレンダリングできます。つまり、イベントが受信されるたびに、次のフレームでウィンドウを再描画する必要があることを示す変数を変更します。その変数がtrueの場合、falseに設定され、その後UIインターフェイスが呼び出されます。アニメーションが必要な場合は、UI自体が次のフレームの再描画をトリガーできるように、この正確な操作順序を使用することが重要です。