Для примера приведу свой вариант и в чём у меня затык. Мне не лень, например.
Есть прототип:
<?xml version="1.0"?> <Prototype Name="A" RecursionLimit="10"> <PlaceableComponent Position="0 60"> <RenderableComponent Model="Box" Width="10" Height="10"> <GameObject Script="ClassesTest" ClassName="ParentRecolorer" /> </RenderableComponent> <A /> </PlaceableComponent> </Prototype>
Есть скрипт.
ParentRecolorer = ParentRecolorer or { } RecCount = RecCount or 0 function ParentRecolorer:OnCreate() self.Test = 0 RecCount = RecCount + 1 self.velcoef = RecCount SubscribeToEvent(self.object, "Attached") SubscribeToEvent(self.object, "EveryFrame") end function ParentRecolorer:OnAttached(event) if GetEventData(event, "Name") ~= GetName(self.object) then return end self.Test = self.Test + 1 SetColor(GetParent(self.object), 1, 0, 0, 1) end function ParentRecolorer:OnEveryFrame() SetAngle(GetParent(GetParent(self.object)), GetAngle(GetParent(GetParent(self.object))) + self.velcoef * 10.0 * GetDeltaTime()) end
В скрипте инициализации создаём объект из прототипа, всё динамически связывается и работает. Затык пока в этих кучах кривых GetParent() для обращения к частям компонентов, потому что система сообщений ещё не доделана. На выходе получаем систему боксов, каждый в системе координат предыдущего, вращается вокруг своего парента. Что скажешь?
Wraith
> А нету ее :)
т.е. у всех компонент есть обратная ссылка на объект, все компоненты знают друг про друга? эдакий адский фарш заместо того чтобы в компонентах держать ссылки только на нужные компоненты, которые этажом выше. я всё правильно понял?
Dreamcatcher
> Для примера приведу свой вариант и в чём у меня затык.
Ну по сути ты собираешь объект в рантайме из компонент ведь, тоесть self.object это линк на объект? если так то можно ему просто добавлять ссылки на компоненты при создании и к ним обращатся.
правка: тоесть плучим тот фаршик что описан чуть выше)
правка2: но для конечного скриптовика будет очень удобно.
kas
> т.е. у всех компонент есть обратная ссылка на объект, все компоненты знают друг
> про друга? эдакий адский фарш заместо того чтобы в компонентах держать ссылки
> только на нужные компоненты, которые этажом выше. я всё правильно понял?
никто ниче не знает кроме своего парента, по которому синхронизироваться нужно.
3eR0.1ive
я не про твою систему, я про его. в моём понимании надо чтото типа уровня для каждого компонента. компоненты могут обращаться ( держать ссылки ) на компоненты с меньшим или таким же уровнем, никогда с большим.
А вы вобще разделяете обьекты на системные и игровые ? В смысле Light, Mesh - это игровые обьекты или нет ?
kas
> я не про твою систему, я про его.
Ясн)
kas
> в моём понимании надо чтото типа уровня для каждого компонента. компоненты
> могут обращаться ( держать ссылки ) на компоненты с меньшим или таким же
> уровнем, никогда с большим.
Вот интересная мысль, но само собой всю эту работу перенести например в скрипты, тоесть обеспечить эту связь где-то вне движка чтоли.
3eR0.1ive
уровни исключительно для апдейта, ну и какойто стройности системы. когда будет апдейтить уровень N уровень N-1 точно проапдейчен. внутри уровня - сортировать по зависимостям и апдейтить. вроде кажется что должно работать, но я сам ещё не пробывал, пока только обдумываю всякое, собираю инфу
PlayerDark
> А вы вобще разделяете обьекты на системные и игровые ? В смысле Light, Mesh -
> это игровые обьекты или нет ?
LightAspect и GraphisAspect просто хранят нужные данные из своих подсистем. Тоесть становятся игровыми аспектами) .
Ну и в самих подсистемах есть свои какие-то системные объекты, которые не выносятся наружу.
kas
> уровни исключительно для апдейта, ну и какойто стройности системы. когда будет
> апдейтить уровень N уровень N-1 точно проапдейчен. внутри уровня - сортировать
> по зависимостям и апдейтить. вроде кажется что должно работать, но я сам ещё не
> пробывал, пока только обдумываю всякое, собираю инфу
Ну у нас апдейт вообще не линеен, он ввиде дерева оформлен, и все объекты подписаны на локацию. и при вызове обновления локации все что на нее подписано обновляется. Сделано для автоподгружающихся локаций в мире.
правка: И при отгрузке локации проверяем что на нее подписано и получаем автоматический сейв, который на уровне архитектуры позволяет таскать объекты по всему миру и не парится об этом)
kas
> т.е. у всех компонент есть обратная ссылка на объект, все компоненты знают друг
> про друга? эдакий адский фарш заместо того чтобы в компонентах держать ссылки
> только на нужные компоненты, которые этажом выше. я всё правильно понял?
Компоненты знают только о тех, о которых им нужно знать. Не больше. Т.е. что там в object лежат поинтеры куда-то еще - это их не касается.
Dreamcatcher
> В скрипте инициализации создаём объект из прототипа, всё динамически
> связывается и работает. Затык пока в этих кучах кривых GetParent() для
> обращения к частям компонентов
а почему кривых? кто мешает передавать объект нужного типа? это же уже игровой скрипт, насколько я понимаю. тут уже все известно.
у нас вот такая же схема. очень удобна для скриптовщиков.
Wraith, а если я хочу компонент, который можно цеплять динамически на что угодно, тем самым добавляя свойство объекту? Например пусть у нас будет Targetable прототип и самонаводящаяся ракета. Ракета наводится на все инстансы таргетаблов, которые можно нацеплять на что угодно, а они предоставляют ракете взаимодействие с тем, к чему прицеплены. Можно динамически снимать и добавлять это свойство таким образом. Получается, что Таргетаблу нужно знать о чём-то на уровне топологии графа сцены, а не чего-то конкретного.
Иннокентий, ну, вот живой пример. У меня была демка на такой системе. Потом я добавил построение BVH (aabb) для всех узлов сцены для отладки. Для этого аттачил каждому узлу сцены в Children Renderable для отрисовки aabb. А где-то там до этого было обращение к Children[0] и всё упало.
А почему нельзя просто ракету наводить на что-то?
Тема в архиве.