Создание механики движения




ОТЧЕТ О ПРОХОЖДЕНИИ ПРОИЗВОДСТВЕННОЙ ПРАКТИКИ В ЛАБОРАТОРИИ

Digital Media Lab

название лаборатории

 

 

Студент группы   11-809 Казаков Александр Дмитриевич
  подпись (ФИО)

 

Руководитель практики от ИТИС:
 
старший преподаватель Кугуракова В. В.
(должность, звание, Ф.И.О.)

 

Руководитель практики от предприятия:
 
старший преподаватель Кугуракова В. В.
(должность, звание, Ф.И.О.)

 

 


 

Оглавление

 

Введение 3

О лаборатории. 4

Основная часть игры. 5

Создание базиса игры... 6

Создание механики движения.. 7

Туннельное передвижение. 8

Управление. 9

Авто – генерация.. 9

Генерация труб.. 9

Генерация препятствий.. 11

Генерация бонусов.. 12

Объединение. 13

Смерть персонажа. 13

Бонус защиты... 14

Бонус ускорения.. 16

Создание UI 18

Создание главного меню... 18

Главное меню... 18

Меню настроек.. 19

Оконный режим.. 19

Громкость.. 20

Разрешение экрана. 20

Качество изображения.. 21

Внутриигровой UI. 21

HUD.. 22

Меню паузы... 25

Панель смерти.. 25

Внутриигровые настройки.. 25

Заключение 27

Список использованных источников 28

Приложения. 29

 


 

Введение


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

Сама возможность быть в иной реальности, испытывать ощущения, которые нет возможности получить в реальной жизни, быть тем, быть реально тем, кем не смог бы стать, так и манит быть частью этого мира.

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

А создают эти возможности как раз разработчики технической части. Именно они и воплощают в реальность все идеи сценаристов. Поэтому навык работы с технической частью очень востребован в наши дни.

 

 


О лаборатории

Лаборатория Digital Media Lab, в которой проводилась практика, занимается преимущественно разработкой различных видеоигр с использованием движков Unity и Unreal Engine.


Лаборатория визуализации и разработки игр является лабораторией Высшей Школы Информационных Технологий и Систем Казанского Федерального Университета. Основные сферы деятельности:

v Разработка компьютерных, мобильных и Web-игр

v Визуальная симуляция производственных процессов

v Культурно-исторические реконструкции с элементами дополненной реальности (виртуальные музеи)

v Проекты с использованием технологий Oculus Rift, Kinect, NettleBox

Лаборатория проводит обучение студентов Высшей Школы Информационных Технологий и Систем по следующим направлениям:

v Создание нарративного и игрового дизайна

v Изучение теории звука и его обработки

v Создание художественной графики, как классическими методами, так и с применением цифровых технологий

v Изучение основ 3D-анимаций, моделирования, создания эффектов при помощи технологий Autodesk Maya, Blender, Foundry Nuke

 


Основная часть игры

 

Были поставлены несколько целей прохождения практики:

- получение опыта и развитие новых навыков программирования;

- получение навыков работы в команде;

- совершенствование знаний гейм дизайна;

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

Геймплей игры заключается в том, что игрок управляет космическим кораблём, который летит на встречу препятствиям в некотором закрытом пространстве, напоминающую трубу, летящих на него спереди. В выживании ему помогает навык игры самого игрока, а также пару бонусов. При столкновении корабля с препятствием корабль уничтожается, что влечёт за собой поражение.

Цель игрока – заработать как можно больше очков.

 

 


 

Создание базиса игры

 

Для разработки игры было указано использовать движок Unity.

Задача предстояла создать игру в жанре «Гонки». Не имея навыков работы в Unity, я принялся изучать основные аспекты работы с данной платформой.

Так как в команде была получена роль технического разработчика, было поставлено несколько задач к созданию базиса всей игры, а именно:

Ø механика движения по трубе

