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

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

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

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

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

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

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

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

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

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

Таблица 4

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

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].