Я разделяю озабоченность автора статьи: действительно, слепой догматизм, будь то "ООП навсегда" или "ECS ради ECS", способен привести к излишней сложности, перегруженной архитектуре и отвлечению от сути создания игры. Однако я не согласен с идеей, что простая модель с главным массивом и наборами функций является универсальным решением.
ECS обеспечивает гибкость и масштабируемость, которые трудно воспроизвести в предложенной модели. Вы советуете использовать плотные структуры Unit[] и редкие поля в пулах с простым конвейером обработки. Такой подход может работать в простых сценариях, но он плохо масштабируется в ситуациях, где игровые механики динамичны, многокомпонентны и разнообразны (пример - Space Station 14). ECS позволяет на лету комбинировать характеристики, достаточно прикрепить к сущности нужные компоненты без переписывания структуры Unit. При этом системы автоматически обрабатывают только сущности с актуальными компонентами, не засоряя основной "скелет" игры.
Что касается производительности и локальности, то они не являются догмой, а скорее одним из ключевых преимуществ ECS. Да, в статье верно отмечено, что лишний указатель не всегда критичен, а ECS может перерасти в бюрократию. Но грамотно реализованная архитектура на ECS использует удобное хранение компонентов и обеспечивает эффективные проходы по данным (часто с поддержкой SIMD) автоматического параллелизма и компактного кэширования. Это особенно важно в сложных симуляциях и при большом числе однотипных сущностей.
Критика ECS за скрытый порядок систем и "неявные протоколы" справедлива лишь для плохо организованных проектов. При правильной архитектуре порядок выполнения систем можно задавать декларативно, документировать и тестировать каждую систему изолированно. В модели же с "одной функцией, которая всё сама обрабатывает" логика переплетена в макароны, что усложняет тестирование и внесение изменений.
Ещё одно важное преимущество ECS - чёткое разделение данных и логики. В модели с "всё в одной структуре" легко скатиться в объекты -прародители или монолитные функции. ECS же разделяет компоненты (данные) и системы (логику), что помогает держать код чистым и модульным, соответствуя принципу single responsibility.
В итоге, когда проект небольшой или находится на стадии прототипа, минималистичный подход может быть уместным. Но в масштабных играх, где сущности динамически приобретают способности, эффекты и состояния, необходима архитектура, позволяющая гибко и безопасно управлять логикой. ECS предоставляет именно такую возможность, предлагая зрелый подход к организации игрового кода.
Я разделяю озабоченность автора статьи: действительно, слепой догматизм, будь то "ООП навсегда" или "ECS ради ECS", способен привести к излишней сложности, перегруженной архитектуре и отвлечению от сути создания игры. Однако я не согласен с идеей, что простая модель с главным массивом и наборами функций является универсальным решением.
ECS обеспечивает гибкость и масштабируемость, которые трудно воспроизвести в предложенной модели. Вы советуете использовать плотные структуры Unit[] и редкие поля в пулах с простым конвейером обработки. Такой подход может работать в простых сценариях, но он плохо масштабируется в ситуациях, где игровые механики динамичны, многокомпонентны и разнообразны (пример - Space Station 14). ECS позволяет на лету комбинировать характеристики, достаточно прикрепить к сущности нужные компоненты без переписывания структуры Unit. При этом системы автоматически обрабатывают только сущности с актуальными компонентами, не засоряя основной "скелет" игры.
Что касается производительности и локальности, то они не являются догмой, а скорее одним из ключевых преимуществ ECS. Да, в статье верно отмечено, что лишний указатель не всегда критичен, а ECS может перерасти в бюрократию. Но грамотно реализованная архитектура на ECS использует удобное хранение компонентов и обеспечивает эффективные проходы по данным (часто с поддержкой SIMD) автоматического параллелизма и компактного кэширования. Это особенно важно в сложных симуляциях и при большом числе однотипных сущностей.
Критика ECS за скрытый порядок систем и "неявные протоколы" справедлива лишь для плохо организованных проектов. При правильной архитектуре порядок выполнения систем можно задавать декларативно, документировать и тестировать каждую систему изолированно. В модели же с "одной функцией, которая всё сама обрабатывает" логика переплетена в макароны, что усложняет тестирование и внесение изменений.
Ещё одно важное преимущество ECS - чёткое разделение данных и логики. В модели с "всё в одной структуре" легко скатиться в объекты -прародители или монолитные функции. ECS же разделяет компоненты (данные) и системы (логику), что помогает держать код чистым и модульным, соответствуя принципу single responsibility.
В итоге, когда проект небольшой или находится на стадии прототипа, минималистичный подход может быть уместным. Но в масштабных играх, где сущности динамически приобретают способности, эффекты и состояния, необходима архитектура, позволяющая гибко и безопасно управлять логикой. ECS предоставляет именно такую возможность, предлагая зрелый подход к организации игрового кода.