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

Введение

игровой стратегия интерфейс защита

Существует большое количество людей в современном мире, которые любят играть в игры на мобильных устройствах таких, как планшеты смартфоны и прочее. Рынок мобильных приложений предлагает большое количество вариантов игр на выбор. В 2015 году количество мобильных приложений в Google Play достигло отметки в 1,8 миллионов и это число быстро растет [1]. Одна из самых быстрорастущих категорий - «Игры». Разнообразие жанров, которое представлено в данной категории восхищает, но среди всего множества выбора лишь малая часть жанров может предложить людям больше, чем просто развлечение.

Один из таких жанров - «Стратегия», тип игр, играя в которые можно не только получить удовольствие, но и развить некоторые навыки. Такие, как например внимательность и умение думать стратегически, кроме того развивается математическое мышление и память. Один из видов стратегий которые можно выделить в отдельный является жанр «башенная защита». Игроку в данном жанре предлагается защитить определенный объект на карте от вражеских боевых единиц, расставляя на поле боя различные защитные сооружения (башни, ловушки) чтобы не дать противнику добраться до объекта. История данного жанра начинается в 1990 году с появлением игры «Rampart». Именно эта игра стала прародителем жанра, который появится уже как самостоятельный только спустя 10 лет. На текущий момент существует много различных вариаций подобного класса игр [2][3], многие из них достигли большой популярности. К играм данного жанра относят: «Plants vs. Zombies», «Kingdom Rush Origins», «Dungeon Defenders» и другие. Основной сложностью в разработке таких приложений является обеспечение оригинальности игры в плане пользовательского интерфейса и игровой логики. Первое нужно для того чтобы привлечь пользователя, а второе чтобы сделать приложение с возможностью играть в него снова и снова.

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

Логическая структура определяет баланс игры. Основная цель баланса предоставить элемент сложности стратегии, без этого фактора ни одна игра не будет интересна. Сложность должна быть сбалансирована под разные типы игроков в зависимости от их умения и постепенно усложнятся вместе с ним. Основная сложность данной задачи представлена противостоянием двух основных субъектов жанра: башен и вражеских единиц (крипов). Крипы представляют из себя подвижные объекты на карте которые перемещаются из начальной точки, точки «появления» до точки, которую должен защитить игрок. У крипов имеются 2 основных параметра: очки здоровья и скорость передвижения, в то время как у башен есть как минимум 3 параметра: уровень урона, радиус атаки и скорость выстрела. Естественно стоит учитывать еще один фактор - фактор ресурсов, которые игрок использует для постройки башен, именно он ограничивает игрока от застройки всего поля боя защитными сооружениями, ресурс дается изначально и накапливается в процессе игры различными способами. Итак, основная цель найти баланс между этими переменными для создания математического уравнения для дальнейшего применения.

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

1. GUI - графический пользовательский интерфейс

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

В начале разработки мобильного приложения с графическим пользовательским интерфейсом возникает вопрос о том, какой API лучше использовать для отображения графической составляющей приложения. На сегодняшний день в мире существует два самых популярных API, которые используются для работы с графикой: Direct3D и OpenGL. Говоря о мобильных устройствах, в особенности операционной системе Android, которая была выбрана как первичная система для игры, она поддерживает только OpenGL со стандартом Embedded Accelerated 3D Graphics (OpenGL ES). Этот стандарт является бесплатным, кроссплатформенным с полной поддержкой функциональности 2D и 3D графики на встроенных системах включая: консоли, мобильные девайсы, техники и транспортных средствах. На сегодняшний день OpenGL ES поддерживается на более чем 1.7 миллиардов устройств [4].

