Разработка компьютерных игр

Введение

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

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

Первые примитивные компьютерные игры были разработаны в 1950-х и 1960-х годах. Они работали на таких платформах, как университетские мейнфреймы и компьютеры EDSAC. В 1952 году появилась программа «OXO», имитирующая игру «крестики-нолики», созданная А. С. Дугласом как часть его докторской диссертации в Кембриджском Университете. В 1958 году Уильям Хигинботам в Брукхейвенской национальной лаборатории для развлечения посетителей создал «Tennis for Two» (с англ. — Теннис для двоих). В 1962 году Стив Рассел разработал игру «Spacewar!» для миникомпьютера PDP-1 в Массачусетском технологическом институте, которая быстро распространилась по всем университетам США. В 1969 году Ральф Баер, который позже стал известен как «Король видеоигр», запросил патент на раннюю версию игровой консоли «Television Gaming and Training Apparatus». В 1967 году Баер создал игру пинг-понг, похожую на «Теннис для двоих».

Данная работа посвящена разработке технической демонстрационной версии трехмерной компьютерной игры «After Reset». Проект относится к жанру ролевых компьютерных игр. Компьютерная ролевая игра (англ. Computer Role-Playing Game (CRPG или RPG)) — жанр компьютерных игр, основанный на элементах игрового процесса традиционных настольных ролевых игр.

1. Анализ задачи

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

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

Разработка наиболее крупнобюджетных игр («AAA-игры») может стоить десятки миллионов долларов США, причем в течение последних десятилетий эти бюджеты непрерывно росли, как и численность команд разработчиков и сроки разработки. Средний бюджет ААА-проекта, как правило, выпускаемых крупнейшими компаниями-издателями, продающихся на физических носителях и нередко входящих в состав известной серии из нескольких игр — колеблется от 18 до 24 млн. долл. Крупнобюджетная игра для двух платформ — Xbox 360 и PlayStation 3 — обходилась в 2012 году в среднем в 20 миллионов долларов, и для того, чтобы она окупилась, нужно было продать около двух миллионов копий.

Благодаря развитию рынка инди-игр, многие разработчики компьютерных игр получили возможность работать над своими игровыми проектами без финансовых и юридических обязательств перед компаниями-издателями. Инди-игры (англ. Indie games, от англ. independent video games — «независимые компьютерные игры») — это компьютерные игры, созданные отдельными разработчиками или небольшими коллективами без финансовой поддержки издателя компьютерных игр. Распространение осуществляется посредством каналов цифровой дистрибуции. Масштаб явлений, связанных с инди-играми, ощутимо возрастает со второй половины 2000-х годов, в основном ввиду развития новых способов онлайн-дистрибуции и средств разработки.

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

1.2 Постановка задачи

Задачей данной работы является разработка технической демонстрационной версии трехмерной компьютерной ролевой игры «After Reset».

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

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

1.3 Выбор средств реализации

Основным средством разработки данного проекта является игровой движок Unity. Unity — это мультиплатформенный инструмент для разработки двух- и трёхмерных приложений и игр, работающий под операционными системами Windows и OS X. Созданные с помощью Unity приложения работают под операционными системами Windows, OS X, Windows Phone, Android, Apple iOS, Linux, а также на игровых приставках Wii, PlayStation 3 и Xbox 360. Есть возможность создавать интернет-приложения с помощью специального подключаемого модуля к браузеру Unity. Приложения, созданные с помощью Unity, поддерживают DirectX и OpenGL.

Основные характеристики Unity:

– Сценарии на C#, JavaScript (модификация) и Boo (диалект языка Python со строгой типизацией для платформы.NET);

– Игровой движок полностью связан со средой разработки. Это позволяет прямо в редакторе испытывать игру;

– Работа с ресурсами возможна через простой Drag&Drop. Интерфейс редактора настраиваемый;

– Осуществлена система наследования объектов;

– Поддержка импорта из очень большого количества форматов;

– Встроенная поддержка сети;

– Есть решение для совместной разработки — Version Control;

