System Entity - Przechowywanie komponentów w Managerze a w Entity

Question

Tak jak wielu początkujących projektantów i programistów, natknąłem się na projekt Entity/Component System, w tym różne doskonałe artykuły na ten temat i kilka działających implementacji. . A ja, podobnie jak wielu innych, podjęłam się wdrożenia takiego systemu.

Pod względem koncepcyjnym Podmiot jest workiem z komponentami, które są niczym więcej, niż workami danych do obsługi przez serię Systemów. Wydaje mi się więc logiczne, że obiekt Entity może być użyty do przechowywania wszystkich powiązanych z nim elementów, ale praca innych mówi inaczej. We wszystkich moich badaniach wydaje się niemal powszechnie zrozumiałe, że Podmiot jest niczym więcej niż identyfikatorem i że za wszelką cenę należy unikać wpadnięcia w pułapkę myślenia zorientowanego na obiekt. Sugerują zamiast tego przechowywanie komponentów w menedżerze, ale bez zwracania uwagi na zalety takiego projektu.

Czy oba projekty, komponenty posiadane w jednostce kontra menedżer nie dają takiego samego wyniku końcowego? Daj mi znać, jeśli coś nie rozumiem.

Answer 1

Nie jestem ekspertem od Entity Component Systems, ale oto mój pogląd na ten temat z tego, co przeczytałem.

Myślę, że nigdy nie należy bezpośrednio uzyskiwać dostępu do komponentów. Jeśli to zrobisz, komponenty zaczną się wzajemnie opierać, a później, gdy zdecydujesz, że chcesz zmienić zachowanie jednego komponentu, wszystkie pozostałe składniki, które chcesz zmienić, muszą zostać naprawione.

Aby uniknąć tego problemu, komponenty nie powinny wiedzieć o sobie nawzajem. Każda z nich ma jedną pracę i powinna skupiać się tylko na tej pracy. Jeśli niektóre dane są potrzebne z innego komponentu (na przykład możesz potrzebować danych pozycji), powinieneś poprosić inny system o dane lub opracować system przesyłania wiadomości.

Oczywiście, po rozpoczęciu kodowania, trudno jest spełnić tę zasadę w 100% przypadków, ale pojawia się pomysł.

Innym powodem, dla którego należy unikać przechowywania komponentów w jednostce, jest szybkość. Kiedy komponenty są zawarte w systemach (gdzie wszystkie podobne komponenty są przechowywane razem), możesz szybko przetwarzać duże ilości składników. Masz szansę na skonfigurowanie dowolnych danych, które mogą być ponownie wykorzystane, przepróbowanie i przetworzenie każdego komponentu, a następnie zwolnienie wszystkich ponownie wykorzystanych danych. Nie tylko to, ale każdy system może (powinien) być w stanie działać na osobnym wątku, co pozwala na łatwe korzystanie z wielu rdzeni.

Ponownie, w praktyce nie zawsze jest to w 100% prawdziwe, ale taka jest jego teoria.

Podsumowując, przechowywanie komponentów w systemach, a nie w jednostce, zmniejsza pokusę bezpośredniego dostępu do komponentów i pozwala na aktualizacje zbiorcze w systemach. Mam nadzieję, że to pomoże, a jeśli masz jakieś pytania, daj mi znać.