Доброго времени суток! Сегодня мы поговорим об архитектурном подходе под названием Entity Component System (ECS), который активно применяется в разработке игр. Рассмотрим его особенности, актуальность, возможное использование в популярных играх, внедрение в такие движки, как Godot, а также обсудим его недостатки и альтернативные подходы.

Entity Component System (ECS)

ECS - это архитектурный паттерн, который становится всё более популярным среди разработчиков, стремящихся избежать проблем с переписыванием кода "с нуля" при внесении изменений в игровые механики. Этот подход позволяет снизить связность между различными игровыми компонентами, обеспечивая возможность добавления, удаления или изменения их независимо друг от друга, без ущерба для производительности. Давайте рассмотрим основы ECS.

Сущности (Entities)

Сущность представляет собой любой объект в игре, будь то персонаж, кнопка в интерфейсе или событие, передаваемое между системами. Сущности не обладают свойствами сами по себе, а служат контейнерами для компонентов. По аналогии с GameObject в игровом движке Unity.

Компоненты (Components)

Основная идея ECS заключается в переходе от традиционного ООП-подхода "Наследование" к подходу "Композиция вместо Наследования". Это позволяет избежать проблем при смешивании различных поведений и исключает необходимость в наследовании. Компоненты содержат только данные и не должны включать в себя логику обработки.

Системы (Systems)

Системы в ECS - это блоки кода, которые обрабатывают набор компонентов на сущностях. Они не содержат локальных данных или ссылок на сущности и компоненты, кроме случаев оптимизации производительности. Системы отвечают только за обработку потока сущностей и компонентов.

Note

Преимущества ECS

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

Important

Unity и ECS

Важно отметить, что хотя Unity предоставляет функциональность, схожую с ECS, оно не является ECS полностью. В Unity GameObject аналогичен ECS Entity, а MonoBehaviour - это сочетание ECS Component и ECS System.

Актуальность ECS

На данный момент ECS (Entity Component System) продолжает оставаться актуальным и важным архитектурным паттерном в разработке игр и других программных продуктов. Вот несколько причин, почему ECS остается актуальным:

Гибкость и масштабируемость: ECS позволяет разработчикам создавать гибкие и масштабируемые системы, разделяя данные и логику. Это позволяет легко добавлять, удалять и изменять функциональность без изменения основной структуры кода.
Улучшение производительности: Подход ECS обеспечивает более эффективное использование памяти и процессорного времени благодаря компактному хранению данных и линейной обработке компонентов. Это особенно важно для игр с большим количеством объектов и сложной логикой.
Отделение данных от поведения: ECS позволяет разработчикам четко разделять данные (компоненты) от поведения (системы), что улучшает читаемость, тестируемость и поддерживаемость кода.
Совместимость с параллельным программированием: Подход ECS хорошо масштабируется при использовании параллельного программирования, так как компоненты обычно являются независимыми от других и могут обрабатываться параллельно.
Подходит для различных типов проектов: ECS может быть применен не только в игровой разработке, но и в других областях программирования, таких как симуляции, визуализация данных, робототехника и многое другое.

Таким образом, ECS продолжает оставаться актуальным и востребованным паттерном в разработке программного обеспечения, особенно в области игровой разработки, благодаря своей гибкости, производительности и масштабируемости.

Недостатки ECS

Хотя ECS (Entity Component System) является мощным и гибким паттерном в разработке игр, его применение может быть ограничено в зависимости от конкретных потребностей и контекста проекта. Вот несколько причин, по которым ECS может редко использоваться в современных играх:

Сложность внедрения: Внедрение ECS может потребовать значительных изменений в архитектуре проекта и требовать больших усилий на начальном этапе разработки. Некоторые команды разработчиков могут предпочесть избегать этой сложности, особенно если у них уже есть устоявшийся код и процессы разработки.
Ограниченная необходимость: Не все игры требуют высокой степени гибкости и масштабируемости, которую предоставляет ECS. Для некоторых проектов более традиционные архитектурные подходы могут быть достаточными для достижения поставленных целей.
Инструментальные ограничения: Некоторые игровые движки и фреймворки могут быть менее совместимы с ECS или не предоставлять поддержки для этого паттерна. В таких случаях разработчики могут отказаться от ECS в пользу более удобных и знакомых инструментов.
Отсутствие опыта и знаний: Введение новых концепций и паттернов, таких как ECS, может потребовать обучения и адаптации для команды разработчиков. Если у команды нет достаточного опыта или знаний по ECS, они могут предпочесть использовать более знакомые подходы.
Сложности в отладке и поддержке: В некоторых случаях ECS может усложнить отладку и поддержку кода из-за своей нестандартной архитектуры. Это может стать проблемой для команд, у которых нет достаточного опыта работы с ECS.

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

Примеры игр где мог бы использоваться ECS

Когда я начал изучать архитектуру Entity Component System (ECS), одним из первых примеров, который пришел мне в голову, была игра Half Life. Однако, при ближайшем рассмотрении стало ясно, что этот подход в этой игре не применяется строго. Возможно, есть сущности и системы, которые кажутся подобными ECS на первый взгляд, но фактически ECS не используется в чистом виде. Вместо этого, игра основана на собственной архитектуре, которая комбинирует различные методологии разработки игр, включая ООП (объектно-ориентированное программирование), композицию и системы.

В Half-Life сущности (entity) обычно представлены в виде объектов в игровом мире, таких как враги, предметы и декорации. Эти объекты часто содержат различные компоненты, такие как модели, анимации, звуки и поведенческие скрипты. Однако структура и управление этими компонентами может отличаться от строгого ECS подхода.

В то время как некоторые элементы ECS-подобного подхода могут быть применены в различных частях игры, включая управление поведением и обновление объектов в игровом мире, основная архитектура Half-Life не представляет собой классическую реализацию ECS.

Rain World - это игра, которая также может показаться подходящей для применения Entity Component System (ECS) из-за ее сложных механик и управления поведением объектов. Однако, подобно Half Life, ECS здесь не используется в чистом виде. В Rain World присутствует иерархия объектов и различные системы управления, которые могут напоминать структуру ECS. Например, игровые объекты (сущности) могут иметь различные компоненты, такие как физика, анимации, искусственный интеллект и другие, что напоминает компоненты ECS. Однако, внутренняя организация и управление поведением объектов в Rain World основывается на других архитектурных принципах, включая использование иерархических структур и комплексных систем управления, которые могут отличаться от строгой реализации ECS.

Следующие примеры игр с возможным ECS

DOTA 2: Это многопользовательская игра в жанре MOBA (многопользовательская онлайн боевая арена), разработанная и выпущенная компанией Valve Corporation. DOTA 2 использует ECS для управления различными аспектами игровых персонажей, включая их атрибуты, навыки, поведение и взаимодействие с окружающим миром.
Dead Cells: Это метроидвания-рогалик, разработанный Motion Twin. Dead Cells использует ECS для управления игровыми объектами, включая игрового персонажа, врагов, предметы и ловушки. Это позволяет игре создавать динамичные и разнообразные уровни с различными игровыми элементами.
Hollow Knight: Это метроидвания-платформер, разработанный Team Cherry. Hollow Knight использует ECS для управления различными аспектами игрового мира, включая игровых персонажей, врагов, предметы, анимации и сцены боя. Это помогает игре создавать живые и интересные миры для исследования.
Stardew Valley: Это фермерская симуляция, разработанная ConcernedApe. Stardew Valley использует ECS для управления различными аспектами фермерской жизни, включая управление фермой, взаимодействие с NPC, рост растений и животноводство. Это позволяет игрокам погрузиться в аутентичный и живой мир фермерской жизни.
Minecraft: В Minecraft ECS используется для управления различными типами блоков, мобов, предметов и игровых механик. Например, каждый блок может быть представлен как сущность, которая содержит компоненты, определяющие его тип, текстуру, поведение и другие характеристики.
Star Citizen: Это космическая симуляция, использующая ECS для управления различными аспектами игрового мира, такими как управление кораблями, боевые системы, экономика и т. д.
Cities: Skylines: В этой градостроительной игре ECS используется для управления различными аспектами города, включая транспорт, экономику, здания и т. д.
Factorio: Эта игра об управлении фабрикой, в которой игрок строит и управляет различными производственными системами. ECS используется для управления производством, транспортировкой ресурсов и другими аспектами игрового мира.

ECS в Minecraft

В Minecraft ECS (Entity Component System) применяется для управления различными элементами игрового мира, такими как блоки, мобы (живые существа), предметы и другие объекты. Давайте рассмотрим более подробно, как работает ECS в Minecraft:

Сущности (Entities):

В Minecraft каждый игровой объект (блок, моб, предмет и т. д.) представлен как сущность.
Сущности являются контейнерами для компонентов и могут иметь различные свойства и характеристики.
Например, игровой блок может быть представлен как сущность, которая содержит компоненты, определяющие его тип, текстуру, положение в мире и другие характеристики.

Компоненты (Components):

Компоненты в Minecraft представляют собой данные, определяющие различные характеристики и свойства игровых объектов.
Например, у блока может быть компонент, определяющий его тип (трава, камень, дерево и т. д.), компонент, определяющий его текстуру, компонент, определяющий его положение в мире и компоненты, определяющие его поведение при взаимодействии с другими объектами или игроками.

Системы (Systems):

Системы в Minecraft отвечают за обработку компонентов и управление поведением игровых объектов.
Например, есть системы, отвечающие за физическое взаимодействие блоков (гравитация, столкновения), системы, отвечающие за визуальное отображение блоков и мобов (рендеринг), системы, отвечающие за искусственный интеллект мобов (AI), и т. д.

Взаимодействие между компонентами и системами:

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

Управление созданием, обновлением и удалением сущностей:

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

Таким образом, ECS в Minecraft является основой для управления различными элементами игрового мира и обеспечивает гибкость, масштабируемость и эффективность в разработке и управлении игровыми объектами.

Важность ECS

Вопрос о важности ECS (Entity Component System) зависит от контекста конкретного проекта и потребностей команды разработчиков. В некоторых случаях ECS может быть важным инструментом для достижения определенных целей, в то время как в других проектах он может быть менее релевантным или даже излишним. Давайте рассмотрим некоторые факторы, которые могут определить важность ECS:

Гибкость и масштабируемость: ECS может обеспечить высокую гибкость и масштабируемость в управлении игровыми объектами, что может быть важно для проектов с большим количеством разнообразных элементов и игровых механик.
Управление сложностью: В проектах с большим объемом кода и сложной архитектурой ECS может помочь управлять сложностью путем разделения логики и данных на отдельные компоненты и системы.
Реализация игровых механик: ECS может быть полезным для реализации определенных игровых механик, таких как системы поведения NPC, системы физической симуляции, системы взаимодействия с игровым миром и другие.
Производительность: В некоторых случаях ECS может обеспечить лучшую производительность по сравнению с традиционными подходами к управлению объектами благодаря оптимизированной работе с данными и распределению нагрузки на системы.

ECS в Godot

Почему Godot не использует ECS:

Архитектура с узлами и компонентами: Godot использует более традиционный ООП подход, предоставляя узлы (Nodes), которые содержат как данные, так и логику. Это подходит под понятие композиции, но на более высоком уровне (узлы, которые вы используете, обычно более высокого уровня, чем компоненты в традиционной ECS).
Использование наследования: Godot делает активное использование наследования, что приводит к более явным отношениям между классами. В Godot узел Button, например, наследуется от различных базовых классов до низлежащего уровня Behavior Script.
Оптимизация: Godot уделяет внимание оптимизации, но это происходит на разных уровнях. Хотя ECS обычно приводит к оптимизации за счет организации данных в памяти, Godot использует различные оптимизации, такие как оптимизации уровня движка и оптимизации в игровой логике.

Можно ли использовать ECS в Godot:

Хотя Godot не является строго ECS-ориентированным движком, вы можете использовать ECS в ваших проектах на Godot. Вот несколько способов:

Реализация собственного ECS: Вы можете реализовать собственную систему управления сущностями и компонентами, используя инструменты и возможности Godot, такие как сигналы, узлы и скриптинг.
Использование сторонних решений и плагинов: Существуют сторонние библиотеки и плагины для Godot, которые добавляют поддержку ECS или похожих концепций. Некоторые из них предлагают реализацию ECS для создания игр в Godot. (Например Godex)
Альтернативные методы оптимизации: Godot предоставляет различные инструменты и методы оптимизации, которые могут быть использованы вместо строгого ECS подхода. Это включает в себя управление видимостью объектов, напрямую использование серверов и использование вычислений (GPGPU) для параллельных задач.

Таким образом, хотя Godot не является чисто ECS-ориентированным движком, вы можете использовать ECS в ваших проектах на Godot, реализуя собственные решения или используя сторонние библиотеки и плагины.

Чем узлы (Nodes) лучше чем подход ECS?

Узлы (Nodes) и ECS (Entity Component System) представляют разные архитектурные подходы к разработке игр, каждый из которых имеет свои преимущества и недостатки. Вот несколько причин, по которым узлы могут быть предпочтительными по сравнению с ECS:

Простота в использовании: Узлы представляют собой интегрированный аспект в многих игровых движках, таких как Godot Engine. Они предоставляют простой и понятный способ организации игровых объектов и их поведения без необходимости дополнительной настройки или освоения новых концепций, как это требуется в ECS.
Интеграция с визуальным редактором: Многие игровые движки, использующие узловые системы, такие как Godot, предоставляют визуальные редакторы для создания и редактирования игровых сцен. Это позволяет дизайнерам и разработчикам без опыта программирования легко создавать и настраивать игровые объекты и их взаимодействия.
Привычный подход: Узловые системы являются традиционным и широко используемым подходом в игровой индустрии. Многие разработчики имеют опыт работы с узлами и привыкли к их использованию для создания игровых объектов и сцен.
Гибкость и расширяемость: Узлы могут быть легко расширены и настраиваемы, позволяя разработчикам создавать разнообразные и сложные игровые объекты и системы. В то время как ECS также обеспечивает гибкость и расширяемость, его использование может потребовать более дополнительной работы и настройки.
Производительность: В некоторых случаях узловые системы могут обеспечивать более высокую производительность по сравнению с ECS, особенно при работе с небольшими проектами или проектами с невысокими требованиями к производительности. Узлы могут быть оптимизированы под конкретные потребности проекта и аппаратные характеристики целевых платформ.

В конечном счете выбор между узловыми системами и ECS зависит от конкретных потребностей и целей проекта, а также от предпочтений и опыта разработчиков. Каждый из этих подходов имеет свои преимущества и может быть эффективно использован в зависимости от контекста проекта.

Пример реализации ECS в Godot с использованием GDScript:

Создание компонента:

# components.gd

class TransformComponent:
    var position: Vector2
    var rotation: float
    var scale: Vector2

    func _init(position: Vector2, rotation: float, scale: Vector2):
        self.position = position
        self.rotation = rotation
        self.scale = scale

Создание системы:

# systems.gd

class MovementSystem:
    func update(entity_manager):
        var entities = entity_manager.get_entities_with_component(TransformComponent)
        for entity in entities:
            var transform = entity.get_component(TransformComponent)
            # Логика обновления позиции сущности
            transform.position += Vector2(1, 1) * delta

Создание сущности и добавление компонента:

# main.gd

extends Node

var entity_manager = EntityManager.new()

func _ready():
    var entity = entity_manager.create_entity()
    var transform_component = TransformComponent.new(Vector2(0, 0), 0, Vector2(1, 1))
    entity.add_component(transform_component)
    entity_manager.add_entity(entity)

