Istnieje wiele sposobów reprezentowania i wdrażania systemów komponentów bytu, ale oto wyjaśnienie jednego ze sposobów. Pamiętaj, że nie ma konkretnej definicji architektury encji / komponentu / systemu, więc jest to tylko jedna implementacja.
Przedstawię analogię do architektury encji / komponentów / systemu, która może pomóc. Pomyślmy o istocie jak o kluczu.
Jednostka
Klucze mają również zęby (ciemnoniebieskie). Zęby naszego klucza bytu to elementy, które go tworzą. Możesz odróżnić byty według ich ID, nawet jeśli mają te same zęby. Więc do czego pasują klucze? Zamki Zamki to nasze systemy. Na przykład system ruchu.
System
Blokada działa tylko wtedy, gdy nasz klucz ma zęby dla pozycji i prędkości. Ten system przetwarza tylko byty, które mają pozycję i prędkość. Istnieje wiele sposobów skonfigurowania sposobu, w jaki systemy te rozpoznają, które podmioty przetwarzać, ale jednym ze sposobów jest użycie long. Każdy bit jest zarezerwowany dla typu komponentu. W naszym przykładzie załóżmy typ 4-bitowy zamiast 64-bitowego. Nasz przykładowy podmiot miałby wszystkie dostępne komponenty. Więc to będzie klucz 1111. Następnie system szuka każdej jednostki, która ma 11--. ( -Reprezentant nie dba o to, ponieważ ruch nie dba o duszka lub zdrowie). Może sprawdzić jednostkę za pomocą prostej ANDoperacji. Więc nasz byt pasuje jeśli ((1111 & 1100) == 1100). Jeśli cię zgubiłem, sprawdź więcej o operacjach bitowych .
Jak widać, systemy mają dostęp do zasobów zewnętrznych. Mogą uzyskać dostęp do czasu, grafiki, dźwięku i tak dalej. Są to po prostu małe procesory, które biorą jeden klucz na raz i przetwarzają dane. Widzisz, że system ruchu przyjmuje prędkość, czas delta i pozycję; następnie wykonuje niektóre obliczenia i zapisuje wynik z powrotem na pozycji.
Klucze encji są naprawdę łatwe do wygenerowania. Możesz je dodawać lub usuwać do woli. Istota nie dba o to, to tylko sposób na grupowanie i trzymanie komponentów. Komponenty nie mają współzależności. Najbliższe interakcje między komponentami mają miejsce, gdy system działa na nich i wykorzystuje dane z jednego do aktualizacji drugiego, tak jak w naszym przykładzie ruchu.
Rzućmy okiem na inny system, który pomoże utrwalić pomysł:
To jest nasz system rysowania. Poszukuje pasujących komponentów 1-1-. Ta encja jest zgodna, ponieważ: ((1111 & 1010) == 1010)Ponadto można zobaczyć, że ten system wyświetla informacje na ekranie, rysując ikonkę encji w jej pozycji.
OK, jeszcze jedno. Spójrzmy na inny byt i zobaczmy, jak mógłby on pasować do naszego przykładu.
Jak widać, do tego bytu jest dołączonych mniej elementów. Patrząc na posiadane komponenty, wygląda na to, że może to być przedmiot statyczny jak skała. Ma tylko pozycję i duszka. Nie będzie się ruszać i nie będą miały na niego wpływu żadne zmiany zdrowia. Ten byt wytworzyłby klucz 1010. Więc jakie systemy działają na tym bycie? Sprawdźmy:
Przeciw naszemu systemowi ruchu:
((1010 & 1100) != 1100)Nie. Wygląda na to, że system ruchu nie dba o ten byt, ponieważ nie ma wymaganych komponentów.
Przeciw naszemu systemowi losowania:
((1010 & 1010) == 1010)Hej, to pasuje. Ten podmiot będzie obsługiwany przez system losowania. System rysowania narysuje duszka w zdefiniowanej pozycji.
Mamy nadzieję, że zobaczysz, jak łatwo byłoby teraz dodać kolejny system, który pobierałby nasze komponenty i działał na nich. Pozwól, że odpowiem na twoje pytania:
Co jeśli wiele systemów potrzebuje dostępu do tego samego komponentu? Gdzie powinny mieszkać dane?
Zazwyczaj systemy działają jeden po drugim. Przetwarzają wszystkie jednostki, które spełniają ich wymagania, a następnie następny system robi to samo i tak dalej. Dane żyją z bytem. W systemie nie powinno być niczego przechowywanego, to tylko zamek, który się przekręca, klucz jest tam, gdzie informacja zostaje i przechodzi od zamka do zamka.
Jak budowane są podmioty? Czy systemy są wewnętrznie powiązane z komponentem? Jeśli chcę wprowadzić nowy komponent, czy muszę również wprowadzić nowy system lub zmodyfikować istniejący?
Podmioty są tylko workami komponentów. Mają unikalny identyfikator i listę komponentów. Systemy są powiązane tylko z komponentami w sposób opisany powyżej. Możesz mieć komponenty bez systemów, które na nich działają, ale to całkiem bezcelowe. Podobnie możesz mieć systemy, które szukają komponentów, których nie ma żaden podmiot. Jest to mniej bezcelowe, ponieważ mogą po prostu czekać na stworzenie encji pasującej do ich zamka. Tak więc, jeśli wprowadzisz nowy komponent, chciałbyś stworzyć system, który będzie korzystał z tego komponentu. W przeciwnym razie po prostu dodajesz zęby do klucza, aby zamek nie istniał.
Jeśli moja jednostka jest tylko identyfikatorem, to skąd mogę wiedzieć, że moja jednostka robota musi zostać przeniesiona lub zrenderowana, a zatem zmodyfikowana przez jakiś system?
Myślę, że odpowiadam na to z pomysłem longklucza, który definiuje komponenty zawarte w encji. Wiesz, ponieważ klucz pasuje do zamka.
Uff! To był długi post! (A przynajmniej tak mi się wydaje z mojego dużego monitora.)