Боли мобильных MMORPG: проект Skylore
Привет, меня зовут Алексей, и я старший тестировщик проекта Skylore. Это новая мобильная MMORPG, сейчас находящаяся в закрытом бета-тесте. Кстати, заявку на тест можно подать здесь, обычно мы разбираем их раз в неделю и добавляем всех желающих.
Сегодня я расскажу о некоторых особенностях тестирования моего проекта и о том, как мы с ними справляемся силами двух человек. На эту идею меня натолкнула проблема, которую я обнаружил, попав в GameDev - информации о наиболее чувствительных компонентах MMORPG совсем не было как в документации проекта, так и в интернете.
Это первая пробная статья из небольшого цикла, и ваши вопросы и предложения могут повлиять на содержание следующих частей, так что смело задавайте их в комментариях.
Объекты тестирования, фичи и особенности
На проекте довольно много объектов тестирования:
- Клиент игры (три платформы: Android, iOS, Windows). Клиент для Windows доступен к тестированию и отладке только для разработчиков
- Сервер
- Несколько редакторов контента и графики
- Центр управления сервером “на лету”
- Система сбора данных для аналитики (ClickHouse)
- Боты
- Прочие: сайт игры, рассылки, музыка, звуки и куча более мелких задач
Клиент Skylore - это кроссплатформенное приложение, поэтому я не буду писать об особенностях тестирования на разных платформах, а сконцентрируюсь на общих аспектах:
- Синхронизация клиента и сервера (у клиента своя логика, у сервера - своя, они должны “дружить”)
- Интернет-соединение
- Возможные проблемы движка
- Большое количество графических элементов - ассетов
- Использование одинаковых UI-элементов в разных окнах
- Большое количество функциональных тест-кейсов
Синхронизация клиента и сервера
Самые частые баги в онлайн-играх, на мой взгляд, - рассинхроны. Это очень коварные, скрытые в недрах кода баги.
А коварство их в том, что никогда не знаешь, где они могут проявиться. Поправить некоторые из них очень трудно: может оказаться, что для исправления нужно полностью переписать логику бэкенда, а значит и клиента, так что иногда с ними приходится мириться и жить. Причина рассинхрона чаще всего очень проста - логика клиента неправильно понимает команды с сервера. Или наоборот - сервер ошибочно распознаёт команды клиента. Такое бывает, когда какие-то тонкости взаимодействия бэкенда и фронтенда команды не обсудили, забыли или не учли. Интересный пример: в нашей игре внедрили функцию автобега нативной кнопкой. Клиент сообщает серверу, что ему нужно попасть из точки А в точку Б. В ответ сервер отдает клиенту необходимый путь. Клиент начинает вести персонажа, и если в этот момент персонаж погибает, то клиент продолжает “тащить” его труп по локации. Конечно, это явная недоработка, и она была сразу обнаружена и исправлена, но всё могло сложиться иначе.
Вот ссылка на небольшой видос с примером на платформе ВК.
Интернет-соединение
Следующее по важности место, где прячутся рассинхроны - интернет-соединение, поэтому я выделил эту особенность вторым пунктом. Здесь все сложнее, и одной логикой для тестирования не обойдешься. Чтобы отловить такие баги, нужно, кроме зоркого глаза, очень много анализировать логи. В нашей команде логируются все операции на клиенте (в дебаг-билдах, у продакшен клиента логов в десятки раз меньше) и очень большое количество операций сервера.
Часто такие рассинхроны всплывают при плохом интернет-соединении или временном его отсутствии, информация от сервера при проблемах с соединением может доходить не вовремя, в неправильном порядке или вообще не доходить. В наши клиенты спрятан функционал для эмуляции таких ситуаций. Мы можем настраивать ping или вовсе блокировать передачу пакетов. В такие моменты клиент предоставлен сам себе и на его стороне могут появиться артефакты, которые отчетливо видны визуально.
Гарантировать стабильное соединение мы не можем, так как его обслуживание и настройка - на стороне провайдера и пользователя. А вот предохраняться от багов на клиенте - можно.
Для примера приведу такой кейс: при плохом соединении пользователь использует скилл, который персонаж применяет, стоя на месте. Но потом сразу нажимает на какой-то интерактивный объект, к которому клиент подводит персонажа автоматически. Информация об этом, из-за проблем с соединением, не доходит до сервера. В итоге на сервере персонаж в одной точке, а на клиенте - уже в другой.
Выводы
Такие ошибки часто встречаются не только в Skylore, а во всех MMORPG. Я заядлый геймер, и наблюдал подобное еще со времен старта Lineage 2 в 2004 году.
Поэтому лучший способ бороться с багами - предупреждать их до того, как фича будет закончена, чтобы разработчик или архитектор могли внести правки как можно раньше. Тогда можно будет избежать ситуаций, которые я описал выше - переписывания с нуля отдельных частей приложения или всей фичи сразу.
Так что, если вы QA, обязательно будьте активной частью команды и принимайте участие в проектировании фич. А лучшим способом предотвращения подобных багов на проде я вижу небольшой регулярный регресс с учетом частых причин рассинхронов. На нашем проекте я выделил следующие:
- Мгновенный каст или нулевая пауза после активации способностей
- Применение способности на бегу
- Взаимодействие/движение к интерактивным объектам
- Высокий пинг
Спасибо за внимание! О других особенностях я расскажу в следующих статьях, готов обсудить написанное или ответить на вопросы =)