– Также можно использовать подходящий пользователю способ контроля версий. К примеру, Tortoise SVN или Source Gear.

В качестве целевой платформы разработки выбраны операционные системы семейства MS Windows (XP/Vista/7/8). Основным языком программирования является C# с платформой.NET 2.0. Написание простых скриптов выполняется на JavaScript, в редких случаях – Boo. В проекте используется графическая библиотека DirectX; основным шейдерным языков является Cg (англ. C for Graphics), разработанный компанией NVidia.

2. Анализ данных

Проект «After Reset» относится к жанру ролевых компьютерных игр. Компьютерная ролевая игра (англ. Computer Role-Playing Game (CRPG или RPG)) — жанр компьютерных игр, основанный на элементах игрового процесса традиционных настольных ролевых игр.

В ролевой игре игрок управляет одним или несколькими персонажами, каждый из которых описан набором численных характеристик, списком способностей и умений; примерами таких характеристик могут быть хит-поинты (англ. hit points, HP), показатели силы, ловкости, защиты, уклонения, уровень развития того или иного навыка и т.п. В ходе игры они могут меняться. Одним из характерных элементов игрового процесса является повышение возможностей персонажей за счёт улучшения их параметров и изучения новых способностей.

У жанра CRPG много общего с настольными ролевыми играми наподобие Dungeons and Dragons — жаргон, сеттинги, геймплейная механика. Обычно игрок управляет одним или несколькими главными героями («партией»), и добивается победы, выполняя задания («квесты»), участвуя в тактических боях и доходя до самого конца сюжета. Ключевая особенность CRPG в том, что персонажи растут в способностях, и этот рост зачастую контролируется игроком. CRPG, за исключением поджанра «action RPG», редко полагаются на физическую координацию и реакцию.

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

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

Механика данного игрового проекта основывается на настольной ролевой игре Dungeons & Dragons редакции 3.5.

Dungeons & Dragons (D&D, DnD; Подземелья и Драконы) — настольная ролевая игра в жанре фэнтези, разработанная Гэри Гайгэксом и Дэйвом Арнесоном. Ранний успех Dungeons & Dragons привёл к распространению схожих игровых систем. Несмотря на это, D&D удерживает позиции лидера на рынке индустрии ролевых игр. В 1977 году система была разделена на две ветви: более простая в освоении Dungeons & Dragons (D&D) и более структурированная Advanced Dungeons & Dragons (AD&D). В 1989 году было опубликовано второе издание AD&D. В 2000 году первоначальная серия игр D&D была прервана, изданная третья редакция AD&D с новой системой была переименована в D&D, которая легла в основу d20 System. В 2008 году была опубликована четвёртая редакция. В настоящее время идёт разработка пятой редакции.

Традиционно руководство игры или свод правил включает в себя три книги: «Player’s Handbook» [2], «Dungeon Master’s Guide» [3] и «Monster Manual» [4]. Данные книги содержат подробное описание игровой механики данной ролевой системы, включая характеристики персонажей, боевую систему, взаимодействие игроков и т.д.

В качестве примера рассмотрим характеристики персонажа. Каждый персонаж обладает набором из 6 основных характеристик:

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

– ловкость, определяет координацию, скорость, рефлексы и устойчивость персонажа, точность выстрелов из огнестрельного и метательного оружия, а также вероятность уклонения от атак противников;

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

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

– интеллект, определяет эрудированность и умственные способности персонажа. Чем выше интеллект, тем больше навыков может освоить персонаж.

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

Таблица 2.1 – Основные типы данных

3. Анализ алгоритмов

3.1 Классы

Движок Unity имеет лицензию несвободного программного обеспечения с закрытым исходным кодом. Все программирование выполняется с помощью сценариев (скриптов) [5]. В качестве скриптовых языков на Unity используются C#, JavaScript и Boo. В каждый из языков внесены модификации для поддержки полного функционала внутреннего скриптового языка UnityScript.

Сценарии являются ясным, простым и быстрым подходом программирования. Все три скриптовых языка используют платформу Open Source.NET (Mono).

