Zmiany stanu jednostek lub komponentów

Mam problem z ustaleniem, jak radzić sobie z zarządzaniem stanem w moich podmiotach.

Nie mam problemów z zarządzaniem stanem gry, takimi jak pauza i menu, ponieważ nie są one traktowane jako system komponentów bytu; tylko ze stanem w jednostkach / komponentach.

Rysując z Orcs Must Die jako przykładu, mam moje elementy MainCharacter i Trap, które mają tylko takie elementy, jak PositionComponent, RenderComponent, PhysicsComponent.

Przy każdej aktualizacji Jednostka wywoła aktualizację swoich składników. Mam również ogólny menedżer zdarzeń EventManager z detektorami różnych typów zdarzeń.

Teraz muszę umieć pułapki: najpierw wybierz pułapkę i pozycję pułapki, a następnie umieść pułapkę.

Umieszczając pułapkę, powinna ona pojawić się przed MainCharacter, renderowana w inny sposób i podążać za nią. Po umieszczeniu powinien po prostu reagować na kolizje i być renderowany w normalny sposób.

Jak zwykle jest to obsługiwane w systemach opartych na komponentach?

(Ten przykład jest konkretny, ale może pomóc w ustaleniu ogólnego sposobu postępowania ze stanami jednostek).

component-based state GriffinHeart
źródło

Czy można dodawać i usuwać komponenty jednostek na podstawie zdarzeń wejściowych? Być może możesz zmienić komponenty pułapki, gdy zmienią się stany. Na przykład podczas umieszczania pułapki będzie ona mieć FollowComponent i RenderEffectComponnent. Po umieszczeniu usuwasz oba komponenty i dodajesz CollisionComponent. (Edytuj: Wyraźniej wyrażony przez Martina Sojkę)

Asakeron,

Tak, mogę, każde wejście jest tłumaczone z „HumanView” na zdarzenia w grze, które w większości są najpierw przetwarzane przez moją klasę GameLogic, która sprawdzi na przykład, czy MainCharacter ma wystarczająco dużo pieniędzy, aby umieścić pułapkę, w jaki sposób dzieje się po tym, co próbuję wymyślić.

GriffinHeart

Odpowiedzi:

Jedną z interesujących aplikacji systemu komponentów jest to, że można zmieniać komponenty jednostki w czasie wykonywania, jeśli zaprojektowano ją tak, aby była w stanie obsłużyć takie. Stan bytu staje się zatem sumą zarówno tego, które komponenty są mu przypisane, jak i tych, które posiadają.

Na przykład, możesz najpierw stworzyć pułapkę za pomocą BuildControllerComponent(regulującej reakcję na kontrolę gracza w fazie budowy), a PositionComponenti a RenderComponent. Ostatnie ma jedno pole danych, które rządzi zastosowanymi modułami cieniującymi pikseli, a jedno z nich nadaje wyglądowi „upiornego” pułapki. Zauważysz, że nie ma jeszcze przypisanych składników fizyki.

Po umieszczeniu pułapki komponenty są wymieniane. Nie BuildControllerComponentjest już potrzebny, więc zostaje usunięty. W RenderComponent„s shadery się zastąpić normalnego standardowego widoku pułapki. Wreszcie, PhysicsComponentpodobnie jak wszystko, co jest potrzebne do działania pułapki, są dodawane do encji.

W podejściu opartym na dziedziczeniu jest to równoważne z posiadaniem konstruktora dla ActiveTrapEntityklasy, który przyjmuje BuildTimeTrapEntityklasę jako argument, przy czym drugi służy do renderowania pułapki podczas jej budowania, a pierwszy służy do pułapki po jej umieszczeniu .

Martin Sojka
źródło

To jest sprytne.

Cypher

To dobra strategia stosowania stanu bytu. Nie rozwiązuje problemu śledzenia stanu każdej jednostki. Skąd wiesz, w jakim stanie jest obecnie jednostka?

MichaelHouse

@MartinSojka To jest prawie to, o czym myślałem po zadaniu pytania. Zastanawiałem się nad dodaniem BuildTrapProcess (coś, co jest aktualizowane w GameLogic), który będzie zarządzał aspektem wykonawczym zmiany składników, aby osiągnąć zmiany stanu potrzebne do zbudowania pułapki. Gdy zostanie wciśnięty przycisk budowy pułapki, logika gry utworzy Proces i go uruchomi. jakieś przemyślenia na temat tego podejścia?

GriffinHeart

@ Byte56: Ogólnie można wyszukiwać powiązane komponenty i ich wartości. W praktyce często musisz znać tylko odpowiedni podzbiór całego stanu, na przykład „Czy ten byt ma BuildControllerComponent?” lub „Jaka jest pozycja tego bytu, jak jest w nim zapisany PositionComponent, jeśli taki istnieje?” - te, które robisz, sprawdzając listę komponentów, które Cię interesują, i opcjonalnie sprawdzając (niektóre) ich wartości.

Martin Sojka

@GriffinHeart: Po prostu zaimplementuję wszystko, co jest potrzebne do „zbudowania” pułapki w systemie związanym z zarządzaniem BuildControllerComponents. Musi już przetwarzać zmiany punktu widzenia postaci (lub kamery) gracza oraz zdarzenia związane z naciśnięciem klawisza i myszy.

Martin Sojka

Nie podoba mi się pomysł, by podmioty wywoływały aktualizacje swoich komponentów (systemy powinny wykonywać tę pracę), a to doprowadzi do problemów z utrzymywaniem wzajemnej nieświadomości komponentów.

Możesz dodać dodatkowy komponent o nazwie „Stan”. Będą dostępne dla twoich systemów renderowania i kolizji. Składnik stanu to tylko flaga, która ma do dyspozycji wiele stanów. W opisanej sytuacji stanami byłyby Playi Build. Gdy system renderujący zobaczy, że jest w stanie Build, narysuje obiekt półprzezroczysty. Gdy system kolizji zobaczy Buildstan, nie będzie przetwarzał kolizji z odtwarzaczem.

Ale tak naprawdę, jeśli nie masz systemów i polegasz na komponentach, które wykonają całą pracę, napotkasz wiele problemów. Komponenty nie powinny wiedzieć o sobie i nie powinny przetwarzać.

MichaelHouse
źródło

To, co mówisz, jest sprzeczne, najpierw powinny być nieświadome (co zgadzam się), a następnie masz komponent, do którego inni mają dostęp. Możesz wyjaśnić? Trzymam komponenty odsprzężone przez system zdarzeń.

GriffinHeart

Mówię oba. Mówię, że powinni być nieświadomi i próbować dostosować moją odpowiedź do tego, jak myślę, że obchodzisz się z komponentami. Kiedy mówisz „Jednostka wywoła aktualizację na swoich komponentach”, daje mi to do zrozumienia, że nie masz encji przetwarzających systemy. Usunąłem mylący język i po prostu powiedziałem, że to systemy. Mówiłem komponenty, ponieważ rozumiałem, że tak właśnie aktualizujesz.

MichaelHouse

Podoba mi się pomysł, StateComponentktóry może być konsumowany przez wiele systemów.

Cypher,

Uprzejme jest podanie uzasadnienia dla głosów negatywnych. Dzięki.

MichaelHouse

Z drugiej strony, twój sprzeciw wobec podejścia pytającego opiera się na założeniu, że cały projekt oparty na komponentach musi aktualizować komponenty z oddzielnych systemów (jak projekt systemu encji). Jest to jeden ze sposobów, ale na pewno nie jedyny, i nie ma powodu, aby zniechęcać do takiego podejścia w przypadku gry, która nie wymaga pętli aktualizacji komponentów optymalizujących pamięć podręczną.

Sean Middleditch,