- L
- Участник
Как рас таки материал и будет определять что это: графическое тело, или узел без нечего, физическое тело взаимодействующие с миром или нет
В конструкторе будет читаться материал и через switch создаваться то-та - то-та
Это избавит от необходимости создания огромного количества сущностей схожих по природе, состоящих из графической модели + физического тела
Все определяться в материале
Чтобы энити независимо от того что это за энити вёл себя как триггер, где ни будь отдельно пишешь компонент триггера, а потом
внедряешь его в те энити которые должны вести себя как триггер,
Помимо того что по факту соприкосновения тел с какими-то конкретными материалами (физическими) должен вызываться калбек ещё
сам по себе компонент физического тела, должен быть спроектирован так чтобы он сам вел себя как триггер. (физический движок это позволяет)
И тогда в конструкторе необходимо указывать
1) имя материала
2) масса
3) позиция
4) поворот
5) список каллбеков - это список условий срабатывания (для этого конкретного тела), указателей на объекты и методы которые необходима вызвать
Это позволит например вызывать калбек по факту касания с такой-то скоростью, под таким то углом такового конкретного тела....
- главное это спроектировать правильный компонент Физического тела.........
L
> а вот стена.. почему она Entity? она в игре всеголишь 2 функции выполняет -
> рисуется и не даёт предметам через неё проходить- т.е. она юзается в
> физическом и графическом мире а игровой тут при чём?
При том что игровой двиг юзает и физ и рендер. Удобно когда все объекты одного базового класса.
u: а есть отдельно владка Brush -> Пролучается они здания и т.д. не считают игровыми сущностями!
me: а есть отдельно владка Brush -> Пролучается тот кто делал редактор решил что так будет удобней для его пользователей
Если тебе важно, то например TGE считает стены игровыми объектными. А на их двигах делает игры UBISOFT или
CapCom. "Потому я и смотрю на них.. раз они сделали, знач так удобно и правильно. : )"©
> ну вот, например, .. скажите, какими свойствами должен обладать базовый класс Entity? (я про его функционал)
ну вот например как-то так
физ свойства(координаты, вес?, скорость, ускорение, столкновения)
граф свойства(моделька, анимация, шейдеры=)?)
игровые свойства(хит поинты, разрушаемость, взаимодействие с игроком)
я знаю что у стены нет хит поинтов, тогда и не надо)))
навскидку методы
Update()
Draw()
Add(Entity e)
колбеки:
OnCollision(Entity e)
OnDeath()
OnCreate()
А чем твой двиг будет лучше Torque 3D? Я как раз двиг ищу. Думаю вот может на твой перейти?
Я извиняюсь, может и глупо, но что если сделать всё проще, без этих бесконечных классовых проблем? Например, Кармак считает, что чем меньше glue кода, тем лучше, в DOOM 3 нет выделенных движков, по сути есть графический движок, физика и остальные с ним составляют целое. Тоже между прочим компания ;-)
движки на все случаи жизни (ogre) - бред, движок пишется для определённого класса игр.
Ariel
> движки на все случаи жизни - бред, движок пишется для определённого
> класса игр.
+500
Kак мысли читаешь. Причем этих классов игр не прям уж как много.
iGod
> А чем твой двиг будет лучше Torque 3D? Я как раз двиг ищу. Думаю вот может на
> твой перейти?
пока не стОит я его ещё не допилил чтоб на публику выставлять.. стрёмно : )
так а я не собираюсь делать мегагибкий движок.. просто пытаюсь повысить реюзабельность кода.
iGod
> А чем твой двиг будет лучше Torque 3D?
Да, хороший двиг - черпаю с него вдохновение...
L
У меня вопрос (немножко уже поднадоевший). У тебя камера на чём построена - на кватернионах или на векторах и матрицах? И какие типы камер у тебя реализованы в двиге?
Алмаз
> У тебя камера на чём построена - на кватернионах или на векторах и матрицах?
на векторах и матрицах
>И какие типы камер у тебя реализованы в двиге?
FPSCamera, RTSCamera, FreeCamera всё остальное делается контроллерами... двигаться по пути - контроллер, дрожать - контроллер и т.д.
вот вопрос есть. Спорим тут с человеком о такой теме:
делать ли Entity мегагибким или нет? Всмылсе прописать базвые классы сущностей типа Human, Ammo, Trigger, Vechicle, Animal а ни их основе делать совершенно разных людей/животных/транспорт спец XML файлами или же делать какойто мегагибкий базовый класс Entity который можно скриптами както сильно расширять и сделать из него любой игровой объект.
Я думаю начинать стоит с игровой логики, т.е. базовый игровой объект - точка в игровом мире. Координаты и положение. Для неё не важно отображени, физика и т.п. Это просто точка.
"Мегагибкость", как правило означет, что когда ты что-то меняешь в своей "мегагибкой" системе, после этого ты много недель подряд сидишь и правишь не менее мега, но уже баги, во всём, что было построенно на этой системе.
Так что, моё имхо - мегагбикость фича левая и почти никогда не нужная.
Мне кажется, скорее так:
- общий класс (энтити)
- более специализированные подклассы (подвижные объекты, не подвижные, живые, не живые и т.д.)
- конкретные классы предметов и событий, которые нельзя получить просто скриптингом предыдущего уровня классов
slava_mib
да, я с тобой согласен!
Я так и хочу делать
есть
1. Entity
1a LifeForm
1aa Human, Animal, Mutant...
1b StaticForm
1ba тут любай статичная гометрия уровня - стены, пол, забор и т.д.
1c Vechicle
1ca Car, Plane, Boat....
L
Ну мысля вполне правильная, осталось реализовать. Главное не уйти в финальную реализацию слишком рано. Ну не отличается игрок от непися. Никак. Только управляющие воздействия у одного от АИ, у другого - от инпута.
ещё вопрос..
я всё ни как не могу определиться с камерой... как она описана в игровом двиге?
Например если у меня - шутер от 3 лица. Камера В Entity или нет? Как камера привязана к игроку? Её тупо контроллер таскает за собой или мегакласс игрока это делает? Или движок это сам делает - получает координаты игрока и рассчитывает? Действительно - меня сейчас только это держит.
Камера сама по себе
При создание камеры указываешь как она будет себя вести, кого будет преследовать или к кому будет привязана (необходимо будет подумать над интерфейсом согласования)
создаёшь игрока,
потом камеру, а среди аргументов указатель на игрока и способ преследования (упрощённо говоря)
имхо в игровом движке больше подходит не объектное а функциональное наследование, т.е. наследование должно определять поведение объекта, а не его иерархию в чем-то (ну есть пара исключений)
Тема в архиве.