Основные типы игровых ошибок

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

В первой статье мы поговорили о видах тестирования, применяемых в играх, а теперь поговорим о результате, который смущает PMов, вводит в краску разработчиков и так крайне не терпим Product Owner’ами на продакшене — багах. Сегодня я их также классифицирую и покажу вам некоторые из них на примерах.

Было бы странно, если в такой комплексной системе как видео игры не было багов. Они есть, встречаются часто и этот бестиарий здесь крайне разнообразен. Ознакомившись с вышеприведёнными видами тестирования для игр, думаю вы догадываетесь, что и баги в видео играх встречаются далеко не только «404 not found» и «game crashed». Давайте же пробежимся по самым часто встречающимся из них в игровой индустрии!

В категорию Visual багов войдут: любые видимые артефакты (Visible Artefacts), пропущенные текстуры (missing textures), Clipping, Culling, Screen tearing, Z-fighting.

Примеры визуальных багов можете посмотреть ниже:

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), застревания (stuck spots) и т.д. Также к багам левел дизайна я бы отнёс баги связанные с нав мешем (Navigation Mesh). Ниже приведу несколько примеров багов левел дизайна:

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, из нетривиального, можно отнести локализацию рекламы, размещение разных материалов на одних и тех же местах в разных регионах и странах (к примеру в этой стране запрещено к показу одно, а в другой — не запрещено или же возрастной ценз, под которые подпадает игра, может не разрешить что-либо показывать в том или ином регионе). Манипуляции с датой на вашем устройстве и сбой работы клиента с сервером я бы тоже отнёс сюда. Ну и «классические» баги локализации и интернационализации никто не отменял. Больше про них и о подходах к их правильному и полному тестированию можете прочитать в моей статье.

Неужто это всё?

Конечно же нет. Это далеко не все разновидности игровых багов, но, пожалуй, самые часто встречаемые. Здесь я не затрагивал баги несоответствия, такие как «элемент записан в blueprints по одному, на back-end — по другому, объект или его атрибуты (ID, описание и т.д.) забыли куда-то добавить и прочее. А не затрагивал их, т.к. это больше не про специфики игр, а в целом неисправности, которые могут быть во многих программах.

А с какими багами вы встречались во время игры или работы над игрой? Буду рад пообщаться с вами на эту и другие релевантные темы в комментариях!

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

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

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

Сегодня мы затронем тему не только локализационного, но и функционального тестирования. А помогать нам будет наш эксперт и руководитель отдела тестирования, Андрей Васильев.

Чтобы успешно заводить баги, нужно их систематизировать. Разделить и властвовать.

Итак, баги в играх можно условно классифицировать по следующим категориям.

Баги, связанные с самой игрой

Багам присваивается степень критичности: какие-то устраняются в первую очередь, а какие-то можно даже оставить в финальном релизе:

Баги различают по затрагиваемой стороне. То есть кому они будут больше всего мешать использовать продукт:

От чего зависит число багов в игре

Действительно, от чего? Почему в одних играх их просто огромное количество на альфа-тестах (привет, No Man’s Sky), а в других — практически нет? Всё довольно очевидно.

Привязка выявляемого количества багов к жанрам

В группе риска:

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

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

Ошибки дизайна уровней

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

Ошибки обратной связи

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

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

Ошибки игрового баланса

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

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

А с какими багами сталкивались вы? Присылайте нам в комментарии — похохочем, что ли.

Если вдруг вы разработчик и хотите, чтобы подобных ошибок в вашем проекте было поменьше, пишите нам на [email protected] — мы придумаем что-нибудь вместе.

И вообще, доверяйте свои игры профессиональным тестировщикам, да поменьше багов вам в готовых продуктах: далеко не все из них станут легендарными, вроде знаменитого «geddan».

Мета тестування ігор полягає у виявленні багів у грі, щоб зменшити їхню кількість до моменту релізу продукту. Баги – це несподіваний результат роботи коду в тестованій версії гри.

Баги можуть варіюватися: починаючи від тих, що заважають гравцеві далі рухатися по сюжету гри і закінчуючи чимось менш значним, наприклад, виходом тексту за межі кнопки.

Щоб полегшити життя розробникам, баги в іграх класифікуються за їх серйозністю ( «Severity»). Ранжування типів багів в іграх допомагає розробникам зрозуміти, які баги слід пофіксити в першу чергу.

Залежно від ступеня впливу на систему розрізняються такі помилки:

S1 Блокуюча (Blocker)

Блокуюча помилка, що приводить гру в неробочий стан, в результаті якого подальша робота з функціоналом, що тестується, стає неможлива. Рішення проблеми необхідно для подальшого функціонування гри.

S2 Критична (Critical)