В исследовательской работе [5] упоминается Фреймворк LibGDX, который использует OpenGL API. В своей работе студенты описывают мотивы, побудившие их на использование данной библиотеки и предоставляют свою оценку этого фреймворка. Основной целью работы исследователей было найти и имплементировать библиотеку для работы с графикой необходимой для игры. Критерии поиска основывались на множестве факторов и упоминаются в секции 2.2.4 в их работе. Одним их главных критериев был критерий открытости кода с возможностью его дальнейшего использования. Среди других критериев для отбора были: поддержка разработчиков, которые постоянно поддерживали свой продукт, наличие документации, а также наличие активного сообщества, использующего данную библиотеку. Все эти исследователи нашли в LibGDX, он поддерживает разработку не только под мобильные платформы, но и для персональных компьютеров, что позволяет разработчику запускать код на компьютере для проверки, вместо того чтобы использовать эмуляторы или мобильные устройства. Как еще один положительный эффект, авторы работы выделяют то, что использование данной библиотеки не требует глубокого понимания работы OpenGL и Android требуется только знание Java, что существенно экономит время на изучение для начинающих разработчиков. Среди негативных факторов, исследователи выявили только одни недостаток LibGDX - это то, что документация к некоторым функциям библиотеки практически отсутствует, и ограничивается лишь простыми уроками.

Возвращаясь к основной цели данного диплома, следующий обзор будет посвящен статье об имплементации виджетов и структурных компонентов которые предлагает LibGDX. Для реализации UI библиотека LibGDX предлагает широкий набор функций, в работе [6] наглядно показывается и раскрывается вся мощь библиотеки. Одна из частей их книги посвящена проблемам, связанным с разработкой GUI. Описанные аспекты помогают лучше понять структуру работы фреймворка, потому что, как упоминалось ранее, документация у LibGDX не совсем полная и требует дополнения. В работе описывается подробная структура классов, которая составляет API для работы с интерфейсом - Scene 2D API или граф сцены. Граф сцены - это базовая структура, которая позволяет организовать иерархически содержимое сцены. Набор различных контейнеров(групп) для объектов (актеров) позволяет применять изменения для всех объектов внутри одного родителя. Иерархическая организация актеров, находящихся в группах Scene 2D наделяются следующими свойствами:

· Система действий: особенность, позволяющая упростить работу с кодом, и позволяющая приложению применять эффекты распараллеливания или цепные эффекты над актерами.

· Преобразование потомков: любые трансформации группы будут так же применены к объектам внутри нее.

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

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

По мнению авторов, Scene 2D - будет единственным правильным вариантом при создании графического пользовательского интерфейса с помощью LibGDX. Каждая особенность кода раскрывается в данной книге широко и с примерами реализации. Авторы дают советы по использованию различных элементов интерфейса таких как: кнопки, картинки, полосы прокрутки и другое. Дают советы по их расположению на экране мобильных устройств и советы как сделать GUI гибким и подходящим под разные размеры экранов.

К другим источникам, показывающим работу с LibGDX, является публикация [7]. Их труд описывает основные аспекты по имплементации игровых объектов на экране на примере игры. Авторы освещают ключевые моменты применения объектов интерфейса каких как: шрифты, различные счетчики и показатели, а также отрисовка объектов на экране. Однако, их объяснение имеет некоторые недостатки: техники графического интерфейса описаны лишь на примере внутри игрового интерфейса, а игровое меню не затронуто. Данная книга предлагает читателю лишь общие черты в работе с библиотекой и поэтому предпочтение будет отдаваться работе Маркеса и Санчеса.

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

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

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

Эргономика -- это наука, изучающая человеческие действия в процессе работы, скорость освоения новой техники, затраты энергии, производительность и интенсивность при конкретных видах деятельности [9]. Эргономика другими словами - это изучение человеко-машинного взаимодействия. В связи с этим можно определить эргономические показатели UI интерфейса -- качественные и количественные характеристики человеко-машинного взаимодействия. Существует много различных эргономических показателей, специфичных для каждого отдельно рассматриваемого проекта. Существует несколько систем из эргономических показателей. На данный момент одной из наиболее распространённых систем является система показателей Бена Шнейдермана [10]. Эта система включает в себя следующие характеристики:

• скорость работы пользователя;

• количество человеческих ошибок;

• субъективная удовлетворенность;

