Войти
ПрограммированиеФорумГрафика

Игровой движок. Создание с нуля. (3 стр)

Страницы: 1 2 3 4 510 Следующая »
#30
16:38, 25 окт 2009

Как рас таки материал и будет определять что это: графическое тело, или узел без нечего, физическое тело взаимодействующие с миром или нет
В конструкторе будет читаться материал и через switch создаваться то-та - то-та
Это избавит от необходимости создания огромного количества сущностей схожих по природе, состоящих из графической модели + физического тела
Все определяться в материале

Чтобы энити независимо от того что это за энити вёл себя как триггер, где ни будь отдельно пишешь компонент триггера, а потом
внедряешь его в те энити которые должны вести себя как триггер,

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

И тогда в конструкторе необходимо указывать
1) имя материала
2) масса
3) позиция
4) поворот
5) список каллбеков - это список условий срабатывания (для этого конкретного тела), указателей на объекты и методы которые необходима вызвать

Это позволит например вызывать калбек по факту касания с такой-то скоростью, под таким то углом такового конкретного тела....

- главное это спроектировать правильный компонент Физического тела.........

#31
17:06, 25 окт 2009

 L 
> а вот стена.. почему она Entity? она в игре всеголишь 2 функции выполняет -
> рисуется и не даёт предметам через неё проходить- т.е. она юзается в
> физическом и графическом мире а игровой тут при чём?
При том что игровой двиг юзает и физ и рендер. Удобно когда все объекты одного базового класса.

u: а есть отдельно владка  Brush ->  Пролучается они здания и т.д. не считают игровыми сущностями!
me: а есть отдельно владка  Brush ->  Пролучается тот кто делал редактор решил что так будет удобней для его пользователей

Если тебе важно, то например TGE считает стены игровыми объектными. А на их двигах делает игры UBISOFT или
CapCom. "Потому я и смотрю на них.. раз они сделали, знач так удобно и правильно. :  )"©

> ну вот, например, .. скажите, какими свойствами должен обладать базовый класс Entity? (я про его функционал)
ну вот например как-то так
физ свойства(координаты, вес?, скорость, ускорение, столкновения)
граф свойства(моделька, анимация, шейдеры=)?)
игровые свойства(хит поинты, разрушаемость, взаимодействие с игроком)

я знаю что у стены нет хит поинтов, тогда и не надо)))
навскидку методы
Update()
Draw()
Add(Entity e)

колбеки:
OnCollision(Entity e)
OnDeath()
OnCreate()

А чем твой двиг будет лучше Torque 3D? Я как раз двиг ищу. Думаю вот может на твой перейти?

#32
19:53, 25 окт 2009

Я извиняюсь, может и глупо, но что если сделать всё проще, без этих бесконечных классовых проблем? Например, Кармак считает, что чем меньше glue кода, тем лучше, в DOOM 3 нет выделенных движков, по сути есть графический движок, физика и остальные с ним составляют целое. Тоже между прочим компания ;-)

движки на все случаи жизни (ogre) - бред, движок пишется для определённого класса игр.

#33
20:02, 25 окт 2009

Ariel
> движки на все случаи жизни - бред, движок пишется для определённого
> класса игр.
+500
Kак мысли читаешь. Причем этих классов игр не прям уж как много.

#34
20:21, 25 окт 2009

iGod
> А чем твой двиг будет лучше Torque 3D? Я как раз двиг ищу. Думаю вот может на
> твой перейти?
пока не стОит  я его ещё не допилил чтоб на публику выставлять..  стрёмно : )

так а я не собираюсь делать мегагибкий движок.. просто пытаюсь повысить реюзабельность кода.

#35
20:57, 25 окт 2009

iGod
> А чем твой двиг будет лучше Torque 3D?
Да, хороший двиг - черпаю с него вдохновение...

#36
20:59, 25 окт 2009

 L 
У меня вопрос (немножко уже поднадоевший). У тебя камера на чём построена - на кватернионах или на векторах и матрицах? И какие типы камер у тебя реализованы в двиге?

#37
21:10, 25 окт 2009

Алмаз
> У тебя камера на чём построена - на кватернионах или на векторах и матрицах?
на векторах и матрицах

>И какие типы камер у тебя реализованы в двиге?
FPSCamera, RTSCamera, FreeCamera  всё остальное делается контроллерами... двигаться по пути - контроллер, дрожать - контроллер и т.д.

вот вопрос есть. Спорим тут с человеком о такой теме:

делать ли Entity мегагибким или нет? Всмылсе прописать базвые классы сущностей типа Human, Ammo, Trigger, Vechicle, Animal а ни их основе делать совершенно разных людей/животных/транспорт спец XML файлами  или же делать какойто мегагибкий базовый класс Entity который можно скриптами както сильно расширять и сделать из него любой игровой объект.

#38
21:15, 25 окт 2009

Я думаю начинать стоит с игровой логики, т.е. базовый игровой объект - точка в игровом мире. Координаты и положение. Для неё не важно отображени, физика и т.п. Это просто точка.

#39
22:20, 25 окт 2009

"Мегагибкость", как правило означет, что когда ты что-то меняешь в своей "мегагибкой" системе, после этого ты много недель подряд сидишь и правишь не менее мега, но уже баги, во всём, что было построенно на этой системе.

Так что, моё имхо - мегагбикость фича левая и почти никогда не нужная.

Мне кажется, скорее так:
- общий класс (энтити)
- более специализированные подклассы (подвижные объекты, не подвижные, живые, не живые и т.д.)
- конкретные классы предметов и событий, которые нельзя получить просто скриптингом предыдущего уровня классов

#40
23:42, 25 окт 2009

slava_mib
да, я с тобой согласен!
Я так и хочу делать
есть
1. Entity
    1a  LifeForm
          1aa Human, Animal, Mutant...
    1b  StaticForm
          1ba тут любай статичная гометрия уровня - стены,  пол, забор и т.д.
    1c  Vechicle
        1ca Car, Plane, Boat....

#41
23:58, 25 окт 2009

 L 
Ну мысля вполне правильная, осталось реализовать. Главное не уйти в финальную реализацию слишком рано. Ну не отличается игрок от непися. Никак. Только управляющие воздействия у одного от АИ, у другого - от инпута.

#42
14:43, 26 окт 2009

ещё вопрос..

я всё ни как не могу определиться с камерой...  как она описана в игровом двиге?
Например если у меня  - шутер от 3 лица. Камера В Entity или нет? Как камера привязана к игроку? Её тупо контроллер таскает за собой или мегакласс игрока это делает? Или движок это сам делает - получает координаты игрока и рассчитывает?  Действительно - меня сейчас только это держит.

#43
15:22, 26 окт 2009

Камера сама по себе
При создание камеры указываешь как она будет себя вести, кого будет преследовать или к кому будет привязана (необходимо будет подумать над интерфейсом согласования)

создаёшь игрока,
потом камеру, а среди аргументов указатель на игрока  и  способ преследования (упрощённо говоря)

#44
15:27, 26 окт 2009

имхо в игровом движке больше подходит не объектное а функциональное наследование, т.е. наследование должно определять поведение объекта, а не его иерархию в чем-то (ну есть пара исключений)

Страницы: 1 2 3 4 510 Следующая »
ПрограммированиеФорумГрафика

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