Skip to content

Latest commit

 

History

History
213 lines (130 loc) · 55.3 KB

testirovanie-igr-game-testing.md

File metadata and controls

213 lines (130 loc) · 55.3 KB
Raw

Тестирование игр (Game testing)

Для тестирования видеоигр, как и в других направлениях, есть “стандартные” и свои особенные подходы для решения определённых задач. Давайте рассмотрим их!

Playtesting - это один из видов тестирования игр, который предназначен для понимания какой игровой опыт и эмоции получают игроки от игрового процесса. Для проведения плейтестов игрокам дают доступ к раннему билду (данный вид тестирования проводится до релиза игры и/или фичи). Чаще всего в плейтестах участвуют не QA специалисты, а рядовые геймеры, родственники, в общем кто угодно, кто может взглянуть на ваш продукт свежим взглядом, дать вам обратную связь на основе своего игрового опыта и впечатлений, а также будет уважать то, что написано в подписанным им NDA перед стартом плейтеста.

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

Говоря о специфических для видеоигр видов тестирования, я бы выделил такую группу как Game Design Testing, куда включу Balance testing, Level Design testing, "Fun Factor" testing).

Balance Testing предполагает проверку того, что баланс есть:

  • одно оружие не критически сильнее/слабее другого в этом же классе,
  • среди персов и их перков нет имбы в той или иной комбинации,
  • классы персонажей побеждают друг друга как задумано (как в камень-ножницы-бумага),
  • легкий уровень сложности не слишком легкий, сложный - не слишком сложный и т.п.

Возможно местами даже стоит подумать о мете игры, но это уже как бонус, этим должен заниматься уже явно не Quality Assurance специалист. Однако QA может сделать заметки и поделиться с командой!

Level Design Testing подразумевает проверку уровней (левелов). Даже самый красивый визуально уровень может содержать непроходимые места из-за, например, невидимых стен (есть модель (меш), но нет текстур), дырок в полу (к примеру из-за плохой стыковки плоскостей или моделей), попадания в так называемые Stuck points, где встрял и уже никуда дальше сдвинуться персонаж не может.

Такой достаточно абстрактный вид тестирования как Fun Factor Testing кто-то выделяет отдельно, а кто-то считает, что это часть Playtesting. Здесь упор делается на "фановость" процесса игры. Идеально сбалансированная игра может банально не весело играться и это отпугнет аудиторию. Также тут стоит проверить такие игровые механики как навигация, прицеливание, взаимодействие с предметами, NPC и т.д. Неудачные механики, непривлекательный арт, также находится на этой стадии. Если вас в процессе ничего не фрустрирует, вы на верном пути =) Больше про плейтесты, включая Fun Factor, можно посмотреть тут, хоть я и не во всем согласен с автором.

Чуть выше кто-то где-то упомянул персонажей/уровни/предметы и т.п.? Т.е. мы начинаем говорить о Visual Components Testing группе, куда можно внести тестирование 3D моделей/сцен, 2D (спрайты) и 2.5D.

3D Models Testing включает в себя проверку корректности модели (хай и лоу поли) на визуальную составляющую и кол-во полигонов, выставленное в требованиях. Также проверяются все ли текстурные карты доступны и используются для моделей, есть ли отображение внутренней стороны моделей (если они видны), не ломается ли модель во время анимации (риггинг и правильный скиннинг). Во время таких проверок всегда можно заранее найти проблемы с, например, текстурными картами и запечь новые для фикса найденной проблемы.

2D и 2.5D Testing - тестирование уже 2D и 2.5D графики. Сюда включают работу со спрайтами (2D), проверка спрайтов и/или 3D моделей для 2.5D игр, часто в таком виде делают файтинги, сайд скроллеры или рогалики. В качестве примеров тестирования, можно привести проблемы с порядком отрисовки мира и героев в изометрических проектах, с "окошком", которое показывает ГГ, если он за стеной (в качестве примера тут можно привести такие игры как Fallout 1 и 2), ну и часто встречаемые в целом нюансы с прозрачными объектами. Хоть ваш проект и в 2D/2.5D, однако такие элементы в нём могут взаимодействовать с 3D объектами и сложными эффектами, связанные с прозрачностью. Один из плохих сценариев в данном случае, когда объект из нескольких спрайтов растворяется или появляется через alpha и alpha каждого спрайта считается отдельно. Как итог вы получите на вид 3 несвязанных объекта вместо 1 ожидаемого. Для предотвращения таких случаев можно рендерить объект в текстуру и уже её использовать для эффекта, чтобы не терять целостность.

