Спасибо за статью. После такого заголовка ожидалось увидеть описание клиент-серверного взаимодействия или может быть трудности, с которыми столкнулись. Тут же больше просто перечисление технологий и плагинов проекта во многом совпадающих с WarRobots. К концу прочтения даже было ощущение, что статья больше для поиска кандидатов в команду.
Это первая, обзорная статья, а вот потом мы будем смотреть про какие направления интереснее всего будет рассказать)
Просто пока не понятно, чем это отличается от проекта WarRobots (не по геймплею, а по технологиям), по которому уже куча подробных технических статей.
Начинка и архитектура клиента и подходы очень отличаются от WR, серверные решения похожие. Стараемся реиспользовать лучшее.

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


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


Кстати, не знал про volatile physics. Это выглядит просто шикарно!

хорошая статья. хотелось бы узнать как вы реализовали клиент — сервер логику. интересно было бы прочитать как реализуется RPC, чат на примере кода. как создавать свой dedicated server если у вас такое имеется и т.д. одним словом все про multiplayer. я вот пытался сделать мультиплеер игру, но застрял на реализации клент — сервера. нет приемлимого материала о том как сделать сервер и т.д. все существующие аналоги платные с кучей специфичного своего кода

Не нашёл в статье словосочетания unit test. Соответственно, возникает вопрос, как у вас с этим? Является наличие тестов частью definition of done? Внедрена ли методика TDD?

TDD нет. Т.е. мы в первую очередь пишем код игры. Но о юнит-тестах думаем. В планах подключить в первую очередь тест-сценарии на реальных устройствах типа «игрок загрузил игру, нажал туда-то, потом сюда, получил такой-то результат и тд». У нас есть отдельная команда по автотестам на разные проекты, сами тест-сценарии пишут QA.
TDD нет.

Печаль.


Но о юнит-тестах думаем.

То есть, не только TDD нет, но и юнит тесты не пишите? Интересно почему. Те, кто мета-сервер разрабатывают — тоже юнит тесты не пишут?


В планах подключить в первую очередь тест-сценарии на реальных устройствах типа «игрок загрузил игру, нажал туда-то, потом сюда, получил такой-то результат и тд».

Это вот эта отдельная команда по автотестам будет делать? А что за сценарии они делают сейчас?

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

Как я понимаю, вы считаете юнит тесты такой плюшкой, добавление которой требует временных затрат и наличие которой надо как-то обосновать? Это в геймдеве повсеместно распространённая точка зрения?


Сейчас игра на стадии проверки гипотез, а для этого юнит-тесты не нужны

А для чего они, по вашему мнению, нужны?

Скажу честно, довольно странным кажется что при настроенном TeamCity и автоматизированном билде у вас совсем нет Unit Тестов (поправьте если я вас неправильно понял).


Как минимум, дельта-компрессию и ECS очень выгодно покрывать тестами, т.к. баги могут оказывать влияние на всю игру, а простора для ошибок много.

Как минимум, дельта-компрессию и ECS очень выгодно покрывать тестами, т.к. баги могут оказывать влияние на всю игру, а простора для ошибок много.

Я думаю, может впринципе в игровой индустрии тесты писать не принято?

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


И на то есть масса причин, первопричина которых лежит самой сути игры:


1) Высокая производительность.
Игра должна выполнять симуляцию 60 кадров в секунду, т.е. 0.016 мс на кадр. Если вы подумаете обо всем том, что происходит в современных AAA играх, это обязано взорвать вам мозг.


Из этого вытекают такие отклонения как отсутствие DI контейнеров; Недостаточное разделение логики.


2) Игра — это Data-Driven приложение.
Код составляет лишь часть (и не всегда бОльшую часть) игры. И поведение зачастую определяется преимущественно настройками, а не кодом.


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


3) Низкая стабильность ТЗ.
Очень редко можно предсказать качество геймплейного элемента до его воплощения в жизнь программистом.


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


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


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

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

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

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

Верно!
В том-то и дело что фича, казавшеяся разумной притерпевает значительные изменения в процессе исполнения.


В геймплее не так прозрачны бизнес-требования, как энтерпрайзе:)

Я правильно понимаю, что вы считаете, что тесты нужны только для того, чтобы избежать регрессий?

Я считаю что любые тесты — попытка доказательства корректности кода.


И если формальный критерий корректности меняется слишком часто, тесты могут быть не выгодны.

Каким образом частота смены формальных критериев корректности кода связана с свыгодностью доказательства корректности текущего варианта? Получается, не очень важно, корректен он, или нет?


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

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


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

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

А вот такой момент, что юнит тесты прогнать быстрее, чем собрать код и вручную погонять программу? Он в геймдеве не выстреливает? Не получается так, что на отладку уходит много времени чисто за счёт накладных расходов на сборку и всё такое?

Из-за низкой стабильности ТЗ, появляется требование к высокой скорости итераций. Так что современные движки (Unity, Unreal,...) поддерживают hot reload кода и через несколько секунд можно посмотреть на результат своей работы.


