Игровая механика представляет собой набор правил, по которым работает игра, и математическую модель, которая стоит за этими правилами. Вместе с дизайном уровней и системой обратной связи с игроком эти три столпа составляют тот самый геймплей. Вот по нему и оценивают геймеры свои впечатления об игре.
На каждом из этих этапов встречаются баги и недоработки, потому что игра — это комплексный труд нескольких человек, а когда речь идёт про AAA-проекты — даже не одного десятка людей. И допустить ошибку в одном из компонентов игры довольно легко.
Сегодня мы затронем тему не только локализационного, но и функционального тестирования. А помогать нам будет эксперт и руководитель отдела тестирования компании Inlingo Андрей Васильев.
Чтобы успешно заводить баги, нужно их систематизировать. Разделить и властвовать.
Итак, баги в играх можно условно классифицировать по следующим категориям:
Баги, связанные с самой игрой:
- Баги функциональности. Не работают или неправильно работают какие-то функции в игре. Например, при переходе в настройки приложения происходит аварийное завершение работы;
- Баги интерфейса. Искажается графика, элементы не находятся на своих местах, текст не вписывается в отведенные ему рамки;
- Баги локализации. Ошибки в текстах, присутствие непереведенных строк. Скажем, вместо перевода выводятся заглушки, вроде “russian_text_001”;
- Баги производительности. Приложение на устройстве работает медленно. Например, во время анимации атаки персонажа FPS заметно «проседает» на устройствах high-end сегмента;
- Баги логики и баланса. Выставленные настройки баланса и игровой логики не позволяют пройти игру или достигнуть нужных целей. К примеру, персонаж наносит урон в 100 единиц, вместо 150 обещанных в игре;
- Технические баги. Игра неправильно работает в условиях нестабильного интернет-соединения, как вариант, приложение не может подключиться к серверу в 3G сетях;
- Баги совместимости. Игра попросту не работает на совместимом устройстве или запускается с критическими ошибками.
Потренируемся: какой это баг по классификациям? Если вы ответили: «Функциональный, низкоприоритетный, графический, затрагивающий команду разработки», то ура — вы тестировщик (нет)
Багам присваивается степень критичности: какие-то устраняются в первую очередь, а какие-то можно даже оставить в финальном релизе:
- максимальный приоритет — баги явно не дают игроку пройти дальше, влияют на способность приложения приносить деньги;
- средний приоритет — баги заметны пользователям, но не влияют на прогресс игрока или на заработок приложения;
- низкий приоритет — баги практически незаметны игрокам, очень редко воспроизводятся или только в очень ограниченных условиях, не мешают прогрессу и заработку.
Иногда разработчики специально оставляют низкоприоритетные баги в игре — для вирусного эффекта. В конце концов, это ведь уморительно, а игры должны развлекать, так почему бы и да?
Баги различают по затрагиваемой стороне. То есть кому они будут больше всего мешать использовать продукт:
- Баги, затрагивающие пользователей. Влияют на популярность приложения, средний рейтинг в магазинах приложений;
- Баги, затрагивающие бизнес. При этом могут не мешать пользователям. Например, игра слишком простая: это радует игроков, но не побуждает их вкладывать деньги;
- Баги, затрагивающие команду разработки. Если функционал реализован не так, как задумывала команда, что не замечают пользователи (они не знают, как задумывалось) и не мешает приложению зарабатывать деньги.
От чего зависит число багов в игре?
Действительно, от чего? Почему в одних играх их просто огромное количество на альфа-тестах (привет, No Man’s Sky), а в других — практически нет? Всё довольно очевидно.
- В первую очередь это зависит от опытности команды разработки.
- На втором месте стоит техническая сложность проекта. Шансы появления багов прямо пропорциональны количеству кода и числу используемых библиотек.
- На третьем месте — количество возможностей в игре и разнообразие игрового процесса в целом.
- Серьёзная статья — это сетевой режим и пути взаимодействия игроков друг с другом. Для сетевого режима разработчики зачастую даже в играх, уже прошедших тестирование на этапе производства, запускают закрытые тестирования для настройки баланса и поиска неочевидных багов.
- Ну и конечно, прямая зависимость от эффективности тестирования именно на раннем этапе разработки. Дело в том, что чем больше багов будет найдено как можно раньше, тем меньше шансов, что эти баги позже приведут к появлению новых.
Двери не нужны
Привязка выявляемого количества багов к жанрам
В группе риска:
- RPG с сетевым режимом. Большой мир, масса сценариев взаимодействия игроков друг с другом;
- Игры с открытым миром. Очень много возможностей поведения игрока, которые надо тщательно тестировать;
- Любые игры с мощной графической составляющей. Практически невозможно одинаково оптимизировать игру под все устройства, если речь не о консольных тайтлах.
Хороший пример того, как игроки испытывают игру на прочность. Skyrim в этом смысле рекордсмен.
Сравнительно проще тестировать игры, где действия игрока ограничены, их реально проверить все за обозримое время теста. В основном, это казуальные игрушки:
- Игры в жанре match-3. Здесь игрок ограничен только игровым полем и комбинациями фишек, бонусов и количеством игровых механик;
- Игры в жанре hidden objects (поиск предметов), в которых, как правило, свобода игрока ограничена
- Файтинги;
- Казуальные игры, действие которых происходит на одном экране — тайм-менеджеры, кликеры, shoot’em up и т.д.
COD WWII за принципиально новый эко-транспорт
Такова классификация багов с нашей точки зрения. В ходе написания материала мы нашли интересное видео с выступлением Дмитрия Химиона про «Тестирование игровой механики в компьютерных играх». Он утверждает, что есть ещё одна классификация ошибок в игре.
Ошибки дизайна уровней
Появляются точки на локации вне досягаемости игрока. Застревания в текстурах, кстати, относят сюда же. И надо справедливости ради заметить, что застреваем мы вовсе не в текстуре, а в геометрической модели, потому как текстура — это картинка. Значит, левел дизайнер где-то ошибся и наделал лишних порогов и ступенек, а нога героя застряла и, пытаясь подчиниться законам физики, начинает вытворять невообразимое
Ошибки обратной связи
Нет звукового или визуального подтверждения при совершаемых игроком действиях, когда игрок недополучает информацию о своём действии, когда он не понимает, кто и откуда его убил (никаких предпосылок — визуальных или звуковых — для этого не было).
Сюда относят все ошибки, связанные с элементами контроля и управления. Они могут возникать при неверной калибровке и невозможности сменить в настройках чувствительность мыши или аналоговых стиков.
Ошибки игрового баланса
Игровой баланс — это качественная характеристика, определяющая уравновешенность игровых сущностей и показателей, а еще поддерживающая интерес к игре. Само создание игрового баланса сопряжено с постоянным тестированием, поэтому ошибкой тут может считаться только незавершенное тестирование.
Несбалансированным может быть оружие, делающее бессмысленным использование любого другого, или дизайн уровня, позволяющий получать преимущество в определенной точке карты без риска. Словом, любые просчеты в балансе, делающие неинтересным игровой процесс в долгосрочной перспективе.
А с какими багами сталкивались вы? Присылайте нам в комментарии — похохочем, что ли.
Если вдруг вы разработчик и хотите, чтобы подобных ошибок в вашем проекте было поменьше, пишите на order@inlingogames.com.