на каком движке world of tanks blitz

Всё, что нужно знать о Tank Company Mobile и в чём отличие от World of Tanks Blitz

Вот и настал счастливый для многих день и нет, это не первое сентября, успокойтесь. Издатель NetEase Games запустил ОБТ для танковой аркады Tank Company Mobile. Одно присутствие арты и солнечные блики уже заставили многих «танкистов» возненавидеть World of Tanks Blitz и быстренько переметнуться «за Китайскую стену». Давайте посмотрим вместе, оправдывает ли хайп ожидания. Надевайте шлем, заваривайте гречку и берегите уши, будет громко!

Общие впечатления

Хочу сказать сразу, что китайцы подошли с умом к глобальной версии, ведь уже сейчас доступны русский язык и СНГ-сервера. Но если вам и этого мало, то NetEase подготовил русскую озвучку танкистов. Картинка приятная, о ней чуть позже, а вот кнопки маловаты, если не играть на «лопате» или планшете. Замечу, что разработчики догадались ввести голосовой чат, что Wargaming не может сделать уже несколько лет. Для ангара ничего нового придумывать не стали и просто «слизали» у тех же белорусов прокачку экипажа, отдельных частей танка и, конечно же, оборудование для нагиба бюджетных геймеров.

Виды техники

Вместо 10 уровней танков в Tank Company мы получаем всего восемь. Они быстрее прокачиваются, плюс есть задел на будущее для добавления более современных моделей. Нации пока всего три: СССР, Германия и США с вымышленными флагами. Разработчики сказали, что другие страны пока вводить не планируют. Начнём с Советов, путь которых начинается с Т-26. Лёгкая ветка не полностью копирует Blitz, поэтому мы имеем такой танк, как «Объект 906» из War Thunder.

В остальном всё более или менее похоже, если не считать добавление «арты». Ветка немцев отличается большим числом так называемых «пазиков», они же Панцеры. У американцев быстрые ЛТ и крутая САУ Т110 GMC, которая выдаёт больше урона, чем немецкий Ягуар, хоть и в ущерб медленной перезарядки. Теперь рассмотрим конкретно каждую ветку танков и что они из себя представляют:

Режимы и карты

Типов игры в Tank Company три: подбор, развлечение и полигон. Первый представлен супербитвами танков всех типов в формате «15 на 15». Захват вражеской точки происходит быстро, а карта крупные, поэтому держите ухо востро. Если нужна мини-карта, то берём формат «7 на 7» (бои не идут в статистику), ну а хардкорным геймерам подойдут рейтинговые сражения. Пока что карт около шести, но на загрузочном экране инсайдеры уже спалили две новые. Отмечу, что на первых двух уровнях карты обрезаны, после третьего они уже полные.

Из развлечений доступно два режима: антиграв как в Блице и прятки. В последнем нас разделяют на две команды, одна ищет, а другая прячется. Сложность в том, что находить мелких колёсников надо вручную, никаких подсказок игра не даёт. Есть истории, как некоторые прятались в воду или просто сидели в засаде весь матч. На полигоне можно пройти обучение, поучаствовать в военных историях и почитать гид по САУ.

Графика, системные требования и донат

Для запуска Tank Company понадобится чипсет Snapdragon 660, 4 ГБ оперативки и 8 ГБ свободного места. Чтобы вы понимали, WoT Blitz требует двухъядерный процессор и 1 ГБ оперативной памяти. Пока что на лицо посредственная оптимизация и нагрев среднего смартфона до такой степени, что пальцам становится не комфортно. Но что мы получаем взамен? Красивые шейдеры, следы от гусениц, детализированные модели и реалистичную физику танков.

Говорю напрямую, донат в Tank Company есть и зачастую в «конских» масштабах. Заносить денежку можно уже на тесте, но благо издатель обещает не только перенести ваши покупки на релиз, но и добавить вкусный бонус. Тем временем самая крупная покупка обойдётся в 9 490 рублей.

А на этом у меня всё, дорогие друзья. Тест продлится примерно до конца августа, за неделю до закрытия серверов разработчики предупредят. Подписывайтесь на наш канал, ставьте лайки и оставляйте комментарии о том, какую ветку и нацию будете прокачивать после релиза. Ну и не забудьте решить, что же лучше: WoT Blitz или Tank Company? До скорого!

