Разработка многопользовательской ролевой онлайн игры "World of Magic"

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



Оглавление

• Введение
• 1. Аналитический обзор
• 1.1 Анализ предметной области
• 1.2 Анализ требований к разрабатываемой игре
• 2. Проектирование
• 2.1 Разработка архитектуры
• 2.2 Анализ и выбор средств разработки
• 2.3 Проектирование схемы базы данных
• 2.4 Проектирование GUI
• 3. Реализация
• 3.1 Серверное приложение
• 3.2 Клиентское приложение
• 4. Тестирование
• 4.1 Функциональное тестирование
• 4.2 Нагрузочное тестирование
• 4.3 Тестирование самовосстановления системы после внепланового отключения
• Заключение7
• Список используемых источников
• Приложение 1 Блок-схема функции server_accept
• Приложение 2 Файл Elements.h

• Введение
• Актуальность
• В наше время почти у каждого второго человека есть компьютер, они являются неотъемлемой частью жизни. Пару десятилетий назад не каждый мог себе позволить ЭВМ. Но те времена прошли. Сейчас дети с раннего возраста пользуются смартфонами и планшетами, а иногда даже компьютерами. Более взрослые люди уже умеют пользоваться этими устройствами для работы или отдыха. С каждым годов ЭВМ наращивают мощности и становятся более доступными. С развитием техники идёт и развитие игровой индустрии, чем мощнее компьютеры, тем красочнее и производительнее игры. Именно из-за этого разработка игр для телефонов и компьютеров в наше время очень хорошо оплачивается. Актуальность разработки можно подтвердить статистикой приведённой на сайте App2Top [1]. Эксперты компании считают, что прибыль с игр по итогу 2018 года составят $138 млрд. Это на 13% больше, чем индустрия заработала в прошлом году. Доля прибыли компьютерных игр составляет 24%.
• MMO RPG - это жанр игр, предполагающий взаимодействие пользователей между собой и исполнение каких-то ролей. Это как торговец, солдат и врач. Один лечит, другой калечит, а третий наживается.
• Цели и задачи
• Целью данной работы является разработка игры в жанре MMORPG для компьютера. Для достижения поставленной цели необходимо решить следующие задачи:
• 1) провести анализ аналогичных игровых приложений и анализ существующих решений;
• 2) спроектировать приложение;
• 3) реализовать игру;
• 4) протестировать игровое приложение.
• Структура и объём работы
• Работа состоит из введения, 4 глав, заключения, списка используемых источников и приложений. Объем работы составляет 42 страницы, объем списка используемых источников - 12 источников, объем приложения - 3 страница. игра приложение тестирование игровой
• Содержание работы
• В первой главе, «Аналитический обзор», рассматриваются примеры существующих игр в жанре «MMO RPG, выделены особенности разрабатываемой игры и ее интерфейса.
• Вторая глава содержит определение функциональных требований к разрабатываемой игре. Представляется проектирование интерфейса.
• В третьей главе, представлено проектирование приложений.
• В четвертой главе, «Тестирование игрового приложения», проведено функциональное тестирование разрабатываемой игры, нагрузочное тестирование и тестирование системы на самовосстановление.
• В заключении сделаны выводы о проделанной работе.
• В приложениях продемонстрирована блок-схема одной из важнейших функций и один из заголовочных файлов.


1. Аналитический обзор

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

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

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

1.1.1 Классификация игр

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

Игровые платформы:

1) PC и ноутбуки.

2) смартфоны и планшеты.

3) консоли и приставки (Sega, Sony PlayStation 4, Xbox360).

Виды игр по количеству игроков:

1) одиночные игры

2) совместные игры

3) многопользовательские игры

Виды сетевых игр:

1) браузерные и социальные игры

2) мобильные игры

3) клиентские игры

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

1.1.2 Массовые многопользовательские игры

Жанр MMO (Massively multiplayer online) - массовые многопользовательские онлайн игры. Он расширяет возможности обычных жанров, дарует новые возможности и перспективы развития.

Среди MMO можно выделить четыре основных жанра:

1) MMORPG (massive multiplayer online role-playing game) - ролевые

2) MMORTS (massive multiplayer real time strategy) - стратегии

3) MMOFPS (massive multiplayer online first person shooter) - шутеры

4) MOBA (multiplayer online battle arena) - боевые арены

MMORPG - жанр игр, в котором большое количество игроков заключено в огромном виртуальном мире, наполненном контентом: приключениями, опасностями и живописным окружением (графикой и музыкой). Основной упор таких игр сделан на социальное взаимодействие - общение, друзья, браки, группы, гильдии, альянсы и сражения. То есть коммуникацию и взаимодействие игроков друг с другом. Это почти как социальная сеть, только с графической оболочкой и иным функционалом. Примеры многопользовательских игр: World Of Warcraft, Shining Nation (Рисунок 1), Ap:piel (Рисунок 2).

Рисунок 1 MMORPG Shining Nation

Рисунок 2 MMORPG Ar:piel Online

1.1.3 Анализ игровых движков

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

Unreal Engine 4 - это игровой движок от компании Epic Games. Написан на С++ и кроссплатформенный [3]. Упрощённое портирование, модульная система зависимых компонентов, различные системы рендеринга, сетевые модули и поддержка различных устройств ввода далеко не полный список всех особенностей движка.

Преимущества:

1) полный доступ к исходным кодам;

2) система Blueprint для написания игровой логики;

3) компиляция С++ кода во время тестирования игрового приложения;

4) богатый функционал;

Недостатки:

1) высокие системные требования;

2) сложность в освоении;

3) плохая оптимизация игровой физики и теней.

Unity3d - это современная среда разработки для создания игр и приложений, разработанная компанией Unity Technologies [3]. Игры можно разрабатывать как для pc, так и для телефонов и консолей.. Огромной плюс данной платформы - это простота разработки приложений и игр для мобильных устройств, как от самых простых в разработке, так и до самых сложных. В Unity есть возможность запускать любое приложение в веб-плагине.

Преимущества:

1) самое большое комьюнити в мире среди всех существующих платформ, для разработки игр и приложений;

2) хороший игровой редактор;

3) огромное количество инструментов для разработки приложений и игр;

4) присутствует внутренний магазин, где можно найти много всего полезного для создания своего проекта;

5) большое количество библиотек, которые позволяют расширить функционал платформы;

6) быстрая компиляция.

Недостатки:

1) у разработчиков нет доступа к исходному коду платформы на системном уровне;

2) условно-бесплатный.

Game Maker - не очень популярный, но довольно интересный игровой движок для создания 2D игр [2].

Преимущества:

1) поддержка расширений и библиотек

2) интеграция со Steam, GooglePlay, AppStore

Недостатки

1) плохая поддержка 3D

2) Среда разработки доступна только на Windows



Таблица 1

Анализ игровых движков

Движок	Языки	Лицензия	Год выпуска
		Free	Plus	Pro
Unity	C#, JS	+	35$/мес.	125$/мес.	2005
Unreal Engine	C++	+	5% прибыли	5% прибыли	1998
Game Maker	GML(JS)	+	$39	$99/$399	2012

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

1.1.4 Анализ библиотеки для разработки игр

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

Популярные мультимедийные библиотеки:

1) OpenGL / Vulkan

2) DirectX

3) SFML

4) SDL 2.0

OpenGL - интерфейс для графических приложений.

Преимущества:

1) широкий функционал

2) кроссплатформенность

Недостатки

1) сложность освоения и применения

Vulkan (glNext) - Это прикладной язык программирования, с помощью которого можно получить полный контроль над видеокартой и её процессами, а также возможности создания 3D и 2D картинки.

Преимущества: позволяет снизить нагрузку на видеокарту, сохраняя качество.

Недостатки: схожесть с названием казино Vulkan, портящее репутацию.

DirectX - графический интерфейс для приложений Windows.

Преимущества:

1) организация максимально реалистичной графики в играх

2) бесплатный доступ к загрузке любой версии платформы

Недостатки:

1) только под Windows

2) при установке игр требуется установка DirectX

SFML - простая и быстрая мультимедийная библиотека

Преимущества:

1) минимальные требования к уровню знаний языка

2) лёгкость освоения

3) кроссплатформенность

4) унаследовала функционал openGL

Недостатки:

1) Плохая поддержка 3D графики

SDL 2.0 - кроссплатформенная 2D библиотека, предназначенная для написания приложений (в основном игр).

Особенности:

1) кроссплатформенность

2) быстрота

3) надёжность

4) лёгкость в эксплуатации

Таблица 2

Анализ графических библиотек

Библиотека	Кроссплат-форменность	тяжесть освоения	Функциональность	3D графика
openGL/Vulkan	+	тяжело	+	+
DirectX	-	тяжело	+	+
SFML	+	просто	-	-
SDL 2.0	+	просто	+	-

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

1.1.5 Интегрированные среды разработок

Из одной библиотеки приложения не сделаешь, нужен компилятор, а ещё лучше - среда разработки. Приведём список популярных IDE [5], и выделим особенности выбранной среды.

