System encji / komponentów i „encje” interfejsu użytkownika

Nadal jestem zielony dla systemów encji / komponentów. Uważam, że skoro mam przydatne komponenty do rysowania ikonek (lub arkuszy) i obsługi danych wejściowych (kliknięcia myszą / dotykiem), naturalnie chcę ich ponownie użyć do tworzenia komponentów interfejsu użytkownika (takich jak przyciski, np. Ekran wyboru poziomu).

To wydaje mi się bardzo dziwne. Zawsze rozumiałem byty jako „model gry”, takie jak gracze, wrogowie, ulepszenia itp. Z drugiej strony, z punktu widzenia ponownego użycia kodu, ponowne użycie komponentów do interfejsu użytkownika ma sens.

W jaki sposób (i gdzie) obawy dotyczące interfejsu użytkownika / GUI mieszczą się w systemie encji / komponentu?

(Uwaga: to pytanie jest niezależne od platformy, ponieważ dotyczy wielu platform / języków)

Po użyciu kilku systemów elementów-bytów, zwłaszcza CraftyJS, mniej więcej dostałem odpowiedź na moje pytanie: tak, możesz ponownie użyć komponentów (zwłaszcza ikonek lub obrazów i programów obsługi kliknięć myszką w grach 2D) do GUI.

W większości przypadków masz dostęp tylko do ECS, a nie do bazowych systemów (np. System rysowania). W takim przypadku można używać komponentów, ponieważ nie masz innego wyboru.

Jeśli masz dostęp do bazowego systemu (np. Ruby roguelike z bezpośrednim dostępem do Curses), może się okazać, że rysowanie / renderowanie bezpośrednio w tym systemie jest bardziej efektywne (mniej kodu, mniej kruche, bardziej naturalne) niż używanie zestawu podmioty i komponenty.

W 2D lub 3D system komponentu bytu (ECS) powinien mieć przynajmniej dostęp do systemu GUI, jeśli nie jest częścią tego samego ECS.

Osobiście nie mieszałbym tych dwóch. Ponowne użycie kodu dla GUI dzieje się naprawdę tylko na najwyższym poziomie. Odpowiadanie na mysz / klawiaturę, renderowanie i tak dalej. Funkcje, które pełnią różne przyciski lub informacje wyświetlane na niektórych listach, nie są tak naprawdę dość ogólne, aby można było z nich korzystać ponownie.

Wyobrażam sobie na przykład, że komponenty jednostek GUI byłyby podobne position, renderi gui. Tam, gdzie komponent GUI określa rodzaj działania, które podejmuje jednostka GUI. Ta akcja będzie jednak wyjątkowa i specyficzna dla kontekstu. Powoduje to, że system, który obsługuje komponenty GUI, jest bardzo duży i zasadniczo zaprojektowany do obsługi każdej z funkcji GUI (załaduj grę, zapisz grę, znajdź serwer itp.). Brzmi bałagan.

Wolałbym zrobić standardowy plik klasy dla każdego „ekranu” GUI. Posiadaj wszystkie funkcje dla tego ekranu w jednym miejscu (z odniesieniami do wspólnej klasy funkcjonalności). Jest o wiele ładniejszy i łatwiejszy w zarządzaniu.

Jednak, jak powiedziałem, ECS powinien mieć dostęp do systemu GUI. Musi być w stanie dostarczyć informacje do GUI na podstawie podmiotów w swoich systemach. Na przykład najechanie kursorem na jednostkę sojuszniczą spowoduje wyświetlenie okna GUI ze wszystkimi informacjami o tej jednostce. Gdy najechanie myszką na jedność wroga wyskoczy okno GUI z ograniczoną ilością informacji. Prawdopodobnie nie chcesz zaprogramować GUI, aby rozpoznać różnicę między nimi, chcesz poprosić jednostkę o wyświetlenie jej informacji.

Tak więc jednostki nadal będą prawdopodobnie miały jakiś komponent GUI, ale będą to jednostki „w grze”, a nie jednostki GUI. Ten komponent użyje zewnętrznego systemu GUI do utworzenia interfejsu GUI.