Разработка игрового приложения в жанре RPG

Размещено на http://www.allbest.ru/



СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1. ПОСТАНОВКА ЗАДАЧИ

2. АНАЛИЗ МЕТОДОВ И СРЕДСТВ РЕШЕНИЯ ПОСТАВЛЕННОЙ ЗАДАЧИ

2.1 Теоретические основы

2.2 Обзор существующих аналогичных программных продуктов

3. АНАЛИЗ ТРЕБОВАНИЙ К ПРОГРАММНОМУ ПРОДУКТУ

3.1 Анализ предметной области

3.2 Определение реализуемых функций

4. ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО ПРОДУКТА

4.1 Архитектура программного продукта

4.2 Выбор инструментальных средств разработки

4.3 Проектирование структур данных и алгоритмов

4.4 Проектирование пользовательского интерфейса

5. РАЗРАБОТКА ПРОГРАММНОГО ПРОДУКТА

5.1 Разработка структуры классов

5.2 Особенности реализации системы

6. ТЕСТИРОВАНИЕ ПРОГРАММНОГО ПРОДУКТА

6.1 Обоснование методики тестирования

6.2 Результаты тестирования

ЗАКЛЮЧЕНИЕ

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

ПРИЛОЖЕНИЕ



ВВЕДЕНИЕ

Компьютерные игры - если не самое, то одно из популярнейших развлечений в наше время. Компьютерные, консольные, мобильные, - для работы виртуальных вселенных используются самые разные платформы. Хотя, используются - слабо сказано, - создаются! Действительно, игровой рынок развит сейчас настолько сильно, что компании готовы создавать собственные ЭВМ, ради погони за уникальностью. Именно эта «уникальность» и волнует множество пользователей - игроков, которые устали от одних и тех же игр, различающихся моделями и звуками.

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

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

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

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

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

программный интерфейс приложение тестирование



1. ПОСТАНОВКА ЗАДАЧИ

В рамках дипломного проекта мною должно быть реализовано минимально работоспособное игровое приложение в жанре RogueLike-RPG. Это не будет являться демонстрационной версией игры. Демоверсия - это продукт, разрабатываемый ради рекламы конечного продукта. В нашем же случае разрабатывается сразу конечный продукт, но без «начинки».

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

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

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

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

1. Загрузку локальных данных.

2. Генерация карты высот по «зерну».

3. Генерация карты биомов.

4. Генерация городов на карте.

5. Перемещение игрока по миру.

6. Переход между сценами.

7. Ведение боя.

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

Генерация карты высот отвечает за размещение на карте различных объектов, которые соответствуют следующим уровням в порядке возрастания высоты: вода, равнины, леса, горы. Под «зерном» подразумевается случайное число, которое будет влиять на генерацию мира.

Биом - это совокупность экосистем одной природно-климатической зоны. Это определение характерно, как для понятия «Биом» в реальной жизни, так и для виртуальных миров. В идеале разделение на биомы должно проходить максимально реалистично: отсутствие резких переходов от холодных зон к жарким и отсутствие слишком маленьких биомов. В приложении для демонстрации должно быть представлено как минимум 3 различных биома. Чем их будет больше, тем лучше.

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

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

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

Ведение боя - расширение требования к наличию сцены боя. Должна быть реализована какая-либо возможность проведения боя в реальном времени.



2. АНАЛИЗ МЕТОДОВ И СРЕДСТВ РЕШЕНИЯ ПОСТАВЛЕННОЙ ЗАДАЧИ

2.1 Теоретические основы

В ходе выполнение дипломной работы мне придётся столкнуться со многими проблемами, которые придётся решать с применением каких-либо инструментов, алгоритмов и шаблонов проектирования.

Игровой мир в приложении гексагональный (hexagon - шестиугольник). Конечно, использование квадратной сетки для позиционирования намного удобнее для работы различных алгоритмов, но есть один минус, который способен перекрыть все плюсы. Всего у квадрата 8 соседей. В 4 из них он может прийти через ребро, а ещё в 4 через угол. При этом расстояние через угол получается примерно в 1.4 раза больше (квадратный корень из 2). Что делать в таком случае? Либо запрещать движение по диагонали, либо ускорять персонажа при движении по диагонали, либо это расстояние, равное 1 он будет проходить дольше. А можно просто не использовать квадратные сетки.