• скорость обучения навыкам оперирования интерфейсом;

• степень сохраняемости этих навыков при неиспользовании программного средства.

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

Однако подход к оценке качества пользовательского интерфейса на основе модели Шнейдермана фрагментарен, поскольку концентрируется на оценке отдельных характеристик. Существует более целостный подход к вопросу об удобстве использования интерфейсов -- это юзабилити [11]. Рассмотрим три наиболее часто встречающихся определения. Согласно международному стандарту (ISO 9241-11) юзабилити -- это степень эффективности, трудоемкости и удовлетворенности, с которыми продукт может быть использован определенными пользователями при определенном контексте использования для достижения определенных целей. Определение, предложенное UPA (Usability Professionals Assotiation) концентрируется больше на понятии юзабилити в контексте процесса разработки программного продукта: «Юзабилити -- это подход к разработке продукта, который вовлекает обратную связь с пользователем на всех этапах разработки с целью создать продукт, отвечающий нуждам пользователя».

Стив Круг в своей книге дает следующее простое определение: «В действительности юзабилити -- просто убеждение в том, что что-то работает хорошо -- будь то веб-сайт, пульт управления или вращающая дверь -- по прямому назначению и не оставляет пользователя безнадежно разочарованным» [12]. Все эти три определения, как и другие определения юзабилити, используют следующие общие тезисы:

• Пользователь вовлечен в процесс.

• Пользователь производит некоторые действия.

• Пользователь производит некоторые действия с системой, продуктом или предметом.

Тем самым понятие «юзабилити» предоставляет полноценную связь для работы с пользовательским интерфейсом, в отличие от модели Шнейдермана: среда, в которой пользователи взаимодействуют с продуктом -- условия для анализа пользовательского интерфейса. Но нас интересует вопрос о том, какие именно показатели пользовательского интерфейса характеризуют юзабилити. В связи с этим остановимся подробнее на первом определении ISO 9241-11. В определении используются базовые показатели качества интерфейса такие как эффективность, трудоемкость и удовлетворенность. С одной стороны, на первый взгляд эти показатели в достаточной мере отображают характеристики, которые могут описать интерфейс пользователя. Но выбранные показатели вызывают множество споров среди юзабилити-специалистов [13] по следующим причинам. Во-первых, невозможно провести четкую границу между эффективностью и трудоемкостью интерфейса. К примеру, скорость работы пользователя даже в рамках одной и той же системы в разных случаях можно отнести и к эффективности, и к трудоемкости. Таким образом в случае, когда мы оперируем показателем интерфейса, который можно измерить непосредственно, сложно однозначно определить, за какой из базовых показателей качества интерфейса он отвечает. Во-вторых, в стандарте ISO 9241-11 в описание понятий эффективности и трудоемкости попала одна из непосредственных характеристик продукта -- мощность. Увеличение мощности системы в общем случае не имеет прямую пропорциональную зависимость с улучшением качества пользовательского интерфейса: некоторые продукты являются маломощными с целью сохранения упрощенного интерфейса взаимодействия и невысокой стоимости. В связи с перечисленными выше причинами появилась распространенная переформулировка определения из международного стандарта с использованием показателей, определенных в модели Шнейдермана: «Юзабилити -- показатель скорости взаимодействия с системой, количества ошибок, скорости обучения навыкам взаимодействия и субъективной удовлетворенности определенных пользователей продукта, достигающих определенных целей в определенном контексте использования».

Рассмотрим подробнее каждую метрику показателя юзабилити интерфейса.

Скорость взаимодействия с системой - является важным показателем качества интерфейса. На сегодняшний день выделяют несколько показателей из которых состоит данная метрика:

· длительность восприятия исходной информации;

· длительность ментальной деятельности пользователя;

· длительность физических действий пользователя:

· длительность реакции системы на действия пользователя.

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

1. Формирование цели действий

2. Определение направления действий

3. Определение, какие действия необходимо выполнить

4. Выполнение действий

5. Восприятие нового состояние системы

6. Интерпретация состояния системы