Говоря о персонажах, мы не ограничиваемся только игровыми персами и их моделями. Сюда также стоит отнести NPC, а также врагов с их AI, а тут уже целое поле для группы AI testing, куда я включу проверку таких фичи как Pathfinding, AI Spawning, AI Reaction, Detection Range / NPCs (конус зрения) и т.п.). Ведь всегда приятно, когда массовка ведёт себя правдоподобно, не утыкаются в сцены, враги появляются не за спиной или перед игроком и так далее. Тут же проверяем, что Импостеры правильно спаунятся (импостер - это 2D спрайт в 3D массовке или очень лоу поли модели, нужны для разгрузки мощностей вашей машины). Явный пример использования импостеров можно увидеть в финальном сражении Serious Sam 4. Тут стоит упомянуть, что такая уловка используется не только для AI, но также и для отрисовки части игрового мира: которая находится достаточно далеко от игрока, но всё же видна на фоне. Это может быть что угодно: отдельные элементы, город, лес, горы, и т.д. Всё это может быть заменено импостером, пока игрок не подойдёт достаточно близко (такой подход также известен как billboard sprite). Также важно проверить Navigation Mesh (Nav Mesh), чтобы убедиться, что враги и NPC будут двигаться не в предметы и стены. Больше о толпах NPC можно посмотреть здесь.

Такие хитрости как замены хай поли на лоу поли модели или даже на Импостеров, баланс и скорость отображения полигонов на загруженных сценах, обработка эффектов и т.п. очень сильно могут снизить производительность и количество кадров в секунду (FPS). Данные аспекты проверяются в рамках всем нам известного Performance Testing. Я бы отнес плюс/минус в эту категорию и Soak Testing, благодаря которому ищут memory leaks в играх. Также в рамках группы по тестированию производительности стоит отнести Stability testing, в рамках которого вы находите такие всеми любимые вещи как фризы, краши, черные экраны, невозможность загрузить уровень, порча сохранённых данных и прочее.

Однако проблемы могут возникнуть не только при большом количестве моделей на экране, но также и при большом количестве онлайн игроков в вашей игре. Хотя и не при большом, если вы не протестировали неткод в рамках Network Testing. Благодаря данному виду тестирования можно также проверить лаги/дропы в соединении, matchmaking, стабильность конекшенов, инпут лаги контроллеров и многое другое. Немного отходя в сторону, я бы выделил ещё баги, которые воспроизводятся при плохом интернет соединении и, если у вас со скоростью интернета всё хорошо, то нужно эмулировать "плохое интернет соединение". Больше о неткоде и типах соединения можно посмотреть здесь.

Уже всё вышеописанное звучит достаточно громоздкая и сложная система. Но это ещё ничего, ведь мы больше говорили о front-end части (клиент), а ведь Back-End часть и Back-End testing никто не отменял. Здесь мы пробегаемся по вашему беку, который часто включает базы данных, API (к примеру REST API), телеметрию и многое другое.

Выше я говорил о производительности на железе, но не уточнил о каком именно, а ведь игры нужно оптимизировать и переносить на разное железо различных платформ - Playstation 4/5, XBox Series X/S, Nintendo Switch, Steam Deck и самые различные и неповторимые конфигурации вашего персонального красавца (ПК). За это отвечает, как вы уже догадались, Compatibility testing. Многие платформы имеют разные режимы работы, к примеру 4K 30FPS + Raytracing, 1080p 120fps и т.д. Та же Nintendo Switch работает в 2х режимах: портативном (720р) и стационарном (1080р). Не стоит забывать и о тенденции "геймпады везде и всюду" и обязательно стоит проверить, что самые разнообразные контроллеры могут работать с вашей игрой на ПК или консоли - разнообразные контроллеры, руль и педали для авто симуляторов, джойстики, контроллеры в виде музыкальных инструментов и т.п. Все они имеют в вашей игре корректные иконки при переключении контроллеров, а также все конфигурации для них работают исправно.

