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

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

Введение

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

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

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

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

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

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

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

1.1 Основные понятия и определения

Игровой средой (ИС) называют совокупность связей и объектов в игре, а также правил, по которым они изменяются. К примеру, в такой игре, как шахматы, игровой средой являются доска, наборы игровых фигур и правила, регулирующие взаимодействия между ними. Например, правила превращения одной фигуры в другую и взятия. Для известной компьютерной игры «Pong» игровой средой являются игровое поле, шарик и два прямоугольных объекта, изображающих теннисные ракетки.

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

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

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

Тактический план - это действия пользователя, приводящие к достижению некой игровой цели.

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

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

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

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

1.2 Общее описание разрабатываемого ПП

Игра является приложением, выполняющим две функции:

- развлечение игрока;

- развитие навыков многозадачности, реакции и критической оценки своих возможностей;

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

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

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

- Главное меню;

- Различные отображения игровых ситуаций;

- Игровая статистика;

- Справка.

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

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

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

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

В общем виде взаимодействие игрока и программного продукта изображено на диаграмме прецедентов.



Рисунок 1.1. Диаграмма прецедентов

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

В данной версии имеются следующие игровые умения:

- атака. Наносит урон противнику, если противник не в состоянии блока.

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

- исцеление. Увеличивает текущее здоровье игрока, но не превышая максимального значения, заданного в настроечном классе программы.

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

- проникающая атака. Наносит урон противнику и игнорирует блок.

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

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

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

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

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

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

2. Анализ методов и средств решения поставленной задачи

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

Опыт пользователя (англ. user experience, UX) - это восприятие и ответные действия пользователя, возникающие в результате использования и / или предстоящего использования продукции, системы или услуги (ГОСТ Р ИСО 9241-210-2011). Опыт взаимодействия включает в себя различные психофизические реакции во время - и после - использования программного продукта. Он сочетает в себе устоявшиеся мнения об общих чертах поведения программных включающие в себя предшествующий опыт и накопленные навыки.

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

Roguelike - подвид компьютерных ролевых игр. Ключевые особенности roguelike-игр - случайно генерируемые уровни, пошаговый режим и завершение игры после смерти персонажа. После данного события игру можно начать только заново. Антураж большинства roguelike-игр ориентирован на классические настольные игры, вроде Dungeons and Dragons, в основе которых лежат путешествия по подземельям. В отличие от классических ролевых игр, в roguelike отсутствует сюжетная линия. Игры данного жанра используют упрощенный графический интерфейс, представленный символами (рисунок 2.1) или простыми тайлами. С начала XXI века стали появляться игры, имеющие основные принципы roguelike, но содержащие в себе элементы игр других жанров. Например, «Slaves to Armok II: Dwarf Fortress», имеющий в себе элементы стратегической игры и симулятора, или Darkest Dungeon, имеющая элементы классической тактической ролевой игры.

Рисунок 2.1. Игра «Rogue», основоположник жанра «roguelike»

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



Рисунок 2.2. Игра «Mortal Kombat 3» в жанре «fighting»

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

Рисунок 2.3. Пример тайла травы

2.2 Аналитический обзор существующего ПО

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

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

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

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

В играх жанра «roguelike» стоит проанализировать генерацию подземелий. Стоит отметить, что она не полностью случайна - при генерации обычно описыватся условия, отвечающие за появление на карте структур, приближенных к реальности. Например, в одной локации могут встречаться только определенные биологические виды и тайлы. Если это подземелья, то для игрока должны быть созданы процедурно условия, при которых персонаж сможет свободно передвигаться по всем доступным для перемещения местам. Недоступных зон не должно быть. Противники, также, генерируются на карте случайно и имеют определенный уровень, отвечающий за игровые качественные характеристики и зависящий от игровой локации. Например, такой подход реализован в играх серии «Tales of Maj'Eyal».

Рисунок 2.4. Локация игры «Tales of Maj'Eyal»

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

Из известных гибридных игр можно рассмотреть Enter The Gungeon, являющийся смесью «roguelike» и боевика в реальном времени. Здесь мы видим случайные локации, карту и награды. В то же время, на отдельных локациях происходят бои с множеством противников с различным поведением. Убраны многие черты «roguelike», которые могли бы излишне перегрузить игру лишними игровыми действиями. Интерфейс предельно простой, не требует углубленного изучения, что можно использовать в качестве примера удачной реализации гибридной игры.

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

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

Для данного проекта было решено использовать имитацию ИИ на основе принятия решений в зависимости от изменяющихся условий игровой ситуации среды. Так называемых триггеров. Данный принцип реализован в большинстве компьютерных игр. В ходе формирования требований возникла идея комбинировать данный метод с потребностями игрового персонажа, подобно персонажам симулятора жизни «The Sim's», где на приоритеты при принятии решений прямым образом влияют их текущие нужды. К примеру, грязный персонаж будет всеми доступными способами искать способ помыться. Но если у него есть индивидуальная склонность «грязнуля», то данная потребность уйдет на задний план, а персонаж будет выполнять иные действия с более высоким приоритетом.