Ø генерация карты

Ø генерация препятствий

Ø активация бонусов

 

Для динамичных объектов игры в интернете были найдены спрайты космического корабля, ракет, астероидов и взрывов.

Во вкладке Game было создано несколько папок:

Ø Images, где хранятся все изображения;

Ø Scripts со всеми C# скриптами;

Ø Prefabs, которая содержит все префабы;

Ø Scenes хранит сцену игры.

Ø Models хранит все модели.

Ø Effects хранит все визуальные спец эффекты

Ø Animations хранит все анимации

Ø Materials хранит все материалы

Ø Textures хранит все текстуры

 


Создание механики движения

 

Задачей перемещения было движение по туннелю, а также поворот и при нажатиях клавиш. Был создан скрипт Moving, который был перемещён в папку scripts и использован на камере.

Предварительно было добавлено несколько экземпляров объектов и методов

_endPoint - текущая точка движения корабля

_secondEndPoint - следующая точка движения корабля
NextTrube - указатель на трубу для полёта

MoveSpeed - значение скорости нашего корабля, которое мы сможем изменять
TurnSpeed - скорость поворота

 

TurningAngle - угол поворота. Т.к в данной реализации это шестигранник, то угол соответственно равен 60 градусов
_currentAngle - текущий угол поворота

_status - передаёт значение текущего расположения корабля, от нуля (начала трубы) до двух (конца трубы))

 

В методе Start обозначается стартовая точка- начало трубы и след точка – середина трубы


Туннельное передвижение

Кораблю была добавлена физика жёсткого тела и было убрано влияние физики на корабль. Затем корабль был размещён в центре координат. Данный корабль стал дочерним объектом камеры и был перемещён к основанию трубы для создания эффекта полёта по поверхности трубы

Рисунок 1. Создание движения.

Чтобы управлять космическим кораблём, был написан некоторый объем кода на С#. А именно, данный код, находящийся в методе Update:

Данный код задает движение по трубе через 3 части трубы.

Управление

Далее стояла задача добавить передвижение по сторонам. Была выбрана концепция передвижения по рёбрам трубы.

В управлении участвуют клавиши клавиатуры A, D. В тот же метод Update было добавлено следующее:

Данный код задавал точку поворота +- 60 в зависимости от нажатой клавиши, и через линейную интерполяцию изменял поворот корабля.
На этом функционал скрипта Moving заканчивается.

Авто – генерация

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

Генерация труб

Создание бесконечной трассы нужно было начать с основания. За основу была взята модель трубы.

Рисунок 2. Первый концепт
труб с препятствиями

Первой идей была последовательная генерация труб через инициализацию объектов. Однако при такой реализации происходили случаи некорректного удаления трубы и её потенциального содержимого.

Улучшением идеи стало реализация односвязного списка и контроль количества труб через список этих самых труб.

Также к трубе было добавлено 2 пустых объекта которые были расположены на концах трубы для удобства.


Был создан скрипт TrubeInfo где единственной строкой кода было поле NextTrube которое несло ссылку на следующий экземпляр трубы. А также учёт всех труб на сцене через List <GameObject>.

Был создан скрипт MapGenerator, ставший ответственным за генерацию всей карты. За объект с активным триггером был создан пустой объект с элементом box collider огромного размера и получивший в распоряжениe скрипт. Для удобства как - Destroyer. Его предназначение было опознавать объект при уничтожении и выполнять соответствующую реакцию.

Была добавлена ссылка на последнюю имеющуюся трубу как элемент реализации односвязного списка.

А также значение стартовых труб для корректного отображения.

Задумка была таковой, что, когда destroyer касался конца трубы, он создавал новую с началом у конца последний трубы в списке труб. Таким образом на карте всегда существовало определённое количество труб, не потребляя дополнительные ресурсы процессора

В методе OnEnable через цикл создавалось StartTrubesAmount стартовых труб.

Сам метод генерации выглядит следующим образом

 

В итоге вышел вот такой результат:


Рисунок 3. Результат кода
генерации труб

 

Генерация препятствий

 

Следующим этапом было настроить создание препятствий внутри трубы.
При появлении объекта было решено использовать то пространства между началом и серединой, концом и серединой.


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

В скрипт MapGenerator добавилось поле хранения препятствий.Также было решено контролировать генерацию препятствий через шанс появления. В метод GenerateNewTrube был добавлен вызов метода GenerateBarriers, который создавал по 2 случайных препятствия в трубе.

Препятствия создаются по отдельности с разным шансом появления и сo случайном углом поворота кратным 60 градусов

Генерация бонусов

По задумке, в игре существует 2 бонуса. Молния и щит, которые дают эффект. Задачей было создать генерацию этих самых бонусов.

Здесь ничего не пришлось придумывать нового. В скрипт MapGenerator были добавлен массив бонусов, а также шанс их появления. Ну и добавить их в очередь генерации, при условии, что там нету препятствия

 

Как можно заметить, стали появляться как бонусы, так и препятствия.

Рисунок 4. Результат кода
генерации объектов

 

Объединение

На данном этапе уже есть генерация карты, однако нет никакого взаимодействия между объектами на сцене. Как раз время — это исправить.

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

Смерть персонажа

Сам персонаж никак не реагирует на препятствие. Это, естественно, неправильно. Решением было создать скрипт PlayerReaction, который по задумке должен был реагировать на встреченные игроком события.

Один из вариантов было создать скрипт PlayerInfo, который хранил данные о персонаже.

В PlayerReaction было добавлено реагирование на объект, если его тэг = “Wall”

А также экземпляр объекта камеры


Отлично, теперь сам корабль исчезает при смерти, а камера перестаёт двигаться. Осталось только дать всем препятствиям тэг “Wall”.

Бонус защиты

 

Рисунок 5. Бонус защиты

Первым бонусом является щит, защищающий от одного повреждения.
Для бонуса следовало создать новый скрипт – BonusInfo, который хранил бы наименование того бонуса, что персонаж будет подбирать.

Пусть название эффекта бонуса будет “Shield” и пусть скрипт будет на модели бонуса, естественно предварительно дав ему collider. В данном случае, mesh collider.

Отметим бонус тегом “Bonus”

Теперь в PlayerReaction добавим реакцию на подбор бонуса

Отлично. Теперь после подбора бонуса в скрипт PlayerInfo поступает информация о подобранном бонусе. Также бонус уничтожается после смерти.

Добавление в PlayerInfo активации самого бонуса

Теперь если подобран бонус, то при активации над головой персонажа будет светиться соответствующего цвета свет, а также эффект не развеется и из ячейки бонуса у персонажа обнулится.

Добавление в PlayerReaction обработку ситуации, если у игрока активен щит

Try и catch здесь использованы по причине конфликта с одной моделью.

Debug.Log был использован с целью видеть эффект кнопки в Play режиме Unity. В самой игре, естественно, игрок ничего не видит.

Теперь если активен щит, то при столкновении препятствие уничтожается, а щит вырубается. Добавление выключения свечения в PlayerInfo в метод Update

 

Бонус ускорения

 

Рисунок 6. Бонус ускорения

Вторым бонусом является будет ускорения.

Реакция на бонус уже есть. Сам бонус позволяет ускориться и быть неуязвимым на некоторое время. Во-первых, дадим бонусу скрипт BonusInfo где дадим ему имя бонуса Speed.

Активация будет включать соответствующий свет, очищать ячейку подобранного бонуса. Также введём переменную oldSpeed, которая будет запоминать старую скорость параллельно этому будет увеличена скорость персонажа в 2 раза.

Добавлена обработка активации ускорения в PlayerInfo

 