Основные среды разработки, которые могут подойти для разработки игр:

1) Microsoft Visual Studio (проще написать какие языки не поддерживает)

2) Android Studio (Java, Cotlin, C, C++, Python, Basic, Lua)

3) NetBeans (С, C++, HTML5, Java, PHP и др.)

4) IntelliJ IDEA (HTML, JS, NodeJS, PHP, Phyton, Ruby, TypeScript и др.)

5) Eclips (С, C++, Java, Perl, PHP, …)

Microsoft Visual Studio (MVS или VS)

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

Языки: Ajax, ASP.NET, DHTML, JavaScript, JScript, Visual Basic, Visual C#, Visual C++, Visual F#, XAML и другие.

Особенности:

1) огромная библиотека расширений, которая постоянно увеличивается;

2) настраиваемая панель и закрепляемые окна;

3) простой рабочий процесс и файловая иерархия;

4) статистика мониторинга производительности в режиме реального времени;

5) инструменты автоматизации;

6) легкий рефакторинг и вставка фрагментов кода;

7) поддержка разделенного экрана;

8) список ошибок, который упрощает отладку;

9) проверка утверждения при развертывании приложений при помощи ClickOnce, Windows Installer или Publish Wizard.

Недостатки:

супертяжелая (требует много памяти)

Из приведённых выше сред разработки была выбрана именно Visual Studio. Причины выбора очень просты - среда очень мощная, удобная, практически безошибочна и удобная трассировка ошибок. Не маловажным фактором является трёхлетний опыт работы с данной средой разработки. Также имеются хорошие уроки на русском языке по работе игр с помощью SFML и Visual Studio [2].



1.1.6 Выводы

Игровая индустрия на сегодняшний день является крупным сектором в ИТ.

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

1.2 Анализ требований к разрабатываемой игре

При разработке многопользовательской сетевой онлайн игры следует отталкиваться от требований и проблем, которые присуще современным ММО играм, а также на опыт создания компьютерных игр предыдущих лет [6].

Требования к сервер-приложеням:

1) одновременная обработка большого количества клиентов

2) обеспечение производительности

3) способность реагировать на несанкционированный доступ

4) способность к восстановлению, после выключения

Требования к клиент-приложениям:

1) показатель FPS не должен падать ниже 24 кадров в секунду.

2) запуск приложения должен осуществляться в течении 10 секунд (некоторые игры запускаются по 1-2 минуты, что не удивительно при наличии мощной графической оболочки)

Техническое предложение.

В качестве технического предложения предлагается создать MMORPG игру - систему из двух взаимодействующих по сети приложений, написанных на языке С++ и использующих мультимедийную библиотеку SFML. Этими приложениями являются сервер-приложение и клиентское приложение. Клиентское приложение передаёт действия игроков на сервер, а сервер в свою очередь регламентирует поведение игры и сообщает игрокам о том, как игра повела себя после действий конкретного игрока.



2. Проектирование

2.1 Разработка архитектуры

Всю систему можно поделить на три части: клиентское приложение, сервер-приложение и база данных [7]. В схематичном виде архитектура системы изображена на рисунке 2.1.

База данных хранит все данные о состоянии игры на конкретный момент времени: информацию об игроках и их характеристиках, о предметах, принадлежащих игрокам и об игровых объектах.

Сервер-приложение при старте выбирает нужную информацию из базы данных, и создаёт игровой мир (модуль данных). Далее запускается обработчик игры (логический модуль) и сетевой обработчик (сетевой модуль). Задача сетевого модуля - принимать данные о действиях игроков и отправлять эти действия в логический модуль. Логический модуль при получении данных принимает решение, о том, что сделал клиент, и при необходимости меняет данные в модуле данных и выдаёт сетевому модулю информацию для отправки. Тот в свою очередь рассылает данные подключённым клиентам.

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



Рисунок 2.1 Схема архитектуры системы

2.2 Анализ и выбор средств разработки

Из рассмотренных в аналитическом обзоре платформ, игр, игровых движков, библиотек и IDE были выбраны средства разработки (Таблица 3).

Таблица 3

Выбранные средства разработки

Средство	Название	Причина выбора
IDE	Visual Studio 2017 Community	Мощная и бесплатная среда для разработки программ на С++. Опыт работы: 3+ лет
Библиотека	SFML	Простота и эффективность. Опыт работы: 3+ лет
База данных	MySQL Server 5.5	Потому что подключилась и работает
Графические редакторы	Paint / Paint.net	Простые и бесплатные графические редакторы Опыт работы: 10+ лет.

