тестирование игр – это неотъемлемая часть процесса разработки. Оно позволяет выявить и исправить ошибки, улучшить игровой опыт и в целом повысить качество продукта. В этой лекции мы рассмотрим различные виды тестирования, методы и инструменты, которые используются для обеспечения высокого качества игр.Тестирование игр — это важный этап разработки, направленный на выявление багов и улучшение геймплея. Качественное тестирование помогает создать стабильный и увлекательный продукт, который удовлетворит ожидания игроков.
Для тестирования видеоигр, как и в других областях, существуют как универсальные, так и уникальные подходы для решения различных задач. Давайте разберем их!
Playtesting — это один из методов тестирования игр, направленный на изучение того, какой игровой опыт и эмоции получает игрок во время процесса. Для проведения плейтестов участникам предоставляют доступ к ранней версии игры (тестирование проводится до официального релиза игры или ее функций). Чаще всего в плейтестах участвуют не специалисты QA, а обычные геймеры, друзья, родственники или любые другие люди, которые могут взглянуть на продукт свежим взглядом. Они делятся обратной связью на основе своих впечатлений и игрового опыта, при этом соблюдая условия NDA, подписанного перед началом тестирования.
Существуют разные мнения о том, стоит ли привлекать к плейтестингу разработчиков, включая QA-команду. Поскольку они досконально знают игру, их фидбек может быть менее ценен, чем мнение представителей целевой аудитории. Цель плейтестинга — понять, насколько игра интересна вашей целевой аудитории. Решение о том, проводить ли плейтесты внутри компании или привлекать внешних участников, зависит от возможностей и предпочтений вашей команды.
Почему важно тестирование игр?
- Выявление багов: Ошибки в игре могут привести к ее нестабильной работе, вылетам или некорректному поведению игровых элементов.
- Улучшение геймплея: Тестирование позволяет оценить, насколько игра интересна, увлекательна и сбалансирована.
- Соответствие техническим требованиям: Проверка совместимости игры с различными устройствами и платформами.
- Обеспечение качества: Тестирование гарантирует, что игра соответствует высоким стандартам качества и готова к релизу.
Говоря о специфических для видеоигр видов тестирования, я бы выделил такую группу как Game Design Testing, куда включу Balance testing, Level Design testing, "Fun Factor" testing).
Balance Testing предполагает проверку того, что баланс есть:
Иногда имеет смысл задуматься даже о мете игры, но это скорее дополнительный бонус, и подобные задачи явно не входят в зону ответственности QA-специалиста. Однако QA может делать пометки и делиться своими наблюдениями с командой.
Level Design Testing подразумевает проверку игровых уровней. Даже визуально впечатляющий уровень может оказаться непроходимым из-за, например, невидимых стен (когда есть модель, но отсутствуют текстуры), дыр в полу (например, из-за некорректной стыковки поверхностей или моделей) или так называемых Stuck points — мест, где персонаж застревает и не может двигаться дальше.
Fun Factor Testing — это достаточно абстрактный вид тестирования, который некоторые выделяют отдельно, а другие считают частью Playtesting. Здесь акцент делается на "фановость" игрового процесса. Даже идеально сбалансированная игра может оказаться скучной, что оттолкнет игроков. На этом этапе также проверяются игровые механики: навигация, прицеливание, взаимодействие с предметами, NPC и прочее. Неудачные механики или непривлекательный арт обычно выявляются именно здесь. Если в процессе игры ничего не вызывает у вас раздражения, значит, вы двигаетесь в правильном направлении.
Мы переходим к обсуждению Visual Components Testing, которое включает в себя тестирование 3D моделей и сцен, 2D элементов (спрайтов) и 2.5D объектов.
3D Models Testing охватывает проверку моделей (high-poly и low-poly) на соответствие визуальным требованиям и допустимому количеству полигонов, указанному в спецификациях. Также оценивается наличие и использование всех необходимых текстурных карт, корректность отображения внутренней стороны моделей (если они видны) и поведение модели при анимации, включая риггинг и скиннинг.
Такие проверки позволяют заранее обнаружить возможные проблемы, например, с текстурными картами, и при необходимости запечь новые текстуры для устранения выявленных недостатков.
2D и 2.5D Testing охватывает тестирование графики для 2D и 2.5D игр. Это включает работу со спрайтами (2D), а также проверку спрайтов или 3D моделей, используемых в 2.5D проектах, которые часто применяются в файтингах, сайд-скроллерах и рогаликах.
Примеры тестирования включают выявление проблем с порядком отрисовки объектов, таких как мир и персонажи в изометрических играх, или корректностью работы "окна", показывающего главного героя за стеной (как в Fallout 1 и 2). Также часто встречаются нюансы с прозрачными объектами, которые могут взаимодействовать с 3D элементами или сложными эффектами, связанными с прозрачностью.
Один из распространенных проблемных сценариев — это когда объект, состоящий из нескольких спрайтов, растворяется или появляется через эффект alpha, но прозрачность каждого спрайта обрабатывается отдельно. В результате вместо единого целого игрок видит разрозненные элементы. Чтобы избежать таких ситуаций, объект можно предварительно отрендерить в текстуру и использовать ее для эффекта, сохраняя визуальную целостность.
Когда мы говорим о персонажах, речь идет не только об игровых героях и их моделях. Сюда также включаются NPC и враги с их искусственным интеллектом (AI). Это открывает обширное поле для AI Testing, которое охватывает такие аспекты, как Pathfinding, AI Spawning, AI Reaction, Detection Range (например, конус зрения NPC) и другие элементы. Ведь гораздо приятнее, когда массовка ведет себя реалистично, не застревает в объектах, а враги появляются в логичных местах, а не прямо за спиной или перед игроком.
На этом этапе также проверяется корректность работы импостеров — упрощенных моделей, используемых для оптимизации. Импостеры могут быть представлены в виде 2D спрайтов в 3D окружении или низкополигональных моделей, которые разгружают ресурсы системы. Например, их использование можно увидеть в финальной битве Serious Sam 4. Однако импостеры применяются не только для AI, но и для отрисовки дальних элементов игрового мира, таких как города, леса или горы, которые игрок видит на расстоянии. Эти объекты заменяются импостерами, пока игрок не подойдет ближе, что известно как billboard sprite.
Важно также протестировать Navigation Mesh (Nav Mesh), чтобы убедиться, что NPC и враги не сталкиваются с предметами или стенами во время передвижения.
Подробнее о механиках взаимодействия с толпами NPC можно узнать здесь.
Использование хитростей, таких как замена моделей высокого качества (high-poly) на упрощенные (low-poly) или импостеры, оптимизация баланса и скорости отрисовки полигонов в загруженных сценах, а также обработка эффектов, может существенно повлиять на производительность игры и снижение FPS (кадров в секунду). Эти аспекты проверяются в рамках Performance Testing.
К этой категории можно также отнести Soak Testing, которое помогает выявлять утечки памяти (memory leaks), и Stability Testing, направленное на обнаружение таких проблем, как фризы, краши, черные экраны, невозможность загрузить уровень, повреждение сохранений и другие ошибки.
Однако снижение производительности может происходить не только из-за большого количества моделей на экране, но и из-за высокой нагрузки при большом числе онлайн-игроков. Даже при малом количестве игроков проблемы могут возникнуть, если вы не протестировали сетевой код в рамках Network Testing. Этот вид тестирования позволяет выявить лаги, разрывы соединений, проблемы с матчмейкингом, стабильность подключений, задержки ввода (input lag) и другие нюансы.
Особое внимание стоит уделить багам, возникающим при плохом интернет-соединении. Если ваше тестирование проходит при хорошем интернете, важно эмулировать условия низкого качества сети.
Подробнее о сетевом коде и типах соединений можно узнать здесь.
Все вышеперечисленное уже выглядит как сложная и громоздкая система. Но это только верхушка айсберга, ведь речь в основном шла о фронтенд-части (клиенте). Однако никто не отменял и бэкенд, а вместе с ним и 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, в свою очередь, работает в двух режимах: портативном (720p) и стационарном (1080p).
Кроме того, с учетом тенденции "геймпады везде и всюду", важно протестировать работу игры с разнообразными контроллерами. Это включает стандартные геймпады, руль и педали для автосимуляторов, джойстики, музыкальные контроллеры и другие устройства. Все они должны корректно отображать соответствующие иконки при переключении и работать без ошибок на ПК или консоли.
Отдельно стоит упомянуть активно развивающийся рынок VR и AR игр и приложений. VR и AR Testing заслуживают отдельного подхода, так как эти устройства имеют множество уникальных особенностей. Например, одной из сложностей в разработке и тестировании для VR является эффект укачивания (motion sickness), который может возникать при использовании шлемов. Это "физическое" ограничение делает VR-тестирование доступным не для всех специалистов.
Виды тестирования игр
- Функциональное тестирование: Проверка соответствия игровых функций требованиям технического задания.
- Тестирование производительности: Оценка производительности игры на различных устройствах и при различных нагрузках.
- Тестирование пользовательского интерфейса (UI): Проверка удобства и интуитивности интерфейса.
- Тестирование игрового баланса: Оценка баланса между игроками и игровыми элементами.
- Тестирование совместимости: Проверка работы игры на разных устройствах и операционных системах.
- Тестирование локализации: Проверка правильности перевода и адаптации игры для разных регионов.
- Тестирование на проникновение: Поиск уязвимостей в системе безопасности игры.
-
Функциональное тестирование
- Проверка основных функций игры на соответствие требованиям.
- Включает тестирование механик, интерфейсов и взаимодействий.
-
Регрессионное тестирование
- Проверка исправленных багов и новых функций на предмет возникновения новых ошибок.
- Обеспечивает стабильность после внесения изменений.
-
Тестирование производительности
- Оценка производительности игры на различных устройствах и платформах.
- Включает тестирование загрузки, частоты кадров и времени отклика.
-
Тестирование удобства использования (Usability Testing)
- Оценка удобства и интуитивности интерфейсов и элементов управления.
- Включает сбор отзывов от пользователей и анализ их поведения.
-
Тестирование на совместимость
- Проверка работы игры на различных устройствах, операционных системах и конфигурациях.
- Обеспечивает доступность игры для широкой аудитории.
Этапы процесса тестирования
- Планирование: Определение целей тестирования, составление тестовых планов и сценариев.
- Подготовка тестовой среды: Настройка тестовой среды, установка необходимых инструментов.
- Выполнение тестов: Проведение ручных и автоматизированных тестов.
- Анализ результатов: Анализ полученных данных, выявление ошибок и их приоритезация.
- Отчетность: Составление отчетов о результатах тестирования.
- Исправление ошибок: Исправление выявленных ошибок разработчиками.
-
Планирование
- Определение целей и задач тестирования.
- Разработка тест-планов и сценариев.
-
Подготовка
- Настройка тестовой среды и инструментов.
- Подготовка тестовых данных и учетных записей.
-
Выполнение тестов
- Проведение тестов в соответствии с планом.
- Запись результатов и выявление багов.
-
Анализ и отчетность
- Анализ результатов тестирования и приоритизация багов.
- Составление отчетов и передача их команде разработчиков.
-
Исправление и повторное тестирование
- Исправление выявленных багов и повторное тестирование для проверки исправлений.
- Обеспечение стабильности и качества игры.
Методы тестирования
- Ручное тестирование: Тестировщик вручную проходит через игру, выполняя различные действия и фиксируя обнаруженные ошибки.
- Автоматизированное тестирование: Использование специальных инструментов для автоматизации рутинных тестов.
- Бета-тестирование: Привлечение внешних игроков для тестирования игры перед релизом.
- A/B-тестирование: Сравнение двух или более версий игры для определения наиболее эффективной.
Инструменты для тестирования игр
Роли в процессе тестирования
- Тестировщик: Непосредственно выполняет тестирование, выявляет и фиксирует ошибки.
- Тестировщик автоматизации: Разрабатывает и поддерживает автоматизированные тесты.
- Менеджер по качеству: Координирует процесс тестирования, планирует и распределяет задачи.
Улучшение геймплея через тестирование
- Сбор обратной связи: Опрос игроков, анализ форумов и социальных сетей.
- Анализ игровых метрик: Изучение данных о поведении игроков, чтобы выявить проблемные места.
- Итеративное тестирование: Постоянное тестирование и внесение изменений на основе полученных результатов.
Важно держать во внимании, что кроме ваших собственных стандартов качества к игре, свои стандарты есть у платформодержателей. Часто такие проверки называются 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 - баги, относящиеся к работе рендера и графического пайплайна.
-
Также отдельно стоит выделить похожий, но в сути другой баг - проблемы коллизий. В видеоиграх отсечение может быть связано с набором алгоритмов, которые реагируют на взаимодействие двух смежных или перекрывающихся геометрий (collision detection). А для выявления таких багов существуют специальные режимы просмотра (view modes).
В рамках Audio bugs группы выделю достаточно базовые, но не менее надоедливые вещи:
-
невозможность проиграть SFX/музыки/диалога,
-
пропуск (триггера) проигрыша,
-
Invisible Walls (невидимые стены) могут являться как багом, так и фичей. Ранее так ограничивали передвижение персонажа игрока и не давали уйти дальше нужного. Сейчас же стараются не создавать "невидимых препятствий", а ограничивать "проходимость" при помощи левел дизайна, к примеру выставить непроходимую преграду, баррикаду, горы, ворота города и т.п. Показывать игроку, что впереди что-то есть, но при этом использовать невидимые стены для недопуска персонажа в эту зону - признаки плохого левел дизайна. Сейчас так почти не делают и невидимые стены часто могут быть следствием реконструкции уровня: к примеру какую-нибудь модель могли забыть убрать или добавили невидимых элемент в качестве временной заглушки.
-
Map Holes чаще всего вызваны не плотным прилеганием плоскостей объектов (пол, стены и т.п.). Это места, где пользователь может, незапланированно для разработчиков, попасть за границы игровой зоны. Такие баги часто еще называют Out of Bounds.
-
Баги Navigation Mesh часто связаны с перестройкой уровня или автоматической генерацией сетки. К примеру вы передвинули предметы, однако навигационная сетка осталась старой. Как следствие, ваши NPC могут "идти в стену" или любой другой предмет, который они не смогут обойти и встрянут там (один из случаев Stuck Points).
Ошибки искусственного интеллекта (AI):
-
NPC не двигаются, застряли, не следуют за игроком,
Раз уж у нас есть и часть движка, отвечающая за физику, то было бы странно, если бы и багов с физикой не было. Тут может быть почти что угодно:
Баги такого рода вы могли видеть в мемах самых разных игр, например GTA 5 или, из актуалочки, Cyberpunk 2077. Хороший разбор многих багов из Cyberpunk 2077, включая только что описанные, можно посмотреть тут.
Баги стабильности и перформанса включают в себя:
-
невозможность загрузить уровень,
-
видимая для пользователя подгрузка хай поли моделей или вообще каких-либо объектов,
-
слишком долгую инсталляцию игры, а также невозможность запустить игру на ПК с минимально допустимыми требованиями.
Не редко встречаются и баги совместимости. Особенно частые примеры выглядят следующим образом:
-
беспроводная гарнитура выдает звук в моно и т.п.
О проблемах онлайн игр наслышаны все. Плохое соединение, лаги, "невидимые игроки" или же "я зашел за угол, а меня убили", ошибки подсчета очков, невозможность реконнекта (если такая фича есть), потеря пакетов во время игры, расхождение в подсчетах информации между клиентом, дедикейтед сервером и бек эндом. Также при плохом соединении некоторые элементы интерфейса можно использовать по несколько раз, что-то может не прогрузиться и "пропасть" и т.д., но, как правило, это UI баги и сильно не влияют на user experience игрока.
Под баги локализации и compliance, из нетривиального, можно отнести:
-
размещение разных материалов на одних и тех же местах в разных регионах и странах (например, в этой стране запрещено к показу одно, а в другой - не запрещено или же возрастной ценз, под которые подпадает игра, может не разрешить что-либо показывать в том или ином регионе).
Думаю многие видели этот баг из Assassins Creed. Причины могут быть разные - не подгрузился mesh или материал и вовсе неправильный. А также не стоит исключать возможность включения LOD mesh, котороый не установлен
Было бы странно, если в такой комплексной системе как видео игры не было багов. Они есть, встречаются часто и этот бестиарий здесь крайне разнообразен. Ознакомившись с вышеприведенными видами тестирования для игр, думаю вы догадываетесь, что и баги в видео играх встречаются далеко не только "404 not found" и "game crashed". Давайте же пробежимся по самым часто встречающимся из них в игровой индустрии!
В категорию Visual багов войдут: любые видимые артефакты (Visible Artefacts), пропущенные текстуры (missing textures), Clipping, Culling, Screen tearing, Z-fighting.
Примеры визуальных багов можете посмотреть ниже:
Visual Artefacts - любые визуальные баги, не подпадающие под другие виды.
Вупс... Что-то пошло не так
Missing Textures - пропущенные/исчезнувшие текстуры. Обычно на их месте стараются ставить "заглушку" в виде яркой текстуры по умолчанию в виде шахматной доски. Это не обязательно, но благодаря такому подходу, пропущенные текстуры видны не вооруженным взглядом.
Пропущенная текстура и хороший пример "шахматки" вместо потерянного файла
Z-fighting - данный баг появляется, когда несколько примитивов расположены на примерно одинаковом расстоянии до камеры и они имеют фактически одинаковые значения в Z-buffer, которые отслеживают глубину. Из-за этого примитивы могут частично отображаться один над другим.
Z-fighting , также называемый сшиванием или planefighting , — это явление в 3D-рендеринге , которое происходит, когда два или более примитивов находятся на очень близких расстояниях от камеры. Это приводит к тому, что они имеют почти одинаковые или близкие значения в z-буфере , который отслеживает глубину. Это означает, что при рендеринге определенного пикселя неоднозначно, какой из двух примитивов отрисовывается в этом пикселе, поскольку z-буфер не может точно различить, какой из них находится дальше от другого. [ 1 ] Если бы один пиксель был однозначно ближе, менее близкий можно было бы отбросить. Это особенно распространено с копланарными полигонами, где две грани занимают по сути одно и то же пространство, и ни одна из них не находится впереди. В результате затронутые пиксели рендерятся с фрагментами из одного или другого полигона произвольно, способом, определяемым точностью z-буфера. Он также может меняться при изменении сцены или камеры, заставляя один полигон «выигрывать» z-тест, затем другой и т. д. Общий эффект — мерцающая, шумная растеризация двух полигонов, которые «борются» за цвет пикселей экрана. Эта проблема обычно вызвана ограниченной точностью субпикселя, ошибками округления с плавающей и фиксированной точкой .
Чем выше точность z-буфера, тем меньше вероятность, что возникнет z-борьба. Но для копланарных полигонов проблема неизбежна, если не предпринять корректирующие действия.
Демонстрация z-fighting с несколькими цветами и текстурами на сером фоне
Screen Tearing или "разрыв экрана" - это визуальный артефакт, при котором отображается информация из нескольких кадров на одном изображении.
Culling и Clipping - баги, относящиеся к работе рендера и графического пайплайна. Часто - пересечение двух объектов, при котором один закрывает геометрию другого, скрывая ее от взгляда. Если немного углубиться, то Culling - это отсечение того, что заведомо невидимо. В таком случае игра даже не будет пытаться отрисовать данный сегмент. Culling бывает разным и вот его примеры: rustrum culling - отсечение по пирамиде видимости, backface culling - отсечение "задних" граней, occlusion culling - отсечение граней факту их перекрытия другой геометрией, depth culling - перекрытие одной геометрии другой, которая уже была нарисована, но на основе depth buffer. А вот когда рисуется достаточно большой полигон и от него отрезается все то, что заведомо находится за пределами экрана - это уже Clipping.
Также отдельно стоит выделить похожий, но в сути другой баг - проблемы коллизий. В видеоиграх отсечение может быть связано с набором алгоритмов, которые реагируют на взаимодействие двух смежных или перекрывающихся геометрий (collision detection). А для выявления таких багов существуют специальные режимы просмотра (view modes), но об этом я расскажу в следующей статье.
Вот так можно легко "войти" в объект с кривой коллизией (или без нее вовсе)
Баг такого рода также можно описать термином occlusion, т.е. перекрытие одного объекта другим не так как задумано.
В рамках Audio bugs группы выделю достаточно базовые, но не менее надоедливые вещи: не возможность проиграть SFX/музыки/диалога, пропуск (тригера) проигрыша, плохое микширование (звук слишком тихий или громкий), искажения (distortions), дропы.
Баги левел дизайна - невидимые стены (invisible walls), пропасти в карте (map holes), застревания (stuck spots) и т.д. Также к багам левел дизайна я бы отнес баги связанные с нав мешем (Navigation Mesh). Ниже приведу несколько примеров багов левел дизайна:
Invisible Walls (невидимые стены) могут являться как багом, так и фичей. Ранее так ограничивали передвижение персонажа игрока и не давали уйти дальше нужного. Сейчас же стараются не создавать "невидимых препятствий", а ограничивать "проходимость" при помощи левел дизайна, к примеру выставить непроходимую преграду, баррикаду, горы, ворота города и т.п. Показывать игроку, что впереди что-то есть, но при этом использовать невидимые стены для недопуска персонажа в эту зону - признаки плохого левел дизайна. Сейчас так почти не делают и невидимые стены часто могут быть следствием реконструкции уровня: к примеру какую-нибудь модель могли забыть убрать или добавили невидимых элемент в качестве временной заглушки.
Герой не может пройти дальше из-за невидимой стены, однако дорога все не заканчивается...
Map Holes чаще всего вызваны не плотным прилеганием плоскостей объектов (пол, стены и т.п.). Это места, где пользователь может, незапланированно для разработчиков, попасть за границы игровой зоны. Такие баги часто еще называют Out of Bounds.
А вот так ваша игра выглядит "изнутри"
Баги Navigation Mesh часто связаны с перестройкой уровня или автоматической генерацией сетки. К примеру вы передвинули предметы, однако навигационная сетка осталась старой. Как следствие, ваши NPC могут "идти в стену" или любой другой предмет, который они не смогут обойти и встрянут там (один из случаев Stuck Points).
Здесь Nav Mesh проходит сквозь объекты в красном круге
Ошибки искусственного интеллекта (AI): NPC не двигаются, застряли, не следуют за игроком, предполагаемое взаимодействие с предметами не работает, застревание, NPC делают то, что не задумано изначально и т.п.
Раз уж у нас есть и часть движка, отвечающая за физику, то было бы странно, если бы и багов с физикой не было. Тут может быть почти что угодно: левитирующие объекты, нереалистичная физика, ускорение свыше нормы, а также взмывание предметов " в космос" из-за сложения векторов при обработке контактов. Баги такого рода вы могли видеть в мемах самых разных игр, например GTA 5 или, из актуалочки, Cyberpunk 2077. Хороший разбор многих багов из Cyberpunk 2077, включая только что описанные, можно посмотреть тут.
Плотва, что ты делаешь???
Летающие машины в Cyberpunk 2077 - не редкость
Баги стабильности и перформанса включают в себя фризы, краши, черные экраны, невозможность загрузить уровень, видимая для пользователя подгрузка хай поли моделей или вообще каких-либо объектов, просадка FPS, дооооооооолгая загрузка, а также микрофризы (подгрузки). Сюда же добавлю слишком долгую инсталляцию игры, а также невозможность запустить игру на ПК с минимально допустимыми требованиями.
Извините, я вас не узнал... У вас лицо не прогрузилось
Не редко встречаются и баги совместимости. Особенно частые примеры выглядят следующим образом: на некоторых видеокартах могут встречаться краши (к примеру на минимально возможных требованиях или новых видеокартах на рынке), контроллеры той или иной фирмы не работают, игра не запускается на какой-то определенной версии ОС, беспроводная гарнитура выдает звук в моно и т.п.
О проблемах онлайн игр наслышаны все. Плохое соединение, лаги, "невидимые игроки" или же "я зашел за угол, а меня убили", ошибки подсчета очков, невозможность реконнекта (если такая фича есть), потеря пакетов во время игры, расхождение в подсчетах информации между клиентом, дедикейтед сервером и бек эндом. Также при плохом соединении некоторые элементы интерфейса можно использовать по несколько раз, что-то может не прогрузиться и "пропасть" и т.д., но, как правило, это UI баги и сильно не влияют на user experience игрока.
С таким количеством повторений, походу это уже не баг, а фича. Пора вводить очереди как в Diablo 2
Под баги локализации и 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 - азартная игра) - игра, результат в которой полностью или в значительной мере зависит от воли случая (удачи).
Хотя гемблинг и является собирательным типом для многих игр, букмекерских ставок, бинарных опционов и турниров по играм, тестирование каждого конкретного подвида может отличаться. Кроме того, гэмблинг может как относиться к тестированию игр в некоторых случаях, так и не иметь с ним вообще ничего общего.
-
взаимодействие с законодательством;
Заключение
Это далеко не все разновидности игровых багов, но, пожалуй, самые часто встречаемые. Здесь я не затрагивал баги несоответствия, такие как "элемент записан в blueprints по одному, на back-end - по другому, объект или его атрибуты (ID, описание и т.д.) забыли куда-то добавить и прочее. А не затрагивал их, т.к. это больше не про специфики игр, а в целом неисправности, которые могут быть во многих программах.
Тестирование игр – это непрерывный процесс, который начинается на ранних этапах разработки и продолжается до самого релиза. Качественное тестирование позволяет создавать игры, которые не только работают стабильно, но и приносят удовольствие игрокам.Тестирование игр — это комплексный процесс, требующий внимания к деталям и систематического подхода. Качественное тестирование помогает создать стабильный и увлекательный продукт, который удовлетворит ожидания игроков и обеспечит успех на рынке.
А с какими багами вы встречались во время игры или работы над игрой? Буду рад пообщаться с вами на эту и другие релевантные темы в комментариях!
Вопросы для обсуждения
- Какие виды тестирования вы считаете наиболее важными для игр вашего жанра?
- Как можно автоматизировать процесс тестирования?
- Как привлечь игроков к бета-тестированию?
Задания для самостоятельной работы
- Проведите анализ интерфейса какой-либо игры и составьте список потенциальных проблем.
- Разработайте простой тест для проверки баланса в игре.
- Изучите один из инструментов для автоматизации тестирования игр.
Вау!! 😲 Ты еще не читал? Это зря!
- тестирование
- качество
- надежность
Ответы на вопросы для самопроверки пишите в комментариях,
мы проверим, или же задавайте свой вопрос по данной теме.
Комментарии
Оставить комментарий
Разработка компьютерных игр, гейм-дизайн
Термины: Разработка компьютерных игр, гейм-дизайн