Войти
ПрограммированиеФорумОбщее

Компонентная система игровых сущностей. (комментарии) (29 стр)

Страницы: 124 25 26 27 28 29
#420
16:13, 25 сен. 2013

neio
> Можно пример?
boost::io_service

> к примеру, из физики (положение объектов) в рендер
есть физдвиг с rigid body и есть рендерер с VBO или не знаю что там, между ними стоит сцена с объектами которые содержат motion state от физтел
физдвиг производит симуляцию rigid body, апдейтит соответствующие motion state в сцене, рендерер пробегается по сцене и применяет transform к VBO

правда тут нет ничего близкого к топику темы : )
до тех пор пока мы не сделаем общий реестр в котором зарегаем все наши менеджеры и не подпишем одни менеджеры на события других


#421
21:02, 25 сен. 2013

Pushkoff
> расскажи как это работает у вас сейчас
Движок рассылает сообщение - event, который хранит в себе указатели на отправителя, блок данных (если нужно). И еще содержит в себе основную команду, и дополнительную..
Этот ивент рассылается менеджерам копией на стек, а не указателем или ссылкой...
Менеджер принимает команду и выполняет задачу, те менеджер которые работают в тредах - складывают ивенты в свой стек, и работают с ним по своим алгоритмам..
Создание самого объекта, в игровой логике, мы думали скинуть на скрипты.
В скриптах и будет компоноваться сам объект, не пересекая на прямую менеджеры..
Вот как то так, не нравиться нам, что ивент создается на стеке постоянно  в области видимости функций, и удаляется после их выхода. По ссылке передать не получается, так как другой менеджер уже будет получать пустоту, так как уже новый тик движка будет.

#422
21:24, 25 сен. 2013

Sh.Tac.
> до тех пор пока мы не сделаем общий реестр в котором зарегаем все наши
> менеджеры и не подпишем одни менеджеры на события других
С точки зрения теории - мы это поняли, а вот как это перенести на код - и грабли и гвозди...
А знакомства с опен сорс движками еще больше разбивает в ошметки мозги и идеи реализации )

Sh.Tac.
> и не подпишем одни менеджеры на события других
патерн подписка? Обмен сообщениями или еще что то?

#423
23:18, 25 сен. 2013

neio
> как это перенести на код - и грабли и гвозди
static реестр, каждый желающий может найти в нём (получить указатель на) нужный менеджер/компонент тупо по имени, т.к. делается это один раз обычно

далее когда указатель известен и вдруг мы знаем какой метод надо дёрнуть, то создаём std::function посредством std::bind при этом вешая нужное количество аргументов
такой делегат попадает из любого треда (неважно кто послал) в контейнер "класса-адресата" и далее обрабатывается из треда "класса-адресата" например при помощи boost::apply

более сложный паттерн состоит в реализации механизма request-response если это зачем-то нужно

> патерн подписка?
ага, я его не люблю потому-что есть две чистых модели работы с данными, вытягивание (pull) и проталкивание (push), а подписка это эдакий тяни-толкай выходит : )

#424
12:30, 29 сен. 2013

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

Зачем вдаваться в крайности и использовать сразу Blob объекты или наоборот только наследование, не лучше ли объединить эти два подхода?

#425
14:48, 29 сен. 2013

Sh.Tac.
> static реестр
дерево? мапа? потоко-безопасный доступ?

Sh.Tac.
> std::function
лямбды не просадят производительность? Так как в С++11 это тоже не полноценные делегаты же по своей структуре...

Sh.Tac.
> две чистых модели работы с данными, вытягивание (pull) и проталкивание (push)
Обсервер?

Я так понял - каждый менеджер исполняется в своем потоке? Имеет свой тик обновления... Сам же игровой движок рулит управлением и созданием / уничтожением объектов?

#426
15:40, 29 сен. 2013

neio
> дерево? мапа? потоко-безопасный доступ
всё что угодно, если сервис может подниматься на ходу, то потокобезопасный, в противном случае можно один раз всех поставить при старте приложения и познакомить между собой

> в С++11 это тоже не полноценные делегаты
в плюсах нет полноценных делегатов, рекомендую тогда сменить язык на шарп, например : )

> Обсервер?
это та же подписка, чистое проталкивание это то что я написал до этого, когда отправитель знает всё об адресате, а адресат не знает ничего об отправителе

> каждый менеджер исполняется в своем потоке? Имеет свой тик обновления
да пожалуйста, хоть в одном, хоть в разных с потокобезопасным контейнером сообщений, можно без тика, когда очередь выгребается по факту помещения туда сообщения

Прошло более 5 лет
#427
20:44, 16 апр. 2019

Прошу прощения за некропост.
Разбираюсь с Unity ECS.
Там самая большая боль сейчас это большое кол-во систем, порядок выполнения которых важен.
В описанной архитектуре используется такой же подход? Если да, то как реализована настройка и отслеживание порядка выполнения систем?

#428
11:25, 17 апр. 2019

Skyblade
похоже ты сам участвовал в этой же теме
кого ты здесь спрашиваешь ?

Skyblade
по-идее твой уровень уже должен быть одним из самых высоких
из тех кто здесь есть или скорее был - особенно глядя на даты темы

Skyblade
если действительно нужно , то конечно можно помочь
за что-то реально ощутимое в котором есть смысл

Страницы: 124 25 26 27 28 29
ПрограммированиеФорумОбщее