Из выбранных ПО и средств будут составлены две программы:

- Client-приложение, которое предоставляет клиенту доступ в игровой мир (подключение к Server-приложению).

- Server-приложение, необходимое для организации взаимодействия между несколькими Client-приложениями.



2.3 Проектирование схемы базы данных

Для хранения информации о состоянии системы потребуется база данных [8].Она будет хранить информацию об учётных записях (клиентах), их персонажах, а также параметрах и предметах, которые принадлежат этим персонажам. Для этого мне потребовалось 6 таблиц. Самая главная таблица - clients, таблица в которой будет храниться информация о клиентах. Информация о персонажах и предметах будет храниться в других таблицах. Также будет отдельная таблица под игровые объекты и две таблицы связки для атрибутов и предметов, которые имеются у клиентов в наличии. На рисунке 2.2 представлена схема базы данных.

Рисунок 2.2 Схема базы данных

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

Таблица 4

Сведения о схеме данных

Имя таблицы	Атрибут	Ключ	Назначение
clients	Id	PK	ID клиента
	Login	-	Логин клиента
	Password	-	Пароль клиента
	Name	-	Имя персонажа
	X	-	Координаты персонажа
	Y	-
Objects	Id_obj	PK	ID объекта
	Type_obj	-	Тип объекта
	Info_obj	-	Информация об объекте
	X	-	Координаты объекта
	y	-
Atributs	Id_atr	PK	ID атрибута
	Name_atr	-	Имя атрибута
	Info_atr	-	Информация об атрибуте
Items	Id_item	PK	ID предмета
	Name_item	-	Имя предмета
	Info_item	-	Информация о предмете
Unique_atributs	Id	FK	ID персонажа
	Id_atr	FK	ID атрибута
	Value	-	Значение атрибута
	Info	-	Информация
Unique_items	Id	FK	ID игрока
	Id_item	FK	ID предмета
	slot	-	Номер слота
	count	-	Количество предметов

2.4 Проектирование GUI

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

В клиентском приложении GUI представляет собой структуру данных, которая объединяет в себе управляющие и информирующие внутри-игровые элементы (Windows, Buttons, Labels, Slots, TextBoxs и т.д.). В приложении 2 можно увидеть существующие элементы. Все элементы хранятся в векторах (Рисунок 2.3.). Для удобства использования были созданы 3 вектора. В первом они находятся в порядке отрисовки на экране, во втором - в порядке добавления к GUI, а в третьем - связка кода клавиши и окна.

Рисунок 2.3 Векторы, хранящие ссылки на окна

Для добавления окна к GUI используется функция addWindow, принимающая входными параметрами идентификатор текстуры, координаты окна в игре, размеры окна, ключевая клавиша, по которой будет открываться/закрываться окно и название окна (Рисунок 2.4). Текстура необходима для графического отображения окна на экране, она будет растягиваться по размеру окна. После всех настроек окно добавляется в вектора и связывается с GUI c помощью переменной gui. В случае чего окно всегда сможет обратиться к вышестоящей структуре.

Рисунок 2.4 Функция создания окна

Все элементы в GUI унаследованы от базового класса Element (Рисунок 2.6). У этого класса есть всё необходимое, для того чтобы от него создать производные классы GUI. Определено множество виртуальных функций, для того чтобы наследуемые элементы могли либо использовать уже имеющиеся функции, либо использовать усовершенствованную версию функцию [9]. Иерархия классов GUI представлена на рисунке 2.5.



Рисунок 2.5 Иерархия наследования элементов GUI

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

Рисунок 2.6 Класс Element

Обработка событий (нажатие мыши и/или клавиатуры) происходит с помощью функций eventKey и eventMouse (Рисунок 2.7).

Рисунок 2.7 Функции обработки клавиатуры и мыши

Эти функции идут по иерархии вызова прямо из игры (Рисунок 2.8).

Рисунок 2.8 Пример иерархии вызова функции у элемента GUI

GUI настраивается в функции init_interface принадлежащей классу Game. Пример кода создающего внутри-игровое окно представлен на рисунке 2.4.1.

Рисунок 2.9 Создание внутри-игрового окна «Инвентарь»

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

Рисунок 2.10 Внутри-игровое окно «Инвентарь»



3. Реализация

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

3.1 Серверное приложение.

3.1.1 Соединение с базой данных MySQL

