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

Компонентная система сущностей

Advanced: Тема повышенной сложности или важная.

Страницы: 1 2 39 10 Следующая »
#0
22:59, 21 июля 2010

Итак, делаю компонентную систему сущностей. Сразу вопрос: на сколько динамичной ее делать? По идее будет N компонентов и сё, но позволить ли создавать свой компоненты?

Итак дизайн:
Есть сущность Entity, по идее это просто контейнер для компонентов. Есть фабрика сущностей аля EntityFactory, она читает xml и создает сущность и ее Компоненты.
Псевдокод:

===tank.xml===
<?xml bla bla?>
<entity name="tank">
 <component name="graphics">
  <param name="texture">tank.png</param>
  <param name="material">tank.mat</param>
 </component>
 <component name="physics">
  <param name="weight">4000</param>
 </component>
  .....
</entity>
===somewhere in main===
Entity* e = EntityFactory::Create("tank.xml");

===EntityFactory::Create()===
xml = LoadXml();
Entity *e = new Entity(xml->entity->name);
foreach(component in xml->component){
  e->AddComponent(ComponentFactory::Create(component->attr()->name, component->params));
}

===ComponentFactory::Create()===
if(name == "graphics")
 return new GraphicsComponent(TextureManager->GetTexture(params->texture), MaterialManager->GetMaterial(params->material));
else if(...)
 ....

Для каждого вида компонента будет "фабрика" которая держит (owning) компоненты того вида.
Для общения компоненты будут использовать систему сообщений.

Вот) Это какБы первые наброски в голове. Покритикуйте плз, и посоветуйте че почитать по теме.

Спасибо!


#1
23:15, 21 июля 2010

Думается, фабрики для каждого компонента должны быть разными.
Кроме того, была здесь уже одна эпическая тема про компонентную систему сущностей. Искал?

#2
23:17, 21 июля 2010

GeniusIsme
> Думается, фабрики для каждого компонента должны быть разными.
Да я тоже так думаю.


GeniusIsme
> Кроме того, была здесь уже одна эпическая тема про компонентную систему
> сущностей. Искал?
Да, читал

#3
0:10, 22 июля 2010

skwee
> Есть сущность Entity, по идее это просто контейнер для компонентов.
>..
> e->AddComponent(ComponentFactory::Create
ну можно и так.
Entity только для связи компонент между собой? тогда у компонент ссылки на другие интересные им компоненты кэшировать.
после того как все компоненты конкретного Entity закэшируют ссылки друг на друга сам объект Entity вроде будет не нужен.
может лучше делать не e->AddComponent(..), а ф-ю CreateEntity(..) которая создаст все компоненты и раздаст кому надо ссылки на другие компоненты?
если писать generic ф-ю - то у компонент должно быть можно спросить какие им нужны ссылки на другие компоненты, ну и установить эти ссылки.

#4
9:54, 22 июля 2010

Xunter
Я не уверен что понял тебя.

> после того как все компоненты конкретного Entity закэшируют ссылки друг на
> друга сам объект Entity вроде будет не нужен.
Как это не нужен? Что тогда будет сущностью сцены?

> может лучше делать не e->AddComponent(..), а ф-ю CreateEntity(..)....
См. Entity* e = EntityFactory::Create("tank.xml");

> если писать generic ф-ю - то у компонент должно быть можно спросить какие им
> нужны ссылки на другие компоненты, ну и установить эти ссылки.
Слишком связано получиться.. Вся фишка в  компонентной системе что там связей мало. Для этого и хочу сделать систему сообщений между компонентами одой сущности и компонентами одного вида в разных сущностях.

#5
10:30, 22 июля 2010

Если про ресурсъ, то там между отдельнъми ресурсами не много связей - меш, анимация, скелет, маска костей, материал, шейдер. Все ето можно собрать в одном контейнере, не имея вообще связей между отдельнъми компонентами.

#6
11:12, 22 июля 2010

Xunter
> Entity только для связи компонент между собой? тогда у компонент ссылки на
> другие интересные им компоненты кэшировать.
> после того как все компоненты конкретного Entity закэшируют ссылки друг на
> друга сам объект Entity вроде будет не нужен.
> может лучше делать не e->AddComponent(..), а ф-ю CreateEntity(..) которая
> создаст все компоненты и раздаст кому надо ссылки на другие компоненты?
> если писать generic ф-ю - то у компонент должно быть можно спросить какие им
> нужны ссылки на другие компоненты, ну и установить эти ссылки.

+1, все верно.

skwee
> > после того как все компоненты конкретного Entity закэшируют ссылки друг на
> > друга сам объект Entity вроде будет не нужен.
> Как это не нужен? Что тогда будет сущностью сцены?

А никто, зачем тебе такое понятие, зачем то что разъединял, соединять обратно и чем-то ограничивать?

skwee
> > если писать generic ф-ю - то у компонент должно быть можно спросить какие им
> > нужны ссылки на другие компоненты, ну и установить эти ссылки.
> Слишком связано получиться.. Вся фишка в  компонентной системе что там связей
> мало. Для этого и хочу сделать систему сообщений между компонентами одой
> сущности и компонентами одного вида в разных сущностях.

Он дело говорит, послушай его, Ну будет там связанности. Эта самая удобная и масштабируемая система из всех что я встречал и делал.
Главное описать эту связь абстрактно.

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

#7
11:26, 22 июля 2010

skwee
> if(name == "graphics")
> return new GraphicsComponent(TextureManager->GetTexture(params->texture),
> MaterialManager->GetMaterial(params->material));
> else if(...)
не должно быть на уровне entity текстур, текстуры через материалы  IMHO

#8
11:42, 22 июля 2010

innuendo

> текстуры через материалы
А материалы через эффекты и т.д.

#9
11:56, 22 июля 2010

Ghost2
> > текстуры через материалы
> А материалы через эффекты и т.д.
я про эффекты ничего не говорил :)