Программирование на движке Unity является объекто-ориентированным. Иерархия классов представлена на рисунке 3.1.

Рисунок 3.1 – Иерархия классов Unity3d

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

– GameManager, игровой менеджер – отвечает за игровой цикл. Является связующим звеном между отдельными элементами архитектуры игры;

– InterfaceManager, менеджер интерфейса – отвечает за интерфейс пользователя, включая графический интерфейс и устройства ввода;

– PlayerManager, менеджер игрока – отвечает за главного персонажа игры, контролируемого пользователем, его поведение и состояние;

– UnitManager, менеджер юнитов – отвечает за юнитов;

– SceneManager, менеджер уровней – отвечает за игровые уровни и т.д.

Все менеджеры реализованы на основе паттерна Singleton («одиночка») (см. Приложение А). Они имеют только один экземпляр и являются общими для всей игровой системы. Обращение к ним происходит по типу.

Основные игровые объекты реализованы на основе паттерна Finite State Machine («конечный автомат») (см. Приложение Б). Это позволяет легко контролировать состояние игрового объекта и управлять его поведением.

Рисунок 3.2 – Конечный автомата для описания поведения игрока

3.2 Основные алгоритмы

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

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

– система поиска пути;

– система графического интерфейса пользователя;

– система взаимодействия объектов;

– и дополнительные системы управления приложением.

Рассмотрим эти системы по-отдельности.

Поиск пути (англ. Pathfinding) — термин в информатике и искусственном интеллекте, который означает определение компьютерной программой наилучшего, оптимального маршрута между двумя точками. Пример поиска пути представлен на рисунке 3.3.

Рисунок 3.3 – Пример расчета пути в двумерном пространстве

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

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

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

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

На рисунке 3.4 изображен пример расчета пути на конфигурационном пространстве, представленным навигационной сеткой.

Рисунок 3.4 – Пример поиска пути на основе навигационной сетки

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

Графический интерфейс пользователя, графический пользовательский интерфейс (англ. Graphical user interface, GUI) — разновидность пользовательского интерфейса, в котором элементы интерфейса (меню, кнопки, значки, списки и т. п.), представленные пользователю на дисплее, исполнены в виде графических изображений.

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

Рисунок 3.5 – Главное меню

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

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

Взаимодействие объектов – процесс воздействия объектов друг на друга. Данный процесс описываем механику игры. К системе взаимодействия объектов можно отнести:

– боевую механику;

– интерактивные объекты (двери, пульты управления и т.д.);

– управление персонажем с помощью мыши/клавиатуры;

– коллизию объектов, обладающих физическими свойствами;

– звуковую подсистему (звуки шагов, выстрелов и т.д.);

– искусственный интеллект компьютерных персонажей (ботов).

Все эти элементы являются главными составляющими игрового цикла.

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

Рисунок 3.6 – Игровой процесс

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

4. Архитектура системы и иерархия классов

В качестве основной парадигмы программирования используется объектно-ориентированный подход [6]. ООП ориентировано на разработку крупных программных комплексов. Объектно-ориентированное проектирование состоит в описании структуры и поведения проектируемой системы, то есть, фактически, в ответе на два основных вопроса:

– из каких частей состоит система;

– в чём состоит ответственность каждой из частей.

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

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

Большое значение имеет правильное построение иерархии классов. Иерархии классов подсистем представлены в приложении Г. Одна из известных проблем больших систем, построенных по ООП-технологии — так называемая проблема хрупкости базового класса. Она состоит в том, что на поздних этапах разработки, когда иерархия классов построена и на её основе разработано большое количество кода, оказывается трудно или даже невозможно внести какие-либо изменения в код базовых классов иерархии (от которых порождены все или многие работающие в системе классы). Даже если вносимые изменения не затронут интерфейс базового класса, изменение его поведения может непредсказуемым образом отразиться на классах-потомках. В случае крупной системы разработчик базового класса просто не в состоянии предугадать последствия изменений, он даже не знает о том, как именно базовый класс используется и от каких особенностей его поведения зависит корректность работы классов-потомков.

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