Источник

Как мы улучшили графику World of Tanks Blitz для современных смартфонов и планшетов

Около года назад в World of Tanks вышел апдейт, в котором появилось сразу несколько заметных графических улучшений: откат стволов орудий, следы попаданий по технике, следы от гусениц, динамические тени, мягкие частицы и мягкие границы воды для всех платформ. Некоторые из них полезны, если смотреть с геймплейной точки зрения (следы попаданий), другие сделали игровое окружение красивее.

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

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

Динамическая подвеска

Подвеска — она же система подрессоривания — предназначена для переноса веса танка через опорные катки и гусеницы на грунт, для смягчения толчков и ударов, действующих на корпус танка, и для быстрого гашения колебаний корпуса. От конструкции подвески в значительной степени зависят боевые качества танков: скорость движения по пересеченной местности, точность при ведении огня в движении, относительный комфорт для экипажа, надежность и долговечность всех основных узлов и механизмов техники. Первые танки и другие гусеничные машины имели так называемую жесткую подвеску, где все элементы гусеничного движителя, кроме собственно гусениц, неподвижно крепились к корпусу. Но практика показала, что такое устройство ходовой применимо лишь на скоростях движения в пределах 3–5 км/ч. Первенец мирового танкостроения (ромбовидный Mark I образца 1916 г.) однажды временно появлялся в World of Tanks Blitz и вполне соответствовал реальному прототипу по устройству ходовой части, но если бы мы в реальных условиях собрали с жесткой подвеской практически любой другой танк из World of Tanks Blitz и запустили в поле на средней скорости, его ходовая очень быстро разрушилась бы из-за ударов и сильнейшей вибрации, а экипаж мог бы получить серьезные травмы. В действительности подавляющее большинство прототипов техники в «Танках» имело те или иные разновидности независимой подвески, в которой каждый из катков смонтирован с помощью рессорной системы разных конструкций (пружины, торсионы и т. д.) и может двигаться индивидуально.

«Основная сложность реализации этой фичи заключалась в том, что мы не создавали подвеску с нуля. Потому что в таком случае нам бы не составило большого труда изначально подготовить все модели для работы подвески и смоделировать каждую гусеницу подвижной. У нас было множество танков, которые необходимо было адаптировать для этой фичи. Они имели монолитные неподвижные гусеницы и катки. Для реализации динамичной подвески нам приходилось программно разрезать гусеницу на множество отдельных сегментов и симулировать их движение. И все это в коде, без художников».

Поэтому динамическая подвеска — фича, которую давно ждали и хотели игроки, небезразличные к визуальной составляющей World of Tanks Blitz. Первые активные просьбы добавить физику подвески появлялись еще в конце 2014 года. Но речь идет о физической симуляции в том или ином виде, и такая функциональность не может не требовать вычислительных ресурсов. В первые годы существования игры лишь лучшие мобильные CPU могли обеспечить сколько-нибудь комфортную производительность при такой симуляции, и таких устройств у игроков было немного. Но прогресс не стоит на месте, и сейчас стало возможным добавить динамическую подвеску в игру так, чтобы ее могла оценить бóльшая часть аудитории World of Tanks Blitz.

Игроки очень давно просили эту фичу. Ведь многие люди, играющие в «Танки», являются фанатами этого вида техники. Поэтому им важно видеть танк таким, какой он есть на самом деле. Если провести аналогию, то, например, существуют игрушечные машинки, у которых нет ни открывающихся дверей, ни поворачивающихся колес. И существуют машинки, сделанные более качественно, у которых все это есть.

Источник

На каком движке world of tanks blitz

В России игру скачали 36,4 млн раз. Игра неоднократно попадала в ТОП рейтингов. Сегодня игра получила улучшенную графику, новые танки и ограниченный по времени специальный режим.

С выходом обновления 7.0 в игре существенно улучшилась графика, добавлены высокоуровневые британские легкие танки. Праздничный ивент дал старт большому событию внутри игры, который продолжится и в июле, когда появится (на ограниченное время) новый режим «Столкновение».