Также относительно недавно начал активно развиваться рынок VR и AR приложений и игр. VR и AR Testing я хочу выделить отдельно, т.к. данные устройства имеют слишком много особенностей, чтобы запихнуть их под одну гребенку с остальными девайсами. Как интересный факт из практики: у VR есть "физическое" ограничение, из-за которого не все смогут разрабатывать/тестировать под VR, а именно - моушн сикнес (укачивание), который возникает при использовании шлемов.

Важно держать во внимании, что кроме ваших собственных стандартов качества к игре, свои стандарты есть у платформодержателей. Часто такие проверки называются Technical Requirements Checklist или TRC, а проверяются они в рамках Compliance testing и, часто, не вашей командой, а командой QA на стороне платформодержателя. В рамках данного тестирования вы можете также проверить внутриигровые покупки, достижения (Achievements), подписки (subscriptions), если они у вас есть, а также поддержку фич стриминговых сервисов. Часто для таких нужд "отпочковывается" отдельный билд, который доводят до ума и не аффектят его изменениями основной билд.

Похожая ситуация происходит во время Альфа и Бета тестирования. Pre-Alpha, Alpha и Beta Testing это больше не о подходе к тестированию, это о срезе игры в определенный момент времени и проверки готовности определённого скоупа на той или иной стадии. Ранее часто подразумевалось, что Альфа - это еще внутреннее тестирование, а Бета - уже внешнее (например, закрытое бета тестирование, когда ключи от билда дают определенному количество игроков). Сейчас же много игр выходит в раннем доступе и альфа билды становятся доступны широкому количеству игроков. Живой фидбек даёт понять разработчикам что они делают (не)верно, что помогает оперативно реагировать и удовлетворять нужды игроков.

Но даже на таких ранних стадиях важно, чтобы игроки могли удобно использовать различные контроллеры во время геймплея и навигации по вашей игре - вот мы и пришли к Usability testing. Здесь никакого секрета нету, вашей игрой должно быть интуитивно понятно и приятно пользоваться.

Более чем уверен, что много читателей данной статьи - аудиалы. Звук в играх, как и в кино - один из самых важных и мощных инструментов для влияния на игрока. За тестирование таких нюансов как триггер и проигрыш музыки, звуковых эффектов (SFX), диалогов и реплик, миксовка музыки под происходящее на экране и прочее отвечает Audio testing. Для работы со звуком есть специализированный софт и триггеры многих эффектов и реплик можно найти в автоматическом режиме. Если вы не специализируетесь на тестировании аудио, то скорее всего ваши задачи будут лимитированы пунктами выше. В ваши задачи далеко не всегда будет поиск и использование нужных звуков, главное - заимплементировать возможность проигрыша их при определённых условиях, а далее аудио команда уже сделают оставшуюся магию за вас - вставит нужное аудио или создаст абсолютно новое! Всегда приятно, когда саунд-дизайн в вашей игре на высоте!

А еще приятнее пользоваться игрой на родном для вас языке + выход на глобальный рынок подразумевает больший охват потенциальной аудитории. Вооружившись знаниями по тестированию I18N и L10N вы сможете сделать так, чтобы от вашей игры получали удовольствие даже в противоположной от вас части земного шара! В качестве особенности проверки локализации игр (Localization testing), стоит упомянуть разницу в часовых поясах ваших игроков и сервера, а также возможность манипуляции времени и даты на вашем устройстве через смену даты и/или времени через календарь. Часто это приводит к разнообразным ошибкам или нежелательному результату. К примеру если вы засетали какой-то контент для отображения с определённой даты, то хитренький пользователь может сменить дату на будущую и заранее увидеть всю ту красоту, что вы ему подготовили и спойлернуть это всем. Даже дата майнингом заниматься не обязательно :) Для проверки корректности языков есть специальные команды локализации, но не забывайте, что в ваших силах проверить языко-независимые вещи в рамках данного тестирования и это стоит сделать заранее!

