В первых 2х статьях (раз и два) мы с вами уже взглянули на виды тестирования, применяемые в геймдеве и примеры багов, часто (и не очень) встречаемых в играх. Но в воздухе остался неозвученный вопрос: «Каким образом всё это тестировать?» В этой главе поделюсь подходами и инструментами, которые я использую для тестирования тех или иных игр, включая игры с большими картами (к примеру в жанре Battle Royal) или же что-то более локальное, такое как спортивный симулятор.
Чит коды / Чит меню (Cheat Codes / Cheat Menu)
Чит коды изначально были не пасхалками или полезными ништяками для игроков, чтобы те могли загружать определенный уровень или установить себе бесконечное здоровье/деньги и даже были придуманы не для сохранений, хоть и могут быть так применены. Чит коды использовались разработчиками для отладки игр. Их, в силу разных ограничений, нужно было вводить на определённом экране игры или меню. Со временем коды попали в народ и стали крайне востребованы по понятным “божественным” причинам.
Сейчас же вместо кодов, которые нужно запоминать и долго вводить, используются Чит Меню, в которых уже есть списки чит кодов, сгруппированных в удобный для использования вид. Данный список можно вызвать практически на любом экране, однако если код не подходит под текущие условия, то он не выполнится (к примеру если вы пытаетесь заспавнить объект в главном меню). Чит меню — это не типовая функциональность, у каждой игры оно имеет и уникальный вид, и уникальный код, ответственный за его реализацию.
Однако с большой силой приходит и большая ответственность — использование чит кодов может привести к багам, которые в реальных игровых условиях никак не добиться. Именно по этой причине достаточно сложные и даже «странные» баги нужно перепроверять и воспроизводить без использования чит кодов, а также всегда держать в уме весь флоу, который должен пройти игрок, чтобы наткнуться на данную проблему. Также стоит учитывать и то, что есть большая вероятность, что тот или иной баг, легко воспроизводимый при помощи читов, игрок никогда на практике и не встретит.
P.S. Motherlode и Konami Code навсегда в наших сердечках!
Игровая консоль
Консоль в игре может и часто используется в качестве полезного в тестировании инструмента. Обычно вызывается она при нажатии кнопки «~» (тильда), выпадает либо внизу небольшой строчкой, либо сверху экрана, занимая приличную его часть. Думаю многие использовали консоль в Counter Strike 1.6, превращая вашего персонажа из правши в левшу или меняя характеристики вашего прицела. Однако консоль не была включена по-умолчанию: её нужно было предварительно активировать в Options.
При помощи консоли на дев билдах (к примеру сразу из Unreal Editor) можно подключать back-end с нужными вам тестовым аккаунтам, ускорять или замедлять игру (не FPS, а именно внутриигровые действия), использовать чит коды, включать-выключать нужные вам HUD и многое другое.
Внутриигровые HUD (Heads-Up Display)
Крайне полезные инструменты, которые, в прочем, без помощи разработчиков, не получить. HUD виджеты часто вызываются при помощи консольной команды. В зависимости от того, как разработчики настроят HUD, будет выводиться та или иная информация под определённые нужды. При помощи таких элементов крайне удобно следить за нанесённым уроном, прогрессам по испытаниям (challenges), использованием предметов (consumables) и т.п.
Стоит упомянуть, что такие HUD разрабатываются разработчиками специально для отладочных нужд и их вполне может не быть в вашем проекте.
Weapon room / Training room
Такого рода комнаты, как правило, содержат оружие, персонажей, врагов (включая боссов), поверхности, предметы (consumables), транспорт. В общем всё необходимое и теоретически необходимое, что может пригодиться для тестирования во время геймплея. Кроме всего вышеперечисленного, в таких пространствах могут быть созданы комнаты под определённые нужды: например в одной могут быть расставлены предметы таким образом, чтобы проверить защищает ли преграда определённого размера вас в приседе, стоя и т.п.; в другой комнате — проходит ли персонаж между объектами и т.п.
Такие пространства встречаются, как правило, в достаточно больших играх, ведь для их создания нужен бюджет и разработчики, которые смогут всё необходимое собрать вместе. Далее вы уже сможете и сами «достраивать» нужные вам пространства внутри данной карты, если умеете пользоваться редактором движка.
Файлы конфигурации
Файлы конфигурации встречаются повсеместно и вы можете ими пользоваться для самых разных нужд. В дев билдах таких файлов больше, чем в релизной версии, и через них вы можете включать/выключать фичи, менять разрешения, управлять уровнем логирования, указывать к какому back-end’у конектиться, управлять настройками графики и многое другое. Часто любители «игр в возрасте» ковыряются в файлах конфигурации (например формата «.ini») для настройки работоспособности старых игры на новом железе, если для неё не выходил соответствующий патч или переиздание. Количество и объём доступных настроек и их формат могу кардинально отличаться от игры к игре, даже если игры написаны на одном движке.
Управление вашим интернет соединением
Крайне важный пункт для проверки в наше время, т.к. даже в сингл плеерных играх могут (и чаще всего встречаются) элементы, завязанные на онлайн. К сожалению здесь нету какого-то уникального и всеобъемлющего инструмента. Лично мне приятно и удобно использовать инструмент Clumsy в качестве помощника в этом деле. Программа манипулирует не игрой, а вашим соединением в целом, что делает Clumsy удобным инструментом для управления вашим соединением для абсолютно любых нужд: web, standalone software и т.п. В рамках данного инструмента вы можете управлять такими возможностями испортить ваше интернет соединение как Lag, Drop, Throttle, Out of order, Duplicate и Tamper. При чём делать это вы можете как для Inbound, так и для Outbound, указав шансы на встречу данной проблемы.
Режимы просмотра (View modes)
Игровые движки обладают такой функциональностью как «режимы просмотра» (view modes), которая помогает вам увидеть тип данных, обрабатываемых в вашей сцене, а также диагностировать любые ошибки или неожиданные результаты. У самых распространённых режимах просмотра есть свои горячие клавиши и они могут отличаться от движка к движку, но вы всегда можете просмотреть их все из режима просмотра или вызвать при помощи соответствующей команды в консоли. Ниже я приведу несколько примеров на основе View Modes из Unreal Engine, а больше и подробнее вы можете почитать в документации движка.
Давайте же взглянем на несколько из них.
Lit mode
Режим Lit отображает финальный результат вашей сцены после применения всех материалов и освещения.
Unlit mode
Данный режим выключает всё освещение в сцене, показывая только Base Color.
Wireframe mode
Wireframe mode или режим “проволочной рамки” показывает все полигоны в сцене без заполнения. Цвет линий рёбер полигонов может иметь дополнительную функцию. А может и не иметь 🙂 (тогда условно все рёбра — чёрные).
Reflections mode
Режим Reflection полезен для диагностики деталей отражений и позволяет вам размещать больше «Reflection Capture Actors» в областях, где вам нужно больше деталей.
Инструментарий игровых площадок
Все игровые площадки предоставляют разработчикам свой инструментарий для загрузки и тестирования игры через их систему. Например Steam позволяет через меню Properties вашей игры переключать языки (локализация), запускать игру с вашими собственными параметрами (например запуск игры с нужными вам параметрами или переписи значений используемых параметров), позволяет проверять целостность файлов игры, вручную проверять обновления с вашей CI/CD системы и многое другое! Ну и само-собой площадки позволяют вам загрузить и добавить в библиотеку вашу игру по специальному коду. Если же игра уже доступна для скачивания игрокам или вы хотите использовать разные окружения (environments) для разных команд, то для таких нужд игровые площадки предоставляют возможность использования разных веток (Branches) для таких нужд. К примеру один бранч смотрит на master client — test backend («рабочее окружение»), а второй — production client — live backend (релизное окружение).
Такой способ крайне удобен в использовании и помогает всем членам одной команды или даже разным командам использовать нужные всем версии игры без влияния друг на друга. При использовании «рабочего окружения» также площадки перед запуском спрашивают о необходимости запуска анти-чит системы.
Во многих случаях тестировщикам даже не нужно использовать Editor build (запуск игры через редактор игрового движка), ведь большинство нужд покрывается, по умолчанию, билдом с площадки. Также такая версия билда является максимально приближенной к тому, что получит конечный игрок, что является важным критерием для выбора данных сборок в качестве главных кандидатов для регрессионного тестирования.
Общие инструменты, которые могут быть полезны в тестировании игр
Говоря об инструментах, которые напрямую не связаны с тестированием, но могут облегчить вам жизнь, я бы выделил следующие: VCS (Perforce, Git), редакторы игровых движков, Grafana и Playfab.
VCS
Про Perforce и Git не буду говорить много, т.к. это распространённые Version Control System программы и важные элементы workflow большинства проектов. При помощи Perforce вы можете выкачать дев билд, залить изменения, выбрать и использовать определённый номер билда (Change List), сделать файлы доступными для редактирования (Check Out), задать нужные вам настройки и т.п. После проведения манипуляций, описанных выше, вы можете использовать данный билд как вашей душе угодно, например взять определённые файлы или коммиты и убедиться, что баг там (не)представлен, но это уже совсем другая история =)
Часто недалеко от Perforce можно найти и Git на вашем проекте, но используются они для разных нужд, например Perforce — для работы с клиентом, Git — для работы с Back-End частью. Больше о Perforce можно почитать на их оффициальном сайте и я крайне настоятельно рекомендую ознакомиться с ним.
UnrealGameSync (UGS)
Если же вы не хотите мучаться с изучением Perforce, но при этом вам нужна возможность собирать билды с определёнными CL’ами, то в помощь вам всегда придёт такой классный инструмент как UnrealGameSync (UGS). В данном случае это инструмент для Unreal Engine, который позволяет вам видеть и фильтровать CL’ы в репозитории. При помощи UGS крайне удобно отслеживать последние изменения и собирать новый билд — просто кликни дважды на нужный CL и процесс пойдёт! (звучит как рекламный слоган xD)
Engine Editor
Примерно та же история у нас и с редактором игровых движков. Тут вы можете перенастроить нужные вам элементы внутри игры перед её запуском. Игру можно запускать как в режиме «редактора» (игра запускается во ViewPort вашего движка), так и в «standalone» режиме. Любые ваши пожелания и предпочтения можно выполнить тут, если таковые имеются, однако чаще всего тестировать игру нужно на «финализированных» билдах, которые можно либо выкачать с ваших внутренних ресурсов после завершения очередного CI/CD процесса, либо играть напрямую через игровые площадки наподобие Steam.
Стоит также упомянуть, что редактора может не быть в некоторых кастомных движках.
Grafana
Grafana — это дашборд для визуализации метрик используется многими членами команды. Крайне полезный инструмент во время Performance и Network тестирования благодаря возможности следить за количеством реальных и сэмулированных игроков в данный момент времени, отображению ограниченного количества информации для внешних команд в вашем процессе и многое другое. Больше о данном инструменте можно почитать тут.
Playfab
Думаю также стоит упомянуть про Playfab. По сути это готовый Back-End, предоставляемый в наши дни компанией Microsoft по подписке, который объединяет аккаунты из разных игр в единый (мастер) аккаунт, помогает в настройке экономики без «лишнего» кодинга. Как утверждается на сайте Playfab — это комплексное серверное решение, которое позволяет избежать трудностей со сборкой, управлением и запуском серверов в нужном масштабе, а также помогает в организации чатов и обмена данными с минимальной задержкой.
В рамках тестирования Playfab будет использоваться не часто (это НЕ инструмент для тестирования, как и все инструменты в данной секции), однако может быть интересен, когда речь заходит про проверку правильности использования, например, аналитики, которая прикручивается к вашей функциональности. Кто же откажется использовать аналитику для BattlePass или системы прогрессии?
На сайте Playfab вы можете увидеть много игр, использующих данный продукт. Среди них — Doom Eternal, Minecraft, Roblox, Gears 5 и многие другие! Обзор предоставляемых Playfab функций можно посмотреть на их сайте.
Инструменты от производителей консолей
В конце данной секции уточню, что все производители консолей имеют свои инструменты для связи и работы с дев и тест китами. Данные программы имеют множество полезных функций, таких как сбор логов, работа с данными сохранений, сбор информации при краше игры, возможность использования расширенных ресурсов дев китов, эмуляция работы с онлайн сервисами без прямого подключения к ним, удалённое управление и многое другое! Начиная с 2020 все эти программы начали улучшать уже имеющийся функционал по удалённому управлению консолями, что крайне удобно современных реалиях.
Так что же по итогу?
Как вы могли убедиться, тестирование игр — это сложный, многоступенчатый, но крайне увлекательный и творческий процесс, который включает в себя самые разные виды тестирования, включая специфические, которые вы не найдёте в других “жанрах” программ. Начать тестировать игры, как и в целом начать заниматься тестированием, можно с простых задач, зная только базу для позиции “джуниор” и понимание чем и как живёт игровая индустрия. Для этого не обязательно иметь профессиональное высшее игровое образование =)
Однако как и во всём, чтобы стать специалистом в чём-то, вам нужно будет гриндить опыт в разных сферах и инструментах, а также обладать аналитическими качествами, которые помогут вам в этом направлении, например аналитические и логические навыки, глубокое знание видеоигр, их устройство и механики; способность работать под давлением и т.д. Тестирование игр — своего рода рейд босс, для победы над которым нужен соответствующего уровня специалист. И чтобы прокачать такого специалиста обычно не достаточно просто взять «опытного QA инженера», чтобы у вас вдруг материализовался классный Game Tester. В таких случаях часто всё работает наоборот, так как наиграть наработать богатый игровой опыт в краткосрочной перспективе — крайне сложная задача.
Но в целом, всё зависит от того, чем вы хотите далее заниматься: кто-то хочет помогать разработчикам своим фидбеком и прекрасным стартом для данной активности будут плейтесты, ранние доступы и т.д., а кто-то — углубленно изучать игры и добиваться их качества собственноручно, находить и локализовывать проблемы качества продукта прямиком на проекте! Данная серия из 3х статей как раз и была призвана помочь вам во всех этих случаях и ввести вас в курс дел на этот поприще! Надеюсь они были вам полезны и вы открыли для себя что-то новое! Пишите также примеры из вашего опыта в комментариях, чтобы мы могли подискутировать на данную тему!
