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

А чё на сайте на забугорском всё? Ничего так скрин, приличненко. Продолжай в том же духе.

P. S. А у тебя получается команда есть?

 L 
скрин классный, я надеюcь тени от пальм динамические? При всём уважении, C# и D3D - адская смесь, я пишу на C / ObjC / OpenGL

у шарпа ведь автоматическая сборка мусора - она всегда сливает ручной

Алмаз
> А чё на сайте на забугорском всё?
да по привычке както написал : )  привык всё на англицком бахать х.з.  + он какбэ ж международный  (чтоб все могли узнать, кто их поработил  xDD)

Алмаз
> P. S. А у тебя получается команда есть?
ну..  кодер - я.  тестер свалил кудато и не появляется.. так и не успел потестить..  а третий.. он ещё сам учится (у меня) программировать както так.  посему ПОКА ЧТО я сам всё делаю.

Ariel
> я надеюcь тени от пальм динамические?
PSSM

Ariel
> C# и D3D - адская смесь
о дааа : )

Ariel
> у шарпа ведь автоматическая сборка мусора
даже говнокод она делает вполне рабочим : )

 L 
> Ariel
> > C# и D3D - адская смесь
> о дааа : )
:D

По пути написания игрового двига понадобилось изменить графический.
Ну там в графическом снёс поддержку сцен,теперь сцены формирует игровой двиг.  А потом глянул на свои безобразные (ИМХО) классы StaticObject/DynamicObject
и подумал, а ЗАЧЕМ они нужны? Я уже и не помню, нафиг я их делал. У кого есть Static/Dynamic объекты в ГРАФИЧЕСКОМ движке и чем это разделение аргументировано?

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

Я делаю компонентную систему сущностей в игровом двиге.. тоесть есть сущность - она  == набор компонентов (ai, visual и т.д.) т.к. всё на начальной стадии - ни чего кроме очищщенного экрана пока не видел!  вот задача нарисовать сцену.. тоесть тупо плоскость над которой можно перемещаться используя клавиши клаиватуры.  Что для этого нужно - статичная сущность (плоскость "земли") и игрок.  С "землёй" то я разберусь : ) а вот с игроком непонятки.  Игрок может быть как и человек, так и просто Free camera!  Тогда получается, что понятие "игрок" ни как не привязывается к конкретному классу сущности! так?

вот на основе этих суждений я пришёл к такому выводу: 

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

вот здесь возникают у меня вопросы:
как управлять камерой? отдельный контроллер камеры создавать?  тоесть в сущности есть gocAi, gocVisual, gocCamControl, gocMotionController  тут ИИ анализирует ситуацию, посылает управляющие команды в MotionController.. тот соответственно в gocVisual меняет координаты и т.д. и вызывает в контроллере камеры какойнить апдейт.. и камера читает/анализирует/обрабатывает данные с нужных ей контроллеров?
Или както по-другому лучше управлять камерой?

второй вопрос попридержу

в принципе правильно и логично ты описал. только не много смущает терминология, особенно ИИ ;)
в юнити, например, сделано похоже - есть обьект камера (месторасположение, вращение, скейлинг) и есть контроллеры (FirstPersonController, ThirdPersonController, CutSceneController etc), которые и содержат этот самый объект камеры. Причем как сам объект камера так и контроллеры могут быть обьектами игрового движка. Таким образом получаем, что контроллер читает входные данные(клаву, мышку, скрипт...) и в соответствии с ними меняет у своей камеры ее три параметра (позишн, ротейшн, скейлинг). Нужные контроллеры дописываются по мере необходимости. Просто и работает :) Вот вроде и все.

Nup
из твоего поста я так понял, что лучше объединить мои придуманные gocCamControl, gocMotionController в один  FirstPersonController? и в нём при движении также обновлять камеру?  тоесть создаём абстрактный класс Controller -> далее абстрактный MotionController который явл. наследником Controller  а FirstPersonController это наследник MotionController..  (чтобы ии мог примести FirstPersonController к MotionController и тоже управлять объектом)

а как там камера устанавливается? я всмысле - у меня можеть быть много камер! камера может рендерить сцену и например показывать картинку на телевизор (кооторый в игре) ..это доп камера. а есть и главная камера игрока.    Как определяется, что камера главная/нет?  Тупо при создании руками добавляешь контроллер ? и всё?

Nup
а чем занимается контроллер?  Например кто выполняет эту работу: повернуть перса в нужном направлении, подвинуть на столько то юнитов, выставить такойто трек анимации.  это делает контроллер или сам класс человека а контроллер просто юзает функции класса Human

 L 
это кагбэ задача проектирования и тут все зависит от желания проектировщика;)
скажем так, контролер - это абстрактный интерфейс, от которого уже и наследуется тот же FirstPersonController, который содержит в себе, например, связанные обьекты - камеру, GUI HUD, 3d HUD и т.д..