Осталось определиться с длительностью и неуязвимостью. Это тоже решается довольно просто. Было введено 2 переменные. Теперь добавим обработку, что если бонус был активирован, то персонаж получает временное усиление.

Ещё здесь меняется угол обзора камеры для придания эффекта ускорения. Время действия было реализовано через указания времени действия неуязвимости и вычета из этой величины игрового времени

 

Добавлена реакция активного бонуса ускорения в PlayerReaction

Создание UI

Когда основная техническая часть была закончена, пришёл момент создавать HUD или UI, как удобнее.

Создание главного меню

В каждой игре должно быть приветственное функциональное меню, поэтому в игре необходимо было тоже создать нечто хотя бы издали напоминающее главное меню. В планах было реализовать 2 экрана - экран настроек и приветственный экран, он же главный.

Главное меню

Для начало нужно было создать элемент UI – Canvas. Для главного меню был создан элемент UI – Panel. Якорем был назначен растяжением во все стороны. Это было сделано для адаптации под разное разрешение экрана.

Была создана панель MainMenu


Рисунок 7. Главное меню.

У панели MainMenu было решено создать три дочерних объекта UI button, с элементом Layout Element со включённым Ignore Layout.

Разместив кнопки в соответствующие места и переименовав соответственно их функциям, пришло время написать скрипт для кнопок. К скрипту MenuControls были добавлены две команды для кнопки выхода и кнопки старта игры:

Скрипт был привязан к панели MainMenu. Привязав соответствующий метод к кнопкам, получилось сделать выход из игры и старт самой игры.

Меню настроек

Вторым этапом было создание меню настроек. Было решено для начало реализовать несколько функций, а именно:

 

· Оконный режим, с переключением обратно

· Кнопка выхода в главное меню

· Ползунок громкости аудио звуков

· Изменение разрешения экрана

· Изменение качества в игре

У всех этих настроек был элемент Layout Element со включённым Ignore Layout. Меню настроек было расположено в иерархии выше, чем MainMenu. Таким образом кнопка перехода в настройки была реализована тем, что при её нажатии панель MainMenu деактивировалась, тем самым давая доступ к панели Settings.
Кнопка выхода из Settings имела обратную реакцию. При её нажатии панель MainMenu снова активировалась. Закрывая доступ к панели Settings.

Оконный режим

 

На панель был добавлен UI элемент – Toggle. Был создан скрипт Settings.

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


 

Громкость

 

Громкость регулировалась через UI элемент – Slider. Был создан объект типа AudioMixer, через который будет осуществляться контроль звука и добавлен в код соответственно.

Для slider был добавлен метод, который при изменении значения Slider’a изменял бы значение громкости AudioMixer’a. Также для удобства пользователя было введено запоминание той громкости, которую игрок выбрал ранее.

Также в метод Awake было добавлено считывание значения громкости, установленного игроком


Позже был добавлен пункт сброса свойства перезагрузки сцены. Это связано с тем, что рестарт игры осуществляется перезагрузкой сцены. Соответственно внутриигровой трек играл бы вновь. Это было исправлено тем, что трек не уничтожался при перезагрузке. Однако при выходе в главное меню этот параметр требовалось сбрасывать. Поподробнее об этом будет рассказано в пункте внутриигрового HUD’a.

 

Разрешение экрана

 

Разрешение экрана изначально присутствует в самом Unity. Идеей реализации было использование встроенных настроек.

Для этого было решено брать список разрешений экрана из настроек Unity и перемещать их в список для выбора, изменяя разрешение экрана параллельно, естественно. Был создан UI элемент – Dropdown. Изменять содержимое данного элемента будет код:

Качество изображения

 

Аналогично предыдущему пункту, качество изображения уже присутствует в Unity. Поэтому задачей было импортировать уже настроенные варианты в список для выбора. Для настроек также был использован Dropdown.
В Dropdown было вписано 6 настроек качества – Very Low, Low, Medium, High, Very high, Ultra. В скрипт Settings был добавлен метод изменения качества в зависимости от выбора пользователя.

