ТЕСТИРОВАНИЕ ИНТЕРЕСА К ИГРЕ

Введение

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

1. Требования к игре
Понятно, что основное требование к игре состоит в том, чтобы она была интересной. Но интерес во многом зависит от выполнения некоторых требований, которые иногда, даже не осознаются пользователем, но, тем не менее, невыполнение их ведет к снижению качества игры.
Создание игры состоит из трех этапов: реализации механики игры(game mechanics),
игрового интерфейса(game interface) и игрового процесса(game play)
Под механикой игры понимается комбинация свойств, присущих созданной программной модели воплощённых с помощью анимации и программирования.
Под игровым интерфейсом понимается организация управляющих элементов, с помощью которых пользователь управляет программой. Это реакции на горячие клавиши, иерархические меню, механизмы отклика на действия мыши или джойстика и так далее.
Игровым процессом называется последовательность действий, которые должен проделать пользователь, чтобы достигнуть цели игры. Также к реализации игрового процесса относится создание сюжета игры, уровней, принципы начисления очков и так далее
Ниже представлены те требования, которые автор считает наиболее важными
• Управляющие клавиши и элементы меню должны соответствовать принятым в отрасли стандартам.
• Пользователю должны быть всегда доступны его очки или игровой статус
• Количество горячих клавиш должно быть минимальным
• Для предоставления обратной связи должно использоваться звуковое сопровождение
• Количество пунктов меню должно быть минимальным
• Действия, которые нужно производить должны быть понятны настолько, что нет необходимости обращаться к руководству пользователя
• Скорость отклика на действия игрока должна быть как можно большей
• Скорость отклика должна быть равномерной
• Скорость
• Цель игры должна быть понятной
• В игре должна быть возможность выбрать уровень сложности
• В каждом уровне должно быть несколько целей
• Должно существовать несколько выигрышных стратегий
• Должна присутствовать возможность сохранить начатую игру и вернуться к ней позже
• Сохранение игры должно производиться автоматически, через определённые интервалы времени или по достижению ключевых точек в игре
• У пользователя должна быть возможность автоматического создания уровней
• Присутствие определённой сложности в достижении игровых задач(Challenge). Как показывает практика, игра, прохождение которой не требует от игрока усилий, не пользуется популярностью
• Сложность уровней должна монотонно возрастать.
• Первый уровень не должен представлять особенной сложности. Его задача пояснить пользователю правила игры
•
Очевидно, что конкретное применение этих условий зависит от жанра игры.

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

2. Виды тестирования игр

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

2.1 Тестирование функциональности (functionality testing) Цель – выявить отклонения от требуемой функциональности и ошибки так называемые «баги» (профессиональный жаргон). Этот тип тестирования, как правило, не требует от тестировщика больших технических познаний помимо понимания базовых концепций программирования и сводится к многократному прохождению игры, выявлению неполадок и условий в которых они воспроизводятся. Описание проблем производится в произвольной форме, важно лишь, чтобы текст был понятен разработчику.
Данный вид тестов является общим для всего программного обеспечения, поэтому останавливаться на нём подробно нецелесообразно.

2.2 Тестирование соответствия аппаратному обеспечению(compliance testing) Программирование игр, как и любого другого программного обеспечения, производится на персональных компьютерах: настольных или ноутбуках. В тоже время, многие игры предназначены для других типов устройств, таких как различные игровые приставки(Nintendo, Sony, Microsoft), мобильные телефоны, карманные портативные компьютеры (наладонники), коммуникаторы и другие. Первоначально разработка производится при помощи симуляторов указанных устройств, однако, как и всякая модель, они отличаются от оригинала, часто существенно. Поэтому, игра, успешно работающая на симуляторе, может иметь проблемы при запуске на устройстве. Кроме того, многие из производителей устройств, вводят лицензирование для программного обеспечения. Одним из необходимых условий успешного прохождения лицензии есть соответствие списку технических требований. Примером могут быть требования компании «Sony» для игровых приставок - Sony publishes a Technical Requirements Checklist (TRC), компании Microsoft - Microsoft publishes Technical Certification Requirements (TCR) и другие. Даже в случае незначительных отклонений от требований, в лицензии может быть отказано. В этом случае программа возвращается на доработку и таким образом теряется время, что приводит к потере и денег. Кроме того, процесс лицензирования в большинстве случаев платный. Поэтому, очень важно проверить игру на соответствие заявленным параметрам аппаратного обеспечения.

2.3 Нагрузочное тестирование(crash testing) Часто бывает, что программа, нормально работающая в большинстве ситуаций, обнаруживает проблемы при эффективных вычислениях. Этот вид проблем особенно неприятен потому, что интенсивность вычислений может не зависеть от логики игры.
Например, в программах написанных для Java – платформы, AVM2 (flash - player) и других может запускаться сборщик мусора. Принцип его работы такова, что он запускается независимо от деловой логики. В тоже время, его работа дорога в смысле вычислительных ресурсов. Кроме того, игровые ситуации с большим объёмом вычислений могут быть не замечены тестировщиками.
Поэтому, целесообразно создать тестовые ситуации, требующие большой вычислительной нагрузки. Таким образом, гораздо легче заметить и улучшить имеющиеся потенциально ненадёжные участки кода.

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