World of Tanks Blitz всегда стремится создать у игроков эффект присутствия в бою. На новый уровень ощущений «танкистов» выведут улучшения графики: отдача орудий, следы на земле от траков машин, различия в отметинах от попаданий в зависимости от калибра снаряда, реализация технологии динамических теней, улучшенные эффекты частиц и намокания.

Праздник в честь дня рождения начинает особое событие, в ходе которого будет доступен уникальный танк VI уровня — P.43/06 Anniversario. Оно продлится с 19 по 29 июня, а завершившие его «танкисты» получат уникальный профиль игрока в честь дня рождения World of Tanks Blitz. Также всех ожидает множество других подарков, количество которых зависит от «стажа» в игре.

Завершит торжества новый режим «Столкновение», который начнется 9 июля и доведет идею Blitz до максимума. Игроки схлестнутся друг с другом в супердинамичных и максимально интенсивных схватках — в режиме 5 на 5, на компактных картах. Для победы в «Столкновении» потребуются нервы из чистой стали!

Источник

Создание World of Tanks Blitz на базе собственного движка DAVA

Пролог

Эта история началась более трех лет назад. Наша небольшая компания DAVA стала частью Wargaming, и мы начали обдумывать, какие проекты делать дальше. Чтобы напомнить, каким был мобайл три года назад, скажу, что тогда не было ни Clash Of Clans, ни Puzzle & Dragons, ни многих очень известных сегодня проектов. Mid-core тогда только-только начинался. Рынок был в разы меньше сегодняшнего.

Изначально всем казалось, что очень хорошей идеей будет сделать несколько мелких игр, которые бы привлекали новых пользователей в большие «танки». После ряда экспериментов оказалось, что это не работает. Несмотря на отличные конверсии в мобильных приложениях, переход от мобильного телефона к PC оказывался пропастью для пользователей.

Тогда в разработке у нас находилось несколько игр. Одна из них носила рабочее название «Sniper». Основной геймплей-идеей была стрельба в снайперском режиме из стоящего в обороне танка, по другим танкам, которыми управлял AI и которые могли атаковать в ответ.

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

С этого все и началось!

Когда мы начинали разработку “Снайпера”, то рассматривали технологии, которые тогда были доступны для мобильных платформ. На тот момент Unity был еще на достаточно ранней стадии своего развития: по сути, необходимых нам технологий еще не было.

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

Также мы понимали, что на C# мы не сможем выжать максимум из устройств, под которые мы разрабатываем, и всегда будем ограничены.
Unreal Engine 3 тоже не подходил по ряду похожих причин.

В итоге, мы решили дорабатывать свой движок!

Он на тот момент уже использовался в наших предыдущих казуальных проектах. Движок имел достаточно хорошо написанный низкий уровень работы с платформами и поддерживал iOS, PC, Mac, плюс были начаты работы по Android. Было написано много функциональности для создания 2D-игр. То есть, был неплохой UI и много всего для работы с 2D. В нем были первые шаги по 3D-части, так как одна из наших игр была полностью трехмерной.

Что у нас было в 3D-части движка:

Начало работ

Началось все с доказательства возможности отрисовать ландшафт на мобильных устройствах: тогда это были iPhone 4 и iPad 1.

После нескольких дней работы мы получили вполне функциональный динамический ландшафт, который работал довольно сносно, требовал где-то 8MB памяти и давал 60fps на этих устройствах. После этого мы начали полноценную разработку игры.

Прошло около полугода, и маленький мини-проект превратился в то, чем сейчас является Blitz. Появились совершенно новые требования: MMO, AAA-качество и другие требования, которые движок в его изначальном виде на тот момент уже не мог обеспечить. Но работа кипела полным ходом. Игра работала и работала неплохо. Однако производительность была средней, объектов на картах было мало, и, собственно, было множество других ограничений.

На этом этапе мы начали понимать, что фундамент, который мы заложили в движок, не выдержит пресса реального проекта.

Как все работало на тот момент

Вся отрисовка сцен была основана на простой концепции Scene Graph.

Основной концепции являлись два класса:

