Да, это довольно интересно.
Вопрос тестирования стоит остро в геймдеве, как вы и сами знаете:)
И я не знаю никого (включая нас), кто умеет это дело правильно готовить. Так что было бы круто прочитать вашу точку зрения об этом.
Из-за низкой стабильности ТЗ, появляется требование к высокой скорости итераций. Так что современные движки (Unity, Unreal,...) поддерживают hot reload кода и через несколько секунд можно посмотреть на результат своей работы.
Да, полноценный билд проекта в standalone приложение занимает много времени. Но это требуется довольно редко и зачастую настраивается регулярная автоматическая сборка (например, раз в день).
В игровой индустрии пока не приняты многие нормы классической разработки.
Например, в геймдеве очень любили экономить на штуках типа виртуальных функций. Это дикость в мире энтерпрайза, но норма в мире разработки игр.
И на то есть масса причин, первопричина которых лежит самой сути игры:
1) Высокая производительность.
Игра должна выполнять симуляцию 60 кадров в секунду, т.е. 0.016 мс на кадр. Если вы подумаете обо всем том, что происходит в современных AAA играх, это обязано взорвать вам мозг.
Из этого вытекают такие отклонения как отсутствие DI контейнеров; Недостаточное разделение логики.
2) Игра — это Data-Driven приложение.
Код составляет лишь часть (и не всегда бОльшую часть) игры. И поведение зачастую определяется преимущественно настройками, а не кодом.
Это приводит к тому, что попытка Unit-тестировать компоненты, относящиеся к геймплею превращается в бесполезный сизифов труд. Ведь во-первых гораздо проще напортачить в настройке, чем в коде, а во-вторых придется замокать все взаимодействие со внешним окружением, что бывает проблематично.
3) Низкая стабильность ТЗ.
Очень редко можно предсказать качество геймплейного элемента до его воплощения в жизнь программистом.
В результате TDD подход, где тесты пишутся до логики, заставляет программиста писать тесты, которые будут выкинуты в тот же день.
Вот это у меня постоянно крутится на уме.
Мы покрываем Unit тестами глубинные части нашей архитектуры, которая плотно зафиксирована и не собирается меняться.
Integration тестами мы покрываем геймплейную составляющую, которая сложна в реализации; баги в которой потенциально являются гейзенбагами или которая сложна для ручного тестирования.
Скажу честно, довольно странным кажется что при настроенном TeamCity и автоматизированном билде у вас совсем нет Unit Тестов (поправьте если я вас неправильно понял).
Как минимум, дельта-компрессию и ECS очень выгодно покрывать тестами, т.к. баги могут оказывать влияние на всю игру, а простора для ошибок много.
Подобных обзорных статей очень мало, а тех, с которыми хочется соглашаться в каждом пункте — только одна. Эта.
Мы используем очень похожий стек технологий и потратили кучу времени на подбор и поиск подходящих технологий. Я очень рад, что кто-то собрался и поделился этой информацией:)
Кстати, не знал про volatile physics. Это выглядит просто шикарно!
Он переопределит операцию сравнения вместо хеша, и у него неправильно будет работать код. Как это повлияет на работу программы?
Да как угодно:) В зависимости от того, как и зачем используется таблица:)
Согласен с вопросом. Написана дичь. Способ обхода надо выбирать в зависимости от того, как ни странно, в каком порядке вы желаете обойти граф! Внимание, любой граф, а не только дерево.
Да, это довольно интересно.
Вопрос тестирования стоит остро в геймдеве, как вы и сами знаете:)
И я не знаю никого (включая нас), кто умеет это дело правильно готовить. Так что было бы круто прочитать вашу точку зрения об этом.
Из-за низкой стабильности ТЗ, появляется требование к высокой скорости итераций. Так что современные движки (Unity, Unreal,...) поддерживают hot reload кода и через несколько секунд можно посмотреть на результат своей работы.
Да, полноценный билд проекта в standalone приложение занимает много времени. Но это требуется довольно редко и зачастую настраивается регулярная автоматическая сборка (например, раз в день).
Связано тем, что для быстрой проверки фичи эффективнее единоразово вручную оценить корректность по результату выполнения программы.
В общем, наверное вы правы и я считаю что в простых геймплейных фичах выгода тестов проявляется только в поиске регрессий.
Я считаю что любые тесты — попытка доказательства корректности кода.
И если формальный критерий корректности меняется слишком часто, тесты могут быть не выгодны.
Верно!
В том-то и дело что фича, казавшеяся разумной притерпевает значительные изменения в процессе исполнения.
В геймплее не так прозрачны бизнес-требования, как энтерпрайзе:)
В игровой индустрии пока не приняты многие нормы классической разработки.
Например, в геймдеве очень любили экономить на штуках типа виртуальных функций. Это дикость в мире энтерпрайза, но норма в мире разработки игр.
И на то есть масса причин, первопричина которых лежит самой сути игры:
1) Высокая производительность.
Игра должна выполнять симуляцию 60 кадров в секунду, т.е. 0.016 мс на кадр. Если вы подумаете обо всем том, что происходит в современных AAA играх, это обязано взорвать вам мозг.
Из этого вытекают такие отклонения как отсутствие DI контейнеров; Недостаточное разделение логики.
2) Игра — это Data-Driven приложение.
Код составляет лишь часть (и не всегда бОльшую часть) игры. И поведение зачастую определяется преимущественно настройками, а не кодом.
Это приводит к тому, что попытка Unit-тестировать компоненты, относящиеся к геймплею превращается в бесполезный сизифов труд. Ведь во-первых гораздо проще напортачить в настройке, чем в коде, а во-вторых придется замокать все взаимодействие со внешним окружением, что бывает проблематично.
3) Низкая стабильность ТЗ.
Очень редко можно предсказать качество геймплейного элемента до его воплощения в жизнь программистом.
В результате TDD подход, где тесты пишутся до логики, заставляет программиста писать тесты, которые будут выкинуты в тот же день.
Вот это у меня постоянно крутится на уме.
Мы покрываем Unit тестами глубинные части нашей архитектуры, которая плотно зафиксирована и не собирается меняться.
Integration тестами мы покрываем геймплейную составляющую, которая сложна в реализации; баги в которой потенциально являются гейзенбагами или которая сложна для ручного тестирования.
Скажу честно, довольно странным кажется что при настроенном TeamCity и автоматизированном билде у вас совсем нет Unit Тестов (поправьте если я вас неправильно понял).
Как минимум, дельта-компрессию и ECS очень выгодно покрывать тестами, т.к. баги могут оказывать влияние на всю игру, а простора для ошибок много.
Подобных обзорных статей очень мало, а тех, с которыми хочется соглашаться в каждом пункте — только одна. Эта.
Мы используем очень похожий стек технологий и потратили кучу времени на подбор и поиск подходящих технологий. Я очень рад, что кто-то собрался и поделился этой информацией:)
Кстати, не знал про volatile physics. Это выглядит просто шикарно!
Так он предупреждает. Отдельно говорит о встравивании предупреждений о том, что модель перестала работать.
А смотрите-ка, Телеграм пытаются блокировать, а спамботы с там-тамом захватывают посты про блокировки:)
Мне кажется, это неспроста:)
В ваших комметариях альтернативные варианты не просвечивают. А ничего кроме комментариев и не видно:)
А вы, стало быть, флора?)
Да, до меня тоже.
Я сначала подумал, что Синтакс Цукор — это как Jon Skeet:)
м.б. все же дискредитируют?)
Он переопределит операцию сравнения вместо хеша, и у него неправильно будет работать код. Как это повлияет на работу программы?
Да как угодно:) В зависимости от того, как и зачем используется таблица:)
Согласен с вопросом. Написана дичь. Способ обхода надо выбирать в зависимости от того, как ни странно, в каком порядке вы желаете обойти граф! Внимание, любой граф, а не только дерево.
Спасибо за переводы.
Сложно писать так чтобы легко читалось:)
Да, тяжело читать. Zanak достаточно адекватно ответил на широкий вопрос, который можно было интерпретировать тысячей способов:)
А такого вы и не увидите в книгах по алгоритмам.
Вы можете увидеть псевдокод RSA, можете увидеть декартово дерево. Но до 1500 строк там очень далеко:)