Критична помилка, неправильно працює ключова ігрова логіка, діра в безпеці, проблема, яка призвела до тимчасового падіння сервера або приводить в неробочий стан деяку частину функціоналу, без можливості вирішення проблеми, використовуючи інші вхідні точки. Рішення проблеми необхідно для подальшої роботи з ключовими функціями гри, що тестується.

S3 Значна (Major)

Значна помилка, частина основної логіки не функціонує належним чином. Помилка не критична або є можливість працювати з функцією, що тестується, використовуючи інші вхідні точки.

S4 Незначна (Minor)

Незначна помилка, що не порушує логіку частини гри, що тестується, очевидна проблема призначеного для користувача інтерфейсу.

S5 Тривіальна (Trivial)

Тривіальна помилка, яка не стосується логіки гри, погано відтворена проблема, малопомітна за допомогою призначеного для користувача інтерфейсу, проблема сторонніх сервісів, проблема, не надає ніякого впливу на загальну якість продукту

Крім серйозності, баги класифікуються за категоріями:

• візуальні (visual) – розрив зображення на екрані, відсутність текстур, кліппінг (обрізання областей зображення) та ін.;
• аудіо (audio) – відсутність озвучення, спотворення звуку, занадто низька/висока гучність;
• баги дизайну рівнів (level design) – невидима стіна, відсутність геометрії (текстура присутня, але 3D моделі немає, що дозволяє пройти крізь стіну);
• штучний інтелект (artificial intelligence) – гравець не в змозі рухатися правильно по ходу гри, не рухається зовсім, занадто часто вмирає, не може відкрити двері;
• баги фізики (physics) – об’єкти літають у повітрі, коли не повинні, об’єкт не ламається, об’єкт не зупиняється після того, як його штовхнули, неможливість скласти об’єкти в купу;
• стабільність (stability) – фризи, креш (чорний екран), Crash to Desktop (ПК), неможливо завантажити рівень, гра не відповідає;
• дефекти продуктивності (performance) – найнижчий показник ФПС (проблеми з анімацією), занадто довго завантажуються рівні, мінімальна підтримувана конфігурація ПК не може відтворити гру, гра дуже довго встановлюється, дуже часто гра зупиняється, щоб завантажити дані;
• нетворкінг (networking) – проблеми із з’єднанням, неможливо приєднатися до запрошення, лаги (затримки у відповіді сервера на дії гравця), невидимі гравці, помилки з підрахунком очок.

Реальні приклади багів в іграх, знайдені нашими гейм-тестувальниками:

до … – це час, коли максимально точно проявляється баг

Audio Drop – https://youtu.be/HS9Tx7PjWlw?t=3m17s до 3,40

Distortion – https://youtu.be/mA-vJWW9WaQ?t=2m21s до 2,35

Dynamic Behavior в Half Life scene – https://youtu.be/MQt1jtDBNK4?t=26s до 0,34

Freeze в грі League of Legends (Riot) – https://www.youtube.com/watch?v=trs__lGo9sM

Frame Rate issue в грі Darksouls – https://www.youtube.com/watch?v=Ha6K5KtW3W8 до 0,33

Minimum Requirements Machine баг в грі Відьмак – https://youtu.be/QLjxhB0-s2A?t=29s 0,36

Lag issue в грі WoW – https://youtu.be/VT0EhB7j7Bc?t=1m12s до 1,24

Достаточно часто у игроков возникает резонный вопрос к разработчикам: откуда вообще берутся баги, если существуют ПТС, отделы QA и прочие инструменты, направленные на «отлов» ошибок.

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

Почему баги вообще существуют?

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

Что влияет на скорость устранения багов?

Первый и основной фактор – это насколько критична существующая ошибка. Все баги и ошибки можно разделить на три основные категории: критические — это те, которые влияют на основные игровые процессы и не дают возможность попросту играть; серьезные ошибки – те, которые влияют на большинство игроков, но не затрагивают основные игровые процессы; и ошибки с низким приоритетом, те, которые едва ли влияют на игровой процесс.

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

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

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

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

Как так получается, что баги с ПТС все же переходят на основной сервер?

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

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

Почему некоторые ошибки и вовсе не возникают на ПТС?

Это достаточно сложный вопрос и одного ответа тут не может быть. Прежде всего, ПТС во многом отличается от других способов, простейший из которых — рабочая нагрузка сервера, которая становится причиной множества проблем в игре. Во-вторых, если ошибка непостоянная, то это означает, что она вызвана особыми условиями, которых нет у большинства игроков. Часто сложно найти то, что возникает в редких случаях на ПТС. В-третьих, баг может появляться в игровых режимах, которыми игроки не часто пользуются. Лучший пример – это изменения в оружии. Обновление обычно содержит 2 новых вида оружия, в то время как остальные пушки получают различные изменения в характеристиках. Очевидно, что большинство игроков рванет тестировать новое оружие, в то время как старое останется без внимания. Это один из возможных способов упустить ошибку.

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