Первые шаги по улучшению ситуации

Для начала мы решили полечить проблемы с производительностью и сделать это быстро.

Собственно, сделали мы это, введя дополнительный флаг NEED_UPDATE в каждой ноде. Он определял, нужно ли такой ноде вызывать Update. Это действительно повысило производительность, но создало целый ворох проблем. Фактически код функции Update выглядел вот так:

Это вернуло нам часть производительности, однако началось много логических проблем там, где их не ждали.

LodNode, и SwitchNode — ноды, отвечающие, соответственно, за переключение лодов (по расстоянию) и переключение объектов (например, разрушенных и неразрушенных) — начали регулярно ломаться.

Периодически тот, кто пытался исправить поломки, делал следующее: отключал NEED_UPDATE в базовом классе (ведь это было простое решение), и совершенно незаметно FPS опять падал.

Когда код, проверяющий флаг NEED_UPDATE, был закомментирован раза три, мы, решились на радикальные перемены. Мы понимали, что сделать все сразу у нас не получится, поэтому решили действовать поэтапно.

Самым первым шагом было заложить архитектуру, которая позволит в перспективе решить все возникающие у нас проблемы.

Комбинирование компонентного и data-driven-подхода

Решением этой проблемы стал компонентный подход, комбинированный c data-driven подходом. Дальше по тексту я буду употреблять data-driven-подход, так как не нашел удачного перевода.

Вообще понимание компонентного подхода у многих людей самое разное. То же — и с data-driven.

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

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

Что же такое data-driven. В моем понимании, это подход к проектированию программного обеспечения, когда за основу потока выполнения программы берутся данные, а не логика.

На нашем примере представим следующую иерархию классов:

Код обхода этой иерархии иерархически выглядит так:

В данной иерархии C++ наследования мы имеем три различных независимых потока данных:

Давайте представим, как это должно выглядеть в data-driven подходе. Напишу на псевдокоде, чтобы была понятна идея:

По сути, мы развернули циклы работы программы, сделав это таким образом, чтобы все отталкивалось от данных.

Данные в data-driven подходе являются ключевым элементом программы. Логика — лишь механизмы обработки данных.

Новая архитектура

В какой-то момент стало понятно, что надо идти в сторону Entity-based подхода к организации сцены, где Entity являлась сущностью, состоящей из многих независимых компонентов. Хотелось, чтобы компоненты были полностью произвольными и легко комбинировались между собой.

Читая информацию по этой теме, я наткнулся на блог T-Machine.

Он мне дал множество ответов, на мои вопросы, однако основным ответом было следующее:

• Entity не содержит никакой логики, это просто ID (или указатель).
• Entity знает только ID компоненты, которые ей принадлежат (или указатель).
• Компонент — это только данные, то есть. компонент не содержит никакой логики.
• Система — это код, который умеет обрабатывать определенный набор данных и выдавать на выходе другой набор данных.

Когда я понял это, в процессе дальнейшего изучения различной информации наткнулся на Artemis Framework и увидел хорошую реализацию этого подхода.
Исходники тут, если предыдущий линк не работает: Artemis Original Java Source Code

Если вы разрабатываете на Java, то очень рекомендую посмотреть на него. Очень простой и концептуально правильный Framework. На сегодняшний день он спортирован на кучу языков.

То, чем является Artemis, сегодня называют ECS (Entity Component System). Вариантов организации сцены на базе Entity, компонентов и data-driven достаточно много, однако мы по итогу пришли к архитектуре ECS. Сложно сказать, насколько это общепринятый термин, однако ECS значит, что есть следующие сущности: Entity, Component, System.

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

Этот пункт очень важен в “православном” компонентном подходе. Если нарушить первый принцип, появится очень много соблазнов. Один из первых — сделать наследование компонентов.

Несмотря на гибкость, заканчивается обычно макаронами.

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

ECS — более чистый подход, и решает больше проблем.

Чтобы посмотреть на примере, как это работает в Artemis, можете глянуть вот тут.

Я на примере покажу, как это работает у нас.

Главным классом контейнером является Entity. Это класс, который содержит массив компонентов.

Вторым классом является Component. В нашем случае, это просто данные.

