Тестирование игр. Что это? Зачем это?

Что такое игра?

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

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

Получение вознаграждения за то, что ты правильно и круто выполнил процесс игры, рождает эмоциональную связь между игроком и игрой. Всем приятно получать пряник, и никому не приятно получать кнут. Игра дарует игроку счастье, выраженное в том, что он прошел уровень или получил что-то от игры, чего добивался определенное время. Но также игрок связан с игрой физически.
Никогда не забуду, как увидел человека, который первый раз проходил Mirror’s Edge. В этой игре главный герой прыгает по крышам и делает пируэты, невообразимые для человеческого мозга и тела. С каждым движением главного героя на экране, с каждым движением камеры мой друг двигался сам. Он был привязан к процессу настолько, что физически пытался отзеркалить движения персонажа на экране! А сколько раз мы пытались заглянуть за угол, повернув нашу голову? И это касается не только игр, которые специально сделаны таким образом. Даже сити-билдеры, игры, где основная идея заключается в постройке города, дают свою физическую связь. Человек смотрит на свой город и думает, красив он или нет. Оценивает его своим взглядом. Ему нравится, что он видит! Именно этот микс эмоционального и физического контакта делает игру настолько уникальным видом развлечения!

Это отлично, скажете вы, но как это относится к тестированию игр?
С чего бы начать?

1. Баланс
Люди, которые играют в многопользовательские игры, уже слышали это слово.
Что такое баланс? Баланс – это набор таблиц, каждая из которых отвечает за какой-то отдельный набор объектов в игре. В каждой из таблиц есть список наименований и набор значений, которые нужны для данного объекта в игре. Например, у «Монстра» будут прописаны количество жизней и объем получаемого и наносимого им урона. У «Оружия» будут расписаны его уникальные качества, редкость, тип, количество наносимого урона и так далее.
Баланс составляется геймдизайнером, перед которым ставится такая задача.
Когда игра разрабатывается, в нее добавляются объекты: оружие, строения, предметы, монстры, враги, друзья, ресурсы, деньги и так далее. Используя эти объекты, создатель настраивает процесс, в который будет погружен игрок. И вот, когда все предметы созданы, создатель, он же геймдизайнер, настраивает их так, чтобы процесс игры был для игрока затягивающим и комфортным. Он берет все, что есть в игре, и назначает его важность, «вес» и цену. Он ставит «гири» на чаши весов, где на одной чаше написано «награда», а на другой – «наказание». Он, как царь и бог, может сказать, что одно оружие наносит столько урона, а другое – столько. Именно он занят тем, чтобы монстры, которых встретил игрок на начальном уровне, были для игрока достаточно просты.

Так как нам тестировать баланс? Есть несколько вещей о тестировании баланса, о которых я хочу вам рассказать:

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

2. Формулы
Существуют формулы, которые должны рассчитывать ту или иную часть игрового процесса в зависимости от значений. Но в формулах могут быть ошибки. Везде могут быть ошибки. Формулы тоже пишет геймдизайнер, именно у него мы, как тестировщики, можем получить информацию: как они выглядят, откуда они берут значения, какое значение должно получаться. Когда мы вытрясли из него все, первое, что нужно сделать, – это посмотреть на формулу и подставить под нее простые значения. Например, формула нанесения урона врагу может выглядеть вот так:
((баз. урон + «Сила» + урон от оружия) * коэффициент) — процент невосприимчивости врага. К сожалению, в таблице могут быть приведены значения, при которых наша голова будет болеть, считая даже эту простую формулу. Но после того, как мы подставим простые значения: ((2 + 1 + 2) * 2) — 15%, нам становится проще представить себе конечный результат.

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

3. Процесс
Так как игра не статична, мы не можем протестировать баланс, исследуя его только в некоем вакууме наших цифр. Игра – это процесс, и только в самом процессе мы можем выяснить, работает ли баланс игры. Что, если сама задумка данного расчета неправильная? Что должно быть? Стоит ли сделать игру проще или сложнее? Правильно ли настроено количество вознаграждения за победу и наказания за поражение? Давайте поговорим об этом.