3. Метод экспертной оценки в тестировании игр

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

3.1 Фокус группы (Focus Groups) Группа пользователей, обычно содержащая десять – двенадцать человек обсуждает определённый аспект игры. Такой, например, как звуковое сопровождение или реалистичность кинематики движения персонажей. Результаты дискуссии и фиксируются в протоколе. Метод хорошо подходит для выявления глобальных недостатков в концепции игры, может быть использован до завершения работы над игровой механикой.
Недостатки состоят в том, что невозможно получить конкретные численные данные, обсуждаемая концепция игры может коренным образом отличаться от концепции готового продукта, в дискуссии могут превалировать два три участника с более развитыми навыками полемики, подавляя тем самым мнение остальных.

3.2 Ретроспективное анкетирование. Чаще всего производится после выхода игры. В анкете задаются вопросы о качестве графики, звукового оформления, персонажей, сюжета и так далее. Разновидностью данного вида анкетирования являются комментарии на сайтах соответствующей тематики. В случае онлайн игр пользователю, в большинстве случаев, предлагается оценить игру непосредственно на web – странице, где она расположена. Упоминаемый выше рейтинг на игровых сайтах также можно считать видом ретроспективного анкетирования.
Этот вид тестирования позволяет непосредственно оценить игру - с его помощью можно получить объективную оценку. Данные, полученные таким образом, можно использовать как критерий качества в методе анализа пользовательских реакций, метод неприменим для улучшения вышедшей игры. Он может помочь лишь в устранении имеющихся недостатков для последующих продуктов. Также, пользователи обычно не стимулированы заполнять большие анкеты, а иногда и необъективно оценивают игру.

3.3 Бета тестирование Модификацией предыдущего метода можно считать метод бета – тестирования. После выхода бета – версии игры создатель может предложить желающим бесплатно получить программу. Взамен, тестеры указывают на существующие недостатки. Этот метод хорош тем, что позволяет проверить реакцию конечного пользователя до официального окончания работы над игрой. Кроме того, бета - тестеры в большинстве случаев являются очень опытными игроками, поэтому их замечания объективны и точны.
Для небольших и онлайн игр можно предложить тестирование посетителям тематических форумов. Так на форуме www.flasher.ru присутствует раздел обсуждения готовых flash – приложений, в том числе и игр.

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

4. Тестирование игрового интерфейса и процесса с помощью записи реакций игрока.

Анкетирование и обсуждение позволяет выявить качественные проблемы игр, однако любая оценка игры субъективна. Кроме того, добровольные тестеры часто не в состоянии пояснить, что именно им не нравится в процессе игры, а профессионалы обходятся дорого. Далее, любое тестирование, основанное на фиксации мнения игрока, способно решить проблему лишь качественно. Конкретные численные характеристики приходится находить экспериментально, что увеличивает время и стоимость работы. Поэтому, принято записывать реакции игрока и путём их анализа корректировать численные параметры игры.
В качестве примера применения логирования и информации, которую можно с помощью него получить, рассмотрим такой класс игр, как головоломки.
Суть таких игр сводится к решению последовательности задач на логику, внимание, память, иногда необходимо решить задачу за определённое время. Классическими головоломками являются пазлы, шахматные и шашечные задачи, судоку, кроссворды и так далее. В последнее время появились головоломки, которые сводятся к предсказанию поведения механической системы. Такие как игры расположенные по адресам: http://www.kongregate.com/games/TheGameHomepage/red-remover, http://www.kongregate.com/games/inXile_Ent/fantastic-contraption,
http://www.kongregate.com/games/inXile_Ent/super-stacker-2 и другие. Видно, что игра состоит из последовательности логических задач повышающейся сложности.

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

Ниже приведены параметры, подлежащие записи и данные, которые можно получить в процессе их анализа.

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

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



Перспективы дальнейших исследований.

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


Литература
1. John P. Davis, Keith Steury, and Randy Pagulayan. A survey method for assessing perceptions of a game: The consumer playtest in game design http://www.gamestudies.org/0501/davis_steury_pagulayan/
2. Melissa A. Federoff. Heuristics and usability guidelines for the creation and evaluation of fun in video games
3. Sauli Laitinen. Better Games Through Usability Evaluation and Testing http://www.gamasutra.com/features/20050623/laitinen_02.shtml
4. David Kieras, User Interface Design for Games http://www.eecs.umich.edu/~soar/Classes/494/talks/User-interfaces.pdf
5. Sauli Laitinen. Do usability expert evaluation and test provide novel and useful data for game development?
6. Shannon Lucas and Denise Fulton What We Learned Evaluating the Usability of a Game http://www.stcsig.org/usability/newsletter/0410-gameevaluation.html
7. Martin Peterson Why Game Documentation is Essential to a Satisfying User Experience http://www.stcsig.org/usability/newsletter/0410-gamedocs.html