Więcej zabawy z ES ...
Obecnie mam kilka systemów:
- Renderer (atrybut do renderowania, atrybut przekształcenia)
- Ruch (atrybut ruchomy, atrybut Przekształć, atrybut Renderowalny [dla obwiedni itp.])
- Dane wejściowe (atrybut InputReceiver)
- itp.
Dodam wykrywanie kolizji. Moją pierwszą myślą było dodanie nowego systemu, który wykonuje kolizję. Sensowne jest dla mnie trzymanie tego w izolacji od Motionsystemu, ponieważ nie wszystkie rzeczy, które się poruszają lub są animowane, koniecznie uczestniczą w wykrywaniu kolizji - kamery, mgła itp. - ale wydaje się, że Collisioni Motionsą od siebie zależne.
Kiedy Motionporusza się byt, transformacja musi być zatwierdzona Collision, a ruch albo anulowany, albo dostosowany (odbijanie, zatrzymywanie się przy ścianie itp.).
Alternatywą byłoby utworzenie atrybutu Collidable, który zachowuje odniesienie do obiektu kolizyjnego - drzewa kd, oktetu itp., Który jest współużytkowany przez jednostki, które mogą się ze sobą kolidować. MotionSystem będzie wtedy sprawdzać tego atrybutu i użyć go w celu sprawdzenia czy regulować ruch.
Z punktu widzenia kodu jest to akceptowalne rozwiązanie. Jednak z punktu widzenia architektury ECS wydaje się, że wpycha logikę do Motionsystemu, która nie ma zastosowania do wszystkich jednostek, które mają Movableatrybut.
Mógłbym również zapisać w Movableatrybucie wektor ruchu i Colliderdostosować system Transformw razie potrzeby, ale będzie to wymagało duplikowania funkcji pomiędzy Motioni Colliderlub oddzwaniania od Colliderdo Motionz niektórymi danymi o lokalizacji kolizji i danych powierzchni do odbicia / odbicia itp. .
Może to być objęte hasłem „special case hack”, ale chciałbym uzyskać informacje od tych, którzy wcześniej sobie z tym poradzili, bez tworzenia mnóstwa kodu sprawy.
Pytanie Jaki jest dobry sposób na uniknięcie ścisłego połączenia między systemami ruchu i kolizji, gdy wydaje się, że wymagają one wzajemnej wiedzy?