На этом функционал меню настроек заканчивается.

 

Внутриигровой UI

 

Последним этапом разработки было создание внутриигрового HUD’a. Его создание можно подразбить на 4 основных момента:

· Создание паузы

· Создание непосредственного игрового HUD’a, отображающего игровую информацию

· Создание внутриигрового меню настроек

· Создание окна смерти

Все моменты были созданы в виде панелей и закреплены в иерархии именно в таком порядке, что был перечислен. Все последующие скрипты были закреплены на Canvas’e данного UI, за исключением HudScript. Он же был закреплён непосредственно за панелью HUD.

 


HUD

 

По задумке HUD должен был отображать очки игрока, его максимальный рекорд, подобранный бонус, проведённое время в игре и количество кристаллов. Кристаллы служили валютой для магазина. К сожалению, сам магазин не был реализован.


Рисунок 8. HUD игры.

Расположение элементов HUD’a изображено на рисунке.

Для всего HUD был использован скрипт HudScript с двумя методами Start и Update. В дальнейшем все изменения будут происходить только с ними.

Для начала, следовало получить ссылки на текстовые элементы всех элементов, за исключением бонуса, для изменения значения параметров.

Время

Для того, чтобы вести учёт проведённого в игре времени требовалось изменять Text элемент соответствующего элемента HUD на время действия приложения. В метод Update было добавлено обновление самого времени в целых значениях

 

Кристаллы

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

В метод Start было добавлено считывание значения кристаллов. А в метод Update отображение этого значения.

Также в скрипт PlayerReaction была добавлена реакция на новый объект

 

Бонус

Так как было всего 2 бонуса. Было решено использовать переключения между изображениями бонусов в зависимости от подобранного игроком

 

В метод Update было добавлена обработка переключения состояния изображений

 

Счёт

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


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


В метод Update, в свою очередь, была добавлена обработка учёта обоих счётчиков

 

Меню паузы

 

Принцип работы паузы заключается в приостановке самой сцены. Меню паузы по нажатию кнопки должно было отключать время, а при повторном закрывать себя и панель настроек, если та активна. Решением стало отключения движения времени у сцены.


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

Панель смерти

 

При смерти персонажа должна была появляться надпись об этом. Для его этого была созданная характерная панель с кнопками возрождения и выхода из игры. Кнопка возрождения просто перезагружала сцену, кнопка выхода закрывала приложение. Оба метода уже реализованы в MenuControl

Также в скрипт PlayerReaction была добавлена строчка активации панели в момент смерти.


Внутриигровые настройки

 

Для начала, был добавлен пустой объект, вне Canvas’a для управления Audio. Для него был создан скрипт InGameAudio, который регулировал звук.
Этот объект уничтожался при возврате на главное меню, однако не уничтожался при перезагрузке сцены. Таким образом музыка играла корректно, не начинаясь заново каждый раз

Также в самой панели настроек был создан Dropdown, отвечающий за сложность игры. В скрипте InGameSettings реализовано изменение режимов сложности, а также запоминание выбранного режима игроком ранее.

Сами режимы сложности представляют из себя разные значения скорости, частоты появления препятствий и бонусов


Заключение

Во время прохождения практики были все задачи, которые были поставлены в моей области. В результате всей работы была разработана компьютерная игра в жанре гонок. В игре была использована музыкальное сопровождения. Игра была выполнена в трёхмерном измерении.

Благодаря прохождению практики в лаборатории DML, я получил опыт и развил новые навыки программирования, навыки работы в команде, усовершенствовал знания геймдизайна и получил приятные впечатления от проделанной работы.

 




Поделиться:




Поиск по сайту

©2015-2024 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2019-07-29 Нарушение авторских прав и Нарушение персональных данных


Поиск по сайту: