Да, ввод понятно что дублируете:)
Т.е. если я правильно понял, при потере 1 пакета состояния мира, вы не можете применить состояние на клиенте в течение еще 1 RTT?
т.к. клиент должен отправить на сервер nack, и только после этого сервер перепошлет потеряный пакет?
Вот вы говорите что у вас мобильная игра, а потом говорите про дельта-компрессию.
Как вы справляетесь с потерей пакетов? Избыточно перепосылаете состояние мира несколько раз?
Прям детерменизм нужен только если есть объекты которые очень редко обновляются (и то обычно они редко обновляются т.к. игрок их не видит, а значит и хрен с ним с недетерменизмом).
А так да, много раз в секунду отправляется все состояние мира.
Забавно кстати что вы это решили включить в ECS:)
Кажется что интерполяция, сериализация и ECS — три разные вещи, а у вас они вместе лежат.
Кстати, у меня вот какой вопрос:
Своего игрока, как известно, надо экстрополировать (ну т.е. client-side prediction).
А вражеских игроков надо интерполировать.
Как у вас это разделение реализовано в концепции систем?
А еще: при выстреле вы наверняка используете Lag Compensation. Для этого надо откатывать во времени назад всех, кроме стрелка. Так что тут аналогичный вопрос. Или вы откатываете только физику, а поля компонент оставляете теми же?
P.S. если кто-то не понимает о чем я тут говорю, тут можно прочитать.
Скажите пожалуйста, а как вы применяете команды (пользовательский ввод) в системах?
Удобно ли пользоваться подходом "все есть компонент" и в случае с "событием" Dead? Или все же есть ощущение что не хватает более callback ориентированного подхода?
Забавный факт №1: я вас не минусил.
Забавный факт №2: если вы в ветке про дискриминацию оставляете односложный комментарий, выглядещий как "The MeToo movement is an international movement against sexual harassment and assault.", не ожидайте что кто-то использует менее очевидную интерпретацию ваших слов.
Да, это довольно интересно.
Вопрос тестирования стоит остро в геймдеве, как вы и сами знаете:)
И я не знаю никого (включая нас), кто умеет это дело правильно готовить. Так что было бы круто прочитать вашу точку зрения об этом.
Из-за низкой стабильности ТЗ, появляется требование к высокой скорости итераций. Так что современные движки (Unity, Unreal,...) поддерживают hot reload кода и через несколько секунд можно посмотреть на результат своей работы.
Да, полноценный билд проекта в standalone приложение занимает много времени. Но это требуется довольно редко и зачастую настраивается регулярная автоматическая сборка (например, раз в день).
В игровой индустрии пока не приняты многие нормы классической разработки.
Например, в геймдеве очень любили экономить на штуках типа виртуальных функций. Это дикость в мире энтерпрайза, но норма в мире разработки игр.
И на то есть масса причин, первопричина которых лежит самой сути игры:
1) Высокая производительность.
Игра должна выполнять симуляцию 60 кадров в секунду, т.е. 0.016 мс на кадр. Если вы подумаете обо всем том, что происходит в современных AAA играх, это обязано взорвать вам мозг.
Из этого вытекают такие отклонения как отсутствие DI контейнеров; Недостаточное разделение логики.
2) Игра — это Data-Driven приложение.
Код составляет лишь часть (и не всегда бОльшую часть) игры. И поведение зачастую определяется преимущественно настройками, а не кодом.
Это приводит к тому, что попытка Unit-тестировать компоненты, относящиеся к геймплею превращается в бесполезный сизифов труд. Ведь во-первых гораздо проще напортачить в настройке, чем в коде, а во-вторых придется замокать все взаимодействие со внешним окружением, что бывает проблематично.
3) Низкая стабильность ТЗ.
Очень редко можно предсказать качество геймплейного элемента до его воплощения в жизнь программистом.
В результате TDD подход, где тесты пишутся до логики, заставляет программиста писать тесты, которые будут выкинуты в тот же день.
Вот это у меня постоянно крутится на уме.
Мы покрываем Unit тестами глубинные части нашей архитектуры, которая плотно зафиксирована и не собирается меняться.
Integration тестами мы покрываем геймплейную составляющую, которая сложна в реализации; баги в которой потенциально являются гейзенбагами или которая сложна для ручного тестирования.
Скажу честно, довольно странным кажется что при настроенном TeamCity и автоматизированном билде у вас совсем нет Unit Тестов (поправьте если я вас неправильно понял).
Как минимум, дельта-компрессию и ECS очень выгодно покрывать тестами, т.к. баги могут оказывать влияние на всю игру, а простора для ошибок много.
Подобных обзорных статей очень мало, а тех, с которыми хочется соглашаться в каждом пункте — только одна. Эта.
Мы используем очень похожий стек технологий и потратили кучу времени на подбор и поиск подходящих технологий. Я очень рад, что кто-то собрался и поделился этой информацией:)
Кстати, не знал про volatile physics. Это выглядит просто шикарно!
Да, ввод понятно что дублируете:)
Т.е. если я правильно понял, при потере 1 пакета состояния мира, вы не можете применить состояние на клиенте в течение еще 1 RTT?
т.к. клиент должен отправить на сервер nack, и только после этого сервер перепошлет потеряный пакет?
Да, это мне все понятно. Непонятно только как системы отличают локального игрока и не локального:)
В общем ок, жду следующей статьи.
Ок, понятно.
Мы примерно из тех же соображений слили воедино сериализацию и дупликацию объектов:) Правда интерполяция у нас немного в стороне.
Вот вы говорите что у вас мобильная игра, а потом говорите про дельта-компрессию.
Как вы справляетесь с потерей пакетов? Избыточно перепосылаете состояние мира несколько раз?
Прям детерменизм нужен только если есть объекты которые очень редко обновляются (и то обычно они редко обновляются т.к. игрок их не видит, а значит и хрен с ним с недетерменизмом).
А так да, много раз в секунду отправляется все состояние мира.
Забавно кстати что вы это решили включить в ECS:)
Кажется что интерполяция, сериализация и ECS — три разные вещи, а у вас они вместе лежат.
Кстати, у меня вот какой вопрос:
Своего игрока, как известно, надо экстрополировать (ну т.е. client-side prediction).
А вражеских игроков надо интерполировать.
Как у вас это разделение реализовано в концепции систем?
А еще: при выстреле вы наверняка используете Lag Compensation. Для этого надо откатывать во времени назад всех, кроме стрелка. Так что тут аналогичный вопрос. Или вы откатываете только физику, а поля компонент оставляете теми же?
P.S. если кто-то не понимает о чем я тут говорю, тут можно прочитать.
Скажите пожалуйста, а как вы применяете команды (пользовательский ввод) в системах?
Удобно ли пользоваться подходом "все есть компонент" и в случае с "событием" Dead? Или все же есть ощущение что не хватает более callback ориентированного подхода?
Забавный факт №1: я вас не минусил.
Забавный факт №2: если вы в ветке про дискриминацию оставляете односложный комментарий, выглядещий как "The MeToo movement is an international movement against sexual harassment and assault.", не ожидайте что кто-то использует менее очевидную интерпретацию ваших слов.
Как вы тут захарраситься умудрились?
Здорово что вы делаете свой вклад в opensource.
Да, это довольно интересно.
Вопрос тестирования стоит остро в геймдеве, как вы и сами знаете:)
И я не знаю никого (включая нас), кто умеет это дело правильно готовить. Так что было бы круто прочитать вашу точку зрения об этом.
Из-за низкой стабильности ТЗ, появляется требование к высокой скорости итераций. Так что современные движки (Unity, Unreal,...) поддерживают hot reload кода и через несколько секунд можно посмотреть на результат своей работы.
Да, полноценный билд проекта в standalone приложение занимает много времени. Но это требуется довольно редко и зачастую настраивается регулярная автоматическая сборка (например, раз в день).
Связано тем, что для быстрой проверки фичи эффективнее единоразово вручную оценить корректность по результату выполнения программы.
В общем, наверное вы правы и я считаю что в простых геймплейных фичах выгода тестов проявляется только в поиске регрессий.
Я считаю что любые тесты — попытка доказательства корректности кода.
И если формальный критерий корректности меняется слишком часто, тесты могут быть не выгодны.
Верно!
В том-то и дело что фича, казавшеяся разумной притерпевает значительные изменения в процессе исполнения.
В геймплее не так прозрачны бизнес-требования, как энтерпрайзе:)
В игровой индустрии пока не приняты многие нормы классической разработки.
Например, в геймдеве очень любили экономить на штуках типа виртуальных функций. Это дикость в мире энтерпрайза, но норма в мире разработки игр.
И на то есть масса причин, первопричина которых лежит самой сути игры:
1) Высокая производительность.
Игра должна выполнять симуляцию 60 кадров в секунду, т.е. 0.016 мс на кадр. Если вы подумаете обо всем том, что происходит в современных AAA играх, это обязано взорвать вам мозг.
Из этого вытекают такие отклонения как отсутствие DI контейнеров; Недостаточное разделение логики.
2) Игра — это Data-Driven приложение.
Код составляет лишь часть (и не всегда бОльшую часть) игры. И поведение зачастую определяется преимущественно настройками, а не кодом.
Это приводит к тому, что попытка Unit-тестировать компоненты, относящиеся к геймплею превращается в бесполезный сизифов труд. Ведь во-первых гораздо проще напортачить в настройке, чем в коде, а во-вторых придется замокать все взаимодействие со внешним окружением, что бывает проблематично.
3) Низкая стабильность ТЗ.
Очень редко можно предсказать качество геймплейного элемента до его воплощения в жизнь программистом.
В результате TDD подход, где тесты пишутся до логики, заставляет программиста писать тесты, которые будут выкинуты в тот же день.
Вот это у меня постоянно крутится на уме.
Мы покрываем Unit тестами глубинные части нашей архитектуры, которая плотно зафиксирована и не собирается меняться.
Integration тестами мы покрываем геймплейную составляющую, которая сложна в реализации; баги в которой потенциально являются гейзенбагами или которая сложна для ручного тестирования.
Скажу честно, довольно странным кажется что при настроенном TeamCity и автоматизированном билде у вас совсем нет Unit Тестов (поправьте если я вас неправильно понял).
Как минимум, дельта-компрессию и ECS очень выгодно покрывать тестами, т.к. баги могут оказывать влияние на всю игру, а простора для ошибок много.
Подобных обзорных статей очень мало, а тех, с которыми хочется соглашаться в каждом пункте — только одна. Эта.
Мы используем очень похожий стек технологий и потратили кучу времени на подбор и поиск подходящих технологий. Я очень рад, что кто-то собрался и поделился этой информацией:)
Кстати, не знал про volatile physics. Это выглядит просто шикарно!
Так он предупреждает. Отдельно говорит о встравивании предупреждений о том, что модель перестала работать.
А смотрите-ка, Телеграм пытаются блокировать, а спамботы с там-тамом захватывают посты про блокировки:)