7. Оценка результата

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

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

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

· Ввод некорректных данных в форму для заполнения (к примеру, неверный логин/пароль);

· Неверный выбор элемента в выпадающем списке (к примеру, выбор «Удалить» вместо «Изменить» в пункте меню);

· Выполнение некорректной последовательности действий (форматирование диска вместо записи на него информации)

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

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

Игровой баланс

В данной части обзора рассматривается статья, посвященная математическому подходу в обеспечении игрового баланса. Как пример приложения, в котором был применен математический подход, можно рассмотреть следующий вариант, предложенный в статье. В работе [14] рассказывают о проблеме порядка постройки в стратегии реального времени, проблеме которая заключается в том, чтобы оптимизировать выполнение стратегии посредством разделения действий на подзадачи. Для того чтобы достигнуть данного результата авторы используют многокритериальную оптимизацию. Задача многокритериальной оптимизации состоит в поиске вектора целевых переменных, удовлетворяющего наложенным ограничениям и оптимизирующего векторную функцию, элементы которой соответствуют целевым функциям. Эти функции образуют математическое описание критерия удовлетворительности и, как правило, взаимно конфликтуют. Отсюда, «оптимизировать» означает найти такое решение, при котором значение целевых функций были бы приемлемыми для постановщика задачи. Обычно таким решение является критерий Парето. В своем проекте авторы определяют многокритериальную проблему постройки тремя функциями и накладывают 3 ограничения: совокупного, дизъюнктивного и выходного [15]. Для того чтобы получить множество оптимальных решений Парето или Парето-фронт, исследователи проводят серию экспериментов с помощью специальной стратегического планировщика Balanced Annihilation C++ Planner, именно он помогает в процессе сбора данных. Как результат их исследования, метод анализа порядка постройки позволяет выбрать почти оптимальное решение для данного рода игр. Научная работа этих авторов показывает пример научного подхода для решения различных проблем в жанре стратегий и в частности жанра «tower defense». Некоторые решение полученные в результате исследования это научной статьи будут применены в текущей работе для решения проблемы балансировки сил.

Для более детального рассмотрения баланса нужно более подробно описать, что он из себя представляет и дать его определение.

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

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

2. Реализация графического интерфейса

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

табл. 1

Респондент	Тест 1 (сек)	Тест 2 (сек.)	Тест 3 (сек.)	Тест 4 (сек.)	Тест 5 (сек.)
1	5,4	3,1	2,4	2,1	1,4
2	7,3	5,2	3,5	3,2	2,0
3	8,1	5,1	5,0	3,4	2,0
4	12,9	8,3	4,6	3,7	2,4
5	15,0	7,9	6,3	4,0	2,7
Итог:	48,7	29,6	21,8	16,4	10,5

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

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

табл.2

Респондент	Впечатление от игры	Удобство интерфейса	Возможность играть в игру после теста
1	5	5	5
2	4	4	4
3	4	4	2
4	5	4	4
5	5	4	2

Как можно заметить в целом, общее впечатление от приложения было оценено выше среднего (4,6), однако удобство интерфейса оценили не так высоко уже на 4,2, а желание продолжить играть вообще оказалось низким. Все эти результаты наводят на мысль, что в данном интерфейсе есть недостатки. В вербальном опросе большинство участников отметили такие недостатки как: мелкий шрифт надписей, маленький размер элементов на экране, отсутствие кнопки «играть».

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

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

1. Простота: для того чтобы начать играть нужно сделать минимальное количество итерация в игровом меню.

2. Шаблонность: большинство кнопок расположены приблизительно в одних и тех же местах в разных играх.

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

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

Стимпамнк (или паропамнк) (от англ. steampunk) -- направление научной фантастики, моделирующее цивилизацию, в совершенстве освоившую механику и технологии паровых машин. Сам термин является смесью слов англ. steam «пар» и англ. punk «мусор». Как правило, стимпанк подразумевает альтернативный вариант развития человечества с выраженной общей стилизацией под эпоху викторианской Англии (вторая половина XIX века) и эпоху раннего капитализма с характерным городским пейзажем и контрастным социальным расслоением. Возможно, однако, и наличие в произведениях стимпанка большей или меньшей доли элементов фэнтези [16].

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

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

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