Рисунок 4.1 – Прототип архитектуры игрового движка

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

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

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

– убедиться, что программа соответствует требованиям;

– выявить ситуации, в которых поведение программы является неправильным, нежелательным.

Существует несколько уровней тестирования программного обеспечения:

– модульное тестирование (юнит-тестирование) — тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция;

– интеграционное тестирование — тестируются интерфейсы между компонентами, подсистемами или системами;

– системное тестирование — тестируется интегрированная система на её соответствие требованиям;

– альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком;

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

Проект прошел все стадии тестирования на различных версиях операционных систем семейства Windows (XP, 7, 8) с различными конфигурациями оборудования (тактовая частота процессора, количество ядер, разрядность, объем оперативной и видео памяти и т.д.). Системные требования к программе соответствуют заявленным в техническом задании. Все найденные ошибки исправлены, большинство алгоритмов было оптимизировано, что позволило увеличить скорость работы приложения и его стабильность.

Рисунок 5.1 – Статистика ресурсопотребления ЭВМ при работе системы

На рисунке 5.1 представлена информация о требуемых ресурсах для работы системы:

– CPU Usage – использование ЦПУ ЭВМ;

– GPU Usage – использование ГПУ ЭВМ;

– Rendering – построение кадров, выводимых на монитор ЭВМ;

– Memory – использование ПЗУ ЭВМ;

– Audio – использование аудио подсистемы ЭВМ;

– Physics – обработка физики;

– дополнительная информация (количество обращений к видеокарте, количество полигонов на сцене, разрешение экрана и т.д.).

6. Техническое задание

1. Назначение разработки

Дипломная работа «Техническая демонстрационная версия трехмерной компьютерной игры «After Reset»:

является комплексным проектом, охватывающим различные аспекты разработки ПО;

содержит все основные аспекты компьютерной ролевой игры;

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

2. Требования к программе или программному изделию

2.1 Требования к функциональным характеристикам

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

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

а) графический функционал:

1) выбор разрешения экрана;

2) выбор качества графики;

3) выбор полноэкранного или оконного режима;

б) звуковой функционал:

1) регулировка общей громкости;

2) регулировка громкости музыки;

3) регулировка громкости внутриигровых звуков;

в) внутриигровой функционал:

1) система поиска пути;

2) система взаимодействия игровых объектов;

3) боевая система;

г) интерфейс пользователя:

1) переходные сцены (вступительная, финальная, экран загрузки);

2) главное меню;

3) графический интерфейс пользователя.

2.2 Требования к входным и выходным данным

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

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

2.3. Требования к надежности

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

2.4. Требования к составу и параметрам технических средств

Минимальные системные требования:

– ОС (операционная система): Windows XP/Vista/7/8;

– Процессор: Intel Core 2 Duo @ 3.0 Ghz / AMD Athlon 64 X2 6000+;

– Оперативная память: 1 Gb;

– Жесткий диск: 10 Gb свободно;

– Видео память: 512 Mb;

– Видео карта: nVidia GeForce 9800 / AMD Radeon HD 4870;

– Звуковая карта: Совместимая с DirectX;

– DirectX 9.0c;

– Клавиатура, Мышь.

Рекомендуемые системные требования:

– ОС (операционная система): Windows Vista/7/8;

– Процессор: Intel Core i5 @ 3.2 GHz / AMD Phenom II X4 @ 3.6 GHz;

– Оперативная память: 2 Gb;

– Жесткий диск: 10 Gb свободно;

– Видео память: 1 Gb;

– Видео карта: nVidia GeForce GTX 460 / AMD Radeon HD 5850;

– Звуковая карта: Совместимая с DirectX;

– DirectX 11;

– Клавиатура, Мышь.

2.5. Требования к информационной и программной совместимости

Программа должна функционировать под управлением ОС семейства Windows следующих версий: Windows XP, Vista, 7, 8. В приложении используются библиотеки платформы.NET Framework. Также требуется установленный DirectX 9.0c или более поздней версии.

