- Mr F
- Постоялец
Wraith
> Дык подожди, компонентная система как раз и подразумевает, что каждый компонент
> обрабатывается собственной подсистемой, что подсистемы всем и рулят.
> Декомпозиция такая. struct Object в этом случае - это просто способ достучаться
> из одного компонента в другой, принадлежащий той же комплексной сущности.
> Поэтому и подписка не нужна. У Object даже Update() нету, потому что апдейтятся
> подсистемы целиком.
Можно и так, но это уже гейм-код, я все-же про движок наверное писал. У меня просто это все в скриптах, там хранятся в каком угодно виде компоненты и там-же идет управление ими.
Что значит "гейм-код" в твоем случае?
3eR0.1ive, напиши, пожалуйста, ради примера скрипт для такой логики: Есть мячик. На столкновение с таким же мячиком пусть проигрыватеся какой-нибудь звук и мячик меняет цвет на красный, который потом со временем фейдится обратно в (255, 255, 255, 255).
Wraith
> Что значит "гейм-код" в твоем случае?
Наверное это все, для изменения чего теруется компиляция движка.
Wraith
> Что значит "гейм-код" в твоем случае?
Все что относится к конкретной игре. А не к системе в целом.
Dreamcatcher
> напиши, пожалуйста, ради примера скрипт для такой логики: Есть мячик. На
> столкновение с таким же мячиком пусть проигрыватеся какой-нибудь звук и мячик
> меняет цвет на красный, который потом со временем фейдится обратно в (255, 255,
> 255, 255).
Честно, писать лень, но у меня все это сделано через каллбеки на столкновение, тоесть звук столкновения не имеет отношения к просто проигрывающемуся звуку (SoundAspect).
по-мойму статья не раскрыла тему. почему все аспекты должны иметь позицию и ориентацию? зачем они, например, скрипту? тут как-то хитрее должно быть.
-Eugene-
> Наверное это все, для изменения чего теруется компиляция движка.
Угу. Движок отдельно, игра отдельно. В идеальном случае движок вообще не нужно трогать для написания игры.
3eR0.1ive
> В идеальном случае движок вообще не нужно трогать для написания игры.
Со скоростью проблем не будет?
Mr F
> по-мойму статья не раскрыла тему. почему все аспекты должны иметь позицию и
> ориентацию? зачем они, например, скрипту? тут как-то хитрее должно быть.
Я лишь предложил что эта связь может быть трансформацией. Ее можно расширить\сузить\переделать по настроению. Но мне пока не попадались варианты где-бы это было необходимо.
А по поводу скриптов, они тоже не являются компонентами. Скрипт привязан к локации.
3eR0.1ive, жаль что лень, так бы было куда яснее и понятно, что не так. Звук столкновения не имеет отношения к СаундАспект? А как же гибкость и единообразие? Опять же да, зачем всем аспектам трансформация? Почему не сделать отдельный аспект для трансформации объекта, навроде Placeable?
-Eugene-
> Со скоростью проблем не будет?
Да нет, все критичное все равно в ядре движка сделано как нужно.
Dreamcatcher
> Звук столкновения не имеет отношения к СаундАспект? А как же гибкость и единообразие?
Написал для простоты, на самом деле в плагине для обработки столкновений создается пул из звуковых аспектов и они используются.
Dreamcatcher
> Почему не сделать отдельный аспект для трансформации объекта, навроде
> Placeable?
Тогда прийдется решать как связать их. Но я говорил что расширить понятие связи можно.
3eR0.1ive
Всё таки напиши пример использования третьей иерархии...
Ибо не понятно, как это всё будет в конечном счёте взаимодействовать... (тем более такой нубяре как я)
>Я лишь предложил что эта связь может быть трансформацией. Ее можно расширить
тогда получится такой же god object только для взаимодействия разных компонентов.
Mr F
> тогда получится такой же god object только для взаимодействия разных
> компонентов.
Частично по такой причине мы и остановились на трансформации. Ее вполне достаточно.
ezhickovich
> Всё таки напиши пример использования третьей иерархии...
> Ибо не понятно, как это всё будет в конечном счёте взаимодействовать... (тем
> более такой нубяре как я)
Попозже выдеру какой-нить пример из демок.
Тема в архиве.