Странно, что я так долго обходил стороной упоминание основы основ -** функциональное и нефункциональное тестирование**. Здесь есть где разгуляться и не всегда вам нужно глубокое знание игр и их механик. Самый главный документ с требованиями, который вам точно будет нужен - это Game Design Document (GDD). Здесь описаны все основные и важные нюансы по вашей игре. Есть даже мнение со стороны разработчиков, что тестировщикам не нужно разбираться в играх, чтобы их тестировать, ведь есть GDD и многие другие доки с требованиями. С этим утверждением я больше не согласен, т.к. знание механик, трендов и игр в целом помогает проводить анализ найденных ошибок и создания комплекса ивентов для предотвращения появления их в будущем или возможности найти их на самых ранних стадиях. Формально, да, можно тестировать без знания и понимания многих вещей, да и на аутсорс нередко отдают разработку и тестирование, не связанное с геймплеем или изменением основных геймплейных механик, но так можно тестировать всё, что угодно и это ничем не будет отличаться от Monkey Testing или, если QA крайне пылает энергией и энтузиазмом, но отказывается изучать особенность домена - Gorilla Testing.

Мы уже поговорили о ПК, консолях, даже о VR и AR играх, но не обсудили те девайсы, которые используют большинство геймеров - мобильные телефоны. Как минимум основы Mobile Testing важно знать и понимать, ведь оооочень много игр выходит на мобилки и этот рынок уже давно обогнал по выручке консоли и ПК. Да, игры эти, в большинстве своём, казуальные и гиперказуальные, но и далеко не все игроки "хардкорные" и имеют достаточно времени, чтобы играть в ААА и инди игры на ПК и консолях. Все виды тестирования, упомянутые выше, действительны и для мобильных игр, но также тут важно знать специфику мобильных девайсов и приложений!

Не стоит также забывать и о Security Testing, использование которого глобально не отличается от других сфер. В играх используются учетные записи, аккаунты от разных систем, включая онлайн сервисы и аккаунты от ваших учеток на консолях (к примеру вам нужно играть играть в Rocket League через Epic Games аккаунт, но в системе Playstation), В наше время крайне важно уделять этому аспекту достаточно внимания, ведь никто не хочет потерять даже одну игру, которую этот человек купил или донатил в ней, не говоря уже о потере целого аккаунта со всем "наработанным" добром!

Также стоит упомянуть работу с DRM системами (Denuvo и т.д.) и Anti-Cheat программами (Easy Anti-Cheat и т.п.).

В качестве финального пункта на сегодня в разделе "видов тестирования" важно выделить Game Automation Testing. Автоматизация в геймдеве является достаточно сложным процессом. Многие вещи крайне сложно поддаются автоматизации, к примеру, геймплей, ведь важно не только "знать" расположение персонажа, но и понимать, что вокруг него происходит. Если у вас есть рандомайзер, который спавнит врагов в разное время и в разном количестве или ваши элементы для "3 в ряд" появляются далеко не всегда одинаково, то вам нужно придумать что-то наподобие бота для автоматизации и осмысленных действий в рамках ваших тестов. Думаю вы уже догадались, что автоматизация UI элементов или навигации по таким экранам как "Главное Меню" не составит большого труда. Геймплей же автоматизируют при помощи написания своих ботов. Также можно использовать Image Recognition тулы, они также хорошо подходят и для автоматизации скринов без геймплея. Про одну такую интересную тулу (Airtest) я писал в своих предыдущих статьях. Вот они: раз, два и три.

Разновидности «игровых» багов

Картинки примеров см. в источнике.

