3D.ru

О чем, собственно, вопрос, можно понять, прочитав это: https://unity.com/ru/dots
Сейчас я не касаюсь в своём вопросе burst и jobs, только Entity - Component - System, а точнее миграции проекта с КОП/ООП на эту парадигму.

Если с компонентно-ориентированным кодом все понятно - его нужно просто слегка модифицировать по образцу, то вот, что делать с объектно-ориентированным - не ясно. Представим ситуацию: у меня есть несколько C# скриптов, активно использующих наследование. В контексте игры это может быть что угодно - типы врагов, юнитов, персонажей в рпг и т.д. Главное, что все они в целом схожи, но при этом имеют ряд особенностей: например, у каждого есть своя реализация одного метода, у некоторых переопределен ещё один, у кого-то дописан другой. И вот тут возникает сложность: как все это обернуть в ECS?

Можно написать по компоненту/системе для каждого типа врага, но тогда придется буквально копировать 80% кода, что уже сразу недопустимо. Можно разбивать бывший ООП код на некоторое количестве компонентов/систем. Но в таком случае, если мы все же в будущем захотим использовать, скажем лишь половину фич компонента/системы, нам придётся все равно его переписывать. Можно вообще вынести буквально каждый метод, который теоретически может быть не использован в будущем в свой компонент/систему, но в таком случае, рано или поздно мы столкнемся с ситуацией, когда у одной сущности будет 20-30 компонентов вместо 5, как раньше. И как же, тогда, все таки поступать?

Итак, думаю, суть вопроса ясна. Заранее спасибо за ваше мнение.

Вы что собираетесь обрабатывать все данные объектов подряд с помощью ECS? Помоему вы не до конца разобрались как и зачем используют эту систему в unity.

А в чем фишка этого ECS? за счет чего ускорение происходит?

Equinty писал(а):А в чем фишка этого ECS? за счет чего ускорение происходит?

В ECS все данные в оперативной памяти находятся на небольших расстояниях друг от друга и overhead процессора снижается в разы
В дефолтной компонентной системе при каких-либо операциях с объектами все данные раскидываются по памяти и процессор затрачивает больше времени на выделение/поиск/удаление информации

Вообщем, всё работает по принципу дефрагментации памяти на жёстком диске...
После дефрагментации ПК же чуть-чуть лучже работает не так-ли!?

lawsonilka писал(а):Вы что собираетесь обрабатывать все данные объектов подряд с помощью ECS? Помоему вы не до конца разобрались как и зачем используют эту систему в unity.

В таком случае, прошу, просветите меня.
Мне кажется, используя ECS в связке с другими подходами, мы просто создаем чудовище Франкенштейна, сшитого из разных, слабо сообщающихся между собой частей. Я понимаю, что ECS в принципе не нужен для многих проектов (ну или не особо нужен, как минимум), однако, это не обязательно значит, что мы можем использовать несколько подходов одновременно без ущерба для архитектуры проекта.

Jarico писал(а):

Благодарю, изучу в свободное время.

Jarico писал(а):В ECS все данные в оперативной памяти находятся на небольших расстояниях друг от друга и overhead процессора снижается в разы
В дефолтной компонентной системе при каких-либо операциях с объектами все данные раскидываются по памяти и процессор затрачивает больше времени на выделение/поиск/удаление информации

Вообщем, всё работает по принципу дефрагментации памяти на жёстком диске...

В "двух словах" объяснения не нашел либо вода, либо лекция на час, но она тоже ни о чем. Если разница всего лишь в расположении в памяти ОЗУ, почему тогда эту технологию ставят в противовес ООП и КОП? Как-то мало отличий чтобы претендовать на что-то новое.

Equinty писал(а):В "двух словах" объяснения не нашел

Код из видео устарел но думаю суть уловишь

Хотел тоже сюда это видео добавить. Как раз смотрю.
Скажем так тут дело не только в памяти, а в подходе более ориентированном на многоядерные системы.

Вкратце тут https://habr.com/ru/company/pixonic/blog/413729/ в разделе после "Некоторые факты о ECS"

Вот еще простое и внятное объяснение: https://leopotam.com/2/

Ну что нужно, скоро новый раздел создавать про ECS... Интересно на Android поддержка уже есть?

В целом интересно ООП я толком не изучал все делал линейно, может на ECS сразу перескочить, там как раз один Update()

Equinty писал(а):Ну что нужно, скоро новый раздел создавать про ECS... Интересно на Android поддержка уже есть?

Должна быть. Насколько я знаю, ECS рекомендуют для мобильных платформ, где необходимо добиться одновременно достаточной производительности и качества игры сопоставимого с другими платформами.

В ECS все данные в оперативной памяти находятся на небольших расстояниях друг от друга и overhead процессора снижается в разы
В дефолтной компонентной системе при каких-либо операциях с объектами все данные раскидываются по памяти и процессор затрачивает больше времени на выделение/поиск/удаление информации

Звучит как бред. Оперативная память ведь не жесткий диск, тут не надо ждать пока диск провернется до нужного места, физическое положение информации неважно. Выделение\удаление памяти вообще при нормальном подходе единоразовая операция и ECS не требует.
На самом деле, ECS ввели чтобы им можно было в нативном коде распараллеливать одинаковые операции.

jetyb писал(а):

В ECS все данные в оперативной памяти находятся на небольших расстояниях друг от друга и overhead процессора снижается в разы
В дефолтной компонентной системе при каких-либо операциях с объектами все данные раскидываются по памяти и процессор затрачивает больше времени на выделение/поиск/удаление информации

Звучит как бред. Оперативная память ведь не жесткий диск, тут не надо ждать пока диск провернется до нужного места, физическое положение информации неважно. Выделение\удаление памяти вообще при нормальном подходе единоразовая операция и ECS не требует.
На самом деле, ECS ввели чтобы им можно было в нативном коде распараллеливать одинаковые операции.

чоэта? А как же выравнивание данных в памяти? Там столько оптимизаций по этому делу производители процов и компиляторов наворотили, черт ногу сломит.
ЗЫ для распараллеливания ввели джоб систем, а не ECS.

jetyb писал(а):Звучит как бред. Оперативная память ведь не жесткий диск, тут не надо ждать пока диск провернется до нужного места, физическое положение информации неважно.

Причём тут работа ЖД? Читай еще раз!!

В ECS все данные в оперативной памяти находятся на небольших расстояниях друг от друга и overhead процессора снижается в разы
В дефолтной компонентной системе при каких-либо операциях с объектами все данные раскидываются по памяти и процессор затрачивает больше времени на выделение/поиск/удаление информации

jetyb писал(а):Выделение\удаление памяти вообще при нормальном подходе единоразовая операция и ECS не требует.
На самом деле, ECS ввели чтобы им можно было в нативном коде распараллеливать одинаковые операции.

Теперь смотри как проц тужится при создании объектов через Instantiate

Как я понял, фундаментальное отличие ООП и ECS, в том что в ООП всё построено на наследовании, а в ECS композитный подход, сущности не наследуются а конструируются из блоков (сборка из частей и как следствие полная свобода действий). Ну а то что память там более упорядочена и есть Burst compiler это уже как производное дополнение к ECS.