Пример показан на рисунке 2.1.

Рисунок 2.1 - Квадрат и его соседи



На гексагональной сетке у шестиугольника всего 6 соседей и со всеми он сообщается через рёбра, что обеспечивает нам одинаковое время перемещения до каждого из соседей.

Пример приведен на рисунке 2.2.

Рисунок 2.1 - Шестиугольник и его соседи

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

2.2 Обзор существующих аналогичных программных продуктов

Пик популярности жанра Roguelike пришёлся на 80-90 годы 20-го века. Сейчас крупные компании не берутся за подобные жанры по нескольким причинами: нет интереса у игроков, сложность развития и расширения проекта. Изредка инди-разработчики выпускают на рынок свои приложения, которые внешне не ушли далеко от тех самых игр из 80-90 годов прошлого столетия.

Жанр RPG популярен всегда: игроки не желают отказываться от возможности создать своего героя мечты и вместе с ним покорять просторы виртуального мира. Рынок наполнен подобными ролевыми играми, но из-за их популярности возникла проблема «однотипности» игр этого жанра.

Объединение этих двух жанров - необычно для игрового рынка, поскольку подобных приложений крайне мало. Существуют некоторые проекты, которые вдохновили на создание данного приложения. Например, в игре «For the King» мне понравилась визуальная составляющая, игровой мир и способ перемещения по нему. А из игры «Bad North» отчасти была позаимствована боевая система.

Основной аналог - “For the King”. “For the King” - это пошаговый рогалик(RogueLike) с элементами RPG. В ней игроку в распоряжение даётся отряд из 3 юнитов, которыми он должен исследовать мир, проходить сюжетную линию и побеждать врагов. Мир игры насыщен различными объектами, противниками и ландшафтами. Также имеется возможность развития всех 3 юнитов, которыми управляет игрок.

Скриншот мира представлен на рисунке 2.3.

Рисунок 2.3 - «For the King» - скриншот игрового мира.

В игре «For the King» реализованы достаточно интересный генератор игрового мира и перемещения персонажей. Проанализировав генерацию мира в игре и просмотрев информацию в интернете, в поисках подходящего алгоритма, я пришёл к выводу, что существуют довольно сложные алгоритмы, которые позволяют генерировать карту вплоть до климатических зон, но их реализация довольно сложна. Так что взял что-то более серьёзное, чем «рандом», а именно «Шум Перлина». Также для перемещения персонажей можно было использовать множество различных алгоритмов, но в рамках проекта мне не понадобился бы какой-то серьёзный и производительный алгоритм, так как расчёты путей минимальны. В связи с этим я решил воспользоваться простым «Поиском в ширину».

В игре «Bad North» мне понравилась реализация боя: перемещения персонажей и сама динамика. В попытках разобраться с тем, как это устроено я наткнулся на интересный инструмент в Unity3D - NavMeshAgent. С помощью этого инструмента мы можем создать искусственный интеллект, который по заранее обработанной карте будет находить маршрут до поставленной ему цели.



3. АНАЛИЗ ТРЕБОВАНИЙ К ПРОГРАММНОМУ ПРОДУКТУ

3.1 Анализ предметной области

Целевой аудиторией данного приложения являются пользователи от 12 до 30 лет. Для детей младше 12 лет данная игра будет не столь привлекательна, поскольку им хочется что-то создавать, причём создавать самостоятельно, а это больше относится к играм жанра «Песочница», таким как «Minecraft» и «Terraria». Чем старше становится человек, тем меньше его начинают интересовать компьютерные игры. Как следствие, я считаю, что люди старше 30 в редких случаях будут проявлять интерес не только к данному приложению, но и ко всей игровой индустрии в целом.

У игроков старше 12 лет, как правило, появляется желание думать и совершенствоваться в игре. В приложении эти потребности пользователей выполнены в виде тактической составляющей боя, заставляющей пользователя думать, как расставить отряды, чтобы победить с минимальными потерями, и в RPG-составляющей, позволяющей пользователю развивать и совершенствовать своего персонажа.