В категорию Visual багов войдут:

  • Visual Artefacts - любые визуальные баги, не подпадающие под другие виды.
  • Missing Textures - пропущенные/исчезнувшие текстуры. Обычно на их месте стараются ставить "заглушку" в виде яркой текстуры по умолчанию в виде шахматной доски. Это не обязательно, но благодаря такому подходу, пропущенные текстуры видны не вооруженным взглядом.
  • Z-fighting - данный баг появляется, когда несколько примитивов расположены на примерно одинаковом расстоянии до камеры и они имеют фактически одинаковые значения в Z-buffer, которые отслеживают глубину. Из-за этого примитивы могут частично отображаться один над другим.
  • Screen Tearing или "разрыв экрана" - это визуальный артефакт, при котором отображается информация из нескольких кадров на одном изображении.
  • Culling и Clipping - баги, относящиеся к работе рендера и графического пайплайна. Часто - пересечение двух объектов, при котором один закрывает геометрию другого, скрывая ее от взгляда. Если немного углубиться, то Culling - это отсечение того, что заведомо невидимо. В таком случае игра даже не будет пытаться отрисовать данный сегмент. Culling бывает разным и вот его примеры: rustrum culling - отсечение по пирамиде видимости, backface culling - отсечение "задних" граней, occlusion culling - отсечение граней факту их перекрытия другой геометрией, depth culling - перекрытие одной геометрии другой, которая уже была нарисована, но на основе depth buffer. А вот когда рисуется достаточно большой полигон и от него отрезается всё то, что заведомо находится за пределами экрана - это уже Clipping.
  • Также отдельно стоит выделить похожий, но в сути другой баг - проблемы коллизий. В видеоиграх отсечение может быть связано с набором алгоритмов, которые реагируют на взаимодействие двух смежных или перекрывающихся геометрий (collision detection). А для выявления таких багов существуют специальные режимы просмотра (view modes).

В рамках Audio bugs группы выделю достаточно базовые, но не менее надоедливые вещи:

  • невозможность проиграть SFX/музыки/диалога,
  • пропуск (триггера) проигрыша,
  • плохое микширование (звук слишком тихий или громкий),
  • искажения (distortions),
  • дропы.

Баги левел дизайна:

  • Invisible Walls (невидимые стены) могут являться как багом, так и фичей. Ранее так ограничивали передвижение персонажа игрока и не давали уйти дальше нужного. Сейчас же стараются не создавать "невидимых препятствий", а ограничивать "проходимость" при помощи левел дизайна, к примеру выставить непроходимую преграду, баррикаду, горы, ворота города и т.п. Показывать игроку, что впереди что-то есть, но при этом использовать невидимые стены для недопуска персонажа в эту зону - признаки плохого левел дизайна. Сейчас так почти не делают и невидимые стены часто могут быть следствием реконструкции уровня: к примеру какую-нибудь модель могли забыть убрать или добавили невидимых элемент в качестве временной заглушки.
  • Map Holes чаще всего вызваны не плотным прилеганием плоскостей объектов (пол, стены и т.п.). Это места, где пользователь может, незапланированно для разработчиков, попасть за границы игровой зоны. Такие баги часто ещё называют Out of Bounds.
  • Баги Navigation Mesh часто связаны с перестройкой уровня или автоматической генерацией сетки. К примеру вы передвинули предметы, однако навигационная сетка осталась старой. Как следствие, ваши NPC могут "идти в стену" или любой другой предмет, который они не смогут обойти и встрянут там (один из случаев Stuck Points).

Ошибки искусственного интеллекта (AI):

  • NPC не двигаются, застряли, не следуют за игроком,
  • предполагаемое взаимодействие с предметами не работает,
  • застревание,
  • NPC делают то, что не задумано изначально и т.п.

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

  • левитирующие объекты,
  • нереалистичная физика,
  • ускорение свыше нормы,
  • взмывание предметов " в космос" из-за сложения векторов при обработке контактов.

Баги такого рода вы могли видеть в мемах самых разных игр, например GTA 5 или, из актуалочки, Cyberpunk 2077. Хороший разбор многих багов из Cyberpunk 2077, включая только что описанные, можно посмотреть тут.

