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

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

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

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

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

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

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

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

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

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

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

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

};

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

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

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

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

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

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

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