Комментарии 43
Подобных обзорных статей очень мало, а тех, с которыми хочется соглашаться в каждом пункте — только одна. Эта.
Мы используем очень похожий стек технологий и потратили кучу времени на подбор и поиск подходящих технологий. Я очень рад, что кто-то собрался и поделился этой информацией:)
Кстати, не знал про volatile physics. Это выглядит просто шикарно!
Не нашёл в статье словосочетания unit test. Соответственно, возникает вопрос, как у вас с этим? Является наличие тестов частью definition of done? Внедрена ли методика TDD?
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 приложение занимает много времени. Но это требуется довольно редко и зачастую настраивается регулярная автоматическая сборка (например, раз в день).
del
Я вам просто чисто по человечески говорю, как человек, которому игра нравилась на самом деле — суть последних обновлений это банальное «добавить пару новых несбалансированных пушек, пару карт и „новый“ конкурс». Всё. Буквально.
Видимо есть ещё люди, в это не игравшие, потому аналитика считает что есть приток новых пользователей и пока у проекта всё хорошо. Но факт в том, что без дальнейшего развития его ждёт медленное угасание, как сотни других проектов. Это вопрос времени теперь уже, не более.
На самом деле большая часть компании работает над War Robots и команда проекта только растет. Проекту уже 4 года, но нового запланировано еще на годы вперед :)
А на новый проект мы набрали новую команду, потому что проект с технической точки зрения отличается от WR. Мы придерживаемся принципа „Нет опыта в чем-то — найми тех, кто уже такое делал и научись у них».
И — ни одного скрина, не точобв анимации, чтобы хотя бы понять, что вы имели в виду, говоря про красочность и интересность.
Дополните?
И другой вопрос, связанный с этой библиотекой. То что она исключительно двухмерная накладывает ограничения и на размерность игры? Или это уже вопрос геймдизайна?
Здорово что вы делаете свой вклад в opensource.
А какие варианты рассматриваете?
Можете поделиться эмпирическими данным по этому вопросу?(хотелось бы циферок и графиков побольше)
Ну и до кучи вопросик, после компановки в атласы какой эффект на рантайм производительность?
Про цифры — dxt5 сжимает в 4 раза, и раз и два
При использовании сжатия уменьшается размер – со всеми вытекающими (меньше весит пакет установки, быстрее грузиться) и возможно улучшиться производительность рендеринга =)
ECS-архитектура отличный подход для создания архитектуры, о котором я ранее не знал.
Как мы замахнулись на мобильный fast paced шутер: технологии и подходы