Баги стабильности и перформанса включают в себя:

  • фризы,
  • краши,
  • черные экраны,
  • невозможность загрузить уровень,
  • видимая для пользователя подгрузка хай поли моделей или вообще каких-либо объектов,
  • просадка FPS,
  • дооооооооолгая загрузка,
  • микрофризы (подгрузки).
  • Сюда же добавлю слишком долгую инсталляцию игры, а также невозможность запустить игру на ПК с минимально допустимыми требованиями.

Не редко встречаются и баги совместимости. Особенно частые примеры выглядят следующим образом:

  • на некоторых видеокартах могут встречаться краши (к примеру на минимально возможных требованиях или новых видеокартах на рынке),
  • контроллеры той или иной фирмы не работают,
  • игра не запускается на какой-то определённой версии ОС,
  • беспроводная гарнитура выдает звук в моно и т.п.

О проблемах онлайн игр наслышаны все. Плохое соединение, лаги, "невидимые игроки" или же "я зашёл за угол, а меня убили", ошибки подсчета очков, невозможность реконнекта (если такая фича есть), потеря пакетов во время игры, расхождение в подсчётах информации между клиентом, дедикейтед сервером и бек эндом. Также при плохом соединении некоторые элементы интерфейса можно использовать по несколько раз, что-то может не прогрузиться и "пропасть" и т.д., но, как правило, это UI баги и сильно не влияют на user experience игрока.

Под баги локализации и compliance, из нетривиального, можно отнести:

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

Подходы и инструменты

Чит коды / Чит меню (Cheat Codes / Cheat Menu)

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

Сейчас же вместо кодов, которые нужно запоминать и долго вводить, используются Чит Меню, в которых уже есть списки чит кодов, сгруппированных в удобный для использования вид. Данный список можно вызвать практически на любом экране, однако если код не подходит под текущие условия, то он не выполнится (к примеру если вы пытаетесь заспавнить объект в главном меню). Чит меню - это не типовая функциональность, у каждой игры оно имеет и уникальный вид, и уникальный код, ответственный за его реализацию.

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

Игровая консоль

Консоль в игре может и часто используется в качестве полезного в тестировании инструмента. Обычно вызывается она при нажатии кнопки "~" (тильда), выпадает либо внизу небольшой строчкой, либо сверху экрана, занимая приличную его часть. Думаю многие использовали консоль в 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, а больше и подробнее вы можете почитать в документации движка. Давайте же взглянем на несколько из них.

Инструментарий игровых площадок

Все игровые площадки предоставляют разработчикам свой инструментарий для загрузки и тестирования игры через их систему. Например Steam позволяет через меню Properties вашей игры переключать языки (локализация), запускать игру с вашими собственными параметрами (например запуск игры с нужными вам параметрами или переписи значений используемых параметров), позволяет проверять целостность файлов игры, вручную проверять обновления с вашей CI/CD системы и многое другое! Ну и само-собой площадки позволяют вам загрузить и добавить в библиотеку вашу игру по специальному коду. Если же игра уже доступна для скачивания игрокам или вы хотите использовать разные окружения (environments) для разных команд, то для таких нужд игровые площадки предоставляют возможность использования разных веток (Branches). К примеру один бранч смотрит на master client - test backend ("рабочее окружение"), а второй - production client - live backend (релизное окружение).

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

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

Общие инструменты

Говоря об инструментах, которые напрямую не связаны с тестированием, но могут облегчить вам жизнь, я бы выделил следующие: VCS (Perforce, Git), редакторы игровых движков, Grafana и Playfab.

Тестирование в азартных играх/казино (Gambling)

Гемблинг (от англ. Gambling - азартная игра) - игра, результат в которой полностью или в значительной мере зависит от воли случая (удачи).

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

Из специфического:

  • тестирование различной математики (алгоритмы, вероятности и т.п.);
  • взаимодействие с законодательством;
  • финансовые операции (депозиты, кошельки, бонусы, реферальные программы).

Источники:

Доп. материал: