Comments 9
А можно посмотреть в сторону ECS (не обязательно штатной реализации) и понять, что там это все реализуется даже проще.
:) если вам нравится парадигма ECS это не означает что большинству она проще и удобней. Кстати я так понимаю есть ECS фреймворк леопотам? )
Есть много реализаций, в том числе и моя. Есть Entitas, Svelto, EgoEcs и т.п. Смысл в том, что в случае ecs размазывание обработки последовательно с пре/пост-процессингом получается просто и непринужденно, без использования ООП.
Все реализации кроме нативной не дадут того прироста производительности, и по факту являются надстройкой над монобехом.
Очень смелое и абсолютно голословное утверждение. Мое поделие как и Entitas не имеет никаких зависимостей от юнити и может использоваться в .net core безо всяких монобехов, например, в серверной реализации или вообще сторонних проектах (например, мод кастомных ранений для gta5). И да, джобы делаются через штатный мультитред без проблем.
Для начала можно пройтись по ссылкам, там есть тесты производительности. Ну и можно зайти с другой стороны — когда unity-ecs позволит передавать без адского бойлерплейта, занимающего треть кода, инстансы классов дальше для работы (после джобов и т.п) — вот тогда можно будет рассматривать ихнее поделие как рабочий вариант. Сейчас это — исключительно one-task-performance-only решение для ускорения одной задачи, из-за которой потом приходится страдать и выковыривать данные обратно из NativeArray и т.п. Все коммунити-проекты (тот же Entitas) являются multipurpose-решениями и позволяют строить всю архитектуру приложения на них.
Спасибо)
О проектировании гибкой системы способностей персонажей в играх