· Соблюдение приоритета - элементы которые используются наиболее часто должны быть расположены в наиболее удобных местах.

· Минимализм элементов - количество элементов на экране должно сводится к минимуму, что не запутать пользователя.

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

Удобство расположения. Размеры экранов у современных гаджетов сильно варьируются, но сегодня можно наблюдать тенденцию роста диагонали мобильных устройств [17]. Большие размеры экрана увеличивают количество места для отображения информации, однако создают некоторые неудобства при держании в руках у пользователя. По оценкам исследователей [18], большинство людей, играющих в мобильные игры или использующие приложения, требующие удерживать устройство в горизонтальном положении, используют обе руки поддерживающие гаджет снизу слева и справа и используют в качестве управления экраном свободные большие пальцы рук (рис. 1).

рис. 1

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

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

Минимализм присущ всем мобильным играм [19], это касается разработки для устройств с небольшим экраном, где размер и количество элементов интерфейса может сильно снизить удовольствие от игры, так как пользователь может не увидеть, что происходит в игре и из-за этого проиграет и ему не захочется больше играть в эту игру. Когда дело касается жанра башенная защита, где игроку нужно видеть, как можно больше клеток и просчитывать свое строительство на небольшом экране элементов интерфейса должно быть, как можно меньше, с возможностью на время их развернуть (для выбора башни), а также размер элементов должен меняться в зависимости от размера экрана пользователя.

3.Реализация баланса в игре жанра башенная защита

Следующая задача для выполнения поставленной цели - это продумать баланс будущей игры [20]. Баланс заключается в определении базовых характеристик для основных объектов игры: крипов и башен. Крип - базовый воин, имеющий 2 характеристики: скорость передвижения и количество очков здоровья, основная задача крипа в игра пройти путь из точки «появления» до точки, которую обязан защитить игрок. Логика игры такова что крип, всегда ищет кратчайший путь и реагирует на изменения в этом пути, перестраивая маршрут по ходу движения. Башня - это основная защитная единица для игрока, с помощью которой он должен остановить движение крипа к его цели, характеристики башни: сила выстрела, скорость выстрела, радиус атаки, количество клеток, занимаемых башней на поле и стоимость постройки. Задача игрока - имея ограниченное количество ресурсов, расположить башни на поле таким образом, чтобы все крипы были уничтожены до того, как дойдут до конечной точки. Оптимизация баланса в игре реализована в несколько этапов:

· теоретические расчеты;

· альфа-тестирование

· корректировка значений;

· бета-тестирование;

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

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

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

2. Башня - устанавливаемый игроком неподвижный юнит, дистанционно воздействующий на противников.

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

4. Тайл - квадратная ячейка поля.

5. HP(ХП) - очки здоровья крипов. То, что отнимается при атаке башнями.

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

В качестве значения ХП крипов, их скорость передвижения и награда будут базовыми величинами, на которые будут опираться остальные расчеты. Представим их в виде таблицы (табл.3):

табл. 3

Имя	ХП	Скорость (тайл/сек.)	Награда
Легкий пехотинец	100,0	1,0	10
Тяжёлый пехотинец	500,0	1,0	20

Исходя из данной таблицы можно составить другу таблицу (табл. 4), в которой будут классифицироваться башни для игры:

табл. 4

Имя	Сила выстрела (ХП)	Скорострельность (выстрел/сек)	Радиус атаки (Тайл)	Стоимость
Каменная башня	5,0	1,00	1	10
Башня с лучниками	3	3,00	1	20
Башня с баллистой	15,0	0,50	3	40

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

