[Mithras]

Taką rozkminę mam: chciałbym mieć całą (albo możliwie dużo) logiki gry jako osobny "byt" (nie jako MonoBehaviour ani żadne inne rzeczy aktualizowane przez Unity), aby móc je porozrzucać po wątkach i tam dziergać. Problem (koncepcyjny) pojawia się np. dla poruszania dużej liczby jednostek zgodnie z prawami fizyki. Z mojego punktu widzenia bez sensu jest korzystać z fizyki dla obiektów, które są daleko i ich nie widać, za to prościej jest dodać odpowiedni wektor ruchu do pozycji i tyle - jednostka się porusza (z punktu widzenia logiki gry jest poprawnie) a jest mniejszy narzut.
Pytanie właściwe - jak organizujecie taką logikę u siebie? Na GameObjectcie siedzi jakiś skrypt z MonoBehaviour, który ma przypisany skrypt/klasę logiki i w zależności od widzialności GO przez kamerę, zmieniacie flagę, która deaktywuje skrypt chodzenia z fizycznego na uproszczone (efektywnie przełączane są aktualizacje z własnej logiki do Unity)?
Podobnie z animacjami - w skrypcie/klasie logiki jest licznik postępu wykonania animacji i jak tylko GO zacznie być widoczny, aktualizujecie postęp animacji na ten z licznika i aktywujecie komponent animacji?
Oczywiście niesie to ze sobą konsekwencję w postaci wyboru kto ma aktualizować pewne wartości (postęp animacji czy chociażby pozycja) z komponentów dołączonych do GO na skrypt/klasę logiki i odwrotnie.
Dobrze myślę czy to zdecydowanie przekombinowane i można prościej?
#unity #unity3d #gamedev #programowanie

[sathra]

@Mithras: Wydaje mi się, że wpadasz w pułapkę przedwczesnej optymalizacji. Zobacz to. Jeżeli chodzi o animacje to zapoznaj się z AnimatorCullingMode. Dla statycznych obiektów używaj occlusion culling.

[Mithras]

@sathra Pewnie masz rację co do przedwczesnej optymalizacji. Zrobię jeszcze kilka testów i na ich podstawie podejmę decyzję co do fizyki, bo animacja faktycznie jest załatwiona. A occlusion culling niestety nie wykorzystam, bo wszystko jest budowane dynamicznie. :(

[sathra]

A ile bedzie tych obiektow?

[devml]

@Mithras: dobrze myślisz i nie jest to przedwczesna optymalizacja. Jeżeli w grę wchodzi liczenie fizyki i kolizji, to warto minimalizować ilość przetwarzanych obiektów.

[Mithras]

@sathra @devml Celowałbym w naście tysięcy (przy czym widocznych w jednym momencie nie powinno być więcej jak ~tysiąc). Nie wiem jeszcze na ile to będzie możliwe, więc w razie czego rozmiar świata może ulec zmianie, aby ograniczyć te liczby. Właśnie z powodu skali martwię się o optymalizacje już teraz, bo każde zaoszczędzone obliczenia są dosyć cenne. I im więcej rzeczy będzie niezależnych od Unity, tym lepiej dla mnie - mogę

[devml]

@Mithras: dobrze, że bierzesz to pod uwagę już na etapie projektowania. Jeżeli chodzi o wydajnośc, to cieżko powiedzieć, nie wiedząc jakie obliczenia ma wykonywać pojedyńczy obiekt. Zamiast cullingu do widoku, możesz użyć spatial hashing lub drzewek.

[Mithras]

@devml Do cullingu drzewko powinno być wystarczające, przynajmniej jeśli chodzi o elementy statyczne (albo mało dynamiczne).

Jeżeli chodzi o wydajnośc, to cieżko powiedzieć, nie wiedząc jakie obliczenia ma wykonywać pojedynczy obiekt

Jeszcze sporo przede mną i też wszystkiego nie wiem, ale pierwsze testy sugerują, że lepiej będzie mieć większe zużycie pamięci niż CPU dla wielu podejmowanych akcji. Na razie mam sporo pomysłów na optymalizacje, ale wszystko to trzeba będzie na spokojnie