База данных и таблицы создаются вручную из приложения. Из предоставленного функционала MySQL и предполагаемым игровым функционалом были составлены соответствующие названия таблиц и данные для их заполнения. Для удаления и создания нужных таблиц созданы специальные функции createTables и dropTables соответственно. Функция createTable изображена на рисунке 3.1. Функция создания таблиц подразумевает, что таблицы ещё не созданы, а если и созданы, то они удалятся функцией удаления таблиц. Очень важно понимать, что при удалении всех таблиц данные о состоянии игрового мира будут стёрты, поэтому функцию удаления таблиц лучше закомментировать на всякий случай. Для просмотра запросов при вызове функций нужно установить входной параметр flag равный true и увидеть все запросы и их результаты, которые будут выполнены при вызове функции. После удаления таблиц создаются 6 таблиц, которые заполняются значениями, указанными в соответствующих функциях.



Рисунок 3.1 Функция для создания таблиц в базе данных

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

Рисунок 3.2 Функция createTable_items заполняющая таблицу items данными

Рисунок 3.3 Функция query, выполняющая запросы к базе данных

Для удобства тестирования запросов к функции был добавлен параметр flag, который при истинном значении выводит в консоль как сам запрос, так и его результат: true - если выполнен успешно, false - если ошибка в запросе [10].

3.1.2 Описание серверной части приложения

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

Серверное приложение работает с двумя потоками и с двумя объектами - game и network. Объект game хранит в себе состояние игры и обрабатывает игру. Объект network отвечает за то, чтобы у игроков в клиентском приложении было точно такое же состояние игры, как и на сервере. Вся информация о состоянии игрового мира хранится в базе данных и периодически обновляется. Первый поток обрабатывает функцию network_handler(), которая отвечает за сетевую обработку, а второй поток обрабатывает функцию game_handler(), которая отвечает за игровую обработку. В функции main() создаются и настраиваются эти самые потоки. Также настраивается объект network - ему задаётся номер порта и добавляется слушатель на этот порт. Код функции main() представлен на рисунке 3.4.

Рисунок 3.4 Главная функция

Сетевой обработчик всего лишь запускает функцию обработки сервера server_accept() объекта network. Реализацию сетевого обработчика можно посмотреть на рисунке 3.5.

Рисунок 3.5 Сетевой обработчик

Игровой обработчик включает в себя три переменные и игровой цикл. Сначала создаётся игровое окно - window, затем переменная для хранения времени между обработками приложения - time, и clock - счётчик времени, класс предоставленный библиотекой SFML для подсчёта времени. Игровой цикл работает до тех пор, пока игровое окно не будет закрыто. В начале цикла в переменную time записывается время, которое отсчитал счётчик после последнего обнуления счётчика, после чего счётчик обнуляется, для засекания очередного промежутка времени. Когда промежуток времени стал известен, ссылка на окно и время передаются в игру для дальнейшей обработки с помощью функции behavior() объекта game. Реализация игрового обработчика представлена на рисунке 3.6.

Рисунок 3.6 Игровой обработчик

Объект network включает в себя два объекта - listener и selector, предоставленные библиотекой SFML, которые необходимы для организации сетевого взаимодействия. Также объект network содержит массив всех текущих подключений - sockets, и массив для накопления пакетов для отправки - listOfPackets. Вся информация о клиентах и функционал для работы с ними хранится в базе клиентов - base. Функционал для обработки пакетов хранится в объекте lib. Структура Network представлена на рисунке 3.7.

Рисунок 3.7 Структура Network (Network.h)

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

- server_accept

- handler_packets

- send

- sendAll

Handler_packets() - отвечает за обработку принятых пакетов в зависимости от кода пакета. В зависимости от кода пакета вызывается соответствующая функция, которая была привязана к этому коду. Все функции вызываются из объекта lib. В функции в качестве параметров передаются подключение(сокет и клиент) и сам пакет. Функция handler_packets() представлена на рисунке 3.8.

Рисунок 3.8 Функция handler_packets

Функция server_accept для понятности и наглядности представлена в виде блок-схемы в приложение 1. Объявление функции изображено на рисунке 3.9.

Рисунок 3.9 Объявление функции server_accept

Функция send() рассылает накопленные пакеты (Рисунок 3.10).

Рисунок 3.10 Функция send рассылающая накопившиеся пакеты LibPackets

В структуре Network присутствует структура LibPackets, которая содержит функционал для обработки пакетов. Код структуры представлен на рисунке 3.7. Почти каждая функция принимает входным параметром Connect (сокет и клиент) и packet (пакет). Также структура имеет ссылку на объект Network, чтобы иметь обратную связь с сетевым интерфейсом.

Рисунок 3.11 Структура LibPackets (Network.h)

Функции названы так, чтобы отразить их назначение:

registration - регистрация на сервере

login - авторизация

logout - выход с сервера

set_nickname - установить имя персонажа

connect_client - оповещение уже подключенных клиентов о подключении другого клиента

disconnect_client - оповещение подключенных клиентов об отключении другого клиента

clients_pos_all - послать координаты всех игроков игроку, который только что подключился

nextpos - оповестить всех клиентов о том, что игрок начал перемещение

message - оповестить всех клиентов о том, что игрок что-то написал в чат.

3.2 Клиентское приложение

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

Сначала мы подключаемся к серверу с помощью функции connection. После того как успешно подключились, мы запускаем поток обработки пакетов и продолжаем выполнять функцию main (Рисунок 3.12)

Рисунок 3.12 Начало функции main

После того как клиент подключился к серверу, можно регистрироваться или авторизоваться на сервере. Это делается с помощью ввода логина и пароля в консоль. Сначала идёт регистрация, потом авторизация (Рисунок 3.13).

Рисунок 3.13 Код отвечающий за регистрацию и авторизацию на сервере

Игровой цикл сводится к тому, что игра обрабатывается и рисуется с течением времени. Игровой цикл можно увидеть на рисунке 3.14. В переменной time накапливается время, между итерациями цикла, и, ориентируясь на это время, игра обеспечивает плавность и равномерность движения.

Рисунок 3.14 Игровой цикл



4. Тестирование

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

4.1 Функциональное тестирование

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

4.1.1 Тестирование сервер приложения

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

Для тестирования запросов к базе данных была специально разработана функция query, которая принимает параметр тестирования flag. Если его установить в true, то в консоль будет выдаваться информация о выполнении запроса. На рисунке 4.1. изображена консоль, в которую выводится информация о клиентах, которые имеются на начало старта сервера и после окончания его работы, путём закрытия окна приложения.



Рисунок 4.1 Скриншот консоли сервер приложения

Сначала выводиться сам запрос, потом его результат (true - выполнен, false - ошибка запроса), после чего выводятся данные, если запрос предусматривал выборку.

Тестирование сетевого модуля начнём с авторизации (Рисунок 4.2.). Сначала включим сервер. Затем через клиента попробуем перебрать все варианты авторизации: ошибка ввода логина, ошибка ввода пароля, успешная авторизация и когда клиент уже онлайн и если нельзя зайти на аккаунт. Когда клиент не авторизирован, он имеет идентификатор -1. После того как клиент успешно авторизовался, ему выдаётся идентификатор клиента, к которому пытался получить доступ игрок. Всё работает, так как должно. Если игрок вводит ошибочные данные, ему выдаётся соответствующий пакет с оповещающей информацией. Если данные вводятся правильно, то игрок получает данные об игре и своём персонаже, а подключённые игроки информацию об этом персонаже.

Рисунок 4.2 Скриншоты консолей при авторизации игроков

Теперь протестируем перемещение персонажа. На рисунке 4.3. изображена схема передачи сообщений между клиентами и сервером. Зелёными линиями и стрелками обозначены пакеты, которые идут на сервер, а красными - от сервера. Хронологический порядок пакетов лучше смотреть на сервере (слева на картинке 4.3.). Обозначение c>s означает, что сообщение пришло от Client к Server, и наоборот, s>c - от Server к Client. Первым делом игрок с id=7 присылает пакет на перемещение, после чего ответный пакет рассылается всем подключённым клиентам (в нашем случае id=6 и id=7). Далее принимается пакет на перемещение от игрока с id=6, и происходит тоже самое.

Таким образом, когда приходит пакет с номером 51, сервер создаёт свой пакет с номером 52, и рассылает его всем подключённым клиентам.

Рисунок 4.3 Схема передачи пакетов

По скриншоту видно, что координаты точки, куда должен двигаться игрок передаются правильно.

4.1.2 Тестирование клиентского приложения

Задача клиентского приложения - правильно отображать информацию с сервера и правильно посылать сигналы от клиентского приложения на сервер [12]. Для этого надо убедиться в том, что данные на сервере и на клиенте совпадают. Для сравнения подойдут координаты игрока. На рисунке 4.4 изображён персонаж со своими координатами, и предполагаемая точка, куда персонаж будет двигаться. Предполагается, что координаты у этой точки 300:300. После этого произведём нажатие ЛКМ по этой точке, и нам с сервера должен прибыть пакет, приказывающий двигаться в эту точку (Рисунок 4.5). Он пришёл, но координаты немного отличаются.

Рисунок 4.4 Персонаж, его координаты и следующий пункт назначения