По количеству используемых рабочих мест игры делятся на несколько категорий: однопользовательские (The Elder Scrolls V: Skyrim), многопользовательские (World of Warcraft), с возможностью совместной игры (Minecraft) и с возможностью одновременного сеанса с одного ПК (Cuphead). Данный проект реализован как однопользовательский (Single Player): один игрок использует одно рабочее место и играет в свою партию, в которую никто больше не может вмешаться.

3.2 Определение реализуемых функций

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

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

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

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

Старт игры начинается с кнопки «Начать игру». После этого игрок попадает на игровую карту, где ему предстоит побеждать противников и проходить сюжет всё дальше и дальше.

Нефункциональные требования:

· Программный продукт должен быть расширяемым.

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

· Все используемые в приложении ресурсы должны быть изолированы от пользователя, чтобы тот не имел возможности их изменять.

Функциональные требования:

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

· Количество интерфейса должно стремиться к минимуму, взаимодействие пользователя с приложением в основном должно осуществляться без интерфейсов.

· Приложение должно соответствовать описанию жанра Roguelike: процедурно генерируемый мир и необратимость смерти персонажа.

· Также приложение должно соответствовать описанию жанра RPG: развитие собственного персонажа и наличие сюжета.

· Должна присутствовать возможность смены локализации приложения.

Требования к сопровождению:

· Рабочая версия приложения должна быть выпущена к концу сроков разработки.

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

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



4. ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО ПРОДУКТА

4.1 Архитектура программного продукта

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

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

К минусам локальных приложений можно отнести следующее:

1. Невозможность отследить успехи пользователя в игре. То есть пользователь может с использованием различного ПО взломать игру и испортить себе игровой процесс.

2. Сложность обновлений и устранений ошибок. При необходимости провести какое-либо обновление пользователям придётся каждому отдельно скачивать обновления.

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

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

При проектировании приложения использовалась модель MVC (Model-View - Controller). Данная модель позволяет разбить программу на 3 составляющие, каждая из которых выполняет свою особенную роль.

Модуль Model отвечает за все внутриигровые алгоритмы и логику. Он содержит в себе основную часть всего кода, поскольку игровая логика - это 95% всей игры.

Модуль View отвечает за отображение результатов работы модуля Model на экран пользователю в удобном ему виде (рисованная игровая карта). Этот модуль занимает наименьшую часть, поскольку фреймворк Unity3D самостоятельно отрисовывает все необходимые объекты на экран пользователя.

Модуль Controller отвечает за пользовательский ввод. Это небольшой модуль, который считывает действия пользователя и отправляет данные, соответствующие этому действию в модуль Model.

Вся модель MVC может быть представлена в простом круговороте.

Пример представлен на рисунке 4.1.

Рисунок 4.1 - Пример взаимодействия модулей модели MVC

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

Распределение функций по модулям представлено в следующей таблице (Таблица 5.1).

Таблица 4.1 - Разделение ответственности между модулями MVC

Model	View	Controller
Генерация карты Перемещение персонажа Распределение заданий Чтение данных из файлов	Роль модуля View выполняет сам фреймворк	Считывание пользовательского ввода

4.2 Выбор инструментальных средств разработки

Немного подробнее о выборе кроссплатформенного фреймворка Unity3D. Изначально имелось 3 варианта, на чём разрабатывать приложение: Cocos2D, Unity3D и Unreal Engine 4.

Преимущества Cocos2D в том, что он намного лучше работает с 2D играми, в отличие от остальных двух движков, поскольку направлен как раз на 2D игры. Но в рамках дипломного проекта мною будет реализовываться двумерная игра с трёхмерной графикой, а значит мне понадобится, всё-таки 3D-фреймворк. Unreal Engine 4 - мощный и очень производительный движок. Имеет поддержку C++, что изначально сыграло в его пользу. Но в дальнейшем было решено, что Unreal - сложный для освоения и слишком громоздкий движок для простого «рогалика». Остался Unity3D - достаточно производительный фреймворк, имеет бесплатную лицензию, поддержку C# и JavaScript. Кроме того, этот фреймворк актуален и много где используется. Даже в пределах Вологды мне удалось разыскать 2 вакансии, требующих знание Unity3D. Поскольку выбор фреймворка для разработки пал на Unity3D, то я ограничен в выборе языка разработки. Для написания кода для Unity3D может использоваться либо C#, либо модифицированный JavaScript, названный в простонародье UnityScript.

Мой выбор пал на язык C# по нескольким причинам:

1. Мне мало известен язык JavaScript, а тем более его Unity-версия.

2. В интернете имеется больше полезной информации именно для C#.

3. Для языка C# существует прекрасная среда разработки Visual Studio.

Как следует из 3-го пункта списка, в качестве среды разработки я выбрал Visual Studio, поскольку это та среда, в которой у меня есть небольшой опыт разработки, она поддерживает IntelliSense, помогающий исправлять ошибки и писать код быстрее.

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

4.3 Проектирование структур данных и алгоритмов

При генерации мира мне понадобится некий алгоритм, который сможет выстроить карту таким образом, чтобы на нём присутствовали плавные переходы по высотам и биомам: не должно быть хаотично расставленных рек, лесов и гор в 3 соседствующих клетках и не может быть зимнего биома по соседству с пустыней. Кроме того, использование обыкновенного «рандома» будет неуместно, т.к. при повторном генерировании той же самой карты (такое же зерно) он может выдавать другие значения, что не является правильным.

Для решения данной проблемы мною был использован «Шум Перлина». Алгоритм шума строится таким образом, что он выстраивает в некоторых точках плоскости значения от -1 до 1, которое является тангенсом угла наклона прямой, проходящей через эту точку, а затем, при помощи линейной интерполяции, он получает более точные значения высот между точками, в результате чего плоскость становится сглаженной.

Пример представлен на рисунках 4.2 - 4.3.



Рисунок 4.2 - Выставляем тангенсы в точках

Рисунок 4.2 - Интерполируем значения, получая плавную прямую

Для карты биомов был использован несколько более сложный шум. Можно назвать его трёхмерным или цветным шумом Перлина. Я накладывал один шум на другой так, чтобы получить цветную карту (RGB), в которой определённым цветам будут назначены конкретные биомы. Конкретному шестиугольнику присваивается тот биом, цвет которого максимально приближен к значению шума шестиугольника.

Пример представлен на рисунке 4.4.

Генерация мира по «зерну» реализована предельно просто. Карта генерируется всегда одинаковая, по шуму, за счёт зерна только изменяется стартовая точка появления персонажа. То есть при значении зерна = 0 у меня, условно, персонаж появится в координате (0;0), а при шуме 400 - (400;1200).



Рисунок 4.4 - «Цветной шум Перлина»

Перемещение персонажа по карте - довольно трудоёмкий процесс. Для поиска пути могут быть использованы самые разные алгоритмы, но мой выбор пал на алгоритм «Поиска в ширину».

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

Работа алгоритма поиска в ширину начинается с того, что мы добавляем стартовую точку в очередь (Рисунок 4.5).

Рисунок 4.5 - Начало работы алгоритма поиска в ширину

Дальше начинается основной процесс алгоритма: мы проверяем является ли первый элемент очереди искомым, если да, то путь найден, иначе всех соседей текущего элемента добавляем в очередь (Рисунок 4.6).



Рисунок 4.6 - Основной цикл работы алгоритма (шаг 1)

Далее мы повторяем предыдущий шаг, не забывая записывать расстояния до каждого из соседей (это легко делается по номеру итерации). На рисунке 5.7 представлен следующий шаг работы алгоритма.

Рисунок 4.7 - Основной цикл работы алгоритма (шаг 2)

Все последующие шаги аналогичны предыдущему: мы проверяем является ли элемент очереди искомым, добавляем в очередь соседей и записываем расстояния (Рисунок 4.8).



Рисунок 4.8 - Основной цикл работы алгоритма (шаг 3)

В итоге нами будет получена целая карта (Рисунок 4.9) из пройденных точек и расстояний до них, если искомая точка найдена, то мы восстанавливаем путь до неё.

Рисунок 4.9 - Завершение работы алгоритма

Блок-схема этого алгоритма представлена в Приложении 1.

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

Так, например, он имеет в себе встроенный алгоритм для нахождения «Шума Перлина» для указанных координат. Переход между сценами так же реализован с помощью фреймворка. На сцене боя для перемещения отрядов используется компонент NavMeshAgent, который позволяет игровым объектам находить путь на построенной карте в обход препятствий.

4.4 Проектирование пользовательского интерфейса

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

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

