Разработка уровня «головоломка» в мультижанровой игре

4.1 Реализация уровня головоломка

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

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

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

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

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

Завершим разработку реализовав лечение и броню, а также лечение по таймеру в методе Update. Создадим проверки на переполнение здоровья и брони, указав максимальным пределом 100 единиц. Лечение через метод Heal, измененеие брони через useNewArmour.

Работа со сценами

Перейдем к работе со сценами в уровне головоломка, всего планируется 10 комнат в двух вариациях - одиночная игра, сетевая игра, которые будут иметь небольшое отличие для усложнение кооперативного прохождения. А также требуется загрузочная сцена для создания глобальных не разрушаемых объектов, таких как UI, Менеджеры, Сетевой модуль - для уровня и Глобальные игровые объекты (input Manager, Global_Scene Manager). Создав сцену PZL_Level0 и базовый UI, который описан далее по тексту, реализуем отображающий запуск скрипт.

В коде присутствует прописывание на события, происходящие в глобальном менеджере и запуск первого уровня по окончанию загрузки. Теперь рассмотрим основной менеджер, осуществляющий загрузку. Он имеет собственный игровой объект GameManagers, к которому привязаны все менеджеры, а детьми заданы UI и UIController. Ниже, рис 4.13, описывается событие при создании менеджера, который получает ссылки на все привязанные локальные менеджеры и запускает их. После, предоставляет доступ к каждому через себя. Далее такое обращение позволяет без труда получить доступ к игровым данным и реализовать сохранение.

Далее рассмотрим метод StartUpManagers(), реализованный в корутине Unity. Он использует составленный при создании объекта список менеджеров и в каждом запускает StartUp, реализацию интерфейса. В ходе запуска рассылаются события для отрисовки прогресса загрузки, по завершении события финиша и загружается уровень.

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

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

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

Работа с сохранениями

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

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

Работа со звуком

Фоновая музыка реализована в приложении GarageBadnd, звуки действий созданы Владиславом Макаровым, согласно распределению задач в команде. Для управления громкостью всех звуков и музыки используется PZL_AudioManager, хранящий глобальные переменные громкости и методы для их задания, основанные на событиях. Настройку будем осуществлять через UI, с помощью ползунков громкости, раздельно для музыки и звуков. Система Unity состоит из трех компонентов - звук, источник, слушатель

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

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

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

Реализация основных игровых скриптов

После подготовки всех спрайтов, объектов на сцене и менеджеров перейдем к реализации основных скриптов из группы Controller, которые отвечают за действия игрока, объектов, врагов и другие игровые механики. Ниже приведена таблица скриптов-контроллеров и их описание. Для эффективной разработки было изучено руководство по искуссному написанию сценариев в Unity А. Торна [12].

Таблица 4.2 Контроллеры и их описание

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

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

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

Достижения

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

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

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

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

Сложность и балансировка

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

1. Максимальный уровень здоровья.

2. Максимальный уровень брони.

3. Максимальная стамина.

4. Урон от пуль.

5. Время реакции робота.

6. Размер регенирируемого здоровья.

7. Размер регенирируемой брони.

8. Дополнительные банки здоровья.

9. Дополнительная броня.

10. Дополнительные противники.

11. Отключение зон с газом.

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

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

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

Сюжет и помощь в игре

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

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

Теперь рассмотрим вызов сообщений. Создадим на сцене объекты с бокс калайдером, которые будут триггер зонами. Далее привяжем универсальнй скрипт, рис. 4.43, который будет вызывать событие и оставлять пометку, о том, что данный нарратив показан. Ниже на рисунке 4.44, показана реализация зоны в Unity.

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

4.2 Реализация UI и игрового меню

В ходе работы был создан универсальный спрайт для фона, который делится на 9 частей и растягивается без искажения контуров. UI реализуется на новой технологии Unity. Общение между UI и Игрой осуществляется через UI контроллер и систему сообщений.

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

Следующим шагом расположим по центру экрана область и создадим следующие кнопки:

1. Продолжить - скрывает меню.

2. Перезапуск - запускает все под уровни заного.

3. Инвентарь - показывает окно предметов.

4. Достижения - отображает окно достижений.

5. Сохранить игру - сохраняет прогресс.

