Flashgamedev.ru | Разработка и Монетизация Флэш игр
http://flashgamedev.ru/

архитектура Entity Component System
http://flashgamedev.ru/viewtopic.php?f=15&t=12942
Страница 1 из 1

Автор:  Ivan [ Пт дек 23, 2016 10:33 pm ]
Заголовок сообщения:  архитектура Entity Component System

Мне очень понравилась идея этого архитектурного решения, но тем не менее я не могу его понять его реализацию.
Например в статье на хабре к статье прикреплена диаграмма в которую я влюбился, но на деле оказалось что за красивой картинкой скрывается непонятное существо - реализация :) Погуглив хотя бы что-то из англоязычного сегмента я пришл к мнению, что на деле все ещё хуже, ведь от статьи к статье принципы кардинально отличаются.

Других тематических форумов я не знаю ( кроме gamedev, на котором по большей части сишники, которых я просто не понимаю ), поэтому очень надеюсь что у кого-то из присутствующих обладающих достаточными для ответа знаниями найдется свободная минутка и желание раскрыть тайну, как же удаляются сами Entity?

Вот например в системе столкновений я понял что CarNode врезалась в одно из препятствий и должна быть удалена соответствующая сущность. Но как узнать какая сущность должна быть удалена?

Автор:  Vitaly [ Вт янв 03, 2017 12:45 am ]
Заголовок сообщения:  Re: архитектура Entity Component System

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

Из своего опыта работы с ECS могу ответить на первый вопрос довольно просто: сущности удаляются когда они больше не нужны. Стрела попала во врага и нанесла урон? Ок, удаляем. Перед удалением сущность выкидывает из себя все компоненты, что ведёт к оповещению об этом событии всех заинтересованных систем.

Если речь об этой статье, то второй вопрос лучше адресовать разработчику Ash Framework. Но, насколько я понимаю, должен быть некий способ по компонентам ноды выяснит к какой сущности они относятся (хотя бы полным перебором этих самых сущностей). Но я бы предпочёл держать в компоненте ссылку на сущность, которая им владеет.

Автор:  ADF [ Вт янв 03, 2017 11:04 am ]
Заголовок сообщения:  Re: архитектура Entity Component System

Во-первых - правильно не удалять, а держать все в пуле и у каждого компонената иметь флаг навроде active, inuse и т.д.
Во вторых - у каждого компонента должен быть свой UID, обновляемый при инициализации компонента. И в связке с UID можут быть, соответственно, ownerID, targetID и прочее. Если ownerID>=0 - то периодически (НЕ в каждом игровом такте) проверяем, существует ли активный компонент с таким ацдишником, если нет - деактивируем данный компонент.

...

Но самое главное - далеко не всегда entity component system вообще нужна. Просто разберемся: какую задачу она решает? Задачу лаконичного описания всего многообразия игровых объектов без необходимости создавать 100500 разных классов. Но нужно ли это (как часто/сильно нужно) при разработке игры? Скорость обработки объектов, составленных из различных компонентов, точно НЕ выше, чем скорость обработки объектов одного класса (без связанных с ними компонент). И сами возможные поля ("компоненты") можно сразу забить внутрь класса игрового объекта, даже если далеко не у каждого игрового объекта эти поля будут использоваться. Да, это сжирает некоторый объем памяти и выглядит менее красиво (каждая инстанция будет носить весь багаж полей объекта, даже если использует, например, только координаты), но память - тут сущие копейки по сравнению с тем, что занимает графика и прочий контент, а вот быстродействие - зачастую является узким местом игрового кода.
В реальных проектах, обычно, вся система вырождается в три класса игровых объектов: универсальный класс игрового объекта (сюда обычно входит и класс игрока, хотя этот может быть и отдельным), класс для пуль/снарядов, и класс для спецэффектов/партиклов. Соответственно, три пула для всех этих категорий, откуда заранее созданые объекты берутся, используются, а затем деактивируются. Игровой цикл выглядит так: проходится по каждому массиву (вектору) и для всех объектов, у которых поднят флаг active - вызывает функции update, draw и т.д., в зависимости от типа объекта лишь функция инициализации меняется - устанавливает некий идентификатор типа (чтобы знать, как этот игровой объект обрабатывать) и инициализирует нужные поля.

Автор:  Stranger087 [ Вт янв 03, 2017 2:11 pm ]
Заголовок сообщения:  Re: архитектура Entity Component System

Юзал Ash с Юнити, годная штукенция. Ответ на вопрос автора содержится в доках:

http://www.ashframework.org/docs/ash/co ... tml#entity
http://www.ashframework.org/docs/ash/core/Engine.html#removeEntity()

Автор:  vovnet [ Вт янв 03, 2017 2:28 pm ]
Заголовок сообщения:  Re: архитектура Entity Component System

Юзаю haxe+flambe, во фламбе тоже ecs, доволен как слон.

Автор:  dm62 [ Вт янв 03, 2017 10:29 pm ]
Заголовок сообщения:  Re: архитектура Entity Component System

Ivan писал(а):
Вот например в системе столкновений я понял что CarNode врезалась в одно из препятствий и должна быть удалена соответствующая сущность. Но как узнать какая сущность должна быть удалена?


Есть миллион вариантов как это сделать. Самый очевидный, это добавить в текущий Entity экземпляр DestroyComponent
Соответственно DestroySystem удалит этот Entity.

Если сложней, то записать в CollisionComponent информацию о столкновении, а в CarSystem прописать реакцию на коллизии.

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

Страница 1 из 1 Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/