Интерфейс, присутствующий на игровой сцене, будет минимальным. На сцене будет размещаться только кнопка «Колода», чтобы игрок мог во время игры посмотреть выбранную колоду и скорректировать её.

Интерфейс меню паузы будет состоять из 2 кнопок: «Продолжить», которая выключит меню паузы, и «Выход», которая закроет приложение.

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



5. РАЗРАБОТКА ПРОГРАММНОГО ПРОДУКТА

5.1 Разработка структуры классов

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

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

Рисунок 5.1 - Диаграмма основных классов в приложении

На диаграмме (Рисунок 5.1) показаны отношения основных классов генерации карты. Класс CustomMap - основной класс генерации. В нём происходит создание чанков (прим. Chunk - кусок), которые являются изменяемыми самостоятельными единицами карты. Стандартный размер чанка - 7х7 тайлов. Также класс CustomMap отвечает за удаление этих самых чанков. Следующим идёт класс ChunkScript. Внутри этого класса прописана логика чанков. При создании чанка он начинает создавать внутри себя тайлы - те самые шестиугольники, из которых будет состоять вся карта. И соответственно ChunkScript ответственен за удаление этих самых тайлов при попытке класса CustomMap удалить данный чанк.

Тайлы - самая маленькая единица карты. Она не имеет никакой логики. Всё, что у неё есть - это текстуры, которые определяются биомом. Поверх тайлов существует сетка, за работу которой отвечает класс GridScript. GridScript определяет, какой тайл она покрывает и выбирает самостоятельно себе текстуру. Если тайл проходим, то одна текстура. А если в этом тайле гора и пройти нельзя, то выбирается заблокированная текстура сетки. Также этот скрипт отвечает за улавливание нажатия пользователя по сетке. Как только происходит нажатие меняется текстура сетки и в модуль Controller отправляется события нажатия мыши по заданной координате.

Следующий класс - CityGeneration, он отвечает за генерацию городов на карте. Данный класс будет генерировать города на уже созданной карте и будет их удалять при удалении карты. Для простоты удаления он хранит список всех активных городов.

MainMap - класс-синглтон и фасад, хранит в себе ссылки на все основополагающие компоненты сцены и выполняет работу по загрузке данных в сцену. Через MainMap можно получить доступ к классам ObjectManager, QuestManager и Director.

ObjectManager - класс, хранящий в себе ссылки на объекты сцены, такие как Map (экземпляр класса CustomMap) и другие, которые не учтены в диаграмме.

QuestManager - класс, ответственный за распределение заданий по городам.

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

Класс PersistentData - важный класс, являющийся синглтоном, и хранящий данные, необходимые при переходе между сценами.

5.2 Особенности реализации системы

В процессе реализации дипломного проекта я наткнулся на многие трудности, которые решались различными алгоритмами или математически. Одним из первых подобных препятствий стал перевод из локальных координат (номера) конкретного шестиугольника в глобальные сцены. Для подобных преобразований сразу на старте разработок был реализован метод GetWorldPosition, который в качестве аргументов принимает локальные координаты шестиугольника, а на выходе даёт координату, по которой этот шестиугольник размещается на сцене. Код метода представлен на рисунке 5.2.

Рисунок 5.2 - Метод преобразования локальных координат в глобальные

На деле метод применяется, например, при расстановке тайлов. По алгоритму у нас создаются локальные координаты тайлов, а нам его нужно поставить в неких глобальных координатах. Здесь на помощь приходит метод GetWorldPosition, который преобразует координаты и мы может выставить каждый шестиугольник по нужным координатам (Рисунок 5.3).

Рисунок 5.3 - Пример правильно расставленных тайлов

Для генерации карты высот по зерну мною был создан метод ElevationMap, который в качестве аргумента принимает конкретную точку на карте (локальная координата шестиугольника) и возвращает значение от 0 до 1, которое определяется по масштабированному и увеличенному на зерно «Шуму Перлина». Масштаб подбирался вручную, исходя из идеи, что карта должна плавно изменять свои высоты, но при этом не растягивать одну высоту на десятки тайлов. Ниже проиллюстрированы скриншоты неудачно выбранного масштаба. На рисунке 5.4 изображена генерация карты со слишком большим масштабом.



Рисунок 5.4 - Пример генерации со слишком большим масштабом

А на рисунке 5.5 изображена генерация со слишком маленьким масштабом.