2.6. Требования к программной документации

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

7. Руководство пользователя

1. Общее назначение программы

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

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

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

– MS DirectX 9 или выше;

– MS dotNet Framework 3.5 или выше;

– драйвер для аудио устройства;

– драйвер для видео устройства.

В состав программы входят:

– After Reset RPG Tech Demo.exe, исполняемый файл программы;

– After Reset RPG Tech Demo_Data, каталог ресурсов программы.

Для запуска программы «After Reset RPG Tech Demo» требуется запустить исполняемый файл «After Reset RPG Tech Demo.exe». На рисунке 7.1 изображено окно запуска приложения, в котором пользователь может настроить следующие параметры:

– разрешение экрана;

– оконный или полноэкранный режим;

– качество графики.

Рисунок 7.1 – Окно запуска приложения

После выбора оптимальных настроек необходимо нажать кнопку «Play!». После загрузки всех необходимых ресурсов в ПЗУ ЭВМ приложение будет запущено. На рисунке 7.2 изображено главное меню приложения.

Рисунок 7.2 – Главное меню

Из главного меню пользователь может перейти к следующим пунктам:

– «NEW GAME» – позволяет запустить игровой процесс;

– «OPTIONS» – настройки игры;

– «CREDITS» – титры;

– «EXIT» – выход из игры.

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

Рисунок 7.3 – Игровой процесс

Минимальные системные требования:

– ОС (операционная система): Windows XP/Vista/7/8;

– Процессор: Intel Core 2 Duo @ 3.0 Ghz / AMD Athlon 64 X2 6000+;

– Оперативная память: 1 Gb;

– Жесткий диск: 10 Gb свободно;

– Видео память: 512 Mb;

– Видео карта: nVidia GeForce 9800 / AMD Radeon HD 4870;

– Звуковая карта: Совместимая с DirectX;

– DirectX 9.0c;

– Клавиатура, Мышь.

Рекомендуемые системные требования:

– ОС (операционная система): Windows Vista/7/8;

– Процессор: Intel Core i5 @ 3.2 GHz / AMD Phenom II X4 @ 3.6 GHz;

– Оперативная память: 2 Gb;

– Жесткий диск: 10 Gb свободно;

– Видео память: 1 Gb;

– Видео карта: nVidia GeForce GTX 460 / AMD Radeon HD 5850;

– Звуковая карта: Совместимая с DirectX;

– DirectX 11;

– Клавиатура, Мышь.

3. Элементы интерфейса и управление

Графический интерфейс пользователя представлен следующими элементами:

– Health Points Bar – полоска очков здоровья;

– внутриигровое меню (см. рисунок 7.4).

Рисунок 7.4 – Внутриигровое меню

Управление игровым персонажем выполняется с помощью компьютерной мыши и клавиатуры.

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

С помощью клавиатуры игрок совершает основные действия:

– Клавиша «A» – атаковать;

– Клавиша «S» – прекратить движение;

– Клавиша «Shift» – сохранять позицию;

– Клавиши стрелок – изменение угла обзора камеры.

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

Рисунок 7.5 – Карта игрового уровня

8. Охрана труда при работе с ПЭВМ

8.1 Требования к ПЭВМ

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

Таблица 8.1 – Допустимые значения уровней звукового давления

Временные допустимые уровни (ВДУ) электромагнитных полей (ЭМП), создаваемых ПЭВМ, не должны превышать значений, представленных в таблице 8.2.

Таблица 8.2 – Временные допустимые уровни ЭМП, создаваемые ПЭВМ

Концентрации вредных веществ, выделяемых ПЭВМ в воздух помещений, не должны превышать предельно допустимых концентраций (ПДК), установленных для атмосферного воздуха.

Мощность экспозиционной дозы мягкого рентгеновского излучения в любой точке на расстоянии 0,05 м от экрана и корпуса видеодисплейного терминала (ВДТ) при любых положениях регулировочных устройств не должна превышать 100 мкР/час.