Говоря о денежных единицах игры, стоит заметить, что у игрока будет иметься изначальный баланс денег до начала игры, в дальнейшем, «казна» будет пополнятся за счет убийство крипов, а также небольшого бонуса в начале каждой волны. Стартовое количество денег и количество крипов в волне будет меняться в зависимости от сложности игры: легкой, средней или тяжелой. Для того чтобы вычислить количество стартового капитала, не обходимо просчитать какое количество башен потребуется для уничтожения первой волны. Ниже приведена таблица с количеством и наполнение каждой волны (табл. 5):

табл. 5

Волны\Сложность	Легкий	Средний	Тяжелый
	ЛП	ТП	ЛП	ТП	ЛП	ТП
Волна 1	8	0	10	1	10	2
Волна 2	10	2	25	2	20	3
Волна 3	15	3	40	3	35	5
Волна 4	20	3	55	5	50	15
Волна 5	25	5	70	10	70	25

Как мы видим первая волна на уровне сложности «легкий» по задумке будет состоять все из 8 крипов: 8 легких пехотинцев (ЛП) и 0 тяжелых пехотинцев (ТП). Каждый ЛП имеет 100 ХП и скорость передвижения 1 тайл в секунду, для его уничтожения потребуется 20 выстрелов из 1 башни, 12 из второй и 7 из третьей. В реальной игре максимальное количество выстрелов, которое сделает башня, пока крип проходит мимо нее зависит от количества клеток пути крипа, пролегающих в радиусе атаки башни, назовем этот параметр боевая эффективность (БЭ), для вычислений мы возьмем следующие значения: для башни с радиусом в 1 тайл, минимальная БЭ будет равняться 3 клеткам, а максимальная 7 рис. 2.

рис. 2

Исходя из рисунка № 2, становится понятно, что достичь БЭ = 7, трудно, даже при построении лабиринта, но БЭ = 6 - в лабиринте из башен, при грамотном построении будет наиболее вероятна. Тем же образом можно найти БЭ для башни радиусом 3, минимальная БЭ = 1, а максимальная величина 20. Для разных уровней сложности для вычисления количества башен необходимых для постройки, будет использоваться данный параметр. Для «лёгкого» уровня сложности БЭ башни с r = 1, будет равен 3, а для r = 3, БЭ = 7, эти значения достигаются путем установки башни на границе с путем крипа. Для «среднего» уровня сложности, БЭ(r=1) = 6, а БЭ(r=3) = 20, так же, как и на уровне «тяжелый».

Итак, когда мы определили БЭ для башни на уровне 1, мы можем посчитать сколько выстрелов сделает «каменная башня» за время прохода мимо нее крипа по формуле: БЭ*сила выстрела * скорость атаки, подставим в формулу значения 3*5*1 = 15. Теперь берем здоровье крипа (100) и делим на получившуюся величину округлив остаток в большую сторону, так мы получим количество башен необходимое для убийства крипа 100/15 = 6,66 ~ 7 башен. Получается, чтобы пройти первую волну игроку нужно построить всего 7 «каменных башен» что по стоимости обойдется в 70 единиц, или 80 для «башни с лучниками» или для «башни с баллистой», если просчитать их эффективность по той же формуле.

табл. 6

Деньги	Легкий	Средний	Тяжелый
Стартовое	100	300	500
Волна 1	50	25	0
Волна 2	50	25	0
Волна 3	50	25	0
Волна 4	50	25	0
Волна 5	50	25	0

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

Заключение

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

Приложение

MainMenu.java:

package com.betmansmall.game;

import com.badlogic.gdx.Gdx;

import com.badlogic.gdx.Screen;

import com.badlogic.gdx.graphics.GL20;

import com.badlogic.gdx.graphics.Texture;

import com.badlogic.gdx.graphics.g2d.Batch;

import com.badlogic.gdx.graphics.g2d.TextureRegion;

import com.badlogic.gdx.scenes.scene2d.Action;

import com.badlogic.gdx.scenes.scene2d.Actor;

import com.badlogic.gdx.scenes.scene2d.InputEvent;

import com.badlogic.gdx.scenes.scene2d.InputListener;

import com.badlogic.gdx.scenes.scene2d.Stage;