Рисунок 4.5 Скриншот консоли с пакетами на перемещение

На рисунке 4.6. видно как персонаж встал в те координаты, в которые указал игрок. Отсюда следует, что клиентское приложение правильно обрабатывает запросы на перемещение персонажа.



Рисунок 4.6 Персонаж в новых координатах

Немаловажным остаётся тот факт, что приложение тестируется на одном компьютере. Для того, чтобы любой пользователь сети интернет мог подключиться к сервер-приложению, необходимо сервер-приложение разместить либо на оплачиваемом хостинге, либо к компьютеру, на котором запущено сервер-приложение подключить кабельный интернет. После чего узнать IP адрес и настроить этот адрес в клиентском приложении. Если запустить сервер-приложение на компьютере, который подключен только к сети Wi-Fi, то он будет виден клиентским приложениям, находящимся в этой Wi-Fi сети.

4.2 Нагрузочное тестирование

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

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

Рисунок 4.7 Функция автоматической авторизации

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

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

Рисунок 4.8 Код для имитации действий игрока

Теперь, когда наш персонаж автоматически управляется, останется только запустить соответствующее количество окон для нагрузочного тестирования. Пример подключения 20 клиентов представлен на рисунке 4.9. Все они бегают, но этого на картинке, конечно же, не видно .

Рисунок 4.9 Одновременное включение 20 игроков

4.3 Тестирование самовосстановления системы после внепланового отключения

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

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

Для сохранения информации о клиентах была разработана специальная функция updateClientPos (Рисунок 4.11). Когда на сервере происходит плановое отключение - например, нажатие крестика на окне приложения, сначала закрывается окно приложения, потом обновляются координаты клиентов, а затем уже происходит отключение от базы данных (Рисунок 4.10).

Рисунок 4.10 Код предусмотренного завершения сервер-приложения

Рисунок 4.11 Функция, обновляющая координаты клиента в базе данных

Проверить факт того, что информация о клиенте сохраняется при выключении сервер приложения можно только при его выключении и включении заново. Зайдём в игру тремя клиентами, и встанем в один ряд в определённых координатах (Рисунок 4.12). После чего отключимся всеми клиентами, и выключим сервер (Рисунок 4.13). После этого мы заново включаем сервер приложение, и подключаем одного клиента, которым специально отходили в угол для демонстрации сохранения координат в базе данных (Рисунок 4.14). Персонаж находится в тех самых координатах, в которых он был при отключении сервера, а значит, сервер обеспечивает целостность данных при плановом выключении.

Рисунок 4.12 Три персонажа встали в ряд для наглядности положения

Рисунок 4.13 Консоль сервера после выхода трёх персонажей и планового выключения сервера



Рисунок 4.14 Скриншот консолей и клиентского приложения после включения сервера повторно



Заключение

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

После анализа идёт проектирование системы. Первым делом разработали архитектуру системы, состоящую из базы данных, клиентского и серверного приложений. Для разработки программ были проанализированы и выбраны средства разработки, подходящие для этих целей - это Visual Studio 2017 Community и MySQL Server. Для хранения данных о состоянии игры к сервер-приложению должна быть подключена база данных, для которой была спроектирована схема базы данных. Также не маловажным этапом в проектировании является разработка графического пользовательского интерфейса, чтобы пользователю было удобно работать с нашей программой.

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

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

Распространение игрового приложение планируется в виде архива, содержащего приложение-клиент и все файлы, необходимые для поддержки этого приложения: файлы инициализации, dll-файлы, картинки, музыка и звуки, шрифты и другие. После получения архива клиент может извлечь данные из него, и, собственно, запустить игру. Если сервер в это время будет включен, а клиентское приложение будет знать правильный IP-адрес и порт, то игра запуститься. В будущем, когда игра обрастёт достаточным функционалом, она будет распространяться с помощью Steam либо собственными силами.

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



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

1. Мировой рынок заработает $137.9 млрд. за 2018 год [Электронный ресурс]. Режим доступа: https://app2top.ru/industry/mirovoj-ry-nok-igr-zarabotaet-137-9-mlrd-za-2018-god-120106.html (дата обращения: 12.05.19)

2. Лучший игровой движок по версии пользователей хабра [Электронный ресурс]. Режим доступа: https://habr.com/ru/post/307952/ (дата обращения: 19.03.19)

3. Unity против Unreal Engine 4: Битва титанов [Электронный ресурс]. Режим доступа: https://visschool.ru/blog/3d-viz-blog/unity-vs-unreal-engine-4-bitva-titanov-27/ (дата обращения: 19.03.19)

