Данный пост — перевод двенадцатой статьи из курса лекций «Принципы гейм-дизайна» за авторством профессионала и преподавателя Яна Шрайбера. Переводы предыдущих лекций вы можете посмотреть по ссылке.

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

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

Чтение

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

Разные виды тестирования

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

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

Тестирование на баги (или Проверка качества – QA)

Целью QA-тестирования является поиск ошибок в поведении игры, которые кроются в её дизайне. «Интересу» здесь места нет. Если дизайнер говорит, что игра должна делать что-то одно, а она в действительности делает что-то совсем другое (даже если то, что она делает – лучше задуманного) – это всё равно баг и его необходимо обнаружить.

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

Фокусное тестирование

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

Тестирования на доступность

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

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

Тестирование баланса

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

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

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

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

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

Порядок действия

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

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

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

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

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

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

Разные типы тестеров

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

— Вы сами. Вы сами себе ценнейший тестер. Не забывайте о том, что вы можете играть в свою игру сами. Вы её знаете лучше, чем кто-либо другой.

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

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

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

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

Порядок близости

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

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

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

Игра с самим собой

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

Удовлетворяет ли игра целям дизайна?

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

Есть ли «дыры» в правилах?

«Дыры» – это ситуации, когда правила просто не говорят, что делать дальше. Например, допустим, что согласно вашим правилам армия одного игрока может атаковать армию другого игрока, но у вас ещё нет правил разрешения атаки. Что происходит тогда? Обычно в таких случаях игроки просто сидят и ждут, когда дизайнер разберётся что к чему!

Для иллюстрации: представьте себе правила игры Крестики-нолики на поле 4х4:

— Игроков: 2

— Цель: начертить символы в ряд.

— Подготовка к игре: Начертите сетку 4х4.

— Ход игры: на своем ходу поместите свой символ («Х» или «О») на пустую клетку.

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

Если вы попробуете играть в эту игру, просто прочитав правила, вы скоро поймёте, что не сможете даже начать – нигде не сказано, кто из игроков Х, а кто О, и кто ходит первым! Чтобы исправить это, вы должны дополнить правила. Например:

Подготовка к игре: Начертите сетку 4х4. Выберите игрока, который ходит первым, за ним закрепляется символ «Х». Другому игроку даётся символ «О».

Есть ли тупики?

«Тупик» – это такое состояние игры, когда продолжать невозможно, но игра не разрешилась. Представьте опять наши правила для Крестиков-ноликов 4х4. Допустим, оба игрока заполнили клетки на поле, и никто не выиграл. Игра не может продолжаться, ведь в правилах указано «поместите свой символ на пустую клетку». Нет пустых клеток, игроки не могут ходить. Но исход неясен, ведь никто не выиграл. В данном случае необходимо добавить новое правило (а именно: в конце игры, когда никто из игроков уже не может сделать ход, но никто и не выиграл, игра заканчивается вничью).

Есть ли неясные правила?

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

Существуют ли очевидные лазейки для злоупотребления правилами?

Есть ли какая-то стратегия, которая слишком легко приводит к победе? Постарайтесь её обнаружить. Будет не так стыдно найти её самостоятельно и исправить до того, как её обнаружили тестеры (или ещё хуже – игроки, уже после выпуска игры). Чрезмерную прозрачность и всякие лазейки зачастую труднее всего заметить в собственной игре; в конце концов, вы ведь хотели создать игру, а не проблемы на свою голову. И всё же постарайтесь – возможно, вам удастся обнаружить ошибки раньше (что сохранит вам очень много времени в перспективе для работы над другими вещами).

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

Трудности теста в одиночку

Есть несколько вещей, которые трудно тестировать одному:

— Многопользовательские игры в реальном времени, например такие, где вам нужно как можно скорее, опередив соперника, хлопнуть по карте или дать правильный ответ.

— Игры со скрытой информацией, где у каждого игрока есть информация, доступная ему одному, и её важно скрывать от противника.

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

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

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

Дайте игре развиваться

Опытные дизайнеры часто говорят о том, что игра «сама себя создаёт» — как будто она живой организм, а дизайнер её просто направляет. На первый взгляд это звучит странно, ведь и правда: игра же не сидит в углу, развиваясь сама по себе – она продвигается только тогда, когда дизайнер в неё играет и что-то в ней меняет. Так что же происходит на самом деле?

А дело вот в чём. Создание игры – это процесс познания. Возможно, у вас есть какое-то представление о том, какой должна получиться игра. Но результат может очень отличаться от того, что вы изначально задумали. Меняется же она потому, что в самом начале вы ещё мало знаете о своей игре. У вас есть лишь замысел, но вы не знаете, как в действительности будут взаимодействовать механики, или какой на самом деле будет динамика и эстетика. В ходе тестирования вы изучаете работу систем своей игры. По мере изучения вам становится всё проще предсказать, как то или иное изменение повлияет на игровые системы.

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

Домашняя забава

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

К полудню понедельника 10 августа, создайте готовый и игре прототип вашей игры. Возможно, вам будет полезно пересмотреть раздел о прототипировании из Уровня 4. Помните, что прототип можно сделать за 15 минут – ему не обязательно быть красивым и завершённым (пока что), но он должен быть пригоден для того, чтобы взять его и начать играть.

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

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