Тестирование «Drakensang: Река времени» или как сделать игру еще лучше?

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

Итак, проверка начинается. Сотрудники отдела получают план тестирования или особые задания, например, проверить новые значки монстров! После этого каждый тестер запускает игру и проверяет свою часть. Если ему поручено проверить значки монстров — он находит всех новых монстров и проверяет, соответствуют ли значки монстрам и правильно ли они работают. Иными словами, многое приходится проверять вручную. Наше преимущество — в рабочей силе, так как над «Drakensang. Река времени» работает очень много тестеров. Даже если один из них пропустит какую-то ошибку, то ее обязательно заметит другой. Разумеется, существует масса автоматических методов проверки, но они рассчитаны на более монотонные игры. В таком сложном проекте, как у нас, нет смысла применять их.

Отдел тестирования работает с базой данных ошибок (или баг-трекером). Как уже упоминалось выше, помимо задач по плану, в обязанности тестеров входит прохождение проекта в роли самого эксцентричного игрока. И даже в этом случае игра должна работать безупречно. Если при прохождении тестеры замечают что-то странное, они заносят описание ошибки в базу данных. Все ошибки разделяются на несколько категорий. Самые серьезные ошибки входят в класс «А» и имеют высший приоритет. Даже в контракте с издателем прописывается допустимое количество таких неполадок. В эту категорию относятся «падения» игры или непроходимости (например, чтобы пройти дальше, вам нужно взять некий предмет, а взять его невозможно). Затем идут ошибки класса «B» — в основном, они встречаются в заданиях. Например, игрок не получает награды после выполнения задания или ему не начисляются очки опыта. Конечно, это неприятно, но эти ошибки не мешают дальнейшему прохождению игры. Третья категория — «С» — как правило, это технические неполадки, например ошибки графики. И, наконец, последняя категория в базе данных — «D». Сюда относятся некоторые идеи — например, кто-то из тестеров предлагает добавить на определенной локации еще одно дерево. То есть, это даже не ошибки, а просто мнения.

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

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

Практически каждый день собирается новая версия игры, в которой проверяются новые возможности или перепроверяются исправленные ошибки. Тестерам приходится проходить всю игру заново. В проекте «Drakensang. Река времени» на прохождение только основного сюжета уходит более семи часов. А как гарантировать, что в конце проекта у нас останется минимум ошибок и относительно стабильная игра? Для этого крайне важно с самого начала четко распланировать порядок работы. Для этого составляется план этапов. В каждом месяце сдается некий этап — то есть, к определенному числу должна быть реализована определенная часть игры. Тогда же начинается и тестирование готовых материалов. Такие этапы — хорошие ориентиры для разработчиков, позволяющие оценить общий прогресс. Наши тестеры также работают поэтапно.

Кроме этого, все разумные разработчики заранее резервируют определенный срок под дополнительное тестирование и доводку деталей — конечно, и у нас для проекта «Drakensang. Река времени» предусмотрен такой период. На таких этапах разработки меняется количество тестеров. Во время процесса производства больше людей занято разработкой и меньше — тестированием. По окончанию цикла производства ситуация меняется, и большие силы перебрасываются на тестирование игры. Это логично, ведь все больше материалов нуждаются в проверке, и все меньше материалов предстоит создать.

Успешная борьба с ошибками в первой части Drakensang — заслуга не только наших тестеров, но вообще всех отделов студии. В «Drakensang. Река времени» все должно пройти так же хорошо, если не лучше — ведь теперь над проектом работает больше людей. А чем больше народу отправляется на поиск ошибок, тем меньше у них шансов остаться незамеченными.