- Что нам нужно для самого интерфейса контролера:
1) виртуальная функция(набо функций) для получения данных
2) виртуальная ф-ция Update() для обработки данных и самое главное - передача параметров связанным с контролером обьектам
3) передача параметров "наружу"
- И теперь что нам нужно для FirstPersonController:
1) получение данных - реализуем обработку клавиатуры/мыши, реализуем получение данных из потока (например, скрипт для кат-сцены или шейдер еффекта или же инфа от физ движка)
2) обработка данных - обрабатываем полученные данные для связанных обьектов - т.е. изменяем координаты/угол/... камеры , анимацию 3d HUD, изменения в GUI HUD, ..., затем передаем полученные данные самим обьектам для изменения их состояния
3) передача физ движку изменений (например "был произведен выстрел в направлении таком-то, с силой такой-то, из оружия такого-то"

в основном же лупе будет что-то типа:
...
StaticObjects.Update(); //это для примера :)))
Monsters.Update();
NPCs.Update();
...
FirstPersonController.Update();
renderAll();

это конечно же сильно упрощенно, в том же юнити нет интерфейса контроллера, есть базовый GameObject и в основном цикле проходятся по всем таким объектам сцены, вызывая у кажого Update().
Таким образом данный конкретный контролер занимается только игроком, обрабатывая его действия и перемещения. Например, при нажатии кнопки мыши(выстрел) - он начинает воспроизведения анимации выстрела и передает физ движку необходимые параметра выстрела. Второй пример - коллизия, игрок жмет "вперед" и утыкается в стену, контролер получает от клавиатуры "вперед", изменяет положение камеры, передает смену позиции физ движку. при следующем тике цикла он получает от физ движка что мол "стена", получает от клавиатуры "вперед" и не изменяет положение камеры. Вот примерно так оно представляется.

Nup
> это конечно же сильно упрощенно, в том же юнити нет интерфейса контроллера,
> есть базовый GameObject и в основном цикле проходятся по всем таким объектам
> сцены, вызывая у кажого Update().
ну у меня сейчас так и сделано

А кстати, книги про строительство движков не читал? Посоветуй, если да...

Алмаз
н-нет,такими не интересуюсь : )

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

Есть главный объект класса TengMain.
На него возложены задачи:
1. Инициализация Direct3D. Возможность доступа ко всем необходимым интрефесам через класс.
2. Работа с матрицами проекций и камерами всевозможными методами.
3. Восстановление устройства при падении (DEVICELOST).
4. Работа с клавиатруой и мышью через DirectInput.
5. Перехват оконных мессаг сабклассингом.
6. Таймер через GetPerformanceCounter.

Есть базовый объект движка TengObject
На него возложены задачи:
1. Уметь грузиться/сохраняться с ресурсов (память, файлы и т.п.)
2. Хранить список субобъектов (объектов класса TengObject)
Таким образом мы можем получить деревья TengObject-ов
Каждый TengObject может "подписаться" на рассылку: информации о потере восстановления устройства, на информацию о состоянии мыши/калвиатуры, на оконные сообщения.
Помимо этого любой TengObject создается с указателем на уже созданный главный объект и хранит в себе указатель на главный объект, что в свою очередь позволяет ему: юзать интерфейсы и рендерится, рулить матрицами проекции и камерами, иметь доступ к таймеру.

Все последующие классы наследуются от TengObject. Фактически все они объекты движка.

На базе TengObject можно наследовать все, апослютно, будь то ящик с гранатами, будь то модель игрока, будь то текстура или даже звук выстрела. Любой наследник будет иметь 2 пункта которые умеет уже TengObject.

Вот и пишем например класс T3DResource. Класс который будет представлять собой ресурс Direct3D.
Посему нам надо "подписать" его на оповещения о DEVICELOST-ах. Т.к. при потере устройства все DEFAULT ресурсы надо освободить, а после восстановления инициализировать заного.
От T3DResource пишем наследников скажем TVertexes и TTexture. Они будут у нас уже иметь интерфейсы очистки и восстановления. Достаточно описать для каждого. От каждого класса будут доступны интерфейсы, от TVertexes доступны IDirect3DVertexBuffer9 и IDirect3DIndexBuffer9, а от класса TTexture IDirect3DTexture9.
Развиваем идею. Можем написать TengTextureManager (или даже TengResourceManager) который будет наследником от TengObject. Его задачей будет выдавать текстурку или модель по его имени/id. Таким образом можно систематизировать текстуры (в этом очень поможет реализация деревом про которую упоминалось выше)

Далее пишем скажем объект TGameObject. Наследуем от TengObject. Любой объект в движке это обычно минимум текстурка + моделька. Следовательно этому TGameObject-у мы должны дать указатель на TVertexes и TTexture. А задача его уметь рендерится и хранить в себе условия где он находится в прострастве. Так сказать уникальный объект. Подобный может быть в другом месте и оба они могут использовать одни и те же TVertexes и TTexture.
Это в общих чертах, в действительности же можно от него породить наследников которые будут уже что то в духе TGameAnimObject (анимированный объект) и т.п.
Т.е. наращиваем объекты до самого тяжолого (многосеточного меша с кучей костей и всякой лабудой) попутно описывая промежуточные классы более простые, которые будут использоваться так же в игре как полноценные классы.

В общем вот такая какая то идея игрового движка. Постарался объяснить как можно подробнее, а вышло как то путано... помоему... или ниче так, понятно?

MrShoor
99% ты описывал графический движок : )  в моём понимании: графический и игровой движки разделяются и графический о игровом вообще ни чего не знает.. это отдельная DLL.  С графикой у меня всё в порядке ; ) Сценеграф, мультипасс рендеринг - всё есть ; )  Я какбе веду дискуссию о чисто игровом движке : ) В нём графика, вершины, матриалы и т.д. особого значения не имеют (ну за исключением типов материалов)