Как и все игроки, тестировщик тратит определенные усилия, чтобы пройти от «пункта А» до «пункта Б» в игре. Но, в отличие от игрока, тестировщик по-настоящему тестирует это время и усилия, сравнивая их с определенными значениями. Это такая же проверка ожидаемого и фактического результатов! Но если фактический результат можно проверить, проходя из «пункта А» в «пункт Б» раз за разом, сравнивая результаты, то где брать ожидаемый результат? У всё тех же геймдизайнеров. Когда геймдизайнер пишет баланс, он не берет его с потолка или, по крайней мере, не должен брать его с потолка. Чтобы игра хорошо игралась, геймдизайнер рассчитывает, сколько усилий и времени потребуется игроку для достижения цели. Например: сколько монстров ему надо убить, чтобы получить второй уровень? Сколько предметов продать, чтобы получить возможность купить новое оружие или доспех? Сколько раз попасть в цель, чтобы повысить уровень навыка стрельбы? Это первый источник нашей информации об ожидаемом результате.

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

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

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

2. Визуальная составляющая
Одна из важнейших частей того, чем игра является в итоге, – это ее визуальная составляющая. Чтобы полностью расписать то, что нужно и можно тестировать в визуальной части, уйдет месяц, может быть даже больше. Но некоторые фишки и важные аспекты мы все-таки зацепим.
«Движок! Я слышал это слово много раз!» – скажут многие. Но начнем с того, что такое engine?
Движок (Еngine) – это программное обеспечение, которое сделано для того, чтобы делать игры. Разработчики используют его для того, чтобы самим не писать многие правила и функции для игры, чтобы сэкономить время себе и деньги для проекта. Основные функциональные возможности, обычно предоставляемые игровым движком, включают в себя движок рендеринга (отображения) для 2D- или 3D-графики, физический движок или обнаружение столкновений (и реагирование на столкновения), звук, сценарии, анимацию, искусственный интеллект, сетевое взаимодействие, потоковую передачу, память, управление, многопоточность, поддержку локализации, граф сцены и могут включать поддержку видео для кинематографии.

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

Правильно ли стоят объекты на карте?
Никакие деревья не летают в воздухе?
Свет не бьет из земли?
Стены вокруг с текстурой стен или пола?

Если все показывается правильно – отлично для нас! Если нет – смело делаем баг-репорт на человека, который ответственен за эту часть игры!

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

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

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

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

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

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

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

Однако этот абзац посвящен не тому, как я отношусь к бета-тестам, а тому, насколько неправильное понимание бета-тестов сложилось у игроков, что у игры не хватает тестировщиков, чтобы сделать ее хорошо сразу или такой, какой бы она понравилась игрокам. И у меня было такое, пока мы сами не выложили игру в бету! Мы полностью сделали игру, основной геймплей был достаточно вылизан, чтобы игроку было комфортно играть, но игроки на форуме начали говорить о неудобствах игрового чата, что он неправильно работает и «не был протестирован». Я специально посчитал, сколько примерно раз в общей сложности тестировщики проверяли игровой чат перед тем, как отдать пользователям. 320 раз! Прописью: триста двадцать раз! Полного прохождения всех тестов, которые были связаны с чатом! И каждый раз прохождения были необходимы по разным причинам! Благо чек-лист был достаточно коротким, на его прохождение уходило две минуты с небольшим. Вы можете спросить: много это или мало? Все познается в сравнении: во время работы над другим проектом я посчитал, сколько раз был пройден короткий чек-лист, примерно такой же по размеру, от начала тестирования до момента, когда фича была отдана пользователям. Я насчитал 32 прохождения!

Да, конечно, я выбрал самый показательный пример! Но если вы оказались тестировщиком игры, которая выпустилась в бета-тесте, и читаете такие сообщения от игроков – не расстраивайтесь! Просто знайте, что теперь вы побывали на другой стороне баррикад.

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

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

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

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

Что бесценно!