Вот список компонентов, используемых у нас в движке, на сегодняшний день:

Третим классом является SceneSystem:

Функции RegisterEntity, UnregisterEntity вызываются для всех систем в сцене тогда, когда мы добавляем или удаляем Entity из сцены.

Функции RegisterComponent, UnregisterComponent вызываются для всех систем в сцене, тогда, когда мы добавляем или удаляем Component в Entity в сцене.
Также для удобства есть еще две функции:

Эти функции вызываются, когда уже создан заказанный набор компонентов с помощью функции SetRequiredComponents.

Например, мы можем заказать получение только тех Entities, у которых есть ACTION_COMPONENT и SOUND_COMPONENT. Передаю это в SetRequiredComponents и — вуаля.

Чтобы понять, как это работает, распишу на примерах, какие у нас есть системы:

В практически любой системе код выглядит следующим образом:

Системы можно классифицировать по тому как они обрабатывают объекты:

Соответственно, если есть желание можете заходить и смотреть на нашу имплементацию в деталях.

Учитывайте тот факт, что все писалось в реальном проекте, и, конечно, это не академическая реализация.

Планы на будущее:

Источник

Мобильные танки и тесты: интервью о тестировании World of Tanks Blitz

У всех есть какое-то представление о франшизе World of Tanks. Но, как правило, оно «снаружи» (пользовательское) и общее. А что, если посмотреть изнутри, и рассмотреть какие-то очень конкретные вопросы? Скажем, на каком языке пишут тесты для мобильной World of Tanks Blitz, и по каким причинам выбрали его?

Студия разработки мобильных «танков» MS-1 компании Wargaming присутствовала на нашей конференции Heisenbug, и там мы позадавали такие вопросы Дмитрию Сычеву — Lead QA Automation в World of Tanks Blitz. А теперь решили для Хабра сделать и текстовую версию этого небольшого разговора.

— Дмитрий, привет! Ты работаешь над проектом World of Tanks Blitz — для начала расскажи, что это.

Дмитрий: Наша студия разработки MS-1 занимается производством мобильных игр. Я работаю над World of Tanks Blitz, в июне этому проекту исполнилось 6 лет. Он представляет собой кроссплатформенный мультиплеерный танковый шутер. Сердцем игры является сервер. Там происходит вся бизнес-логика, расчет очередей, расчет урона и т.д. Клиент игры написан на C++ и использует in-house движок.

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

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

На тот момент вопрос был решен таким образом:

Teamcity (CI)

Основная цель использования TeamCity – формирование очереди тестов, установка и запуск их на соответствующих устройствах, сбор тестовых данных, формирование и рассылка отчётов всем заинтересованным. За очередь отвечает сама CI, а все остальные задачи лежат на скриптах, написанных на Python, и вспомогательном софте, запускаемом этими скриптами.

MongoDB

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

Все тесты были написаны на Lua, движок которой работал прямо в игре. Для связи скриптов на Lua с кодом игры использовалась прослойка SWIG. Код тестов интегрировался в сам архив с игрой, и при наличии определённого файла конфигурации в документах запускалось исполнение определённого сценария. По окончании выполнения сценария, либо при возникновении ошибки, приложение закрывалось и инициировался сбор тестовых данных.

У этого подхода были как плюсы, так и минусы. Явным плюсом было то, что Lua — один из самых легковесных и быстрых языков по сравнению с тем же Python или JavaScript. Однако при его использовании выявилось несколько недостатков.

Про один из них я могу рассказать историю. Когда я только пришел работать в команду, на языке Lua еще не работал, как и многие — он далеко не самый популярный. Но я подумал, что это интересный вызов. Одним из моих первых заданий было написать несколько тестов на Lua. Я сделал это, дальше нужно было протестировать их на устройствах, посмотреть, все ли правильно работает. Нашел несколько проблем, и мне надо было их продебажить. Спросил у своих коллег, как мне это сделать, и тут оказалось, что отладка в Lua — больной вопрос. Обычно все обкладывают логами и смотрят, что и где пошло не так.

Кроме этого, язык Lua влияет на потребление памяти. Это приходилось учитывать в результатах автотестов производительности.

