Боли мобильных MMORPG: Баги движка и ассеты

Привет, на связи снова Алексей из AiGrind. Сегодня я продолжу делиться своими краткими наблюдениями об особенностях тестирования MMORPG.

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

Бонусом в конце этой заметки будут ответы на вопросы из комментариев предыдущего поста. Начнем...

Ошибки движка


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

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

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

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

Как понять, что баг относится к движку? Я не знаю более простого способа это выяснить, чем загуглить. Зачастую другие разработчики, которые тоже используют на своих проектах стороннее ПО, сами рапортуют о багах в нем и ищут методы быстрого их решения. Можно также подписаться в github, stackoverflow и прочие ресурсы по тегам вашего движка. Периодически мониторя их, можно найти интересные кейсы и баги, о которых вы раньше не знали, но которые почти наверняка есть и у вас в проекте.

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

Видео: https://drive.google.com/file/d/1XDBcEsheDQgxq6TX6biWY8OSDwxwPIXD/view?usp=sharing

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

Большое количество графических элементов-ассетов

Некоторые игры имеют потрясающую графику. Но как тестировать графические ассеты? А если их тысячи? Самый простой подход, на мой взгляд, — делать это еще на этапе их создания путем валидации перед коммитом в общую базу ресурсов. В таком случае от тестировщика понадобятся только сведения о том, какие параметры валидировать.

Самые очевидные, навскидку:

- Размер
- Разрешение
- Формат
- Название

Чтобы сформировать более чувствительный фильтр, нужно обсудить с разработчиками и художниками их ожидания и возможные пайплайны.

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

Бегая глазами по экрану, нужно знать, на что обращать внимание, и я выделил несколько акцентов:

- Анимации
- Четкость объектов
- Маштабирование ассетов
- Не перекрывают ли ассеты друг друга
- Не перекрывают ли ассеты персонажей игроков

Несмотря на, казалось бы, минорность багов в ассетах, с технической точки зрения, они формируют впечатление от вашего продукта у пользователей, особенно на первых стадиях игры. Хорошим примером из моего игрового опыта будет передвижение героини в демо-версии NieR: Automata по плоским спускам с провалами обуви под текстуры. К моему большому удивлению, те места, где я наблюдал такие проблемы, были исправлены в финальной версии игры =)

Вывод

Мы перевалили за половину списка особенностей, с которыми я столкнулся, перейдя в новую сферу разработки ПО. Поздравляю, вы заслужили тортик! *смех ГлаДос*

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

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


Рубрика FAQ

В: интересно узнать, есть ли у них какое-нибудь подобие ИИ для тестов?

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

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

В: Есть ли функционал для эмуляции разных игровых ситуаций, и можем ли мы настраивать ping или блокировать передачу пакетов

О: принцип работы как в консоли разработчика браузера. Мы задаем пинг отправки и приема пакетов, и смотрим результаты. Можем вообще ограничить поступление пакетов, эмулируя тем самым обрыв интернет соединения.

В: что вы логируете на клиенте и на сервере?

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

В: почему в объекты тестирования не выделены непосредственно игровые механики, а так же тестирования монетизации? Будет ли более подробно про них расписано учитывая что они изначально не были перечислены?

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