3. Анализ требований к ПП

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

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

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

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

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



Рисунок 3.1. Обучающий автосимулятор «3D-иуструктор»

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

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

- режим игры по количеству пользователей: многопользовательские игры и одиночные;

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

- платформа: программно-аппаратная платформа, на которой возможна работа КИ.



Рисунок 3.2. Игра «Slaves to Armok II: Dwarf fortress»

Примерная классификация жанров КИ:

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

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

- ролевая игра (Role Playing Game) - игра, характеризующаяся тем, что игрок должен играть определенную роль в игровом мире, а так же, развивать способности персонажа и выполнять определенные действия, зависящие от игрового мира. Другой отличительной чертой является относительная свобода в выборе действий и плана на игру. Сюда же относят и многопользовательские ролевые игры, не имеющие, как правило, завершающего этапа игры.

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

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

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

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

3.2 Требования к интерфейсу

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

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

- главное меню;

- справка;

- результаты игровой сессии;

- отображение последних достигнутых игровых результатов;

- режим путешествия;

- режим битвы.

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

- продолжение игры с сохраненной точки (в случае, если последняя игра была окончена, то пункт должен выполнять функцию начала новой игры);

- начало новой игры;

- последние результаты;

- справка.

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

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

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

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

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

Текстовая информация:

- текущее количество очков;

- текущее здоровье персонажа;

- номер текущего этажа.

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

- недоступная клетка;

- доступная клетка (часть прохода лабиринта);

- клетка с противником;

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

Экран в режиме битвы должен представлять собой и графические объекты и текстовые.

Текстовая информация:

- отображение здоровья противника;

- отображение здоровья игрока.

Графические объекты:

- спрайт персонажа;

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

- фоновый рисунок;

- эффекты состояний и умений игрока и противника. Эффекты противника должны выглядеть как зеркальные копии эффектов игрока;

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

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

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

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

3.3 Система приоритетов при разработке ПП

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

Также, немаловажны этапы тестирования, которые непосредственно влияют на интеграцию программного продукта.

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

- каскадная модель;

- спиральная модель.

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

У данной модели жизненного цикла есть свои плюсы:

- каждый этап по завершении обладает соответствием с критериями полноты;

- сроки разработки и затраты легко прогнозируемы.

Рисунок 3.3. Каскадная модель разработки ПО

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

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

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

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

Рисунок 3.4. Спиральная модель разработки ПО

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

4.1 Архитектура ПП

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

Сегодня существует множество фреймворков и библиотек, позволяющих разрабатывать компьютерные игры в кратчайшие сроки, как свободных, так и проприетарных. Отличие фреймворка от библиотеки в том, что из библиотеки можно использовать отдельно взятый модуль и использовать его по назначению. Фреймворк же изначально обязывает использовать уже реализованную архитектуру приложения. Существуют фреймворки различной степени проработанности. К примеру, LibGDX больше ориентирован на графическую составляющую игры, а Unity 3D можно назвать полноценной средой программирования, в которой для описания игровой логики и скриптов используются внутренние языки программирования без использования кода самого фреймворка.

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

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

Рисунок 4.1. IDEF0

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

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

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

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

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

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

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

Рисунок 4.2. Диаграмма состояний (UML) проектируемого приложения

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

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

- возможность работы с объектами;

- возможность создания платформонезависимого исполняемого файла;

- широкий выбор существующих библиотек (в частности, графических);

- удобство при разработке;

- применение на мобильных платформах;

Были выделены для сравнения следующие объектно-ориентированные языки: Java и C#.

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

C# - также объектно-ориентированный ЯП со статической типизацией, работающий на виртуальных машинах. Есть реализации языка для разных операционных систем.

Примеры программы, выводящей на экран текст «HelloWorld!» на Java и C#

Java	C#
class HelloWorld { public static void main (String[] args) { System.out.println («Hello World!»); } }	public class HelloWorld { public static void Main() { System. Console. WriteLine («Hello World!»); } }

Оба языка имеют схожие сферы применения:

- корпоративные системы;

- настольные прикладные приложения;

- WEB-разработка (технологии JSP и ASP.NET, работающие на стороне сервера);

- компьютерные игры (включая мобильные);

Оба языка, также, являются объектно-ориентированными и имеют значительные сходства. И тот, и другой позволяют частично использовать функциональное программирование, которое в определенных ситуациях удобнее императивного подхода (например, можно работать с лямбда-выражениями). Однако, у С# есть преимущество в том, что разработчики языка привносят современные новинки и решения намного раньше, чем разработчики Java (те же лямбда-выражения были добавлены только в 8-й версии Java). Для данного проекта это не столь критично.

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

Выбор библиотек для разработки и развитие сообщества разработчиков сильнее у Java, но C# язык молодой и стремительными темпами догоняет своего конкурента по этим параметрам.

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