#10
12:01, 22 июля 2010

3eR0.1ive
> Он дело говорит, послушай его, Ну будет там связанности. Эта самая удобная и
> масштабируемая система из всех что я встречал и делал.
> Главное описать эту связь абстрактно.
Тогда я не понял что он сказал. Где можно почитать по теме?

3eR0.1ive
> Единственный минус это то, что количество [b]сущностей[/b] в системе возрастает с
> таким подходом
..
> после того как все компоненты конкретного Entity закэшируют ссылки друг на
> друга сам объект Entity вроде будет не нужен
что такое сущность в этом контексте? просто

typedef std::hash_map<ComponentType, IComponent> Entity?


innuendo, Ghost2
это всё фигня, это я потом прикручу

#11
13:26, 22 июля 2010

skwee
> Где можно почитать по теме?

Боюсь что нигде =(

skwee
> что такое сущность в этом контексте? просто
>
> typedef std::hash_map<ComponentType, IComponent> Entity?

Конечной сущностью для системы будет сам компонент, список которых будет просто хранится в менеджере сцены\мира.

А понятие "объект" будет нужен только для загрузки\сохранения  с диска. А для мира это просто набор "компонентов" каждый из которых просто хранит линк на отца.

Очень большой плюс системы в том что масштабируется она влет.

#12
13:28, 22 июля 2010

> typedef std::hash_map<ComponentType, IComponent> Entity?

О_О
Зачем всё это?

#13
14:07, 22 июля 2010


Necrys
> > typedef std::hash_map<ComponentType, IComponent> Entity?
>
> О_О
> Зачем всё это?

Правильный ответ - незачем.

#14
14:39, 22 июля 2010

skwee
> Тогда я не понял что он сказал. Где можно почитать по теме?
http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/
http://seven-degrees-of-freedom.blogspot.com/2010/03/right-of-reply.html

> См. Entity* e = EntityFactory::Create("tank.xml");
> ...
> что такое сущность в этом контексте? просто
> typedef std::hash_map<ComponentType, IComponent> Entity?
нет ) нету такого типа Entity вообще. зачем он нужен? пусть CreateEntity(..) создает только компоненты.

> Слишком связано получиться.. Вся фишка в компонентной системе что там связей
> мало. Для этого и хочу сделать систему сообщений между компонентами одой
> сущности и компонентами одного вида в разных сущностях.
связи так и так нужны. чем каждый раз слать сообщения, спрашивать нетипизированые компоненты по id у своего Entity - не лучше сохранить в компоненте ссылки на другие интересные ей компоненты? избавлятся от связей в коде которые есть на концептуальном уровне - это означает, что связи будут формироваться вне кода, что тяжелее отлаживать и просто медленней. а компоненты одного вида разных сущностей живут в своем менеджере - который в частности обеспечивает все необходимое им общение между собой.

>Вся фишка в компонентной системе что там связей мало.
нет ) есть связи и связи. возможность слать сообщения между произвольными компонентами легко наплодит неявных связей. кто кому в ответ на что шлет какие сообщения понадобится описывать вне кода. а ложное ощущение отсутствия "связей" дасть со спокойной душой наплодить их тьму. надо избавляться от ненужных связей - везде, а не от любых - но только в коде.
компоненты к этому ортогонально.

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

Тема в архиве.