import com.badlogic.gdx.scenes.scene2d.ui.Image;

import com.badlogic.gdx.scenes.scene2d.ui.ImageButton;

import com.badlogic.gdx.scenes.scene2d.utils.ClickListener;

import com.badlogic.gdx.utils.viewport.ScreenViewport;

public class MainMenuScreen implements Screen {

private Image background;

private Image returnButton;

private Image aboutScreen;

private Image welcomeScreen;

private Texture buttons;

private TextureRegion menuButton;

private TowerDefence towerDefence;

MenuButtons menuButtons;

private Stage mmStage;

private ImageButton settings;

private boolean isShowAbout = false;

float timer;

public MainMenuScreen(TowerDefence towerDefence){

this.towerDefence = towerDefence;

create();

}

class MenuButtons extends Actor{

@Override

public void draw(Batch batch, float parentAlpha) {

batch.draw(menuButton,getX(),getY(),getWidth(),getHeight());

}

}

private void create() {

welcomeScreen = new Image((new Texture(Gdx.files.internal("img/welcomescreen.png"))));

welcomeScreen.setSize(Gdx.graphics.getWidth(), Gdx.graphics.getHeight());

welcomeScreen.setPosition(0f, 0f);

//Creating background

background = new Image(new Texture(Gdx.files.internal("img/background.jpg")));

background.setSize(Gdx.graphics.getWidth(), Gdx.graphics.getHeight());

background.setPosition(0f, 0f);

//Adding the return button

returnButton = new Image(new Texture(Gdx.files.internal("img/backbutton.png")));

returnButton.setSize(100f, 100f);

returnButton.setPosition(0f, 0f);

returnButton.addListener(new ClickListener() {

@Override

public void clicked(InputEvent event, float x, float y) {

Gdx.app.log("Return button ", "clicked");

}

});

buttons = new Texture(Gdx.files.internal("img/buttons.png"));

menuButton = new TextureRegion(buttons, 0, 0, buttons.getWidth(), buttons.getHeight());

mmStage = new Stage(new ScreenViewport());

menuButtons = new MenuButtons();

menuButtons.setPosition(mmStage.getWidth() / 2 - buttons.getWidth() / 2, 0);

menuButtons.setSize(buttons.getWidth(), buttons.getHeight());

menuButtons.addListener(new InputListener() {

public boolean touchDown(InputEvent event, float x, float y, int pointer, int button) {

System.out.println("down");

touchDownAnalizer(x, y);

return true;

}

});

settings = new ImageButton(new Image(new Texture(Gdx.files.internal("img/settings.png"))).getDrawable());

settings.setSize(175, 175);

settings.setPosition(Gdx.graphics.getWidth() - settings.getWidth(), 0);

settings.addListener(new ClickListener() {

@Override

public void clicked(InputEvent event, float x, float y) {

Gdx.app.log("MainScreen", "Settings");

}

});

aboutScreen = new Image(new Texture(Gdx.files.internal("img/about.png")));

aboutScreen.setPosition(Gdx.graphics.getWidth() / 2 - 250, 0);

aboutScreen.addListener(new ClickListener() {

@Override

public void clicked(InputEvent event, float x, float y) {

aboutScreen.remove();

}

});

mmStage.addActor(background);

mmStage.addActor(menuButtons);

mmStage.addActor(settings);

mmStage.addActor(returnButton);

// mmStage.addActor(welcomeScreen);

}

@Override

public void show() {

Gdx.input.setInputProcessor(mmStage);

}

private void touchDownAnalizer(float x, float y){

if(y > 73 * menuButtons.getHeight()/600f && y < 231 * menuButtons.getHeight()/600f ){

Gdx.app.log("MainScreen", "Exit");

towerDefence.closeApplication();

}else if(y > 259 * menuButtons.getHeight()/600f && y < 417 * menuButtons.getHeight()/600f ) {

Gdx.app.log("MainScreen", "About");

mmStage.addActor(aboutScreen);

isShowAbout = true;

} else if(y > 442 * menuButtons.getHeight()/600f && y < 600 * menuButtons.getHeight()/600f ) {

Gdx.app.log("MainScreen","Play");

towerDefence.setScreen(new GameScreen());

} else {

Gdx.app.log("MainScreen","Unknown analyzer");

}

}

@Override

public void render(float delta) {

Gdx.gl20.glClear(GL20.GL_COLOR_BUFFER_BIT);

mmStage.act(delta);

mmStage.draw();

if(timer>3)

{

welcomeScreen.remove();

}

timer = timer+delta;

//Gdx.app.log("GameScreen FPS", (1/delta) + "");

}

@Override

public void resize(int width, int height) {

mmStage.getViewport().update(width, height, true);

}

@Override

public void pause() {

}

@Override

public void resume() {

}

@Override

public void hide() {

//Should not be here!

//dispose();

}

@Override

public void dispose() {

mmStage.dispose();

mmStage = null;

}

}