А отдельного упоминания заслуживает непосредственно написание кода на Lua. Многое тут зависит от писателя, однако есть ограничение для все: нативно не предоставлена возможность писать классы. Наиболее ярко это проявлялось при написании мультиплеерных тестов — это боль.

Можно подумать, что не все так плохо, но вот, что под капотом.

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

В итоге мы пришли к тому, что надо что-то менять. Улучшать нашу систему.

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

Первая — тесты должны писаться быстро, легко и удобно, и они должны быть на языке, который люди хотят изучать.
Вторая — удобное написание мультиплеерных тестов.
Третья — универсальность нашего фреймворка. При разработке игры используется много дополнительных инструментов, которые помогают художникам, артистам, рендеру быстро разрабатывать свои фичи. Эти инструменты тоже развиваются и их тоже надо тестировать. И начал подниматься вопрос, что автоматизировать их тоже было бы неплохо.

Мы ставили перед собой три этих задачи.

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

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

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

Многие могут задать вопрос: а как вообще произвести переход между решениями? У вас есть тесты на Lua, вы хотите их сделать на Python и использовать websocket. А автоматизированное тестирование — это такая штука, которая нужна каждый день, каждую версию. Тесты должны быть непрерывными и постоянными.

Мы нашли следующее решение: написали на первое время обертку, которая вызывала Lua-тест, как питоновский. Со временем, когда тесты переводились на Python, Lua уходил, и на данный момент мы полностью избавились от него. Больше мы его не используем. Сейчас я могу рассказать, какие преимущества мы получили.

— Хорошо. Как я понял, вы сейчас полностью перешли на websocket и полностью перешли с Lua на Python, который у вас де-факто стандарт, в том числе в QA Automation в компании. Какие результаты вы в итоге получили? Если сравнивать старые и новые решения, что стало лучше, а что хуже?

Дмитрий: На данный момент все тесты пишутся на Python. Мы смогли написать достаточно удобный фреймворк, который позволяет человеку с минимальным знанием Python писать тесты. Вот пример того же мультиплеерного теста:

Появилась возможность параметризировать тесты для быстрого изменения запуска (например, при дебаге):

При написании теста есть подсказки, некоторые вещи прописывать не нужно, так как они автоматизированы. Как пример: у нас есть такая сущность как Screen Manager. SM — это класс, который разруливает простейшие переходы между экранами, чтобы эти переходы не приходилось постоянно писать самому. Внутри SM определены зависимости между экранами, те прописано как можно перейти с одного экрана на другой. Когда в тесте мы обращаемся к экрану, который указан в зависимостях, SM определяет, на каком экране сейчас находимся и как можно перейти на экран, к которому мы обратились.

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

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

— Насколько я понимаю, у вас довольно развесистая инфраструктура, и в Wargaming десятки самых разных проектов. Существует ли какая-то стандартизация на уровне всей компании? Для автотестов в основном используется Python — это характерно, наверное, не только для вашей команды, а в целом практика для всей компании?

Наверняка есть команда, которая занимается инфраструктурами тестирования, и у них есть очень много разных наработок (мониторинги, биндинги, логи и все, что угодно). Удалось ли с помощью перехода на Python получить все эти плюшки, или вы довольно независимо все это делаете?

Дмитрий: В Wargaming много проектов, но они действуют достаточно распределенно. Потому что на разных проектах — разные требования. Я могу провести такую аналогию: для нашего проекта, когда заводились автотесты, изначально одним из важных условий было то, что это должны были быть UI-автотесты. То есть мы должны делать действия так же, как и юзеры, используя UI-элементы.

А в «больших» World of Tanks используется другой принцип: там проверяется главная логика игры, используется botnet. То есть внутри игры находятся танки, они делают какие-то действия, и проверяются их взаимодействия. Насколько я знаю, это происходит даже без визуализации игры. То есть сам клиент в полномасштабном режиме не запускается.