4. Обзор графических библиотек для С++ [Электронный ресурс]. Режим доступа: https://tproger.ru/digest/cpp-best-gui/ (дата обращения: 22.03.19)

5. 10 лучших IDE [Электронный ресурс]. Режим доступа: https://www.internet-technologies.ru/articles/10-luchshih-ide.html (дата обращения: 19.03.19).

6. Как начать писать игры [Электронный ресурс]. Режим доступа: https://habr.com/ru/post/160547/ (дата обращения: 19.03.19)

7. Глейзер Дж., Мадхав С. Многопользовательские игры. Разработка сетевых приложений. СПб.: Питер, 2017. 368 с.

8. Никсон Р. Создаём динамические веб-сайты с помощью PHP, MySQL и JavaScript. СПб.: Питер, 2013. 496 с.

9. Павловкая Т.А. С/С++. Программирование на языке высокого уровня. СПб.: Питер, 2014. 461 с.

10. Страуструп Б. Язык программирования С++. СПб.: БИНОМ, 1999. 991 с.

11. Луис Д. C и C++. Справочник. М.: Восточная книжная компания, 1997. 592 с.

12. Как делать свои игры бесплатно? Руководство по разработки инди-игр от T3 [Электронный ресурс]. Режим доступа: https://habr.com/ru/company/miip/blog/321922/ (дата обращения: 19.03.19)



Приложение 1

Блок-схема функции server_accept

Приложение 2

Файл Elements.h

// GUI v0.2

#ifndef DSL__GUI_ELEMENTS__H

#define DSL__GUI_ELEMENTS__H

// Headers

#include "Element.h"

// Defines

#define TYPE_WINDOW 1

#define TYPE_IMAGE 2

#define TYPE_LABEL 3

#define TYPE_BUTTON 4

#define TYPE_TEXTBOX 5

#define TYPE_CHECKBOX 6

#define TYPE_SLOT 7

class GUI;

class slotik;

class Window;

class SpaceItem;

class Game;

class Label: public Element

{

sf::Text* text;

public:

Label(sf::Text* t = nullptr);

Label(std::string str);

~Label();

void setText(std::string str, int code=0);

void draw(sf::RenderWindow* window);

void setPosition(float x, float y);

void setPosition(sf::Vector2f position);

void update();

};

class Button: public Element

{

void (*ptr_funct)(Game*, string, string); // ссылка на вып.функцию

sf::Text* text; // текст на кнопочке

public:

Button( void (*func)(Game*, string, string)=nullptr );

Button(std::string str, void (*func)(Game*, string, string)=nullptr);

Button(sf::Text* t, void (*func)(Game*, string, string)=nullptr);

~Button();

void draw(sf::RenderWindow* window);

void perform(std::string s1, std::string s2);

void setText(std::string str, int code=0);

void setPosition(float x, float y);

void setPosition(sf::Vector2f position);

void update();

};

class Slot: public Element

{

sf::Text text;

public:

sf::Sprite* sprite_item;

slotik* item;

Slot();

void draw(sf::RenderWindow* window);

void setPosition(float x, float y);

void setPosition(sf::Vector2f position);

void update();

void setText(std::string str, int code=0);

};

class Window: public Element

{

protected:

SpaceItem* items; // ссылка на сумку

Label text_name;

Button close;

std::vector<Element*> standart; // Базовые элементы на окне

std::vector<Element*> vec; // Добавленные элементы на окне

std::vector<Slot*> vecSlots; // Слоты

std::vector<Button*> vecButtons; // Кнопки

public:

bool isGhost; // Окно призрак - не учитывается при событиях мыши

GUI* gui;

Window();

Window(int code);

~Window();

void addElement(sf::Vector2f offset, Element* element);

void addElement(sf::Vector2f offset, int type_element);

void draw(sf::RenderWindow* window);

void draw(sf::RenderWindow* window, SpaceItem* items, bool isNull=false);

bool eventKey(int type, int code);

bool eventMouse(int type, int code);

void setText(std::string text, int code=0);

void update();

void setPosition(float x, float y);

void setPosition(sf::Vector2f position);

bool checkClose(float x, float y);

Button* checkButtons(float x, float y);

void updateSpaceItem(SpaceItem* xxx, int id=-1, int num=-1);

Element* getElement(int id);

Element* getElement(int type, int num);

Element* getElement(int type, sf::Vector2i pos);

int getNumSlot(sf::Vector2i pos);

void setSprite(sf::Sprite* s, int code=0);

void clearSlots();

};

#endif //DSL__GUI_ELEMENTS__H

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