6. Загрузить игру - загружает последнее сохранение.

7. Главное меню - удаляет общие объекты и переходит в главное меню.

8. Настройки - переходит в общие настройки игры.

9. Ползунок громкости звука.

10. Ползунок громкости музыки.

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

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

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

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

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

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

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

4.3 Реализация сетевой составляющей

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

Серверная часть

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

1. Program.cs - основной класс, логика работы сервера по UDP.

2. AES.cs и MD5Hash.cs - классы для шифрования и дешифрования.

3. Config.cs - класс для конфигурирования и загрузки параметров.

4. GameObject.cs - класс для формирования и структурирования данных перед передачей.

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

1. #GameInfoObject - Тег обозначающий пакет с данными.

2. #AnswerRegistrServer - Ответ о регистрации данного сервера.

3. #PlayerInfo - Пример типа данных, идет после команды GameInfoObject.

4. #GetOnlineServerList - запрос списка всех серверов, вернет JSON в форме List<ServerItem>

5. #RegisterServer - Внесение сервера в список для ММ, вернет ответ в форме string

6. #AnswerOnlineServerList - Ответ листа серверов

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

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

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

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

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

Команда Attach добавляет данные в специальной форме с тегом #PlayerInfo для дальнейшей сериализации.

С разработкой сервера все, на данном этапе сервер может:

1. Зарегистрироваться на ММ сервере.

2. Подключиться к бд.

3. Получать и рассылать данные.

4. Шифровать и дешифровать данные.

5. Объединять данные.

6. Отсылать сообщение в БД.

7. Восстанавливать потоки в случае ошибки.

8. Имеет конфигурационный файл.

Клиентская часть

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

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

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

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

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

Подводя итог, клиент получил следующий функционал:

1. Получить список серверов.

2. Послать сообщение на сервер.

3. Получить данные от сервера.

4. Шифровать и дешифровать данные.

5. Объединять данные по необходимости.

6. Восстанавливать потоки в случае ошибки.

7. Имеет конфигурационный файл.

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

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

Интеграция в Unity

Последний этап разработки сетевого кода - интеграция клиентской части приложения в Unity. Сделаем копию сцены и добавим на ней копию игрока, но отключим PlayerController, который отвечает за управление. Затем добавим объект Network, на котором будут все сетевые компоненты.

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

Отметим, что использовать корутины для таких тяжелых задачь как сервер нельзя, поскольку они представляют из себя лишь выполнение кода между кадрами. Прослушивание так же, как и в тестовом клиенте будет происходить в отдельном потке, по средствам C#.

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

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

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

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

4.4 Сборка в единую систему

Завершив разработку первой версии уровня и сервера, настало время собрать весь проект в единую систему. В первую очередь идет объединение проекта Unity, поэтому проводим проверку всех наименований, добавляем префиксы PZL_ и создаем папки в общих файлах, затем создаем Unity Packet. Далее создается общее облако в Unity и все файлы собираются в единый проект. Для серверной части создано хранилище Git в Microsoft Foundation Service.

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

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

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

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

Заключение

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

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

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

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

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

Работа выполнена согласно запланированного дизайн документа, в процессе проектирования и разработки вносились небольшие правки, улучшающие общую картину. Созданный продукт доступен для скачивания. В рамках продукта реализовано более 2655 строк для уровня «Головоломка» и 1596 строк для сетевого модуля. В числе этого более 110 методов, в 46 скриптах, на клиентской части, список доступен в приложении И, более 23 методов, в 17 классах, на серверной части. На каждой сцене уровня головоломка содержится около 100 объектов и еще около 70 объектов для создания пользовательского интерфейса. Для сохранения игры используется более 10 параметров. Говоря о групповой работе, в репозитории Unity, после объединения проектов в единую игру сделано более 115 коммитов с исправлениями и доработками.

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

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

Библиографический список

1. Бойко-Романовский К., Рынок компьютерных игр, как ниша в бизнесе // www.forbes.ru: Бизнес, финансы, компании, миллиардеры, новости, инвестиции. 23.02.2018. URL: http://www.forbes.ru/tehnologii/357631-sereznye-zabavy-pochemu - videoigry-stanovyatsya-populyarnee-kino (Дата обращения: 7.09.2018)

2. Batchelor J. The Year In Numbers 2017 // www.gamesindustry.biz: The resource for people who make and sell games. URL: https://www.gamesindustry.biz /articles/2017-12-20-gamesindustry-biz-presents-the-year-in-numbers-2017 (Дата обращения: 12.09.2018)

3. Aleem S., Fernando L. Capretz, and Faheem A. A Consumer Perspective on Digital Games, IEEE Consumer Electronics Magazine. США, 2018. 5 с.

4. Нилов С. Как писать дизайн документы для игр //dtf.ru: игры, кино, сериалы, сообщество. 21.12.2017. URL: https://dtf.ru/gamedev/13891-kak-napisat-dizayn-dokument-igry (Дата обращения: 20.01.19).

5. Koen Witters. deWiTTERS Game Loop //Koonsolo.co: helps you make games. 13.07.2009. URL: http://www.koonsolo.com/news/dewitters-gameloop/ (Дата обращения: 25.12.18).

6. Adam. Entity Systems are the future of MMOG development // t-machine.org T-Machine, 11.11.2007. URL: http://t-machine.org/index.php/2007/11/11/entity-systems-are-the-future-of-mmog-development-part-2/ (Дата обращения: 25.12.18).

7. Fiedler G., Networking for game programmers // gafferongames.com. URL: https://gafferongames.com/post/udp_vs_tcp/ (Дата обращения: 5.11.18 - 12.02.19).

8. Дикинсон К. Оптимизация игр в Unity 5. М., ДМК Пресс, 2017. 306 с.

9. Хокинг Д. Unity в действии. Мультиплатформенная разработка на C# 2-е межд. изд. СПб.: Питер, 2019. 352 с.

10. Албахири Д., Албахири Б. С# 6.0. Справочник. Полное описание языка, 6-е издание. М.: Первая образцовая типография, 2016. 1040 с.

11. Gomila L. Официальный сайт разработчика SFML //sfml-dev.org: Simple and Fast Multimedia Library. URL: https://www.sfml-dev.org (Дата обращения: 19.09.18).

12. Торн А. Искусство создания сценариев в Unity. М.: ДМК Пресс, 2016. 360 с.

13. Паласиос Х. Unity 5.х. Программирование искусственного интеллекта в играх. М.: ДМК П ресс, 2017. 272 с.

14. Мэннинг Д., Батфилд-Эддисон П. Unity для разработчика. Мобильные мультиплатформенные игры. СПб.: Питер, 2018. 304 с.

15. Гибсон Б. Unity С#. Геймдев от идеи до реализации. 2-е изд. СПб.: Питер, 2019. 928 с.

16. Ламмерс К. Шейдеры и эффекты в Unity. Книга рецептов М.: ДМК Пресс, 2014. 274 с.

17. Торн А. Основы анимации в Unity, М.: ДМК Пресс, 2016. 176 с.

18. Фленов М.Е. Искусство программирования игр на C++. СПБ. БХВ-Петербург., 2006. 256 с.

19. Букреев. П. Информация по разработке игр на графической библиотеке SFML // kychka-pc.ru. URL: http://kychka-pc.ru/sfml/urok-1podklyuc henie-biblioteki-k-srede - razrabotki-visual-studio-2013.html (Дата обращения: 19.09.18).

20. McAllister G., White G.R. Video Game Development and User Experience. США: Springer, 2015. 11 с.

21. Scacchi W. Practices and Technologies in Computer Game Software Engineering. США: IEEE Consumer Electronics Magazine, 2017. 7 с.

22. Lengyel E. Mathematics for 3D Game Programming and Computer Graphics, Third Edition. Китай: Cengage Learning, 2011. 566 с.

23. Bingqing Z., Wenfeng H., Game Special Effect Simulation Based on Particle. США: IEEE ICIS, 2017. 4 с.

24. Meliones A., Plas I., Developing Video Games with Elementary Adaptive Artificial Intelligence in Unity. США: IEEE Consumer Electronics Magazine, 2017. 8 с.

25. Millington I., Funge J., Artificial Intelligen, США: Elsevier, 2006. 895 с.

26. Ramadan R., Hendradjaya B., Development of Game Testing Method for Measuring Game Quality. США: IEEE Consumer Electronics Magazine, 2014. 8 с.

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