При разработке для мобильных платформ Java более выгоден, так как C# представлен лишь на Windows-устройствах и в некоторых фреймворках для других операционных систем (например, игровой движок Unity 3D). Java ограничивается не только Android-устройствами.

Во время анализа был выбран Java.

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

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

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

Интегрированная среда разработки, ИСP/IDE (англ. Integrated development environment) - комплекс средств, который используется для разработки программных продуктов и ускоряет разработку при помощи специальных возможностей, предоставляемых разработчику. Многие ИСР позволяют работать с различными языками программирования разных парадигм.

Среда разработки включает в себя:

- текстовый редактор,

- компилятор и / или интерпретатор,

- средства автоматизации сборки,

- системы контроля версий,

- визуальные среды разработки (не всегда),

- отладчик.

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

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

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

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

Был выбран JSON, так как он имеет более лаконичную форму записи, чем XML.

Из библиотек будут использоваться стандартные библиотеки Java Standard Edition, графические библиотеки Swing и AWT, разработанные компанией Sun Microsystems и входящие в набор Java Foundation Classes, и библиотека GSON от компании Google для работы с JSON, чтобы исключить ощутимые временные затраты на разработку базовых графических преобразований, парсера и др.

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

- свободное распространение (из экономических соображений);

- быстрые разработка и освоение;

Были изучены три среды разработки для Java: Eclipse и Intellij IDEA и NetBeans как наиболее известные.

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

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

Для создания графических изображений был использован Adobe Photoshop.

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

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

Сейчас реализованы следующие классы:

- Main - Основной класс, имеющий точку входа;

- About - Класс, отвечающий за отображение справочной информации;

- ApplicationStates - Содержит переменные, отвечающие за глобальные состояния игры;

- Enemy - Класс, от которого динамически порождаются объекты-враги. Определяет поведение и свойства противников в игре;

- EnemySkills - Описывающий поведение умений класс. От него создаются умения объектов-противников;

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

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

- GameMap - Класс, отображающий режим игры на карте и реализующий логику перемещений при помощи клавиатуры;

- GameResult - Отвечает за отображение результатов при завершении игры;

- GameStats - Класс, отображающий результаты последних игр;

- MainMenu - Отображает главное меню, реализует логику переключения его пунктов и переходов приложения к другим состояниям в зависимости от активного пункта;

- MainWindow - Создает объекты-экземпляры классов, отвечающих за текущее состояние игры. Имеет метод, создающий окно и описывающий поведение программы при нажатии клавиш в разных ее состояниях;

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

- ProgressState - Вспомогательный класс, экземпляр которого хранит значения, необходимые для сохранения и загрузки данных;

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

- XorCipher - Класс с методами, отвечающими за шифрование и дешифрование данных JSON

Помимо описанных выше классов используются классы стандартной библиотеки Java и библиотеки com.google.gson. Gson.



Рисунок 4.3. Дерево классов проекта, отображаемое в IDE

Диаграмма классов со всеми их отношениями изображена на рисунке 4.3.

Рисунок 4.4. Диаграмма классов

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

- алгоритм метода генерации нового уровня;

- алгоритм метода использования умений;

- алгоритм принятия решений противником;

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

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

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

Реализация принятия решений противниками основана на двух методах класса «Enemy». Первый метод устанавливает характеристики противника в зависимости от текущего уровня карты и случайного значения, отвечающего за тип противника. Переменные со словом «Bonus» означают приоритеты заполнения потребностей в использовании конкретного умения. Здесь мы можем увидеть, что первый тип противника самый агрессивный, но он пренебрегает защитой. Второй имеет сбалансированные характеристики, а третий предпочитает защиту и восстановление. Далее, заполняется массив приоритетов, выраженных количественно (текущее и максимальное значение). При максимальном значении срабатывает триггер, и противник делает попытку атаки, после чего текущее значение обнуляется. Эти действия уже работают во втором методе.

public void initialize () {

maxHp = 500 + ProgressState.mapLevel * 200;

currentHp = maxHp;

enemyType = GameConfig.randomGenerator.nextInt(3);

switch (enemyType) {

case 0:

hitBonus = 1;

blockBonus = 0.5;

healBonus = 0.5;

leechBonus = 1.5;

penetrateBonus = 1.5;

reflectBonus = 1;

break;

case 1:

hitBonus = 1.5;

blockBonus = 1;

healBonus = 1;

leechBonus = 0.5;

penetrateBonus = 1.5;

reflectBonus = 0.5;

break;

case 2:

hitBonus = 1;

blockBonus = 1.5;

healBonus = 1.5;

leechBonus = 0.5;

penetrateBonus = 0.5;

reflectBonus = 1;

break;

}

for (int i = 0; i < 6; i++) {

priorityArray[0] [i] = 200; // Стартовое значение

priorityArray[1] [i] = 300; // Максимальное значение

}

}



Рисунок 4.5. Блок-схема алгоритма, изменяющего здоровье персонажей

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