Развитие игровой вспышки
epayservices.com
Текущее время: Вт мар 28, 2017 12:17 pm

Часовой пояс: UTC + 3 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 6 ] 
Автор Сообщение
 Заголовок сообщения: архитектура Entity Component System
СообщениеДобавлено: Пт дек 23, 2016 10:33 pm 
Не в сети

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

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

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


Вернуться наверх
 Профиль Отправить e-mail  
 
 Заголовок сообщения: Re: архитектура Entity Component System
СообщениеДобавлено: Вт янв 03, 2017 12:45 am 
Не в сети
Аватар пользователя

Зарегистрирован: Пт апр 09, 2010 11:30 pm
Сообщений: 382
Откуда: Петербург
ИМХО, какой-то эталонной реализации не существует в природе, ибо подход относительно новый. Тот же пример на Хабре вводит ноды как промежуточное звено между сущностью и системой. Тогда как в других статьях подобное не упоминается.

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

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


Вернуться наверх
 Профиль Отправить e-mail  
 
 Заголовок сообщения: Re: архитектура Entity Component System
СообщениеДобавлено: Вт янв 03, 2017 11:04 am 
Не в сети
Аватар пользователя

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

...

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


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: архитектура Entity Component System
СообщениеДобавлено: Вт янв 03, 2017 2:11 pm 
Не в сети

Зарегистрирован: Ср апр 06, 2011 12:31 pm
Сообщений: 2491
Откуда: Moscow
Сайт: http://stranger087.com
Юзал Ash с Юнити, годная штукенция. Ответ на вопрос автора содержится в доках:

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


Вернуться наверх
 Профиль Отправить e-mail  
 
 Заголовок сообщения: Re: архитектура Entity Component System
СообщениеДобавлено: Вт янв 03, 2017 2:28 pm 
Не в сети
Аватар пользователя

Зарегистрирован: Ср ноя 02, 2011 9:23 am
Сообщений: 354
Юзаю haxe+flambe, во фламбе тоже ecs, доволен как слон.


Вернуться наверх
 Профиль Отправить e-mail  
 
 Заголовок сообщения: Re: архитектура Entity Component System
СообщениеДобавлено: Вт янв 03, 2017 10:29 pm 
Не в сети

Зарегистрирован: Вт янв 29, 2013 4:52 pm
Сообщений: 171
Ivan писал(а):
Вот например в системе столкновений я понял что CarNode врезалась в одно из препятствий и должна быть удалена соответствующая сущность. Но как узнать какая сущность должна быть удалена?


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

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

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


Вернуться наверх
 Профиль Отправить e-mail  
 
Показать сообщения за:  Сортировать по:  
Начать новую тему Ответить на тему  [ Сообщений: 6 ] 

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB