1.15 Объекты в игре

Intro

В этой Главе:

• Изучим понятие "игровой объект" а также то, как они применяются в играх.
• Исследуем принципы движения объектов с использованием векторов и мировой матрицы (world matrix).
• Внедрим в движок 3 базовых типа объектов, встречающиеся в каждой FPS-игре.¹

В предыдущей части мы разработали систему поддержки ЗD-мешей, которая позволяет загружать ЗD-меши и рендерить (в русскоязычной литературе чаще можно встретить синоним этого слова - "визуализировать") их на экране. В то же время, нам так и не удалось сдвинуть их с места (в предыдущем примере двигалась сама камера). Представь себе игру, в которой все меши статичны и не могут двигаться по игровой сцене либо быть анимированными. Любой игрок хочет видеть в FPS-игре 3D-меши игроков, которые могут бегать по игровой карте, меши оружия и аптечек, которые появляются, непрерывно вращаются на одном месте до тех пор, пока их не подберёт игрок а затем вновь респаунятся (от англ. "respawn" - дословно "перерождение") на том же месте через определённый промежуток времени. В этой Главе мы разработаем необходимую инфраструктуру для поддержки всех этих фич, и вдохнём жизнь в наши ЗD-меши.

Каждый объект сцены - зритель (viewer, виртуальная камера)

Выше мы говорили о том, что матрица вида нужна только объекту игрока, "из глаз" которого мы видим игровую сцену. Мы сделаем ход конём и оснастим матрицей вида каждый создаваемый игровой объект (для чего достаточно оснастить ею базовый объект SceneObject). Так мы получаем возможность видеть мир (игровую сцену) из перспективы любого из них, путём использования их матриц вида. Это очень здорово, особенно принимая во внимание тот факт, что игроки также будут являться объектами сцены. Таким образом мы можем видеть сцену "глазами" не только каждого игрока, но и любого объекта. Даже упаковки с патронами. Данную возможность можно применить, например, для создания камер видеонаблюдения, закреплённых на стенах. С каждой из них можно получить вид, просто запросив матрицу вида. Круто, не правда ли?

Применение игровых объектов

В большинстве игр по игровой сцене разбросаны различные штуки, с которыми игрок может взаимодействовать. На деле персонаж игрока также представлен неким ЗD-объектом, который может перемещаться по ЗD-окружению. Например, объект игрока может быть представлен в виде маленького космического корабля, летающего по экрану и уничтожающего другие корабли. Также в игре могут быть т.н. "аптечки" (power-ups) для восстановления жизней или энергии, которые летают вокруг объекта игрока, а тот их собирает. Кроме того в игре могут быть препятствия, которые также двигаются и игрок должен избегать столкновения с ними. Все вышеперечисленные объекты обладают рядом общих свойств. Во-первых все они (или почти все) обязательно представлены на экране в виде изображения или ЗD-меша. Во вторых, у каждого из них есть набор физических свойств, которые позволяют им двигаться по экрану и сталкиваться друг с другом. Как видим, все эти объекты очень схожи друг с другом. Именно их обычно и называют игровыми объектами (game objects) или, для краткости, просто объектами.
Создание игровых объектов (далее - объектов) это та сфера, где активно применяются наследование и полиморфизм. Мы обсуждали эти понятия в предыдущих Главах. Для остальных напомним, что обе этих техники лежат в основе объектно-ориентированного программирования. Наследованием называют технику создания дочернего класса на основе базового, с сохранением полного функционала "родителя". Полиморфизм определяет порядок вызова функции базового класса, если при этом он переопределён (overriden) в дочернем классе (derived class). Рассмотрим простой пример. Допустим, у нас есть класс, в котором определена виртуальная функция. Ты можешь создать на основе этого класса другой класс, который будет являться дочерним (derived) по отношению к первому, базовому (base) классу. Можно переопределить виртуальную функцию базового класса, чтобы при её вызове вызывалась именно переопределённая версия из дочернего класса.
Эти две техники необычайно важны при определении объектов в игре. Они позволяют создать всего один базовый объект, обладающий общими свойствами, присущими всем другим объектам. К примеру, ты захочешь определить, что все объекты в игре должны иметь определённое положение в ЗD-пространстве. Вместо того, чтобы добавлять вектор положения в каждый из классов игровых объектов, куда проще создать класс базового объекта (base object class), описав в нём вектор положения. Затем мы просто ответвим (derive) от него несколько дочерних классов объектов, каждый из которых унаследует вектор положения, определённый в базовом классе (классе базового объекта), а следовательно сможет использовать его без ограничений. Тот же принцип мы применим к нашим игровым объектам. Мы определим базовый объект, который будет содержать в себе описание наиболее общих свойств, присущих всем объектам в игре. Всякий раз, когда мы будем создавать новый игровой объект, нам будет достаточно ответвить от него новый дочерний класс. И новый объект автоматически будет иметь весь набор свойств базового объекта. И весь процесс здесь не останавливается. От дочернего класса ты можешь также ветвить другие дочерние классы игровых объектов и все они сохранят в себе полный функционал базового объекта (см. Рис.1).
Класс базового объекта, который мы создадим, позволит нам размещать базовые объекты на нашей ЗD-сцене. Они даже будут иметь собственные ЗD-меши, назначенный им, а значит будут видимыми на сцене. Как вариант, ты можешь вовсе не назначать меш объекту. Например при нанесении т.н. вейпоинтов (англ. "waypoint" - точка маршрута; здесь - условные точки, по отрезкам которых перемещаются игровые объекты, контролируемые компьютером), которые изначально задуманы как невидимые ориентиры.
Путём применения векторов и специального типа матрицы, называемой мировая матрица (world matrix) мы сможем задавать положение, вращать и перемещать объекты в ЗD-пространстве. И это будет лишь часть возможностей базового объекта. Создав его однажды, ты можешь ветвить от него другие, более сложные, объекты которые сразу после своего создания будут обладать всеми свойствами базового объекта.
Прежде чем начать разрабатывать наш базовый объект, обсудим ещё пару важных тем, связанных с позиционированием и перемещением игровых объектов в ЗD-пространстве. Точнее говоря мы детально рассмотрим ту самую мировую матрицу, т.к. именно через неё происходит размещение любого объекта или меша в ЗD-пространстве.

Движение объектов

Раз уж наши объекты существуют в ЗD-пространстве, они должны соответствовать Картезианской координатной системе. Другими словами объект должен иметь позицию в ЗD-пространстве, определённую координатами (х, у, z). Самый простой способ представить эти координаты - рассмотреть простой вектор положения (position vector). Вообще просто разместить объекты на сцене и оставить их неподвижными - плёвое дело. Но очевидно, что некоторые из них мы захотим привести их в движение. Сам по себе процесс движения объекта не так сложен: он лишь перемещается из одного положения в другое, меняя свои позиционные координаты. Если у тебя есть объект, расположенный в точке, имеющей координату 12.0 по оси X и ты хочешь переместить его ещё на 2 единицы по той же оси, то необходимо просто изменить его позиционную координату по оси X с 12.0 на 14.0 . Как видим, в перемещении объектов в самом деле нет ничего сложного. Намного труднее отследить направление движения.
Вместо того, чтобы пытаться указать как далеко должен двигаться объект и с какой периодичностью он должен преодолевать эту дистанцию, куда проще разработать простую, основанную на реальной физике, систему движения (movement system), которая сама вычислит нужные временные интервалы. Звучит пугающе, но всё не так страшно, как может показаться на первый взгляд.
Рассмотрим ещё один пример, который поможет прояснить ситуацию. Допустим, мы работаем в ЗD-пространстве, отмасштабированном так, что 1 единица измерения (в 3DS Мах - 1 юнит) равная 1-му метру. Это означает, что 1 метр в реальном мире соответствует 1-му метру в виртуальной сцене. Представим, что в этом ЗD-пространстве объект автомобиль движется по оси X со скоростью 10 метров в секунду (м/с). Мы можем сохранить данное движение в отдельном векторе, который назовём вектором скорости и который будет иметь координаты (10.0, 0.0, 0.0). Суть заключается в том, чтобы быть уверенным, что данный автомобиль перемещается на 10.0 единиц по оси X каждую секунду. Данное обстоятельство является ключевым для понимания всего процесса. Мы не хотим, чтобы автомобиль перемещался на 10.0 единиц в каждом кадре. Потому что в этом случае при частоте обновления, например, 50 кадров в секунду мы получим перемещение автомобиля на все 500.0 единиц по оси X каждую секунду, что эквивалентно скорости 500 м/с! Проблема в том, что мы хотим обновлять перемещение автомобиля в каждом кадре, поэтому это не будет выглядеть как простой прыжок на все 10.0 единиц в течение 1-й секунды, т.к. это создаст отрывочное, "дёрганое" движение.
Так как же нам заставить двигаться автомобиль в каждом кадре так, чтобы он перемещался каждую секунду не более чем на 10.0 единиц по оси X? На самом деле это довольно просто. Если нам необходимо распределить движение автомобиля по 50 кадрам (подразумеваем, что игра запущена в режиме 50 кадров в секунду), необходимо просто разделить скорость движения автомобиля на 50, что даст нам величину, которую проходит автомобиль в каждом кадре. В нашем случае нам необходимо перемещать его на 0.2 единицы (10.0 делить на 50 получается 0.2) по оси X в каждом кадре. И спустя 50 кадров, автомобиль как раз переместится на 10.0 единиц. А так как скорость смены кадров составляет 50 кадров в секунду, значит скорость движения автомобиля составит как раз 10 м/с. Проблема решена, не так ли? На самом деле не совсем. Мы двигаемся в верном направлении, но в нашей идее есть один основной промах. Мы не можем гарантировать, что наше приложение всегда будет работать с частотой смены кадров 50 кадров в секунду. Что если наше приложение будет запущено на другом, более мощном или наоборот слабом ПК? Да, оно будет выдавать разные показатели частоты кадров в секунду и таким образом отправит все наши предыдущие вычисления коту под хвост. Допустим, мы запустили наше приложение на слабом ПК, и оно выдаёт всего 25fps. В этом случае наш автомобиль будет двигаться со скоростью всего 5.0 единиц в секунду, т.к. число кадров в секунду составляет лишь половину от расчётных 50 fps, в то время как дистанция, проходимая автомобилем в каждом кадре осталась прежней. Верным решением здесь будет принятие во внимание тот факт, что частота обновления (частота кадров) может изменяться. Причём часто даже на одном и том же компьютере.
Для решения этой проблемы мы должны принять во внимание время смены кадров и использовать этот временной интервал для определения того, как далеко должен переместиться автомобиль в каждом кадре. Такой подход часто называют движением, основанным на времени (time-based movement) и у нас уже готова инфраструктура для его реализации. В Главе 1.2 при разработке класса Engine в тестовом приложении во время выполнения функции Run мы подсчитывали время показа каждого кадра. Как ты уже знаешь, время, затраченное на показ кадра представляет отрезок времени (определённое число миллисекунд), прошедший с момента показа предыдущего кадра. Так как кадры обрабатываются очень быстро, то часто за одну секунду обрабатывается несколько десятков кадров. То есть затраченное время (elapsed time) всегда будет очень малой величиной, равной приблизительно 0,02 секунды (20 миллисекунд) или около того. Это единственная величина, которая нам необходима для организации движения, основанного на времени.
Зная это, вернёмся к нашему примеру с движущимся автомобилем. В случае, когда наше приложение работает с частотой обновления 50 кадров в секунду (50 fps), изменение положения нашего автомобиля будет также обновляться 50 раз за 1 секунду. Таким образом показатель elapsed time (время, затраченное на показ одного кадра) составит 0,02 секунды. Представь себе показатель затраченного времени в виде определённой процентной доли секунды, необходимой для обработки текущего кадра. Это значит, что при частоте обновления 50 кадров в секунду каждый кадр "ответственен" за подготовку 2% от одной секунды игрового процесса. То есть в каждом кадре нам необходимо перемещать автомобиль всего на 2% от скорости его движения. Чтобы проделать это необходимо лишь умножить скорость движения автомобиля (10 метров в секунду) на показатель затраченного времени (0.02 сек.), что даст нам результат 0.2 м/с, что означает величину, на которую мы должны передвигать автомобиль в каждом кадре для достижения скорости 10 м/с за 50 кадров игрового процесса.
Кажется в нашем текущем примере ничего не изменилось, по сравнению с предыдущим. Но это лишь потому, что частота обновления осталась прежней - 50 кадров в секунду. Если частота обновления изменится (которая часто меняется даже в каждой секунде игрового процесса), ты увидишь, что в предыдущем примере автомобиль двигается неаккуратно, часто слишком быстро либо слишком медленно. Во втором примере в случае правильно настроенного движения, основанного на времени, любые изменения частоты обновления, подсчитанные покадровом уровне и с учётом показателя затраченного времени (elapsed time), будут учитываться и корректно отражаться на времени, прошедшем с показа предыдущего и до начала следующего кадра.

Мировая матрица (World matrix)

В конце предыдущей Главы мы впервые познакомились с матрицей вида (view matrix), а в Главе 1.5 мы также обсуждали матрицу проекции (projection matrix). Сейчас пришёл черёд изучить последнюю из трёх матриц, используемых Direct3D - мировую матрицу.
Но для начала быстро вспомним, что из себя представляют первые две.
Матрица вида (view matrix) применяется для позиционирования и ориентации зрителя (= виртуальной камеры) в 3D-пространстве. Как ты видел в предыдущей Главе, библиотека D3DX предоставляет несколько функций, которые применяются для построения матрицы вида. Наш движок не будет использовать ни одну из них, т.к. мы будем вычислять матрицу вида несколько иным путём, как ты увидишь позднее.
Матрица проекции (projection matrix) выступает в качестве своеобразной "линзы" виртуальной камеры. Матрица проекции позволяет задать угол обзора (angle of view) для поля видимости (field of view), ближней плоскости отсечения (near clipping plane) и дальней плоскости отсечения (far clipping plane). С матрицей проекции можно проделывать ряд трюков, как например сужение или расширение угла обзора, создавая иллюзию зума и фокусировки камеры на отдельных объектах сцены (особенно при использовании совместно с матрицей вида). Вообще эта тема выходит за пределы данного курса, но со значениями этих матриц ты можешь "поиграть" самостоятельно, чтобы разобраться, что там и к чему.
Самой интересной из всех трёх матриц является мировая матрица, т.к. именно она применяется для фактического размещения объектов в ЗD-пространстве. Когда ты размещаешь камеру для того, чтобы увидеть объект в ЗD-пространстве, Direct3D необходимо подсчитать, в каком месте на экране рендерить данный объект, чтобы он был виден в объективе виртуальной камеры. Представь, что экран монитора является своеобразным "окном" в ЗD-пространство, которое также определяет позицию "линз" виртуальной камеры. Для корректного отображения объекта Direct3D необходимо спроецировать трёхмерный объект на двумерную плоскость экрана монитора. Это достигается путём применения (перемножения) всех трёх матриц. Рассмотрим этот процесс более подробно. Единичный меш (который также может быть использован как меш объекта на экране) изначально размещается в так называемом пространстве модели (model, object, local space). Это лишь означает, что меш имеет свою собственную локальную систему координат, схожую с картезианской, которую использует Direct3D. Если ты отметил точку с координатой 2.0 на положительном луче оси X в локальной системе координат меша (mesh's model space), то в этому случае куда бы мы не переместили сам меш в ЗD-пространстве (которое также называется "мировое пространство" - world space), отмеченная точка будет иметь ту же самую координату 2.0 в локальной системе координат (в локальном пространстве - model space), т.к. само локальное пространство всегда перемещается вместе с мешем, к которому оно привязано (см. Рис.2).
Так вот. Direct3D использует мировую матрицу (world matrix) для перемещения меша из пространства модели (model space, она же локальная система координат) в пространство мира (world space). При этом меш размещается в одном пространстве вместе с другими мешами сцены (даже если каждый из них имеет своё собственное пространство модели). Сразу вслед за этим Direct3D применяет матрицу вида (view matrix) для трансформирования (как ты помнишь, матрицы применяются именно для трансформаций) меша в пространство камеры (camera space), чтобы таким образом он был расположен относительно текущего положения и ориентации виртуальной камеры. Далее применяется матрица проекции (projection matrix) для трансформирования меша в пространство проекции (projection space). На этом этапе вершины меша масштабируются (scaled) и вытягиваются для получения впечатления ЗD-перспективы. Наконец, меш обрезается (при необходимости) для размещения на экране и проектируется на пространство экрана (screen space) для рендеринга и показа на экране монитора. Очевидно, что на всех вышеперечисленных этапах "в фоновом режиме" проделывается уйма других всевозможных операций. К счастью, Direct3D берёт всю "чёрную" работу по обеспечению ЗD-рендеринга на себя.
Программеру остаётся лишь корректно настроить матрицы, что на самом деле сделать совсем несложно. В Главе 1.5 мы уже видели как настраивается матрица проекции. И, как мы уже говорили, будучи однажды настроенной, она не требует вмешательства в свою работу в дальнейшем. По крайней мере до тех пор, пока ты не решишь изменить текущую проекцию по каким-либо причинам.
Матрица вида (view matrix) вычисляется и настраивается один раз в каждом кадре. Это логично, ведь в большинстве динамичных игр вид изменяется в каждом кадре вместе с движением игрока по игровой сцене. О настройке матрицы вида мы поговорим чуть позднее в этой Главе.
Что касается мировой матрицы, то нам потребуется создать по одной такой для каждого объекта в игре. Это позволит редактировать и поднастраивать мировую матрицу каждого объекта независимо от других. Другими словами для каждого объекта игровой сцены необходимо вычислять отдельную мировую матрицу. Это вовсе не означает, что мировые матрицы всех объектов будут вычисляться в каждом кадре. Мировую матрицу того или иного объекта необходимо перерассчитывать вновь только при его перемещении. Таким образом, если в игровой сцене присутствует дерево, которое всегда неподвижно, его мировую матрицу необходимо вычислять лишь однажды - при его создании. С другой стороны, мировую матрицу постоянно движущегося объекта необходимо высчитывать заново в каждом кадре. Когда придёт время рендерить объекты на экране, первым делом настраиваем их мировые матрицы (или просто регистрируем их через интерфейсы Direct3D) ДО рендеринга их ЗD-мешей. Тем самым мы укажем Direct3D, где именно должны находиться объекты в мировом пространстве.

Теперь ты должен иметь чёткое представление о том, как работает мировая матрица применительно к игровым объектам и двум другим матрицам, используемым Direct3D. Тема матриц преобразований крайне обширна и мы не будем углубляться в неё далее. Вместо этого мы рассмотрим реализацию нашего базового объекта. Здесь ты как раз и увидишь, как мировая матрица создаётся и настраивается перед рендерингом.

Объекты сцены

Базовый объект (base object) это самый фундаментальный объект, который только можно использовать. Он содержит в себе весь базовый функционал, который является общим для объектов любых других типов, которые будут созданы на его основе. Все новые объекты "ветвятся" (derived) от базового объекта и потому полностью наследуют его общий для всех функционал. Раз уж мы назвали игровое ЗD-пространство "сценой", то и наш базовый объект мы назовём объект сцены - scene object. Объект сцены представляет собой самый базовый объект, который только может существовать в наших сценах.

Добавляем SceneObject.h (Проект Engine)

• Стартуй MSVC++ 2010 и открывай Решение GameProject01 (если не сделал это раньше).
• В "Обозревателе решений" главного окна MSVC++2010 щёлкни правой кнопкой мыши по папке (в терминологии Майкрософт это не папки, а фильтры!) "Заголовочные файлы" Проекта Engine.
• Во всплывающем меню Добавить->Создать элемент... (Add->New Item...)
• В появившемся окне выбери "Заголовочный файл (.h)" и в поле "Имя" введи "SceneObject.h".

Добавленный файл сразу откроется в правой части MSVC++2010.

• В только что созданном и открытом файле SceneObject.h набираем следующий код:

• Сохрани Решение (Файл->Сохранить все).

Исследуем код SceneObject.h

Класс SceneObject является самым большим их трёх типов объектов, которые мы рассмотрим в этой Главе. Так что если ты без труда разобрался в приведённом выше исходном коде, то оставшаяся часть Главы покажется тебе не сложнее прогулки в парке.
Для начала отметим, что класс SceneObject ветвится от класса BoundingVolume. Это позволяет нам "обнести" создаваемые на основе базового класса объекты набором из трёх ограничивающих объёмов (прямоугольник, сфера, эллипс) для самых разных целей, самая очевидная из которых - определение столкновений (collision detection). Помимо этого класс SceneObject имеет ставшие уже привычными конструктор, деструктор, функции Update и Render, без которых нам теперь никуда. Их работу мы обсудим чуть позднее в данной Главе.
Класс SceneObject содержит в себе множество различных функций, которые позволяют нам тонко настраивать (adjust) положение объекта в пространстве, а также его вращение и скорость. Помимо этого класс также имеет несколько служебных (utility) функций, которые дают возможность запрашивать различные матрицы, используемые объектами, а также различные свойства и константы, запрашиваемые у движка.

Добавляем SceneObject.cpp (Проект Engine)

В файле исходного кода SceneObject.cpp будут размещаться реализации функций, объявленных в SceneObject.h.

• В "Обозревателе решений" главного окна MSVC++2010 щёлкни правой кнопкой мыши по папке (в терминологии Майкрософт это не папки, а фильтры!) "Файлы исходного кода" Проекта Engine.
• Во всплывающем меню Добавить->Создать элемент...
• В появившемся окне выбери "Файл С++ (.cpp)" и в поле "Имя" введи "SceneObject.cpp".
• Жмём "Добавить".

Добавленный файл сразу откроется в правой части MSVC++2010.

• В только что созданном и открытом файле SceneObject.cpp набираем следующий код:

• Сохрани Решение (Файл->Сохранить все).

Исследуем код SceneObject.cpp

Обширный список переменных членов мы изучим в порядке их появления в исходном коде. Начнём с конструктора:

Несмотря на свой значительный размер, конструктор выполняет совсем немного действий. Его основное назначение в данном случае - очищать (обнулять) все необходимые переменные члены либо приводить их значения к значениям по умолчанию. Мы обсудим значение каждого переменного члена как только разговор зайдёт об их применении, чуть ниже в этой Главе. Сейчас мы остановимся на двух основных точках конструктора.
Как видим, конструктор принимает type в качестве первого вводного параметра. Он устанавливается путём вызова специальной функции SetType, экспонированной классом SceneObject. В самом начале SceneObject.h стоит определение:

Оно определяет тип объекта сцены. Каждый новый объект будет обязательно иметь свой тип, хранящийся в переменном члене m_type, и как раз передаваемый в конструкторе класса SceneObject. Позднее, когда ты будешь создавать свои собственные типы объектов сцены, то будешь определять их именно этим способом. Мы используем эти типы в качестве идентификаторов классов, для того, чтобы точно знать, с каким типом объектов сцены мы работаем в данный момент. Например у нас может быть связный список, хранящий указатели на все объекты игры. Для проверки того, что хранимые в нём указатели совместимы со всеми типами объектов, поддерживаемыми игрой, достаточно просто разместить в нём указатели всех дочерних классов класса SceneObject. Для того, чтобы воспользоваться всем функционалом базового объекта, необходимо передать указатель класса SceneObject в соответствующие дочерние классы объектов различных типов. Вот здесь-то идентификатор типа (type's identifier) и выходит на первый план. Если, к примеру, ты проверяешь один из своих объектов и он возвращает значение TYPE_PLAYER_OBJECT, то ты точно знаешь, что данный объект является объектом игрока (PlayerObject). Кроме того, в этом случае будет необходимо разместить указатель класса SceneObject внутри указателя PlayerObject для получения доступа ко всему функционалу класса PlayerObject. Если что-то из данного абзаца осталось непонятным, то мы ещё раз остановимся на этом при разработке различных типов объектов при создании игры. Второе, на что следует обратить внимание, это то, как конструктор обрабатывает меш объекта. Конструктор принимает имя файла с мешем (2-й параметр meshName), путь до меша (3-й параметр meshPath), а также статус использования меша (эксклюзивно/совместно с другими объектами; 4-й параметр sharedMesh). Имя файла меша и путь до него необходимы для загрузки меш-ресурса (mesh resource), Флаг sharedMesh указывает на то, использовать ли для загрузки меш-ресурса менеджер ресурсов или нет. Меш для совместного использования (shared mesh) загружается в память всего 1 раз а его инстансы запрашиваются различными объектами при необходимости. Меш для эксклюзивного использования (non-shared mesh) загружается специально для использования только с одним объектом. Из этого следует, что если создать 2 объекта и указать им использовать эксклюзивный (non-shared) меш, каждый из объектов загрузит в память по отдельной копии данного меш-ресурса.
Для статичных (static) мешей всегда необходимо выбирать разделяемые (shared) меш-ресурсы. В то же время для анимированных объектов это не всегда возможно. Анимированные объекты могут изменять свою форму и если два или более объекта ссылаются на один и тот же меш, то любые изменения хотя бы одного объекта моментально отразятся на их общем меше и, как следствие, на других объектах, которые его используют. Таким образом для анимированных мешей, как например меш объекта игрок (player object), необходимо использовать неразделяемые (non-shared) меши. К счастью, в типичной FPS-игре едва ли наберётся анимированных объектов, за исключением толпы объектов игроков. Поэтому неразделяемые (эксклюзивные) меши вряд ли доставят тебе массу хлопот.
В самом конце конструктора вызывается функция SetMesh, которая принимает последние 3 параметра, передаваемые в конструкторе. Она загружает меш и применяет при необходимости менеджер меш-ресурсов, необходимый для разделяемых (shared) меш-ресурсов. Загруженный меш уничтожается в деструкторе класса SceneObject при уничтожении самого объекта. Деструктор класса SceneObject совсем небольшой:

В нём уничтожается лишь меш. Если он был создан при участии меш-менеджера, то и удаляется он из него путём вызова специальной команды Remove.
Прежде чем мы двинемся к функции Update, рассмотрим те самые переменные члены, упомянутые вскользь чуть выше. Мы пропустим рассмотрение представленных матриц и позиционных векторов, т.к. мы также обсудили их чуть выше. Вместо этого рассмотрим векторы m_forward и m_right, которые представляют собой единичные векторы, не содержащие в себе ничего, кроме направления. Здесь всё просто: вектор m_forward применяется для указания передней стороны объекта, при его движении вперёд. Это то направление, куда "смотрит" объект. Вектор m_right применяется для указания направления, указывающего на правую сторону объекта. Если ты вытянешь свою левую руку перед собой, а правую - вправо (перпендикулярно левой), то так ты сымитируешь оба этих вектора. В этом случае левая рука будет выступать в качестве вектора m_forward, в то время как правая рука будет играть роль вектора m_right. Мы ввели эти 2 вектора для наших объектов для выполнения расчётов, основываясь на направлении, куда они повёрнуты. Если заметил, мы вводим оба этих вектора именно в конструкторе класса SceneObject. Значения по умолчанию выставлены так, что объект смотрит "лицом" параллельно положительному лучу оси Z, а вектор m_right указывает в направлении положительного луча оси X. При вращении объекта эти векторы само собой изменяются, в то же время они сохраняют своё положение относительно друг друга и образуют прямой угол. Чуть позднее ты увидишь, как эти векторы рассчитываются и применяются.

Теперь рассмотрим переменный член m_friction. Как ты знаешь, наши объекты существуют в ЗD-пространстве, а следовательно имеют ЗD-координаты своей позиции. При движении объекта в течение времени его позиция также изменяется. Иногда мы будем передвигать наши объекты "вручную", то есть вводить заданные координаты в 3D-пространства, указывающие, куда объект должен двигаться. В то же время, нам необходимо, чтобы движение объекта было в определённой степени автоматизировано. То есть просто указать определённое направление и скорость движения, что, как мы знаем, задаётся вектором скорости (velocity vector). Мы уже определили вектор скорости, назвав его m_velocity. В этом случае в каждом кадре объект будет применять движение, основанное на времени (time-based movement), для перемещения себя самого с заданной скоростью.
Бывают случаи, когда мы не хотим, чтобы наши объекты двигались бесконечно, а хотим, чтобы со временем их движение замедлялось и через какое-то время они сами полностью останавливались. Представь, что мы создали объект автомобиль и хотим задать ему скорость, чтобы он начал движение в направлении "вперёд" (собственно для этого и применяется вектор m_forward) на протяжении всего времени, пока игрок удерживает нажатой клавишу "вперёд" (обычно это стрелка вверх на клавиатуре). Когда игрок отпускает кнопку "вперёд", необходимо, чтобы автомобиль самостоятельно стал замедляться (снижать скорость), а спустя какое-то время полностью остановился бы. Как этого добиться? Конечно же путём применения коэффициента трения (friction coefficient), для чего и нужен переменный член m_friction. Коэффициент трения применяется к вектору скорости в каждом кадре для того, чтобы замедлить движение объекта. В течение всего времени, пока игрок удерживает нажатой кнопку "вперёд", сила скорости (velocity force) будет прибавляться к вектору скорости автомобиля, преодолевая силу трения. В противном случае, при отжатой кнопке "вперёд", коэффициент трения (величина которого обычно составляет 0,99) будет снижать скорость в каждом кадре, что даст эффект постепенного замедления движения автомобиля (см. Рис.3).

Осталось ещё немного переменных членов класса SceneObject, которые нам необходимо обсудить.
m_collisionStamp применяется для сохранения в нём самого последнего кадра, в котором было зафиксировано столкновение объекта. Мы уже обсуждали назначение "штампа столкновений" и даже применили его на практике, при разработке системы ввода. Сейчас нам на самом деле не нужны штампы столкновений (collision stamps). Но в последующих главах ты обязательно увидишь как он применяется для определения момента времени, когда объект столкнулся с чем-либо. И ещё 5 флагов, которые используются движком для различных задач по управлению объектом:

ФЛАГ	ОПИСАНИЕ
m_visible	При значении TRUE объект видим. Невидимые объекты просто не рендерятся.
m_enabled	При значении TRUE объект "включен" (существует). Отключенные объекты не обновляются.
m_ghost	При значении TRUE объект является "призраком". Объекты-призраки "физически" не могут столкнуться с чем-либо.
m_ignoreCollisions	При значении TRUE объект детектирует столкновения. При значении FALSE объект тем не менее сталкивается с другими объектами, но столкновения не регистрируются.
m_touchingGround	При значении TRUE объект коснулся "земной поверхности".

Во второй половине файла SceneObject.cpp размещены реализации служебных функций для установки (set) и запроса состояния (retrieve) каждого из этих флагов. Они используются при необходимости.

Обновление и рендеринг объектов

БОльшая часть вспомогательных функций, реализации которых размещены в SceneObject.cpp предельно просты. В то же время там есть две достаточно сложные функции, представляющие особый интерес. Функции Update и Render являются наиболее важными в классе SceneObject.

Функция Update

Её реализация выглядит так:

Функция Update принимает 2 вводных параметра:

• elapsed - время, прошедшее между выводом предыдущего и текущего кадра;
• addVelocity - флаг, указывающий функции, применять или нет к объекту его внутреннюю (internal) скорость. Если помнишь, мы говорили о том, что объект должен обладать вектором скорости, который позволит автоматизировать его движение в пространстве. По сути данный флаг включает (TRUE) и отключает (FALSE) автоматическое движение объекта.

Если необходимо регулировать скорость движения объекта "вручную", то во втором параметре достаточно просто указать значение FALSE. В этом случае объект будет двигаться только если явно задать его скорость. При выборе автоматического режима движения объекта (когда во втором параметре указано TRUE) мы указываем объекту начальную скорость движения и он двигается с учётом законов физики и коэффициента трения, конечно же. В функции Update стоит проверка данного флага на истинность:

В случае, когда второй параметр выставлен в TRUE, мы подсчитываем величину движения объекта в данном кадре, основываясь на переменной elapsed (временной интервал между предыдущим и текущим кадрами) и затем добавляем координаты вектора скорости к трансляции позиции объекта (object's translation). В расчётах также участвует коэффициент трения, применяемый в данном кадре на основе всё той же переменной elapsed. Скорость затем перемножается на коэффициент трения с целью её снижения до применения трансляции позиции объекта.

Вектор m_spin

Класс SceneObject также включает в себя ещё один вектор, о котором мы не упоминали ранее - m_spin. Данный вектор работает по тому же принципу, что и вектор скорости, разве что в этом случае он указывает, как быстро объект будет вращаться ("spin" - англ. вращаться, вертеться вокруг оси) по любой из своих осей. Мы будем применять данный вектор для создания например таких объектов, как разбросанное по карте оружие (weapon pickup), которое лежит на полу, вращаясь по оси Z в ожидании, когда его подберёт игрок. Как видно из исходного кода, вектор m_spin обрабатывается тем же способом, что и m_velocity:

Здесь первым делом применяем к скорости вращения коэффициент трения. Затем величина вращения применяется к объекту в текущем кадре, с учётом переменной elapsed. И уже затем скорость вращения добавляется к объекту.

Рассчитываем мировую матрицу

Как только трансляция позиции объекта и скорость его вращения были обновлены, рассчитываем мировую матрицу (world matrix) и матрицу вида (view matrix) объекта. Для расчёта мировой матрицы применяем функцию D3DXMatrixMultiply, которая просто перемножает две матрицы друг с другом. Таким нехитрым способом мы можем комбинировать эффекты обеих матриц преобразований. Так, для создания мировой матрицы необходимо скомбинировать (т.е. перемножить) матрицу трансляции позиции (translation matrix) и матрицу вращения (rotation matrix) объекта.
Матрица трансляции позиции объекта необходима для отслеживания положения объекта в ЗD-пространстве. Другими словами она является матричным представлением вектора трансляции позиции объекта (object's translation vector). Матрица вращения применяется для отслеживания вращения объекта (или его направление - facing) и представляет собой матричное представление вектора вращения. Скомбинировав эти две матрицы вместе, мы получаем в результате мировую матрицу для данного объекта, которая трансформирует соответствующим образом ЗD-меш объекта (если объект рендерится) из пространства модели (model, local space) в мировое пространство (world space), чтобы он отображался в корректной позиции и с корректным вращением в ЗD-пространстве.
Если для тебя осталось загадкой, откуда мы берём матрицы трансляции позиции и вращения, то сейчас мы поясним это. Наши объекты используют ЗD-векторы для постоянного отслеживания своего положения и вращения. В нашем случае мы назвали их m_translation и m_rotation соответственно. Ты перемещаешь объект путём изменения его вектора трансляции позиции (translation vector) и вращаешь его, изменяя вектор вращения. Для создания мировой матрицы необходимо сперва создать ещё две других, которые представляют данные, сохранённые в этих двух векторах. В этом случае, повторимся, матрица трансляции позиции (translation matrix) представляет собой трансляцию положения объекта в матрице, а матрица вращения (rotation matrix) - трансляцию вращения объекта в матрице. Всякий раз, при изменении векторов трансляции и вращения их соответствующие матрицы должны быть обновлены. В общем виде матрица трансляции создаётся так:

Функция D3DXMatrixTranslation экспонирована библиотекой D3DX и вызывается всякий раз при изменении вектора трансляции. Она специально разработана для создания матрицы трансляции позиции из ЗD-вектора. Последние 3 её параметра позволяют вводить координаты х, у, z, которые берутся прямо из вектора трансляции. Первый параметр - это указатель на матрицу, в которой будет сохранён результат операции после завершения работы функции.
Создание матрицы вращения чуть сложнее:

Функции D3DXMatrixRotationX, D3DXMatrixRotationY и D3DXMatrixRotationZ экспонированы библиотекой D3DX и вызываются всякий раз при изменении вектора вращения. Они применяются для создания матрицы вращения объекта вкруг его соответствующих осей X, Y и Z. Как только мы подготовили 3 отдельные матрицы вращения (по одной на каждую из осей) мы их комбинируем (= перемножаем) с помощью функции D3DXMatrixMultiply, причём, как видно из кода, делаем это 2 раза. В результате получаем матрицу вращения, в которой скомбинировано вращение объекта по каждой из трёх осей. Получив матрицы трансляции и вращения мы можем смело комбинировать их в одну мировую матрицу:

Рассчитываем матрицу вида (view matrix) объекта SceneObject

Но как создать матрицу вида (view matrix)? На самом деле это очень просто и выполняется всего одной строкой кода. Матрица вида представляет собой "инверсию" мировой матрицы и рассчитывается путём вызова функции D3DXMatrixInverse, также экспонированной библиотекой D3DX:

Функция D3DXMatrixInverse получает в качестве вводного параметра указатель на имеющуюся мировую матрицу, инвертирует её и сохраняет результат в заранее подготовленную матрицу вида (см. первый параметр). Для чего же необходимо рассчитывать матрицу вида для наших объектов? Когда мы обсуждали эту тему, мы говорили, что матрицу вида достаточно рассчитать лишь однажды в данной сцене, которая будет служить своеобразным "смотровым окном" в 3D-пространство игровой сцены. Тогда зачем её рассчитывать для каждого объекта сцены?
Ответ очень прост. Чуть позднее от класса SceneObject мы ответвим объект игрока (player object). Оснастив матрицей вида каждый создаваемый объект, мы получаем возможность видеть мир (игровую сцену) из перспективы любого из них, путём использования их матриц вида. Это очень здорово, особенно принимая во внимание тот факт, что игроки сами будут являться объектами сцены. Таким образом, мы можем видеть сцену "глазами" не только каждого игрока, но и любого объекта, даже упаковки с патронами. Данную возможность можно применить, например, для создания камер видеонаблюдения, закреплённых на стенах. С каждой из них можно получить вид, просто запросив матрицу вида. Круто, не правда ли?

Расчёт векторов m_forward и m_right

Мы уже почти полностью рассмотрели функцию Update. Как только мы рассчитали мировую матрицу и матрицу вида, следующий шаг - рассчитать векторы, указывающие вперёд (forward vector) и вправо (right vectror) объекта, что потребует сведений из школьного курса тригонометрии. В исходном коде наглядно представлено использование переменного члена m_rotation для расчёта векторов, указывающих вперёд и вправо, которые изменяются только в случае вращения объекта:

Мы не будем вдаваться в тригонометрическую теорию. Для этого достаточно открыть любой школьный учебник геометрии и пролистать разделы основных тригонометрических функций: синус (sin), косинус (cos), тангенс (tan). Как только векторы, указывающие вперёд и вправо рассчитаны, мы должны убедиться, что они представляют собой единичные (unit) векторы, применив к обоим функцию нормализации D3DXVec3Normalize, экспонированную библиотекой D3DX. В обоих случаях её применение даст на выходе вектор длиной ровно 1 единицу (unit). Другими словами, так векторы станут чисто направляющими (directional), т.е. без учёта их длины, что, собственно, и требуется.

Перемещаем ограничивающий объём (Moving Bounding Volume)

Финальный шаг - репозиционировать ограничивающий объём (bounding volume) объекта:


Как ты знаешь, класс SceneObject ветвится от класса BoundingVolume. Это значит, что наш объект наделён набором из трёх ограничивающих объёмов (куб, сфера, эллипсоид), встроенные в него путём наследования, и полностью заключающие в себе 3D-меш объекта. Ограничивающие объёмы, "обведённые" вокруг меша объекта, расположены в пространстве модели (model, local space). Но для того, чтобы быть уверенным в том, что ограничивающие объёмы корректно позиционированы по отношению к другим объектам игровой сцены (например, для целей определения столкновений), мы обязательно должны трансформировать их в мировое пространство.
Мы делаем это с помощью специальной функции RepositionBoundingVolume (экспонирована классом BoundingVolume), указав в качестве её единственного параметра матрицу трансляции (translation matrix). Здесь принцип тот же, что и при трансформировании в мировое пространство (world space) объектов сцены. Проблема здесь заключается в том, что мировая матрица также учитывает вращение объекта или, как в нашем случае, ограничивающих объёмов. На деле это означает, что ограничивающие объёмы будут вращаться вместе с мешами объектов, внутри которых они заключены, что крайне нежелательно, т.к. усложняет определение столкновений. Куда проще рассчитать столкновение ограничивающих объёмов, сориентированных по осям проекций, что означает их корректное позиционирование в мировом пространстве, вокруг меша объекта. При этом они не должны вращаться вместе с объектом! Другими словами, объект может свободно вращаться внутри своего ограничивающего объёма. Для достижения этой цели, вместо того, чтобы трансформировать ограничивающие объёмы путём применения мировой матрицы, мы будем трансформировать их матрицей трансляции (translation matrix; См. Рис.4).
Так вот. Для выполнения данного репозиционирования мы просто вызываем функцию RepositionBoundingVolume и передаём в её единственном параметре матрицу трансляции объекта. Это обеспечит "физическое" присутствие ограничивающего объёма именно в мировом пространстве (world space), а не в пространстве модели объекта (object's model space).

Вот и весь рассказ о функции Update. Настоятельно рекомендуем просмотреть документацию DirectX SDK, по теме векторов и матриц (всё на английском!).

Функция Render

Её реализация совсем небольшая по объёму и выглядит так:

Первое, на что ты наверняка обратил внимание, это тот факт, что функция Render принимает в качестве вводного параметра указатель на матрицу. По её имени нетрудно догадаться, что это указатель на мировую матрицу (world matrix). Причина того, что в качестве вводного параметра мы указываем мировую матрицу довольно проста - для большей гибкости. Несмотря на то, что класс SceneObject имеет свою собственную внутреннюю мировую матрицу, иногда бывает необходимость переопределить её и позиционировать объект, применив свою собственную мировую матрицу. В функции Render, кстати, даже есть проверка, не равна ли мировая матрица из вводного параметра NULL. Если она равна NULL, значит альтернативная (пользовательская) мировая матрица не передаётся в функцию, поэтому мы будем использовать внутреннюю мировую матрицу класса SceneObject. Установка мировой матрицы производится тем же способом, что и установка двух других матриц (вида и проекции), а именно путём применения функции SetTransform на объекте устройства Direct3D. Разница состоит лишь в том, что здесь в качестве первого параметра передаётся D3DTS_WORLD для информирования Direct3D о том, что мы хотим назначить мировую матрицу.
После установки мировой матрицы, следующий шаг - вызов функции Render на ЗD-меше объекта. Не забываем, что объект может вовсе не иметь меша. В этом случае локальная переменная m_mesh будет равна NULL. Если при это всё равно вызвать на меше функцию Render, это вызовет ошибку доступа (access violation error). Поэтому для предотвращения подобных ситуаций уже в самом начале реализации функции Render класса SceneObject мы ставим соответствующую проверку.

Уже в следующем подпункте мы рассмотрим класс AnimatedObject, первый из классов, ветвящихся от класса SceneObject.

Анимированные объекты

Анимированный объект - это обычный объект с мешем, который может быть анимирован. Базовый класс SceneObject не поддерживает анимирование меша. В этом нет ничего страшного, если вспомнить, что большинство игровых объектов зачастую не требуют анимирования. К тому же базовый класс SceneObject мы оснастили минимальным, самым общим функционалом.
Но раз уж оставшееся меньшинство объектов всё-таки включают в себя анимированные меши, ассоциированные с ними (например объект игрока), то мы ответвим от базового класса SceneObject новый класс AnimatedObject, который и будет специализироваться на воспроизведении анимаций меша объекта.

Добавляем AnimatedObject.h (Проект Engine)

• Стартуй MSVC++ 2010 и открывай Решение GameProject01 (если не сделал это раньше).
• В "Обозревателе решений" главного окна MSVC++2010 щёлкни правой кнопкой мыши по папке (в терминологии Майкрософт это не папки, а фильтры!) "Заголовочные файлы" Проекта Engine.
• Во всплывающем меню Добавить->Создать элемент... (Add->New Item...)
• В появившемся окне выбери "Заголовочный файл (.h)" и в поле "Имя" введи "AnimatedObject.h".

Добавленный файл сразу откроется в правой части MSVC++2010.

• В только что созданном и открытом файле AnimatedObject.h набираем следующий код:

• Сохрани Решение (Файл->Сохранить все).

Исследуем код AnimatedObject.h

Как и ожидалось, класс AbimatedObject ветвится от класса SceneObject. Вместе с тем, класс AnimatedObject также наследуется от интерфейса ID3DXAnimationCallbackHandler, экспонированного библиотекой D3DX. Данный интерфейс содержит в себе всего одну функцию HandleCallback, которая, как видно из её названия, является функцией обратного вызова и которую нам необходимо переопределить (см. второй параметр объявления класса AnimatedObject). Забегая вперёд, скажем, что в реализации класса AnimatedObject, которую мы скоро разместим в AnimatedObject.cpp, данная функция не делает ровным счётом ничего. Нам и не требуется использовать её в данном классе, но нам необходимо сделать её виртуальной (virtual) для того, чтобы она могла быть переопределена другими классами, которые мы чуть позднее ответвим от класса AnimatedObject (например, класс PlayerObject). Далее мы обязательно разберём действие функции HandleCallback, но сейчас всё-таки вернёмся к разбору объявления класса AnimatedObject.
Очередная точка интереса - это конструктор класса, где мы применяем идентификатор типа TYPE_ANIMATED_OBJECT. Это новый идентификатор типа, определённый в самом начале AnimatedObject.h и используемый по умолчанию всякий раз при создании новых инстансов (экземпляров) класса AnimatedObject.
Другой интересный момент заключается в том, что класс AnimatedObject имеет собственную функцию Update, переопределяющую (override) ту, что представлена в родительском классе SceneObject.
Чуть ниже идёт функция PlayAnimation, которая применяется для проигрывания одной из анимаций, ассоциированных с мешем, назначенным объекту.

Добавляем AnimatedObject.cpp (Проект Engine)

В файле исходного кода AnimatedObject.cpp будут размещаться реализации функций, объявленных в AnimatedObject.h.

• В "Обозревателе решений" главного окна MSVC++2010 щёлкни правой кнопкой мыши по папке (в терминологии Майкрософт это не папки, а фильтры!) "Файлы исходного кода" Проекта Engine.
• Во всплывающем меню Добавить->Создать элемент...
• В появившемся окне выбери "Файл С++ (.cpp)" и в поле "Имя" введи "AnimatedObject.cpp".
• Жмём "Добавить".

Добавленный файл сразу откроется в правой части MSVC++2010.

• В только что созданном и открытом файле AnimatedObject.cpp набираем следующий код:

• Сохрани Решение (Файл->Сохранить все).

Исследуем код AnimatedObject.cpp

Начнём с конструктора класса AnimateObject:

При вызове конструктора класса AnimatedObject, первым делом вызывается конструктор базового класса SceneObject с передачей ему необходимых параметров. Ты должно быть заметил, как передаётся идентификатор типа объекта (object's type identifier), который будет установлен базовым классом SceneObject. Таким образом, всякий раз, когда объект запрашивает свой тип, он не получит в ответ идентификатор типа базового объекта TYPE_SCENE_OBJECT (прописан в начале SceneObject.h). Вместо этого он вернёт TYPE_ANIMATED_OBJECT (прописан в начале AnimatedObject.h) или любой другой идентификатор, который изначально был передан в конструктор класса AnimatedObject. Также заметим, что в последнем параметре стоит значение FALSE, что означает, что мы не хотим использовать меш совместно с другими объектами. Как только конструктор базового класса SceneObject закончил свою работу, мы знаем, что меш был загружен, поэтому теперь мы можем смело начинать выполнение конструктора класса AnimatedObject. В случае, когда меш загружен (напомним, что объект вовсе не обязательно должен иметь меш), первым делом необходимо клонировать (создать копию) его контроллера анимации. Контроллер анимации меша является сердцем класса AnimatedObject и его наиболее важным компонентом. Чтобы сделать копию интерфейса контроллера анимации (ID3DXAnimationController) мы просто вызываем функцию CloneAnimationController на меше. Её реализацию мы разместили чуть ранее в Mesh.срр. Она предельно проста и всё, что она делает - это вызывает функцию CloneAnimationController на интерфейсе ID3DXAnimationController, определённом в классе Mesh. Ведь контроллер анимации загружается в момент создания меша. Интерфейс ID3DXAnimationController:

• применяется для управления анимациями, присвоенными мешу;
• ответственен за соответствие данных анимации фреймам меша, чтобы таким образом корректные трансформации применялись к нужным фреймам;
• обладает возможностью комбинировать несколько анимаций, осуществляя плавные переходы между ними.

Как только у нас есть валидный контроллер анимации, нам необходимо первым делом установить скорость первого и второго треков. Установка скорости первого трека в 1.0 даёт проигрывание всех анимаций на нём на полной скорости. Чуть позднее мы рассмотрим этот момент более подробно. Ты увидишь как контроллер анимации применяется "на лету", как и те две переменные, которые мы очистили в конструкторе.

Функция Update

Функция Update класса AnimatedObject просто переопределяет оную класса SceneObject. Раз уж мы хотим, чтобы наш AnimatedObject вцелом вёл себя точно так же как и все другие объекты, мы обязательно должны сперва сделать вызов функции Update класса SceneObject. И только после этого свои операции выполняет функция Update класса AnimatedObject. Здесь мы первым делом проверяем наличие валидного контроллера анимации. Если у объекта нет даже меша, то контроллера анимации нет и подавно. Если контроллер анимации присутствует, мы продолжаем его обновление путём вызова его функции AdvanceTime, которая принимает 2 вводных параметра:

• количество времени опережения контроллера анимации (в секундах);
• указатель на интерфейс функции обратного вызова пользовательской анимации (user-defined animation call-back handler interface).

В нашем случае в первом параметре выставляем заранее подсчитанную переменную elapsed (которая передаётся в качестве вводного параметра функции Update). Во втором параметре передаём указатель this, чтобы использовать данный класс в качестве интерфейса функции обратного вызова пользовательской анимации. Если помнишь, мы ветвим наш класс AnimatedObject в том числе от интерфейса ID3DXAnimationCallbackHandler (см. AnimatedObject.h). Поэтому мы можем переопределить функцию HandleCallback, встроенную в данный интерфейс. Функция AdvanceTime ищет указатель на пользовательский инстанс интерфейса ID3DXAnimationCallbackHandler, который представляет собой то, во что мы превратили класс AnimatedObject, ответвив его от интерфейса ID3DXAnimationCallbackHandler.
Когда мы увидим класс AnimatedObject в деле (при создании игры), ты увидишь, как в анимацию можно добавлять так называемые ключи анимации (animation keys). Ключ может быть установлен в качестве триггера (переключателя), действующего в определённое время при проигрывании анимации. Так вот, всякий раз при вызове функции AdvanceTime, контроллер анимации проверяет, задействованы ли в данной анимации пользовательские ключи. Если да, то контроллер анимации вызывает функцию HandleCallback, чтобы таким образом обработать данный ключ. Ты узнаешь об этом более подробно чуть позднее, когда мы будем применять ключи анимации для реализации шагов (footsteps) в анимации бега объекта игрока.
После обновления контроллера анимации осталось выполнить ещё 2 важных шага.
Во-первых необходимо инкрементировать (увеличить) переменный член m_currentTime на величину elapsed. Это позволит нам отслеживать течение глобального времени анимации (global animation time). Также мы будем применять данный переменный член в различных временных операциях функции PlayAnimation, которую мы рассмотрим уже очень скоро. Последний шаг - обновление меша объекта, путём вызова не нём функции Update класса Mesh.

Функция PlayAnimation

• Самая сложная и важная функция класса AnimatedObject.

Как всегда, начинаем её рассмотрение с изучения вводных параметров:

Первый параметр - идентификатор анимации, которую хотим воспроизвести. Контроллер анимации ссылается на ту или иную анимацию объекта, применяя её уникальный порядковый номер, начинающийся с 0. То есть первой анимации объекта соответствует порядковый номер 0, второй - 1 и т.д. Поэтому, чтобы, например, воспроизвести анимацию №4, в данном параметре передаём 3.

Второй параметр представляет собой время перехода анимации (animation transition time). Анимированный меш всегда имеет анимацию, проигрываемую в данный момент (например, назначенную по умолчанию). Причём даже если анимация незациклена и закончилась, она всё равно рассматривается как текущая анимация. Это означает, что когда ты указываешь контроллеру анимации сменить текущую анимацию на другую, он вынужден остановить проигрывание текущей анимации и сразу начать воспроизведение новой. Проблема здесь заключается в том, что если резко прервать одну анимацию и начать другую, меш совершит резкий скачок из одного положения в другое. Ты наверняка видел подобный эффект в компьютерных играх. Время перехода как раз и нужно для того, чтобы указать контроллеру анимации необходимое время (в секундах) для совершения перехода от одной анимации к другой. Во время перехода контроллер анимации смешивает (blend) обе анимации вместе, при этом постепенно снижая "вес" текущей анимации и прибавляя оный новой. Примерно тот же принцип лежит в "сведении" двух музыкальных треков диск-жокеем.
Последний параметр - простой флаг, сигнализирующий должна ли анимация быть зацикленной (всё время повторяться) либо её необходимо воспроизвести всего 1 раз. При установке данного флага в TRUE, выбранная анимация будет повторяться снова и снова до тех пор, пока контроллер анимации не получит других команд от пользователя или игры. Зацикленная анимация великолепна для анимаций ходьбы (walk) или "ничегонеделанья" (idle; в терминологии Майкрософт - "состояние простоя"). При установке в FALSE анимация будет воспроизведена всего 1 раз. При этом по достижении своего последнего кадра она остановится и меш будет выглядеть замершим на месте. Такие анимации часто применяются для анимирования смерти игрока, когда требуется, чтобы объект игрока упал замертво и больше не двигался.

Оказавшись внутри тела функции, первым делом снова проверяем наличие валидного контроллера анимации. Если его нет, функция досрочно завершает своё выполнение:

Даже при наличии валидного контроллера анимации мы снова проверяем, что переменная transitionTime больше 0. Делается это потому, что функции библиотеки D3DX большей частью "не любят", когда transitionTime вдруг оказывается равным 0 или меньше его, "вылетая" из приложения с трудноуловимыми ошибками. Причины данного "эффекта" неизвестны, документация DirectX SDK не сообщает об этом ничего. Поэтому, для избежания неприятных ситуаций, мы просто установим начальное значение transitionTime в 0.000001f, которое настолько близко к нолю, что этим можно пренебречь. Далее выбираем, на каком из треков будет проигрываться новая анимация. Контроллер анимации использует треки (tracks) для проигрывания различных анимаций. Например, ты можешь воспроизводить анимацию WALK (ходьба) на первом треке, а анимацию SHOOT (выстрел) - на втором. Контроллер анимации смешивает (blend) обе этих анимации, в результате чего они воспроизводятся одновременно (игрок бежит и стреляет; в первых частях игр Resident Evil игрок мог стрелять только когда стоит на месте). Мы используем переменный член m_currentTrack для определения, на каком из треков проигрывается текущая анимация. Он необходим для определения, какой из треков свободен и готов к воспроизведению на нём новой анимации. Если текущая анимация воспроизводится на первом треке, то для новой анимации мы задействуем второй (в том числе для осуществления плавного перехода). И наоборот: если анимация воспроизводится на втором треке, то для новой мы задействуем первый.
Как только мы определили, на каком из треков будет воспроизведена новая анимация, сразу запрашиваем указатель на анимацию, которую хотим воспроизвести. Контроллер анимации рассматривает одну полную анимацию как анимационный набор (animation set). Для манипулирования анимационными наборами мы применим интерфейс с говорящим названием ID3DXAnimationSet. Получаем доступ к анимационному набору, который хотим воспроизвести, путём вызова функции GetAnimationSet, экспонированной контроллером анимации. Здесь в первом параметре передаём идентификатор анимации, которую будем воспроизводить (он берётся из первого вводного параметра функции PlayAnimation). Во втором стоит указатель на текущую анимацию, возвращаемый при завершении работы функции GetAnimationSet. Следующий шаг - назначение новой анимации треку, на котором она будет воспроизводиться:

Это делается путём вызова функции SetTrackAnimationSet на контроллере анимации. В качестве параметров здесь передаётся идентификатор трека, на котором должна быть воспроизведена анимация (newTrack), а также указатель на саму анимацию (as).
Сразу после этого очищаем все события (events) на обоих треках путём поочерёдного вызова на каждом из них функции UnkeyAllTrackEvents. Здесь в качестве единственного параметра указывается идентификатор очищаемого трека. Анимация работает путём назначения на треках т.н. событий, основанных на времени (time-based events), которые контролируют, как треки будут обрабатываться, а также когда именно в них необходимо вносить изменения. В таблице ниже представлены несколько наиболее часто встречающихся событий (ивентов), устанавливаемых на треки анимации:

EVENT	ОПИСАНИЕ
KeyTrackEnable	Событие, включающее или отключающее трек в данный момент времени.
KeyTrackSpeed	Событие, изменяющее скорость воспроизведения анимации на треке в данный момент времени.
KeyTrackWeight	Событие, изменяющее т.н. "вес смешивания" (blending weight) анимации на треке в данный момент времени.

На данной стадии у нас всё готово для начала установки событий на обоих треках, чтобы контроллер анимации мог сменить текущую анимацию на новую. Как именно должны быть установлены события зависит лишь от одного фактора - будет ли анимация зациклена или воспроизведена лишь однажды. Другими словами, будет ли анимация на данном треке воспроизводиться снова и снова, либо она будет воспроизведена всего 1 раз и меш объекта "замрёт" на последнем кадре анимации. Далее в исходном коде как раз рассматриваются оба случая, обрамлённые условным переходом if. Первыми предопределены события для зацикленной (повторяющейся) анимации:


Если новая анимация будет зацикленной (looped), тогда мы хотим плавно перейти от текущей анимации к новой. Для того, чтобы добиться этого, мы постепенно уменьшаем "вес смешивания" (blending weigth) трека с текущей анимацией, и одновременно увеличиваем "вес смешивания" трека с новой анимацией. В коде это выглядит как установка события веса (weight event) путём вызова функции KeyTrackWeight на каждом из треков. Здесь в первом параметре указываем идентификатор трека, на котором хотим установить данное событие. Во втором - передаём целевой вес смешивания, который хотим установить на данном треке. В нашем случае для старого трека устанавливаем 0.0, а для нового 1.0 (что соответствует 100%). Третий параметр указывает, когда мы хотим произвести переход. В четвёртом параметре указывается как долго будет длиться переход (transitionTime). В нашем случае в качестве начала перехода указана переменная m_currentTime, что означает начать переход немедленно. Время перехода обозначено переменной transitionTime, передаваемой в качестве вводного параметра функции PlayAnimation. Все 4 строки внутри цикла if в совокупности означают, что в течение периода времени обозначенного в пределах от m_currentTrack до m_currentTrack+transitionTime вес старого трека изменится с 1.0 до 0.0, а нового - с 0.0 до 1.0. Последний параметр контролирует, каким образом будет происходить переход и может принимать всего 2 значения (См. Рис. 5):

• D3DXTRANSITION_LINEAR,
• D3DXTRANSITION_EASEINEASEOUT.

Для случая зацикленной анимации, мы выбрали значение D3DXTRANSITION_LINEAR для равномерного изменения значений стечением времени.
Помимо этого, мы активируем (включаем) трек с новой анимацией путём применения функции SetTrackEnable, в параметрах которой указаны идентификатор трека и флаг булева типа (TRUE - включить трек, FALSE - выключить). В нашем случае значение флага - TRUE. Данная функция немедленно включает трек.
Вместе с тем, нам необходимо отключить трек с текущей анимацией. Но мы не можем сделать это немедленно, т.к. необходимо "выждать" снижение его веса смешивания с 1.0 до 0.0. В противном случае во время анимации будет заметен "скачок", моментальный переход меша объекта от одного состояния к другому. Для этого мы снова применяем функцию SetTrackEnable, но уже с флагом FALSE во втором параметре. Так как отключаемому треку не требуется переход, то достаточно просто указать, когда мы хотим отключить трек. Мы знаем длительность перехода (transitionTime). Значит нам нужно подгадать время так, чтобы отключение текущего трека произошло сразу по завершению перехода. Мы можем подсчитать это время путём простого сложения значений переменных m_currentTime и transitionTime. Это и будет временем отключения трека.

Смотрим вторую часть условного перехода if для случая незацикленной анимации, воспроизводимой всего 1 раз:

В случае, когда в последнем параметре функции PlayAnimation стоит значение FALSE, нам необходимо подредактировать трек с новой анимацией таким образом, чтобы он был воспроизведён только 1 раз. Вместо того, чтобы плавно переходить к новому треку, мы просто остановим текущий трек и незамедлительно начнём воспроизведение другого. Это делается путём последовательного вызова функций SetTrackEnable и SetTrackWeight на текущем и новом треках. Для текущего трека в функции SetTrackEnable во втором параметре указываем FALSE, а в функции SetTrackWeight - 0.0f. Для нового трека в функции SetTrackEnable во втором параметре указываем TRUE, а в функции SetTrackWeight - 1.0f. Следующий шаг - вернуть позицию трека на начальную позицию. Никто не даст гарантию, что, в силу определённых обстоятельств, новая анимация будет воспроизведена с самого начала. Поэтому мы сделаем это принудительно, чтобы увидеть нужную анимацию от начала и до конца. В зацикленной анимации это, в принципе, не проблема. В незацикленной анимации нам необходимо добавить на трек событие (ключ), автоматически отключающее (disabled) данный трек по его окончании. Делается это точно таким же способом, что и для зацикленной анимации. Единственная разница, что здесь мы будем вызывать на анимации функцию GetPeriod для определения, как долго она длится. Возвращённое данной функцией значение скажет нам, сколько времени необходимо ждать, прежде чем отключить трек.
В самом конце функции PlayAnimation мы освобождаем (release) анимацию, так как она больше не нужна:

Последняя команда делает так, чтобы при следующем вызове функции PlayAnimation треки вновь сменились.

Объект-спаунер (Spawner object)

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

Добавляем SpawnerObject.h (Проект Engine)

• Стартуй MSVC++ 2010 и открывай Решение GameProject01 (если не сделал это раньше).
• В "Обозревателе решений" главного окна MSVC++2010 щёлкни правой кнопкой мыши по папке (в терминологии Майкрософт это не папки, а фильтры!) "Заголовочные файлы" Проекта Engine.
• Во всплывающем меню Добавить->Создать элемент... (Add->New Item...)
• В появившемся окне выбери "Заголовочный файл (.h)" и в поле "Имя" введи "SpawnerObject.h".

Добавленный файл сразу откроется в правой части MSVC++2010.

• В только что созданном и открытом файле SceneObject.h набираем следующий код:

• Сохрани Решение (Файл->Сохранить все).

Исследуем код SpawnerObject.h

В самом начале мы определили новый тип объекта (TYPE_SPAWNER_OBJЕСТ), который по умолчанию передаётся в конструкторе класса SpawnerObject. Мы также переопределили функции Update и CollisionOccured класса SceneObject, которые мы вскоре рассмотрим более подробно.
Ты, должно быть, также заметил, что объекты-спавнеры управляются скриптами. Это означает, что мы будем создавать скрипты для управления нашими спавнер-объектами. Все параметры, включая тип "выбрасываемого" на сцену объекта, периодичности, с которой он выбрасывается, звук воспроизводимый при подборе игроком выброшенного объекта, - будет контролироваться скриптом. Определение класса SpawnerObject совсем невелико, поэтому сразу перейдём к его реализации.

Добавляем SpawnerObject.cpp (Проект Engine)

В файле исходного кода SpawnerObject.cpp будут размещаться реализации функций, объявленных в SpawnerObject.h.

• В "Обозревателе решений" главного окна MSVC++2010 щёлкни правой кнопкой мыши по папке (в терминологии Майкрософт это не папки, а фильтры!) "Файлы исходного кода" Проекта Engine.
• Во всплывающем меню Добавить->Создать элемент...
• В появившемся окне выбери "Файл С++ (.cpp)" и в поле "Имя" введи "SpawnerObject.cpp".
• Жмём "Добавить".

Добавленный файл сразу откроется в правой части MSVC++2010.

• В только что созданном и открытом файле SpawnerObject.cpp набираем следующий код:

• Сохрани Решение (Файл->Сохранить все).

Исследуем код SpawnerObject.cpp

Конструктор класса SpawnerObject может показаться сложным и запутанным. Но всё, чем он занимается, это подготавливает объект-спавнер, исходя из настроек по умолчанию и настроек скрипта, назначенного ему. В нашем случае объект-спаунер появляется в качестве "призрака", что означает, что он будет регистрировать столкновения с ним, но физически не будет блокировать дальнейшее передвижение сталкиваемого с ним объекта, т.е. объект Игрок сможет свободно проходить сквозь него.
Для того, чтобы загрузить спавнер-объект с настройками его скрипта, в начале этот самый скрипт необходимо загрузить, основываясь на его (скрипта) имени и полном пути до него, передаваемые в конструктор. После этого мы получаем доступ к различным данным скрипта, необходимым для подготовки к работе спаунер-объекта. Например, к его частоте обновления (т.е. временной "задержки" перед повторным появлением) или звуку, проигрываемому при подборе игроком спаун-объекта. В исходном коде видно, что при наличии "звука подбора" мы загружаем его и создаём 3D-аудиопуть для воспроизведения звуков на нём:

Таким образом мы позиционируем звук в 3D-пространстве и другие игроки даже могут слышать "звуки подбора" (collection sounds) других игроков.
Следующий шаг в конструкторе - загрузка 3D-меша объекта, который будет спауниться (патроны, аптечка и т.д.). Данный меш будет использоваться объектом-спаунером для показа игроком объекта, который будет спауниться. Сперва мы загружаем скрипт объекта, который будет спауниться (который, в свою очередь, определён скриптом объект-спаунера), затем мы назначаем в качестве меша объекта-спаунера меш объекта, который будет спауниться:

Далее просто придаём спавн-объекту медленное вращение вокруг его оси Y:

Наконец мы просто задаём спаунер-объекту ограничивающие объёмы, взятые из скрипта меша. Они применяются для определения столкновения объекта игрока со спаунер-объектом и срабатывания "подбора" спаун-объекта игроком. Деструктор класса SpawnerObject, как всегда, уничтожает всё, что мы загрузили в конструкторе и освобождает память. Там всё ясно из исходного кода.

Функция Update

• Является переопределением функции Update класса SceneObject. Вот её реализация:

Как и любой другой анимированный объект, даже несмотря на то, что по сути спаунер-объект является объектом сцены, он должен быть обновлён. Для того, чтобы убедиться в том, что наш спавнер-объект ведёт себя именно как объект сцены, мы сперва вызываем функцию Update базового класса SceneObject. Только после завершения её работы мы вызываем функцию Update дочернего класса SpawnerObject.
Первым делом проверяем, видим ли объект. Если объект не видим, значит он подобран игроком. Когда игрок сталкивается (collide) с объектом-спаунером, мы устанавливаем флаг видимости в FALSE, после чего движок перестаёт его рендерить. Спустя некоторое время он снова появится на том же месте. При респауне (повторном появлении) флаг видимости вновь выставляется в TRUE и спаун-объект становится видим. Таким образом, всякий раз, когда флаг видимости спаунер-объекта установлен в FALSE, мы знаем, что он ждёт респауна и надо просто подсчитать, спустя какое время он должен произойти. Когда объект подбора объекта-спаунера подобран, он появится вновь, спустя определённое количество времени, указанное в переменной m_frequency. Для данной проверки мы используем простой таймер, который обновляет переменную m_spawnTimer, принимая во внимание истёкшее время. Когда переменная m_spawnTimer достигнет значения m_frequency, то это будет значить, что время отсрочки подошло к концу и можно респаунить объект. Это также повлечёт за собой восстановление видимости объекта и обнуление таймера.
Последний шаг в функции Update - обновление ЗD-аудиопути спаунер-объекта. Для этого достаточно проверить, что текущие положение и скорость аудиопути совпадают с оными спаунер-объекта. Обычно спаунер-объект размещается на карте и никогда не двигается. Но, обновляя его подобным образом мы сохраняем возможность перемещать его в ЗD-пространстве, что называется "на лету". Это делается на всякий случай. Например, когда творческий замысел требует, чтобы спаунер-объект был размещён в кузове движущегося грузовика.

Функция CollisionOccured

• Экспонирована классом SceneObject.

До этого мы не видели её в деле, но тем не менее переопределили в классе SpawnerObject для того, чтобы дать ей реализацию, специфичную для спаунер-объекта:

В первую очередь вызывается функция CollisionOccurred базового класса SceneObject для регистрации штампа столкновения (collisionStamp). Затем мы просто проверяем, объект какого тип столкнулся с нашим спаунер-объектом. Так как мы знаем, что ни один из созданных ранее объектов не обладает способностью подбирать объекты из спаунер-объектов, то мы можем безопасно завершить работу функции при столкновении спаунер-объекта с любым из них. Мы определяем тип объекта, столкнувшегося со спаунер-объектом, путём простой проверки типа объекта. Если объект, который столкнулся со спавнер-объектом не относится ни к одному из ранее созданных стандартных типов объектов, то значит тип этого объекта является пользовательским (user-defined), например объект игрока (PLAYER_OBJECT). Исходя из этого, сделаем предположение, что объекты пользовательских типов могут подбирать объекты, выбрасываемые спаунер-объектами.

Как только мы определили, что столкнулись с валидным объектом, переходим непосредственно к "подбору" объекта, выброшенному спаунер-объектом. Здесь мы первым делом устанавливаем флаг видимости спаунер-объекта в FALSE, а флаг игнорирования столкновений (ignore collisions) - в TRUE. Это предотвратит спаунер-объект от регистрации последующих столкновений при ожидании респауна объекта подбора. Далее воспроизводим звук подбора (collection sound), чтобы таким образом игрок получил аудиооповещение о том, что он что-то подобрал.

Интегрируем систему игровых объектов в движок

Принцип тот же, что и при интегрировании других систем.

Изменения в SceneObject.срр (Проект Engine)

• Добавь инструкцию #include "Engine.h" в самом начале файла SceneObject.срр (проверь её наличие).

Изменения в AnimatedObject.cpp (Проект Engine)

• Добавь инструкцию #include "Engine.h" в самом начале файла AnimatedObject.cpp (проверь её наличие).

Изменения в SpawnerObject.cpp (Проект Engine)

• Добавь инструкцию #include "Engine.h" в самом начале файла SpawnerObject.cpp (проверь её наличие).

Изменения в Engine.h (Проект Engine)

• Добавь строки

сразу после строки #include "Mesh.h":

• Добавь новый член

в структуру EngineSetup, сразу после строки
void (*CreateMaterialResource)( Material **resource, char *name, char *path );:

Он представляет собой путь, по которому движок будет искать все скрипты спаунер-объекта. Мы можем, например, сохранять все наши скрипты спаунер-объектов в папке Assets и затем просто указать движку искать их именно там. Затем мы ссылаемся на скрипт спаунер-объекта по его имени, зная что движок дополнит это самое имя корректным путём (path) до файла скрипта. Основной причиной того, что мы поступаем именно так, является то обстоятельство, что спаунер-объекты - это объекты, специфичные для приложения. Движку абсолютно неведомо, что за спаунер-объекты мы создадим и где мы их будем хранить. Поэтому нам необходимо "объяснить" движку об их существовании заранее, чтобы они затем могли быть загружены им по требованию (on demand), без дополнительных команд от пользователя. Чуть позднее мы рассмотрим эту тему более детально.

Изменения в State.h (Проект Engine)

• Добавь новый член

в структуру ViewerSetup:

Он используется в каждом кадре для информирования движка о том, какой из объектов используется для просмотра игровой сцены. Когда движок вызывает твою реализацию функции RequestViewer (от нашего ответвлённого класса State), мы можем указать, какой из объектов в данный момент использовать для просмотра игровой сцены (обычно это объект игрока).

Изменения в Engine.срр (Проект Engine)

• Добавь строки

в реализацию функции Run класса Engine, сразу после строки запроса вьюера if( m_currentState != NULL ) m_currentState->RequestViewer( &viewer);:

При наличии валидного вьюера нам необходимо выполнить два шага. Сперва мы устанавливаем матрицу трансформации вида (view transformation matrix) для данного вьюера, чтобы Direct3D мог отображать сцену "из глаз" объекта просмотра. Дальше обновляем объект ЗD-слушателя (3D sound listener) путём вызова функции UpdateListener на нашей звуковой системе движка. В функцию передаётся несколько уточняющих параметров об объекте слушателя (который одновременно является объектом просмотра сцены). Таким образом мы размещаем виртуальный микрофон как раз в том месте ЗD-пространства, где расположен объект просмотра сцены. Мы используем вектор объекта, направленный вперёд (object's forward vector), чтобы микрофон был ориентирован в нужном направлении.

Тестовая перекомпиляция Engine.lib

Для проверки работосопособности исходного кода, добавленного в этой Главе, перекомпилируем исходный код Проекта Engine:

• В Обозревателе решений щёлкаем правой кнопкой мыши по значку Проекта Engine. Во всплывающем меню выбираем "Перестроить".

По окончании компиляции в панели "Вывод" (в нижней части главного окна IDE) будет представлен отчёт (лог) об успешной (либо неуспешной) компиляции. В нашем случае компиляция прошла успешно.
Полученная в результате компиляции двоичная библиотека Engine.lib перезаписывается по тому же пути (там же её будет искать тестовое приложение из Проекта Test).

Модифицируем тестовое приложение (Проект Test)

Наконец, после изучения столь сложной Главы, наши старания будут вознаграждены наиболее впечатляющим визуальным примером. Впервые с начала данного курса мы воспроизведём на экране нечто более красивое, чем обычный текст. В Главе 1.6 для проверки работоспособности движка в нашем Решении GameProject01 мы создали второй Проект Test, после компиляции которого получили исполняемое приложение (файл .ЕХЕ), показывающее окно. В последующих главах его функционал изменялся. Применив полученные в текущей Главе знания на практике, снова дополним исходный код тестового приложения, оснастив его новым "функционалом". Если по каким-то причинам Проект Test отсутствует в Решении GameProject01, создай его, следуя инструкциям Главы 1.6 . OK, приступаем.

• Открой для редактирования файл исходного кода Main.срр (Проект Test) и замени содержащийся в нём код на следующий:

И вновь в нашем Проекте Test всего 1 файл Main.срр, который содержит весь исходный код тестового приложения. Перед нами готовая система просмотра объектов трёх различных видов (в виде стейта) в действии.

Перекомпилируем Проект Test

Напомним, что для успешной компиляции библиотека Engine должна быть добавлена в Проект Test (см. Главу 1.6). Компилируем Проект Test:

• В Обозревателе решений щёлкни правой кнопкой мыши по названию Проекта Test.
• Во всплывающем контекстном меню выбираем: Перестроить.

Компиляция завершилась успешно. Итоговый исполняемый двоичный файл (Test.exe) расположен на жёстком диске ПК в той же директории, что и библиотека движка (Engine.lib).
В нашем случае, это: C:\Users\<Имя пользователя>\Documents\Visual Studio 2010\Projects\GameProject01\Debug. (В разных ОС путь к файлу может отличаться от представленного).

Готовим ассеты (игровые ресурсы)

Полученная программа сразу после запуска будет автоматически искать в подкаталоге Assets следующие файлы:

• Файл с мешем Marine.х (файл меша с фигуркой пехотинца);
• Файл текстуры пехотинца Maine.dds;
• Файл скрипта текстуры пехотинца Marine.dds.txt;
• Файл скрипта спаун-объекта Spawner.txt, который в свою очередь указывает на файл меша Gun.x, размещённый в подкаталоге Gun.

Если хотя бы одного файла там не окажется, приложение аварийно завершит свою работу, выдав сообщение об ошибке. Это нормально, т.к. проверку на присутствие запрашиваемого файла в указанном каталоге никто не писал. Создание 3D-объектов - тема отдельной Главы. Поэтому в данный момент архив со всеми необходимыми файлами забираем здесь. Напомним, что файлы ресурсов должны быть расположены в подкаталоге Assets каталога содержащего исполняемый файл скомпилированного приложения Test.exe.

• Открой скачанный архив к данной главе из распакуй из него подкаталог Assets, разместив его по пути C:\Users\<Имя пользователя>\Documents\Visual Studio 2010\Projects\GameProject01\Debug .
• Найди и запусти скомпилированное приложение Test.exe.

В открывшемся окне появятся модель пехотинца и автомата (выброшенный объект спаунер-объекта, вращающийся на одном месте) на чёрном фоне. Нажимая клавиши w, a, s, d можно изменять положение виртуальной камеры. Клавиша выхода из приложения в исходном коде приложения Test отсутствует. Закрываем окно программы нажатием F12 (прописано в библиотеке движка) либо стандартной комбинацией клавиш Alt+F4.

• Открой файл скрипта спаун-объекта Spawner.txt (например в Блокноте Windows) и изучи его содержимое.

В скрипте определены:

• Частота (периодичность) выброса объекта подбора (т.е. задержка между подбором объекта и его следующим выбросом).
• Радиус детектирования столкновений (collision radius). Значение 0.0 означает, что для определения радиуса столкновения будет использоваться радиус меша спаун-объекта;
• Имя и полный путь до объекта, который будет выброшен.

Также в него можно добавить звук подбора (в данном примере не показано).

Исследуем код тестового приложения (проект Test)

Для данного тестового приложения были подготовлены 3 объекта, по одному каждого вида.
В функции Load класса TestState хорошо видно, как создаётся каждый из этих трёх объектов.
Первым идёт анимированный объект (AnimatedObject), который использует ЗD-меш со встроенной анимацией:

Второй объект - объект сцены (SceneObject), который мы используем в качестве виртуальной камеры:

Статья по теме: Камера вида от первого лица (First Person Camera)
Третий объект - спавнер-объект (SpawnerObject), который спаунит (выбрасывает) объект, описанный в его скрипте:

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

В функции Update видно, как мы управляем камерой при помощи клавиш клавиатуры W, A, S. D:

Исходные коды Решения GameProject01

...(для MS Visual С++ 2010), с которым работали в данной Главе (вместе с ассетами), забираем здесь.

Итоги главы

Ты можешь "поиграть" с различными значениями исходного кода тестового приложения. Например, можно сменить объект-вьюер на другой или изменить номер проигрываемой анимации (первый параметр функции PlayAnimation). Это была впечатляющая Глава т.к. мы значительно повысили функциональность нашего движка путём добавления различных видов объектов. Мы подробно обсудили принцип функционирования игровых объектов а затем разработали 3 стандартных вида объектов, поддерживаемые нашим движком:

• базовый объект сцены (Scene object);
• анимированный объект;
• спаунер-объект.

Данные объекты "заточены" для создания именно игр в жанре FPS. Если соберёшься создавать игру другого жанра на данном движке, то обнаружишь, что его система объектов может потребовать модификации.
В конце Главы мы интегрировали классы объектов в движок и разработали замечательное тестовое приложение, которое показывает в работе каждый из трёх видов объектов.
При разработке игры во 2-й части данного курса мы сможем выбрасывать на игровую сцену все виды объектов и они смогут корректно сталкиваться друг с другом, при условии, если они унаследованы от базового объекта SceneObject. Поэтому в следующей Главе мы расширим и углубим наши познания об объектах сцены. Она будет завершающей Главой первой части и ею мы завершим работу над движком. Но, прежде чем увидеть свет в конце тоннеля, нам ещё предстоит проделать большую работу. Мы оставили самые лучшие и сложные темы, что называется, на десерт. В конце следующей Главы у нас будет всё необходимое для управления и рендеринга игровой сцены со всеми объектами на ней.

Источники

ДАЛЕЕ ==> Кодим 3D FPS DX9. 1.16 Управление сценой (Scene Management)

---