Да, полноценный билд проекта в standalone приложение занимает много времени. Но это требуется довольно редко и зачастую настраивается регулярная автоматическая сборка (например, раз в день).

Да, говоря про юнит-тесты, я больше имел ввиду клиента и геймплей. У нас есть тесты на стороне meta-сервера, мы подумываем про юнит-тесты на системные классы/задачи в клиенте. На геймплей пока нет, по причинам, которые вы уже сами раскрыли. А вот системные/интеграционные тесты на мета-часть игры (загрузка профиля, покупки, смена снаряжения, нажатие кнопок и тд) задача стоит на специальный отдел, который делает это для всех проектов в компании. Как они это делают — можем тоже отдельную статью написать.

Да, это довольно интересно.
Вопрос тестирования стоит остро в геймдеве, как вы и сами знаете:)
И я не знаю никого (включая нас), кто умеет это дело правильно готовить. Так что было бы круто прочитать вашу точку зрения об этом.

Я вот так и подумал что вы Роботов в итоге забросите. Там все обновления к какому-то унынию свелись, не реализуются ожидаемые годами фичи, старые баги все на месте.
Мы судим по отзывам и аналитикам в абсолютных значениях. По нашим данным, у проекта все хорошо, более того, новые обновления аналогично отлично заходят)
Ну, с аналитикой спорить бесполезно, конечно.

Я вам просто чисто по человечески говорю, как человек, которому игра нравилась на самом деле — суть последних обновлений это банальное «добавить пару новых несбалансированных пушек, пару карт и „новый“ конкурс». Всё. Буквально.

Видимо есть ещё люди, в это не игравшие, потому аналитика считает что есть приток новых пользователей и пока у проекта всё хорошо. Но факт в том, что без дальнейшего развития его ждёт медленное угасание, как сотни других проектов. Это вопрос времени теперь уже, не более.
Спасибо за фидбек!
На самом деле большая часть компании работает над War Robots и команда проекта только растет. Проекту уже 4 года, но нового запланировано еще на годы вперед :)
А на новый проект мы набрали новую команду, потому что проект с технической точки зрения отличается от WR. Мы придерживаемся принципа „Нет опыта в чем-то — найми тех, кто уже такое делал и научись у них».
> нам удалось

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

Дополните?
Пока проект в бета, скриншоты, к сожалению, выкладывать не могу. Но обязательно выложу, как только можно будет.
Спасибо за статью и полезный обзор технологий! Здесь Вы снова упоминаете Volatile Physics, где не реализован детерминизм — не могли бы рассказать, как при удалось реализовать локальную симуляцию и ролбэки?
И другой вопрос, связанный с этой библиотекой. То что она исключительно двухмерная накладывает ограничения и на размерность игры? Или это уже вопрос геймдизайна?
Честно говоря, выбор Volatile Physics был плохим решением. На момент решения других альтернатив на C# особо не было, а еще один проект в компании уже использовал эту библиотеку и тогда еще особо проблем не было. Вообще, Volatile Physics — это больше «проба пера» одного программиста. Использованы самые неоптимальные алгоритмы, много багов. Например, в одном месте вместо sin использован cos(или наоборот, не помню). Мы уже форкнулись и сделали пуллриквесты с фиксами. Подумываем о замене физического движка, благо с нашей архитектурой это не будет большой проблемой.

Здорово что вы делаете свой вклад в opensource.

> Подумываем о замене физического движка
А какие варианты рассматриваете?
Что касается 2d — да, это накладывает ограничения на некоторые дизайнерские решения. И там, где нам нужен 3d, мы пишем кастомную обработку физики.
Про prediction и rollback будет отдельная большая статья. В целом, недетерминизм физики на них особо сильно не влияет. Во многих «взрослых» играх это работает и без детерминированной физики, у нас тоже.
Достойно!
>Сокращаем в разы размеры билда за счет компрессии текстур, сборки их в атласы

Можете поделиться эмпирическими данным по этому вопросу?(хотелось бы циферок и графиков побольше)
Ну и до кучи вопросик, после компановки в атласы какой эффект на рантайм производительность?
После объединения спрайтов в атласы, мы стараемся получить квадратную текстуру степени двойки, это позволяет применять большое кол-во форматов сжатия с потерями и достичь наилучшего результата. Результат зависит от выбранного сжатия, какое сжатие использовать зависит от наличия альфа канала, девайса, содержимого и др.
Про цифры — dxt5 сжимает в 4 раза, и раз и два
При использовании сжатия уменьшается размер – со всеми вытекающими (меньше весит пакет установки, быстрее грузиться) и возможно улучшиться производительность рендеринга =)
Надо поднять старые записи и задачи, посмотрю. Как найду, отпишусь тут.
Огромное спасибо за ваш пост!
ECS-архитектура отличный подход для создания архитектуры, о котором я ранее не знал.
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.