Конструкция ПЭВМ должна обеспечивать возможность поворота корпуса в горизонтальной и вертикальной плоскости с фиксацией в заданном положении для обеспечения фронтального наблюдения экрана ВДТ. Дизайн ПЭВМ должен предусматривать окраску корпуса в спокойные мягкие тона с диффузным рассеиванием света. Корпус ПЭВМ, клавиатура и другие блоки и устройства ПЭВМ должны иметь матовую поверхность с коэффициентом отражения от 0,4 до 0,6 и не иметь блестящих деталей, способных создавать блики.

Конструкция ВДТ должна предусматривать регулирование яркости и контрастности.

8.2 Требования к помещениям для работы с ПЭВМ

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

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

Площадь на одно рабочее место пользователей ПЭВМ с ВДТ на базе электронно-лучевой трубки (ЭЛТ) должна составлять не менее 6 м², с ВДТ на базе плоских дискретных экранов (жидкокристаллические, плазменные) – 4,5 м². При использовании ПЭВМ с ВДТ на базе ЭЛТ (без вспомогательных устройств – принтер, сканер), отвечающих требованиям международных стандартов безопасности компьютеров, с продолжительностью работы менее 4-х часов в день допускается минимальная площадь 4,5 м² на одно рабочее место пользователя.

Для внутренней отделки интерьера помещений, где расположены ПЭВМ, должны использоваться диффузно-отражающие материалы с коэффициентом отражения для потолка от 0,7 до 0,8; для стен от 0,5 до 0,6; для пола от 0,3 до 0,5. Полимерные материалы используются для внутренней отделки интерьера помещений с ПЭВМ при наличии санитарно-эпидемиологического заключения.

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

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

8.3 Требования к освещению на рабочих местах, оборудованных ПЭВМ

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

Искусственное освещение в помещениях для эксплуатации ПЭВМ должно осуществляться системой общего равномерного освещения.

Искусственное освещение должно обеспечивать на рабочих местах освещенность не ниже нормируемых значений (экран – не более 300 лк; стол и клавиатура от 300 лк до 500 лк). Освещение не должно создавать бликов на поверхности экрана.

Следует ограничивать прямую блёсткость от источников освещения, при этом яркость светящихся поверхностей (окна, светильники и другие), находящихся в поле зрения, должна быть не более 200 кд/м².

Следует ограничивать отраженную блесткость на рабочих поверхностях (экран, стол, клавиатура и другие) за счет правильного выбора типов светильников и расположения рабочих мест по отношению к источникам естественного и искусственного освещения. При этом яркость бликов на экране ПЭВМ не должна превышать 40 кд/м² и яркость потолка не должна превышать 200 кд/м².

Яркость светильников общего освещения в зоне углов излучения от 50 до 90 градусов с вертикалью в продольной и поперечной плоскостях должна составлять не более 200 кд/м², защитный угол светильников должен быть не менее 40 градусов.

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

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

Для освещения помещений с ПЭВМ следует применять светильники с зеркальными параболическими решетками, укомплектованными электронными пускорегулирующими аппаратами (ЭПРА). Допускается использование многоламповых светильников с ЭПРА, состоящими из равного числа опережающих и отстающих ветвей. Применение светильников без рассеивателей и экранирующих решеток не допускается. При отсутствии светильников с ЭПРА лампы многоламповых светильников или рядом расположенные светильники общего освещения следует включать на разные фазы трехфазной сети.

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

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

8.4 Общие требования к организации рабочих мест пользователей ПЭВМ

При размещении рабочих мест с ПЭВМ расстояние между рабочими столами с видеомониторами (в направлении тыла поверхности одного видеомонитора и экрана другого видеомонитора) должно быть не менее 2,0 м, а расстояние между боковыми поверхностями видеомониторов – не менее 1,2 м. Рабочие места должны располагаться от стен с оконными проемами на расстоянии не менее 1,5 м; от стен без оконных проемов на расстоянии не менее 1,0 м. Площадь на одно рабочее место должна составлять не менее 6,0 м², а объем – не менее 20,0 м³.

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