Проекты достаточно специфичны, у каждого свои требования. Поэтому нет стандартизации в этом плане. Хотя и у нас тесты написаны на Python, и на «больших» танках тесты написаны на Python, но сама концепция абсолютно разная. С другой стороны, как я говорил, мы закладывали универсальность нашей схемы, и предполагается, что мы будем использовать наш фреймворк для автоматизации других проектов нашей мобильной студии. На данный момент у нас разрабатывается игра на движке Unreal 4, и сейчас мы изучаем вопрос по интеграции нашего фреймворка для автотестов этой игры. В World of Tanks Blitz у нас используется in-house движок, который написан полностью с нуля в нашей студии, а в той игре используется Unreal Engine. То есть это два абсолютно разных движка, но мы будем использовать наши автотесты и там, и там.

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

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

И второе — это производительность. Тестирование производительности. Для мобильных девайсов очень важно, чтобы ваша игра шла без лагов, без затупов и прочего. Нужно сразу учитывать, как вы будете тестировать производительность. Это два основных момента, на которые нужно железобетонно обращать внимание, потому что без них я не представляю себе надежное автотестирование.

— Дмитрий, мы с тобой поговорили про тестирование клиентской части, а как у вас обстоят дела с бэкендом, с нагрузочным тестированием вашего сервера?

Дмитрий: Мы сделали такую штуку как Cloud Client. Это клиент игры, но без визуализации. И в качестве нагрузочного тестирования мы можем создавать до 500000 клиентов игры и заходить ими на сервер. Таким образом мы «ранним» сервер при большом количестве клиентов какое-то время, а далее анализируем логи с сервера на наличие проблем.

— Это, наверное, требует создания некоторой инфраструктуры?

Дмитрий: Естественно. Этот вопрос у нас уже сейчас решается. На данный момент у нас запуск всех автотестов идет с помощью CI-инструмента Team City. Он устанавливает игры на девайс, запускает тесты, регулирует очереди, потом собирает тестовые данные и отправляет заинтересованным людям. Но так как наши тесты подразумевают очень много разных конфигураций запуска, ими пользуются очень много людей, как оказалось, не для всех просто этим пользоваться. Поэтому мы сейчас работаем над тем, что делаем наш портал, на котором будет очень много интересных вещей. Будет реализован запуск тестов в удобном виде. То есть любой человек сможет выбрать то, что он хочет запустить, и это будет запущено на девайсах. Мы туда переводим все отчеты.

На данный момент мы просто формируем html-страницы с графиками, с результатами, со статусами тестов и рассылаем их. А сейчас вся эта информация будет на портале в динамическом виде. Можно будет не только посмотреть текущий запуск, а отсортировать это по дате или по типу или пулу устройств. Это будет удобно для отображения. Если говорить о нагрузочном тестировании, то на портале будет отдельная вкладка для нагрузочного тестирования, где в удобном виде можно будет все посмотреть. Это будет наш кастомный инструмент. Потому что задач ставится перед ним много, и каким-то одним инструментом решить их не получится. Поэтому мы будем развивать свой портал.

— Есть системы (JIRA, TeamCity, Allure), которые позволяют с помощью разных плагинов добиваться примерно того, о чем ты рассказываешь. Почему Allure не подходит для решения такой задачи?

Дмитрий: Allure используется именно для красивого отображения данных. Однако TeamCity это уже CI-инструмент, который используется для запуска тестов, у него стоят абсолютно другие цели. Нам необходимо поддерживать и работу с Allure, и работу с TeamCity, причем как-то сделать удобной работу с TeamCity.

Но это подразумевает поддержку и развитие нескольких инструментов одновременно. А мы можем в одном месте сделать все, так как мы хотим. Ничто не мешает нам на портале прикрутить библиотеки для построения графиков в Allure или еще чем-то другом. В зависимости от того, что нам требуется, мы можем использовать разные вещи. Для отображения больших массивов данных по профайлингу нашей игры (мы используем профайлинг перед тестированием производительности и собираем большое количество данных) удобно работать в BigQuery в Data Studio. Мы будем это использовать, данные уже туда отсылаются. Мы можем в нужном виде их представить, а на портале просто предоставить удобный переход для отображения этих данных. Это не мешает использовать тот же Allure или что-то другое. Просто это все будет сосредоточено в одном месте, удобном для пользователя.

— Дмитрий, спасибо большое за интервью!

Источник