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

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

Страницы: 13 4 5 629 Следующая »
#45
18:37, 3 апр 2011

Для примера приведу свой вариант и в чём у меня затык. Мне не лень, например.

Есть прототип:

<?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() для обращения к частям компонентов, потому что система сообщений ещё не доделана. На выходе получаем систему боксов, каждый в системе координат предыдущего, вращается вокруг своего парента. Что скажешь?

#46
18:43, 3 апр 2011

Wraith
> А нету ее :)
т.е. у всех компонент есть обратная ссылка на объект, все компоненты знают друг про друга? эдакий адский фарш заместо того чтобы в компонентах держать ссылки только на нужные компоненты, которые этажом выше. я всё правильно понял?

#47
18:49, 3 апр 2011

Dreamcatcher
> Для примера приведу свой вариант и в чём у меня затык.
Ну по сути ты собираешь объект в рантайме из компонент ведь, тоесть self.object это линк на объект? если так то можно ему просто добавлять ссылки на компоненты при создании и к ним обращатся.

правка: тоесть плучим тот фаршик что описан чуть выше)
правка2: но для конечного скриптовика будет очень удобно.

#48
18:50, 3 апр 2011

kas
> т.е. у всех компонент есть обратная ссылка на объект, все компоненты знают друг
> про друга? эдакий адский фарш заместо того чтобы в компонентах держать ссылки
> только на нужные компоненты, которые этажом выше. я всё правильно понял?
никто ниче не знает кроме своего парента, по которому синхронизироваться нужно.

#49
18:55, 3 апр 2011

3eR0.1ive
я не про твою систему, я про его. в моём понимании надо чтото типа уровня для каждого компонента. компоненты могут обращаться ( держать ссылки ) на компоненты с меньшим или таким же уровнем, никогда с большим.

#50
18:58, 3 апр 2011

А вы вобще разделяете обьекты на системные и игровые ? В смысле Light, Mesh - это игровые обьекты или нет ?

#51
18:59, 3 апр 2011

kas
> я не про твою систему, я про его.
Ясн)

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

#52
19:02, 3 апр 2011

3eR0.1ive
уровни исключительно для апдейта, ну и какойто стройности системы. когда будет апдейтить уровень N уровень N-1 точно проапдейчен. внутри уровня - сортировать по зависимостям и апдейтить. вроде кажется что должно работать, но я сам ещё не пробывал, пока только обдумываю всякое, собираю инфу

#53
19:02, 3 апр 2011

PlayerDark
> А вы вобще разделяете обьекты на системные и игровые ? В смысле Light, Mesh -
> это игровые обьекты или нет ?
LightAspect и GraphisAspect просто хранят нужные данные из своих подсистем. Тоесть становятся игровыми аспектами) .
Ну и в самих подсистемах есть свои какие-то системные объекты, которые не выносятся наружу.

#54
19:05, 3 апр 2011

kas
> уровни исключительно для апдейта, ну и какойто стройности системы. когда будет
> апдейтить уровень N уровень N-1 точно проапдейчен. внутри уровня - сортировать
> по зависимостям и апдейтить. вроде кажется что должно работать, но я сам ещё не
> пробывал, пока только обдумываю всякое, собираю инфу
Ну у нас апдейт вообще не линеен, он ввиде дерева оформлен, и все объекты подписаны на локацию. и при вызове обновления локации все что на нее подписано обновляется. Сделано для автоподгружающихся локаций в мире.

правка: И при отгрузке локации проверяем что на нее подписано и получаем автоматический сейв, который на уровне архитектуры позволяет таскать объекты по всему миру и не парится об этом)

#55
19:07, 3 апр 2011

kas
> т.е. у всех компонент есть обратная ссылка на объект, все компоненты знают друг
> про друга? эдакий адский фарш заместо того чтобы в компонентах держать ссылки
> только на нужные компоненты, которые этажом выше. я всё правильно понял?
Компоненты знают только о тех, о которых им нужно знать. Не больше. Т.е. что там в object лежат поинтеры куда-то еще - это их не касается.

#56
19:16, 3 апр 2011

Dreamcatcher
> В скрипте инициализации создаём объект из прототипа, всё динамически
> связывается и работает. Затык пока в этих кучах кривых GetParent() для
> обращения к частям компонентов
а почему кривых? кто мешает передавать объект нужного типа? это же уже игровой скрипт, насколько я понимаю. тут уже все известно.

у нас вот такая же схема. очень удобна для скриптовщиков.

#57
19:17, 3 апр 2011

Wraith, а если я хочу компонент, который можно цеплять динамически на что угодно, тем самым добавляя свойство объекту? Например пусть у нас будет Targetable прототип и самонаводящаяся ракета. Ракета наводится на все инстансы таргетаблов, которые можно нацеплять на что угодно, а они предоставляют ракете взаимодействие с тем, к чему прицеплены. Можно динамически снимать и добавлять это свойство таким образом. Получается, что Таргетаблу нужно знать о чём-то на уровне топологии графа сцены, а не чего-то конкретного.

#58
19:20, 3 апр 2011

Иннокентий, ну, вот живой пример. У меня была демка на такой системе. Потом я добавил построение BVH (aabb) для всех узлов сцены для отладки. Для этого аттачил каждому узлу сцены в Children Renderable для отрисовки aabb. А где-то там до этого было обращение к Children[0] и всё упало.

#59
19:22, 3 апр 2011

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

Страницы: 13 4 5 629 Следующая »
ПрограммированиеФорумОбщее

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