Боли мобильных MMORPG: Баги движка и ассеты
Привет, на связи снова Алексей из AiGrind. Сегодня я продолжу делиться своими краткими наблюдениями об особенностях тестирования MMORPG.
Основная цель - поделится опытом, а не дать исчерпывающие знания, поэтому информации может показаться мало, но я надеюсь, она будет полезной.
Бонусом в конце этой заметки будут ответы на вопросы из комментариев предыдущего поста. Начнем...
Ошибки движка
Много ли игровых движков вы знаете? Cейчас компании часто прибегают к использованию готовых решений, а это приводит к дополнительной кучке багов в играх.
Проект на котором я работаю — не исключение: мы тоже используем сторонний движок для его разработки. Из-за этого, помимо отслеживания жизненного цикла багов в jira, приходится следить за новостями о багах движка и патчноутами и, при необходимости, напоминать своим коллегам-разработчикам, что пришло время обновиться.
Такое серьезное изменение, как переход на новую версию движка, может вызвать проблемы в стабильности текущего билда игры. Я на проекте недолго - чуть больше года, но уже несколько раз переживал этот период глобального обновления. После него баги регулярно всплывают еще несколько месяцев, а исправлять их бывает особенно сложно, т.к. возможное решение может быть нигде не документировано. Поэтому обычно всё-таки проще использовать воркараунды, чем ждать, пока разработчик движка исправит найденные проблемы.
Если всё-таки принято решение о переходе, перед этим процессом нужно хорошо ознакомиться с патчноутами новой версии движка и выяснить у разработчиков, в каких частях приложения могут возникнуть ошибки.
Как понять, что баг относится к движку? Я не знаю более простого способа это выяснить, чем загуглить. Зачастую другие разработчики, которые тоже используют на своих проектах стороннее ПО, сами рапортуют о багах в нем и ищут методы быстрого их решения. Можно также подписаться в github, stackoverflow и прочие ресурсы по тегам вашего движка. Периодически мониторя их, можно найти интересные кейсы и баги, о которых вы раньше не знали, но которые почти наверняка есть и у вас в проекте.
Пример от меня: ОС Android при сворачивании приложения кеширует, то, что было на экране. После разворачивания приложения, а затем проигрывания графического эффекта, в его подложке оказалось закешированное изображение. По итогу проблема обнаружилась в не закомментированных парных строчках кода движка.
Видео: https://drive.google.com/file/d/1XDBcEsheDQgxq6TX6biWY8OSDwxwPIXD/view?usp=sharing
Усугубляло этот баг то, что он воспроизводился не на всех ОС. И хорошо, что гугл по ключевым словам подсказал, куда копать.
Большое количество графических элементов-ассетов
Некоторые игры имеют потрясающую графику. Но как тестировать графические ассеты? А если их тысячи? Самый простой подход, на мой взгляд, — делать это еще на этапе их создания путем валидации перед коммитом в общую базу ресурсов. В таком случае от тестировщика понадобятся только сведения о том, какие параметры валидировать.
- Размер
- Разрешение
- Формат
- Название
Чтобы сформировать более чувствительный фильтр, нужно обсудить с разработчиками и художниками их ожидания и возможные пайплайны.
С остальным придётся справляться, отсматривая каждый ассет собственными глазами. В нашей компании принято, что графические элементы проходят ревью арт-директора, проверяются контент мейкерами перед применением, а затем уже готовые мобы, персонажи и предметы уходят в тестирование.
Бегая глазами по экрану, нужно знать, на что обращать внимание, и я выделил несколько акцентов:
- Анимации
- Четкость объектов
- Маштабирование ассетов
- Не перекрывают ли ассеты друг друга
- Не перекрывают ли ассеты персонажей игроков
Несмотря на, казалось бы, минорность багов в ассетах, с технической точки зрения, они формируют впечатление от вашего продукта у пользователей, особенно на первых стадиях игры. Хорошим примером из моего игрового опыта будет передвижение героини в демо-версии NieR: Automata по плоским спускам с провалами обуви под текстуры. К моему большому удивлению, те места, где я наблюдал такие проблемы, были исправлены в финальной версии игры =)
Вывод
Мы перевалили за половину списка особенностей, с которыми я столкнулся, перейдя в новую сферу разработки ПО. Поздравляю, вы заслужили тортик! *смех ГлаДос*
Вывод, который хочется сделать, таков: на больших игровых проектах очень много мест, где могут неожиданно обнаружиться баги. Чтобы поймать хотя бы часть, QA должен быть вооружен и предупреждён, насколько это возможно, путём изучения движка и его особенностей.
А ещё, на разных этапах разработки приёмкой качества компонентов игры могут заниматься коллеги из арт-отдела, программисты и другие разработчики, исправляя часть проблем до этапа тестирования. А если все заводят тикеты с багами по единому стандарту, работа идёт особенно эффективно: так команде легко ориентироваться и быстро бороться с возникающими проблемами.
Ирина Куркина, левел-дизайнер, консультантка и автор канала "Пандоров ящик" в Telegram. Подписывайтесь и делитесь с друзьями!
Рубрика FAQ
В: интересно узнать, есть ли у них какое-нибудь подобие ИИ для тестов?
О: для внутреннего тестирования контента мы используем ботов, работающих через обработку протокола сервера с отправкой ему ответов, запускаются они каждую ночь и формируют отчет после прохождения или падения.
Также автоматизируем тестирование UI-кейсов с помощью sikuli, в основном они проверяют, что все кнопки нажимаются и после их нажатия отображается правильный результат. Там же работают несложные геймплейные енд ту енд тесты.
В: Есть ли функционал для эмуляции разных игровых ситуаций, и можем ли мы настраивать ping или блокировать передачу пакетов
О: принцип работы как в консоли разработчика браузера. Мы задаем пинг отправки и приема пакетов, и смотрим результаты. Можем вообще ограничить поступление пакетов, эмулируя тем самым обрыв интернет соединения.
В: что вы логируете на клиенте и на сервере?
О: В дебажных клиентах мы логируем все входящие и исходящие пакеты, но они имеют обрезанную или закодированную информацию. На сервере обычно логируется все тоже самое, но с большими подробностями и расшифровками ошибок, также на сервере есть логи работы микросервисов и их взаимодействия.
В: почему в объекты тестирования не выделены непосредственно игровые механики, а так же тестирования монетизации? Будет ли более подробно про них расписано учитывая что они изначально не были перечислены?
О: игровые механики как и в целом все кейсы которые можно воспроизвести в игре, на мой взгляд, очень большая тема, и для данного цикла я включил их в последний пункт. Монетизации пока нет на проекте, в его рамках я с монетизацией не сталкивался, поэтому не включил, может быть, в будущем допишу.