Zarejestruj komponenty obiektu gry w podsystemach gry? (Projektowanie obiektowe oparte na komponentach)

Tworzę system obiektowy oparty na komponentach . Kilka porad:

GameObjectjest po prostu listą Components.
Istnieje GameSubsystems. Na przykład renderowanie, fizyka itp. Każdy GameSubsystemzawiera wskaźniki do niektórych Components. GameSubsystemjest bardzo potężną i elastyczną abstrakcją: reprezentuje dowolny fragment (lub aspekt) świata gry.

Potrzebny jest mechanizm rejestracji Componentsw GameSubsystems(kiedy GameObjectzostanie utworzony i skomponowany). Istnieją 4 podejścia :

1: Wzór łańcucha odpowiedzialności . Każdy Componentjest oferowany każdemu GameSubsystem. GameSubsystempodejmuje decyzję, która Componentsrejestracja (i jak je zorganizować). Na przykład GameSubsystemRender może zarejestrować Komponenty Renderowalne.

zawodowiec. Componentsnic nie wiem o tym, jak są używane. Niskie sprzęgło. A. Możemy dodać nowy GameSubsystem. Na przykład dodajmy GameSubsystemTitles, który rejestruje wszystkie ComponentTitle i gwarantuje, że każdy tytuł jest unikalny i zapewnia interfejs do wyszukiwania obiektów według tytułu. Oczywiście w tym przypadku ComponentTitle nie powinien być przepisywany ani dziedziczony. B. Możemy zreorganizować istniejące GameSubsystems. Na przykład GameSubsystemAudio, GameSubsystemRender, GameSubsystemParticleEmmiter można połączyć w GameSubsystemSpatial (w celu umieszczenia całego dźwięku, emitera, renderowania Componentsw tej samej hierarchii i korzystania z transformacji względem rodzica).

kon. Czek dla każdego. Bardzo inne.

kon. Subsystemswiedzieć o Components.

2: Każde Subsystemwyszukuje Componentsokreślone typy.

zawodowiec. Lepsza wydajność niż w Approach 1.

kon. Subsystemswciąż wiem o Components.

3: Componentrejestruje się w GameSubsystem(s). W czasie kompilacji wiemy, że istnieje GameSubsystemRenderer, więc ComponentImageRender wywoła coś takiego jak GameSubsystemRenderer :: register (ComponentRenderBase *).

zawodowiec. Występ. Brak niepotrzebnych kontroli jak w Approach 1.

kon. Componentssą źle połączone z GameSubsystems.

4: Wzór mediatora . GameState(który zawiera GameSubsystems) może implementować registerComponent (Component *).

zawodowiec. Componentsi GameSubystemsnic o sobie nie wiemy.

kon. W C ++ wyglądałoby to jak brzydki i wolny przełącznik typu.

Pytania: Które podejście jest lepsze i najczęściej stosowane w projektowaniu opartym na komponentach? Co mówi praktyka? Wszelkie sugestie dotyczące wdrożenia Approach 4?

Dziękuję Ci.

c++ architecture component-based

— w prawym górnym rogu
źródło

Czuję nadmiar inżynierii. Komponenty rejestrują się w GameObject. Jeśli GameSubsystem jest tym, co myślę, to tylko lista składników, które można dodać do GameObject jednocześnie. Jak to opisujesz, brzmi to jak „magia”, w jaki sposób GameObjects i Components łączą się (szukają się nawzajem? Dlaczego?). Mam również wrażenie, że próbujesz używać komponentów do wszystkiego w silniku, co również chciałbym ponownie rozważyć. Za to, co jest warte, rozważę tylko opcje 3 lub 4.

— LearnCocos2D,

@GamingHorror, Rejestrowanie Componentssię GameObjectsjest poza zakresem mojego pytania. Przeczytaj artykuły na temat podejścia opartego na komponentach lub zadaj własne pytanie na tej stronie, jeśli jesteś zainteresowany. To, o czym myślisz, GameSubsystemjest całkowicie błędne.

— topright

Mam tendencję do opracowywania komponentów do logiki gry, a nie komponentów silnika, a twój opis wydaje się wskazywać w tym kierunku. Bardzo dobrze rozumiem systemy składowe, myślę, że zostałem zrzucony z kursu, ponieważ nie znam używanej terminologii, w szczególności GameSubsystem. Z tego, co przeczytałem, brzmiało to tak, jakbyś próbował zbudować wszystko (np. Cały silnik) tylko z komponentów.

— LearnCocos2D,

Tak, „Obiekty gry oparte na komponentach” i „Programowanie zorientowane na komponenty” to różne terminy, może to być mylące. Nie bądź stronniczy, lepiej „bilasinguj”: scottbilas.com/files/2002/gdc_san_jose/game_objects_slides.ppt

— górę

Numer drzwi 3 ... Składnik rejestruje się w systemie GameSubsystem

Komponent jest na miejscu, aby utrzymać połączenie wyodrębnione z samego GameObject. Jakoś gdzieś coś faktycznie musi wchodzić w interakcje z podsystemami i taki jest komponent i jego cel.

W tym przypadku sprzężenie wcale nie jest złe.

Wydajność jest zasadniczo wymagana w tym przypadku, jeśli spodziewasz się jakiejkolwiek złożoności w swoim systemie, po prostu nie stać Cię na inne style wyszukiwania.

Wreszcie, jeśli jeden podsystem musi reagować na inny (renderer, fizyka, audio muszą wszystko robić, gdy coś się dzieje), komponenty mogą to ułatwić sobie nawzajem poprzez obiekt gry i utrzymywać ten szczególny rodzaj sprzężenia między systemami w zarządzaniu poprzez składniki.

— Stóg
źródło

Dobre. Ale skąd komponenty wiedzą o GameSubsystems? Czy wszystkie podsystemy są singletonami? To nie jest brzydkie? ... Myślę o innym rozwiązaniu, takim jak wstrzykiwanie zależności ... ale kiedy i kto przekazuje instancję podsystemu do każdego komponentu?

— Dani

@Dani Components nie muszą mieć bezpośredniego dostępu do instancji podsystemu, wystarczy wysłać wiadomość z prośbą o dokonanie rejestracji, nie muszą wiedzieć, co to jest podsystem (ale najprawdopodobniej) I dlaczego czy byliby singlami? Nie jest to wymagane, nawet jeśli w większości przypadków będzie potrzebna tylko jedna instancja podsystemu dla każdego podsystemu.

— Pablo Ariel,

@Pablo - zgadzam się.

— Rick,