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

Кто не поленится указать доходчивую литературу на великорусском, либо объяснить, зачем эти заморочки?
Чем не устраивает
class Object
{
PhysicObject*phys;
Renderable*rend;
AIObject....
};

Правка: Там в статье упомянуто. Но не указано, почему нету гибкости.

Подождите, постойте! А чем все-таки первый вариант не угодил? Я вот, честно сказать, смотрю на варианты 2 и 3, и вижу абсолютно ненужную ботву, которой орхетектор пытается обмазать простой и понятный код п.1.

Я вот думаю, что п.1 можно было бы еще улучшить:

struct Object
{
    void* graphicsNode;
    void* physicsNode;
    void* sound;
    void*  ...
    // ...
};

Очень хорошо будет: компоненты сами рулят процессом, а объект только держит их все в одном месте, чтобы наладить связь между компонентами одного объекта.

Хаха, пока писал, уже обогнали :). Вопрос по сути тот же.

Указанно как минимум 3 недостатка:
1. Отсутствие гибкости. Гибкости нет, потому что при нужде в очередном компоненте, нужно править основной код. В описываемом случае можно добавлять типы компонентов хоть с динамически загружаемых плагинов.
2. Blob это плохо. Сопровождать и масштабировать его "одно удовольствие".
3. Тяжело распараллелить.

Wraith
> чтобы наладить связь между компонентами одного объекта.
Вот связь и налажена. Компонент подписан на другой компонент. Нет смысла в ненужном "объекте".

3eR0.1ive
>
> 1. Отсутствие гибкости. Гибкости нет, потому что при нужде в очередном
> компоненте, нужно править основной код. В описываемом случае можно добавлять
> типы компонентов хоть с динамически загружаемых плагинов.
Синдром Абсолютной Гибкости это называется... Так у нас блин много случаев, когда нужно забацать что то нереально крутое и непонятное. Что у нас за игровой объект таокй, которому мало БЛОБ-архитектуры? Если он у нас появился, значит, его стоит делать чем то другим. Не обязательно какой нить ветер или НЁХ в небе делать стандартными игровыми объектами.

> 2. Blob это плохо.
А по моему хорошо.
А вот второй пункт вообще дикая ахинея. С аспектами еще как то понятнее...

> 3. Тяжело распараллелить.
А по-подробнее, пожалуйста, можно?

3eR0.1ive
> Нет смысла в ненужном "объекте".
Ээ.. То есть, логическая связка между физикой, графикой, ИИ и звуком не нужна?

3eR0.1ive
Вот погоди, давай по пунктам.

> 1. Отсутствие гибкости. Гибкости нет, потому что при нужде в очередном компоненте, нужно править основной код.
Почему это? При добавлении нового типа компонентов ты просто добавляешь поле под еще один указатель. Больше ничего в object не меняется.

> В описываемом случае можно добавлять типы компонентов хоть с динамически загружаемых плагинов.
Мы игры пишем или что?

3eR0.1ive
> 2. Blob это плохо. Сопровождать и масштабировать его "одно удовольствие".
Почему это? Все равно компоненты так или иначе должны знать хотя бы частично друг о дружке, хоть в блобе, хоть где.

3eR0.1ive
> 3. Тяжело распараллелить.
Почему это? Определенный тип компонент рулится своей подсистемой. Можно параллелить всяко: внутри или нет.

Wraith
напиши функцию апдейт своего объекта?

kas
А нету ее :)

-Eugene-
> Синдром Абсолютной Гибкости это называется... Так у нас блин много случаев,
> когда нужно забацать что то нереально крутое и непонятное.
Для меня гибкость всегда важна. Я не люблю в последствии сидеть ночами и придумывать выходы из ситуаций которые можно было предусмотреть потратив совсем немного времени. А на счет непонятности, тут уж не я виноват.

-Eugene-
> Что у нас за игровой объект таокй, которому мало БЛОБ-архитектуры
Блоб - не архитектура, а архитектурная ошибка.

-Eugene-
> Если он у нас появился, значит, его стоит делать чем то другим. Не обязательно
> какой нить ветер или НЁХ в небе делать стандартными игровыми объектами.
Вот видишь, уже с ходу появились объекты которые потребуется писать отдельно, которые уже не вписываются в "архитектуру". Дальше - больше.

-Eugene-
> А по моему хорошо.
> А вот второй пункт вообще дикая ахинея.
перестает быть хорошо, когда в проекте больше 40 тыс строк.

Wraith
> Мы игры пишем или что?
Я пишу движок, на котором пишут игры.

Wraith
> Почему это? Все равно компоненты так или иначе должны знать хотя бы частично
> друг о дружке, хоть в блобе, хоть где.
Вот они в подписке и знают, зачем писать лишнее.

Wraith
> Почему это? Определенный тип компонент рулится своей подсистемой. Можно
> параллелить всяко: внутри или нет.
Если компоненты рулятся в своих подсистемах, то да можно.

-Eugene-
> Ээ.. То есть, логическая связка между физикой, графикой, ИИ и звуком не нужна?
нет.
Wraith
> А нету ее :)
именно. Если нужна какя-то особая хероверть, то это попросту делается из скриптов.

Wraith
> А нету ее :)

ну а как же без оной ? :)

innuendo
> ну а как же без оной ? :)
Ну компоненты сами знают как обновляться. А для управления или логики какой все делается в скриптах.

Дык подожди, компонентная система как раз и подразумевает, что каждый компонент обрабатывается собственной подсистемой, что подсистемы всем и рулят. Декомпозиция такая. struct Object в этом случае - это просто способ достучаться из одного компонента в другой, принадлежащий той же комплексной сущности. Поэтому и подписка не нужна. У Object даже Update() нету, потому что апдейтятся подсистемы целиком.

3eR0.1ive
Хм... Интересная идея - сделать все независимым от всего. Подумаю на досуге...