У вас есть тестировщики? Почему постоянные игроки должны прилагать усилия для поиска ошибок?

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

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

Как обрабатываются сообщения об ошибках?

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

Как вы можете заметить, все баг репорты обрабатываются командой поддержки пользователей и достигают команды разработки.     

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

Чем тестирование игр отличается от тестирования ПО

Игры тестировать сложнее, чем неигровые приложения. Причина в игровой механике. Обычное ПО строят на алгоритмах. Они предсказуемо реагируют на действия пользователя. К примеру, он нажал значок «Корзина» — программа тут же удалила часть данных. И так всегда.

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

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

Виды тестирования игр

🧪 Функциональное (functionality testing)

Специалист проверяет:

• меню, вкладки, кнопки;
• единое отображение шрифтов;
• разрешение экрана во время игры;
• звуки, музыку, голоса персонажей.

Задача — найти баги в графике, навигации, контенте и окружающей игрока среде. Типичная функциональная ошибка — когда игровой персонаж проваливается в текстуры. Как раз такое и обнаруживает тестировщик.

🧪 Комбинаторное (combinational testing)

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

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

🧪 Исследовательское (exploratory testing)

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

🧪 Тестирование совместимости (compatibility testing)

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

🧪 Play-тестирование (play testing)

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

🧪 Регрессионное (regression testing)

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

Как тестировать игры: основные этапы

✅ Проработка требований

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

✅ Разработка плана тестирования

Когда функциональные требования проверены, тестировщик разрабатывает план, как проверить игру и поймать в ней баги. В плане описывает объем работ, бюджет, подходы, инструменты, время — получается вроде сметы, но на языке Game Test.

✅ Разработка сценариев тестирования

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

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

✅ Тестирование программного обеспечения

Специалисты проводят различные тесты, отмечают ошибки в чек-листе. В конце отдают отчеты разработчикам — и они исправляют баги.

✅ Повторное тестирование

Когда разработчики устранят баги, тестировщики прогонят игру еще раз. То есть проведут регрессионное тестирование. Если ошибки исправлены — игра готова к продакшену.

✅ Завершение тестирования

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

Станьте инженером по тестированию по программе от Skypro. Освоите специальность за восемь с половиной месяцев, даже если совсем нет опыта в IT. Научитесь писать тестовую документацию: тест-кейсы, чек-листы и тест-планы, тестировать API, мобильные приложения. Всё это — вместе с личным наставником.

Не только дадим знания, но и поможем найти работу с минимальной зарплатой 50 000 ₽. Гарантию трудоустройства закрепляем в договоре.

Типичные ошибки в играх: где возникают

❌ В пользовательском интерфейсе. Вот несколько популярных багов:

• игра не адаптирована под разрешения экранов — на некоторых расползается, на других сжимается;
• игрок не получает подсказки там, где они должны быть;
• пользователь вызывает рюкзак или меняет шмот, а действия тормозят по полминуты;
• игрок делает одно, а интерфейс выдает что-то нелогичное: например, вместо сохранения сворачивает игру.

❌ В графике и анимации. Это любые ошибки, которые возникают с текстурами, краями области. Например, текстура вдруг распалась на пиксели, у персонажей не загрузились головы или NPC заело — он врос в стену.

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

❌ В нарративе. Это любые логические несоответствия. Допустим, персонажи зимой ходят в летней одежде. Или игрок находит заброшенный дом, а он новенький, в нём ни пылинки: странно.

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

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

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

❌ В системе оплаты. Если в процессе оплаты подписки или покупки шмота вылезет ошибка, то персональные данные — банковская карта, пароль, серия и номер паспорта — утекут в сеть и станут доступны третьим лицам. Игрок понесет финансовые потери, а компания — репутационные. К тому же ее могут привлечь к ответственности.

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

Коротко о тестировании игр

• Тестирование игры — это процесс поиска ошибок: логических несоответствий, нарушений законов физики, багов с графикой и анимацией.
• Баги ловит специалист — игровой тестировщик, или game tester. Он знает, как протестировать игру.
• Сначала специалист оценивает требования к игре, потом разрабатывает план тестирования, дальше — сценариев тестов. Наконец, проверяет игру несколько раз и в конце пишет отчет о проделанной работе.
• Во время тестирования используют разные приемы. Например, функциональное тестирование — поиск ошибок в окружающей игрока среде. Или тестирование совместимости — проверка отображения на любом гаджете без искажений.