Рабочие места с ПЭВМ при выполнении творческой работы, требующей значительного умственного напряжения и высокой концентрации внимания, рекомендуется изолировать перегородками высотой от 1,5 до 2,0 м.

Экран видеомонитора должен находиться от глаз пользователя на расстоянии от 600 до 700 мм, но не ближе 500 мм с учетом размеров алфавитно-цифровых знаков и символов, а глаза пользователя должны находиться на уровне центра экрана монитора.

Размер экрана для разных видов работ может колебаться. Для домашних пользователей минимальный размер – 14 дюймов по диагонали; частота обновления должна составлять не менее 85 Гц для кинескопных и не менее 60 Гц для жидкокристаллических мониторов. Оптимальным считается установка максимально возможной частоты при отсутствии мерцания.

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

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

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

8.5 Требования к организации и оборудованию рабочих мест с ПЭВМ для взрослых пользователей

Поверхности рабочих столов для расположения ПЭВМ должны легко и плавно регулироваться по высоте с надежной фиксацией в заданном положении. Высота рабочей поверхности стола для взрослых пользователей должна регулироваться в пределах от 680 до 800 мм; при отсутствии такой возможности высота рабочей поверхности стола должна составлять 725 мм.

Рабочий стол должен иметь пространство для ног высотой не менее 600 мм, шириной – не менее 500 мм, глубиной на уровне колен – не менее 450 мм и на уровне вытянутых ног – не менее 650 мм.

Конструкция рабочего стула должна обеспечивать:

– ширину и глубину поверхности сиденья не менее 400 мм;

– плоскую поверхность сиденья с закругленным передним краем;

– регулировку высоты поверхности сиденья и углам наклона;

– регулировку высоты поверхности сиденья в пределах от 400 мм до 550 мм и углов наклона вперед до 15 градусов и назад до 5 градусов;

– угол наклона спинки в вертикальной плоскости в пределах от -30 до +30 градусов;

– регулировку расстояния спинки от переднего края сиденья;

– стационарные или съемные подлокотники длиной не менее 250 мм и шириной от 50 до 70 мм;

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

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

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

8.6 Требования к организации медицинского обслуживания пользователей ПЭВМ

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

Медицинское освидетельствование студентов высших учебных заведений на предмет установления противопоказаний к работе с ПЭВМ проводится в установленном порядке.

Заключение

Результатом выпускной квалификационной работы является готовый программный продукт «Техническая демонстрационная версия трехмерной компьютерной игры “After Reset”». Реализованы подсистемы поиска пути, графического интерфейса пользователя и взаимодействия внутриигровых объектов. Все подсистемы отлажены, оптимизированы, протестированы и интегрированы в единую программную систему.

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

Проект «After Reset» является интеллектуальной собственностью студии независимых разработчиков компьютерных игр «Black Cloud Studio». Авторские права на программную часть проекта принадлежат автору выпускной квалификационной работы.

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

1. Андреев Г.И. Практикум по оценке интеллектуальной собственности / Г.И. Андреев, В.В. Витчинка, С.А. Смирнов. – Москва: Финансы и статистика, 2002. – 176 с.

2. Jonathan Tweet. Player’s Handbook. Dungeons & Dragons Core Rulebook I / Jonathan Tweet, Monte Cook, Skip Williams. – Wizards of the Coast, Belgium, 2003. – 320 с.

3. Jonathan Tweet. Dungeon Master’s Guide. Dungeons & Dragons Core Rulebook II / Jonathan Tweet, Monte Cook, Skip Williams. – Wizards of the Coast, Belgium, 2003. – 320 с.

4. Jonathan Tweet. Monster Manual. Dungeons & Dragons Core Rulebook III / Jonathan Tweet, Monte Cook, Skip Williams. – Wizards of the Coast, Belgium, 2003. – 320 с.

5. Unity – Scripting [Электронный ресурс]. – Режим доступа: https://unity3d.com/learn/tutorials/modules/beginner/scripting. – Загл. с экрана.

6. Объектно-ориентированное программирование [Электронный ресурс.]. – Режим доступа: http://msdn.microsoft.com/ru-ru/library/dd460654.aspx. – Загл. с экрана.

Приложение А

Шаблон проектирования «Одиночка»

using UnityEngine;

public class Singleton<T> : MonoBehaviour where T : MonoBehaviour

{

private static T _instance;

private static object _lock = new object();

private static bool applicationIsQuitting = false;

public static T Instance

{

get

{

if (applicationIsQuitting)

{

Debug.LogWarning(“[Singleton] Instance ‘” + typeof(T) + “‘ already destroyed on application quit.” + ” Won’t create again – returning null.”);

return null;

}

lock (_lock)

{

if (_instance == null)

{

_instance =(T)FindObjectOfType(typeof(T));

if (FindObjectsOfType(typeof(T)).Length > 1)

{

Debug.LogError(“[Singleton] Something went really wrong ” + ” – there should never be more than 1 singleton!” + ” Reopenning the scene might fix it.”); return _instance;

}

Продолжение приложения А

if (_instance == null)

{

GameObject singleton = new GameObject();

_instance = singleton.AddComponent<T>();

singleton.name = “(singleton)” + typeof(T).ToString();

DontDestroyOnLoad(singleton);

Debug.Log(“[Singleton] An instance of ” + typeof(T) + ” is needed in the scene, so ‘” + singleton + “‘ was created with DontDestroyOnLoad.”);

}

else

{

Debug.Log(“[Singleton] Using instance already created: “+_instance.gameObject.name);

}

return _instance;

}

public void OnDestroy()

{

applicationIsQuitting = true;

}

Приложение Б

Шаблон проектирования «Конечный автомат»

using UnityEngine;

using System.Collections.Generic;

public enum Transition

{ NullTransition = 0 }

public enum StateID

{ NullStateID = 0 }

public abstract class FiniteStateMachine

{

protected Dictionary<Transition, StateID> map = new Dictionary<Transition, StateID>();

protected StateID stateID;

public StateID ID { get { return stateID; } }

public void AddTransition(Transition trans, StateID id)

{

if (trans == Transition.NullTransition)

{

Debug.LogError(“FSMState ERROR: NullTransition is not allowed for a real transition”);

return;

}

if (id == StateID.NullStateID)

{

Debug.LogError(“FSMState ERROR: NullStateID is not allowed for a real ID”);

return;

}

if (map.ContainsKey(trans))

{

Debug.LogError(“FSMState ERROR: State ” + stateID.ToString() + ” already has transition ” + trans.ToString() + “Impossible to assign to another state”);

return;

}

map.Add(trans, id);

}

Продолжение приложения Б

public void DeleteTransition(Transition trans)

{

if (trans == Transition.NullTransition)

{

Debug.LogError(“FSMState ERROR: NullTransition is not allowed”);

return;

}

if (map.ContainsKey(trans))

{

map.Remove(trans);

return;

}

Debug.LogError(“FSMState ERROR: Transition ” + trans.ToString() + ” passed to ” + stateID.ToString() + ” was not on the state’s transition list”);

}

public StateID GetOutputState(Transition trans)

{

if (map.ContainsKey(trans))

{

return map[trans];

}

return StateID.NullStateID;

}

public virtual void DoBeforeEntering() { }

public virtual void DoBeforeLeaving() { }

public abstract void Reason(GameObject player, GameObject npc);

public abstract void Act(GameObject player, GameObject npc);

}

Приложение В

Шаблон скрипта

using UnityEngine;

using System.Collections;

public class ScriptExample : MonoBehaviour

{

// Use this for initialization

void Start ()

{

}

// Update is called once per frame

void Update ()

{

Приложение Г

Иерархии классов подсистем

Рисунок Г.1 – Иерархия классов системы поиска пути

Рисунок Г.2 – Иерархия классов системы графического интерфейса пользователя

компьютерный игра программа алгоритм

Приложение Д

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

Рисунок Д.1 – Архитектура и взаимодействие компонентов системы