func _process(delta):
    MovementSystem.update(entity_manager)

Менеджер сущностей:

# entity_manager.gd

class EntityManager:
    var entities = []

    func create_entity():
        return Entity.new()

    func add_entity(entity):
        entities.append(entity)

    func get_entities_with_component(component_type):
        var filtered_entities = []
        for entity in entities:
            if entity.has_component(component_type):
                filtered_entities.append(entity)
        return filtered_entities

Это простой пример реализации ECS в Godot. В этом примере мы создаем компонент TransformComponent, систему MovementSystem, создаем сущность и добавляем компонент к ней, а затем используем систему для обновления позиции всех сущностей с компонентом TransformComponent в игре.

Аналоги ECS и другие архитектурные подходы

Помимо ECS (Entity Component System), существуют и другие архитектурные паттерны и подходы, которые широко применяются в геймдеве и могут предложить аналогичные или дополнительные возможности. Вот некоторые из них:

ООП (объектно-ориентированное программирование): В многих играх используется традиционный подход ООП, основанный на классах и наследовании. Этот подход подразумевает создание классов для игровых объектов, которые содержат в себе как данные, так и логику. Наследование используется для расширения функциональности и создания иерархии объектов.
Системы и сообщения (Systems and Messaging): Этот подход заключается в использовании отдельных систем для обработки различных аспектов игры (например, физика, рендеринг, искусственный интеллект и т. д.). Системы могут взаимодействовать между собой с помощью системы сообщений для передачи данных и управления.
Data-Driven Design (DDD): Этот подход основан на использовании внешних данных (например, файлов конфигурации, таблиц данных и т. д.) для определения поведения и характеристик игровых объектов. Это позволяет легко изменять игровые параметры без необходимости изменения исходного кода.
Actor Model: Этот подход основан на моделировании игровых объектов как акторов, которые взаимодействуют между собой посредством отправки сообщений. Каждый актор содержит свое состояние и может реагировать на сообщения, которые он получает.
Event-Driven Architecture: Этот подход основан на использовании событий для управления поведением игры. Компоненты или системы могут генерировать события при определенных условиях, а другие компоненты или системы могут подписываться на эти события и реагировать на них соответствующим образом.
Component-Based Architecture (CBA): Этот подход аналогичен ECS, но может иметь некоторые различия в реализации. В CBA игровые объекты состоят из набора компонентов, каждый из которых представляет собой отдельную функциональность или аспект объекта. Эти компоненты затем объединяются в сущности (entities), и системы обрабатывают эти сущности, основываясь на их компонентах.
Data-Oriented Design (DOD): Этот подход фокусируется на эффективной работе с данными и управлении памятью. В DOD данные структурируются таким образом, чтобы максимально использовать кэш-память процессора и минимизировать количество обращений к памяти. Хотя DOD не является строго ECS, его концепции могут использоваться вместе с ECS для улучшения производительности игровых систем.
Actor Component System (ACS): Этот подход объединяет идеи ECS и Actor Model. В ACS игровые объекты представляют собой акторов, каждый из которых может иметь различные компоненты. Акторы взаимодействуют друг с другом, отправляя и обрабатывая сообщения, что делает их более гибкими и расширяемыми.
Service-Oriented Architecture (SOA): В SOA игровые системы представлены в виде независимых служб, которые предоставляют конкретную функциональность. Эти службы могут быть подключены к игровым объектам по мере необходимости, что обеспечивает высокую гибкость и переиспользуемость кода.
Reactive Systems: Этот подход основан на реакции на события и изменения состояния в системе. В реактивных системах компоненты могут реагировать на изменения в других компонентах, а также на внешние события, что обеспечивает динамическое и отзывчивое поведение игры.

Эти подходы могут предоставлять альтернативные способы организации кода и управления игровыми объектами в зависимости от конкретных требований и целей проекта. Как и в случае с ECS, выбор подхода зависит от контекста проекта, потребностей команды разработчиков и их опыта.

Sh1zome/ECS