GameScreen.java:

package com.betmansmall.game;

import com.badlogic.gdx.Gdx;

import com.badlogic.gdx.Input;

import com.badlogic.gdx.InputMultiplexer;

import com.badlogic.gdx.InputProcessor;

import com.badlogic.gdx.Screen;

import com.badlogic.gdx.graphics.Color;

import com.badlogic.gdx.graphics.GL20;

import com.badlogic.gdx.graphics.OrthographicCamera;

import com.badlogic.gdx.graphics.Texture;

import com.badlogic.gdx.graphics.g2d.BitmapFont;

import com.badlogic.gdx.input.GestureDetector;

import com.badlogic.gdx.math.GridPoint2;

import com.badlogic.gdx.math.Vector2;

import com.badlogic.gdx.math.Vector3;

import com.badlogic.gdx.input.GestureDetector.GestureListener;

import com.betmansmall.game.gameLogic.GameField;

import com.betmansmall.game.GameScreenInteface.GameInterface;

public class GameScreen implements Screen {

private static final float MAX_ZOOM = 50f; //max size

private static final float MIN_ZOOM = 0.2f; // 2x zoom

private float MAX_DESTINATION_X = 0f;

private float MAX_DESTINATION_Y = 0f;

private BitmapFont bitmapFont = new BitmapFont();

private float currentDuration;

private float MAX_DURATION_FOR_DEFEAT_SCREEN = 5f;

private Texture defeatScreen;

private GameScreen gs;

public OrthographicCamera camera;

private GameInterface gameInterface;

private GameField gameField;

class CameraController implements GestureListener {

float velX, velY;

boolean flinging = false; // Что бы не пересикалось одно действие с другим действием (с) Андрей А

float initialScale = 2f;

boolean lastCircleTouched = false;

@Override

public boolean touchDown(float x, float y, int pointer, int button) {

Gdx.app.log("CameraController::touchDown()", " -- x:" + x + " y:" + y + " pointer:" + pointer + " button:" + button);

flinging = false;

initialScale = camera.zoom;

return false;

}

@Override

public boolean tap(float x, float y, int count, int button) {

Gdx.app.log("CameraController::tap()", " -- x:" + x + " y:" + y + " count:" + count + " button:" + button);

//CHECK IF THE PAUSE BUTTON IS TOUCHED //CHECK IF THE TOWER BUTTON IS TOUCHED

if(gameInterface.getCreepsRoulette().isButtonTouched(x,y)

gameInterface.getTowersRoulette().isButtonTouched(x,y)) {

return false;

}

Vector3 touch = new Vector3(x, y, 0);

camera.unproject(touch);

GridPoint2 grafCoordinate = new GridPoint2((int) touch.x, (int) touch.y);

GridPoint2 cellCoordinate = gameField.whichCell(grafCoordinate);

if(cellCoordinate != null) {

if(button == 0) {

//if(count)

//gameField.prepareBuildTower(cellCoordinate.x, cellCoordinate.y);

//gameField.towerActions(cellCoordinate.x, cellCoordinate.y);