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

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

Страницы: 1 2 328 29 Следующая »
#0
14:41, 3 апр. 2011

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

Это сообщение сгенерировано автоматически.


#1
14:41, 3 апр. 2011

Найдется хидер с описанием классов для последнего подхода?

#2
15:04, 3 апр. 2011

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/
http://www.insomniacgames.com/assets/filesadynamiccomponentarchit… egameplay.pdf
я просто оставлю это тут.

#3
16:15, 3 апр. 2011

MarkoPolo
> Найдется хидер с описанием классов для последнего подхода?
Найдется, но там немного сложнее чем описано.

#4
16:33, 3 апр. 2011

Я так понимаю получается тоже самое, что  Компоновщик, с учетом того, что компоненты в себе других компонент не содержат ?

#5
16:35, 3 апр. 2011

Скорее получается дерево аспектов. Composite немного не то.

#6
16:45, 3 апр. 2011

Therg
компоновщик - это не то немного, иначе любая коллекция объектов это "компоновщик".

#7
17:01, 3 апр. 2011

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

class CGameComponent
{
  // stuff
  // ...
  vector<CGameComponent*> Children;

  void Attach( CGameComponent* );
  // other methods for linking components

};
#8
17:09, 3 апр. 2011

Да просто в этом нет ничего интересного =)
Работать с этим всем так-же как и с обычными объектами, получил указатель на аспект, совершил действие. А как они будут общаться там написано - через подписку. Тоесть хочешь передвинуть фонарик, двигаешь физику, остальное само будет двигаться.

#9
17:10, 3 апр. 2011

такой подход очень хорошо вписывается в многопоточную архитектуру. например вот

#10
17:11, 3 апр. 2011

3eR0.1ive, ну блин, можно было указать, что с такой системой траверс сцены потом удобно делать визитором в паре проходов.

#11
17:13, 3 апр. 2011

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

#12
17:20, 3 апр. 2011

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

#13
17:25, 3 апр. 2011

Dreamcatcher
> можно было указать, что с такой системой траверс сцены потом удобно делать
> визитором в паре проходов.
не надо в такой схеме обходы визитором делать - компоненты разных типов надо отдельно держать и обходить.

#14
17:34, 3 апр. 2011

Xunter
> не надо в такой схеме обходы визитором делать - компоненты разных типов надо
> отдельно держать и обходить.
истина. отдельно обновляем\считаем все что нужно в своих менеджерах, отдельно обновляем подписку(синхронизируем). тогда все элементарно параллелится.

Страницы: 1 2 328 29 Следующая »
ПрограммированиеФорумОбщее