Рисунок 5.5 - Пример генерации со слишком маленьким масштабом



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

Рисунок 5.6 - Пример генерации с хорошо подобранным масштабом

Код самого метода представлен на рисунке 5.7.

Рисунок 5.7 - Метод, создающий карту высот по шуму

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

Для решения данной проблемы я использовал Coroutines (рус. сопрограммы), которые позволяют разделить выполнение большой задачи на несколько кадров. В стандартном C# отсутствует подобный функционал, но он имеется внутри библиотек фреймворка Unity. При помощи сопрограмм мне удалось растянуть создание и удаление чанков на несколько кадров.

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

Рисунок 5.8 - Метод создания чанков

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



Рисунок 5.9 - Метод удаления чанков

Для старта сопрограммы в Unity имеется специальная функция, которая называется StartCoroutine. Пример старта сопрограммы приведён на рисунке 5.6.

Рисунок 5.10 - Пример запуска сопрограммы

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

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



Рисунок 5.11 - Карта до старта создания и удаления чанков

Рисунок 5.12 - Карта после старта создания и удаления чанков



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

Рисунок 5.13 - Карта после завершения процесса создания и удаления чанков

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

При помощи данного метода я реализовал основное взаимодействие игрока с приложением. При клике текущий шестиугольник становится выделенным (меняется спрайт сетки над шестиугольником) и он вызывает срабатывание события MouseClickEvent, на которое подписан класс Controller. Ничего этого не произойдёт, если нажатие мыши произошло по непроходимому тайлу (вода или горы) или если Controller не подписан на событие MouseClickEvent. Код представлен на рисунке 5.7.

Рисунок 5.14 - Метод нажатия кнопки мыши по объекту

Как сказано выше при клике шестиугольник, по которому произошло нажатие, выделяется, после чего через контроллер персонажу передаётся событие «Двигаться в точку с такими координатами». Дальше персонаж обращается к классу PathFinder, внутри которого реализован алгоритм поиска в ширину, тот, в свою очередь, находит оптимальный путь в указанную точку и возвращает персонажу путь, хранящийся в очереди “Path”. По этому пути персонаж и следует в выбранную точку. Также для наглядности был реализован класс PathVisualizer, который путь, по которому будет следовать персонаж отобразит линией на карте. На рисунке 5.15 изображено движение персонажа по выстроенному пути, который отображается оранжевой линией, в тайл, выделенный при нажатии по нему кнопкой мыши.

Рисунок 5.15 - Передвижение персонажа в указанную точку

Разбиение на биомы, как я уже писал ранее, реализовано при помощи трёхмерного «Шума Перлина». Сначала, при помощи метода BiomeMap каждому шестиугольнику назначается свой собственный цвет. BiomeMap в качестве аргументов принимает локальные координаты X и Y шестиугольников, а возвращает цвет, полученный с помощью трёх «Шумов Перлина» с разными смещениями (см. рисунок 5.16).

Это промежуточный этап, который довольно сложно проиллюстрировать в создаваемом приложении, но подобный алгоритм можно реализовать на языке JavaScript, что я и сделал. На рисунке 5.17 я сгенерировал «Цветной шум Перлина». Можно представить, что весь этот спектр цветов так же хранится внутри тайлов в игре, но не отображается. На рисунке, вместо шестиугольников используются квадраты, но для демонстрации они подойдут.

Рисунок 5.16 - Метод, раскрашивающий тайлы

Рисунок 5.17 - Пример "Цветного шума Перлина"

После генерации подобной карты мы разбиваем наши тайлы по биомам. Для этого я заранее назначаю каждому биому свой собственный цвет. Далее я сравниваю цвет каждого тайла с каждым биомом по RGB-палитре: разница красного + разница зелёного + разница синего = разница цвета. Этот метод не самый хороший, поскольку серый цвет, таким образом, имеет наименьшую среднюю разницу цветов с любым из имеющихся цветов.

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

Рисунок 5.18 - Метод, назначающий биом шестиугольнику

На рисунке 5.19 я снова с помощью JavaScript визуализировал подобное разбиение на биомы. Мне пришлось уменьшить масштаб примера, поскольку иначе весь рисунок будет одного цвета.

Рисунок 5.19 - Пример "Цветного шума Перлина", разбитого по заданным цветам



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

Рисунок 5.20 - Разбиение игровой карты на биомы

В дальнейшем передо мной встала задача генерации городов по карте. При этом для их генерации существовало несколько требований:

· Города не должны находиться вплотную друг к другу.

· Расположение городов должно выглядеть хаотичным.

Для того, чтобы создать минимальное расстояние между городами соблюдалось, я математически разделил всю карту на квадратные области с минимальным размером 6х6 шестиугольников. Внутри этих областей я генерировал координаты городов по «Шуму», который предварительно самостоятельно создал (см рисунок 5.21).

Рисунок 5.21 - Созданный мной шум



На рисунке 5.20 также можно наблюдать структурированно выставленные города с небольшими смещениями.

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

Основная часть всего этого происходит в довольно объёмном методе CreateCities. Этот метод в качестве аргумента принимает локальную позицию шестиугольника. В результате работы метода могут сгенерироваться область, координата города и сам город. Код этого метода приведён в Приложении 2.

Также мною был использован порождающий паттерн проектирования - Объектный Пул. Суть данного паттерна заключается в том, что в некоторых программах создание новых объектов довольно ресурсоёмкая операция и получается более выгодным не генерация и удаление объектов, а их повторное использование, что и позволяет нам сделать объектный пул. В рамках данного проекта я создал пул объектов, которых способен хранить в себе любые игровые объекты, присутствующие на сцене, причём при перемещении в пул объекты сразу отключаются, что делает невозможным какое-либо взаимодействие игрока с ними. Из пула объекты извлекаются по имени, так что все объекты, которые создаются на сцене, для каждой особенной текстуры имеется отдельное имя, например, WinterMountain или FallForest. Реализация данного класса представлена в Приложении 3.

Помимо Объектного пула так же мною был многократно реализован шаблон Singleton. Он встречается в таких классах, как ObjectPool, MainMap, Controller, PauseScript и PersistentData. Суть данного паттерна в том, что он обеспечивает наличие только одного экземпляра класса. Это позволяет инкапсулировать свой код и не позволить кому-либо неправильно им воспользоваться. Так, например, у класса ObjectPool, должен быть только один экземпляр пула, чтобы все объекты, помещённые в него, хранились в единственном месте, а не были разбросаны по куче инициализированных пулов. Образец можно рассмотреть в Приложении 3.



6. ТЕСТИРОВАНИЕ ПРОГРАММНОГО ПРОДУКТА

6.1 Обоснование методики тестирования

В ходе разработки я проводил модульное тестирование, т.е. по мере внедрения проверял работоспособность и корректность результатов работы отдельных модулей программы. Такой подход позволил выявить некоторые ошибки до их внедрения в общую систему. Например, встроенный в Unity алгоритм «Шум Перлина», который должен возвращать значения от 0 до 1 включительно, иногда выдавал значение 1,01 или -0,01, что, в результате тестирования, было исправлено.

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

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

Для всех тестирований применялась комбинированная стратегия тестирования, так называемый «серый ящик». Такой подход был выбран по причине того, что я сам тестировал приложение и при нахождении какой-либо ошибки в работе модуля, начинал искать несоответствия и ошибки в коде.

6.2 Результаты тестирования

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

Рисунок 6.1 - Пример недоработки

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



ЗАКЛЮЧЕНИЕ

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

Реализована генерация карты высот по «зерну», для этого используется алгоритм «Шум Перлина», а «зерно» - это смещение шума по осям.

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

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

Перемещение игрового персонажа реализовано при помощи алгоритма «Поиск в ширину», позволяющий искать кратчайший путь до указанной точки.

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

Ведение боя реализовано в основном при помощи встроенных в Unity алгоритмов, как, например, компонент NavMeshAgent, позволяющий создать простенький искусственный интеллект для перемещения игровых объектов по сцене в обход препятствий.

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

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

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



СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. СТО ВоГУ-МУ.1-2019. Выпускная квалификационная работа. Требования к структуре, содержанию и оформлению. Версия 01. - Введ. 19.02.2019. - Вологда: ВоГУ, 2019. - 67 с.



ПРИЛОЖЕНИЕ

Блок-схема алгоритма поиска в ширину



Метод для генерации городов на карте

Реализация пула объектов



Размещено на Allbest.ru

...