Комментарии 7
Есть отличная статья, которая рассказывает о сетевой механике в Source. Затрагиваются такие проблемы, как интерполяция, лагокомпенсация, предсказание ввода. https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking:ru
Я бы еще рекомендовал видео с GDC о том как работает сетевой код в овервотч www.gdcvault.com/play/1024001/-Overwatch-Gameplay-Architecture-and
Мы вдохновлялись их идеями при разработке этого проекта
Мы вдохновлялись их идеями при разработке этого проекта
Странное решение с двумя разными движками. Неужели вы так не доверяете движкам на C++?
Тут довольно сложная ситуация.
Если исходить из того что нужно использовать один и тот же движок на клиенте и на сервере, то возникают следующие проблемы:
1) Если использовать PhysX Unity на клиенте, то мы не можем гарантировать что на сервере будет использоваться та же версия PhysX. Да Unity публикует данные о том какую версию PhysX они используют, но в той версии которую они поставляют с Unity вполне могут быть кастомные изменения для поддержки движка. Либо использовать Unity на сервере, но на мой взгляд это плохое решение.
2) Если не использовать PhysX, то появляется проблема портации C++ на мобильные платформы и интеграция его с Unity. Наш проект запускался одновременно под Android и iOS. Тратить несколько месяцев разработки на такую задачу, когда проект находится на стадии софт-лаунча, довольно рискованно.
К тому же, как я уже говорил, у нас довольно простая физика в игре, все что нам требовалось делать рейкасты и свипкасты.
Если исходить из того что нужно использовать один и тот же движок на клиенте и на сервере, то возникают следующие проблемы:
1) Если использовать PhysX Unity на клиенте, то мы не можем гарантировать что на сервере будет использоваться та же версия PhysX. Да Unity публикует данные о том какую версию PhysX они используют, но в той версии которую они поставляют с Unity вполне могут быть кастомные изменения для поддержки движка. Либо использовать Unity на сервере, но на мой взгляд это плохое решение.
2) Если не использовать PhysX, то появляется проблема портации C++ на мобильные платформы и интеграция его с Unity. Наш проект запускался одновременно под Android и iOS. Тратить несколько месяцев разработки на такую задачу, когда проект находится на стадии софт-лаунча, довольно рискованно.
К тому же, как я уже говорил, у нас довольно простая физика в игре, все что нам требовалось делать рейкасты и свипкасты.
На кой чёрт вам понадобилось делать симуляции на клиенте? Есть множество объектов, у каждого есть свои данные на текущий стейт, у тех данных которые меняются, должен быть значение-вектор изменений данных, который будет синхронизироваться, вся симуляция происходит на сервере для текущих данных, а в слепках «вектора изменений» для каждых данных в каждом тике за n-тиков с помощью них, можно вычислять все предыдущие стейты, для только текущих обрабатываемых данных клиента
Не понял ваш комментарий по поводу «вектора изменений».
Физика на клиенте нужна, для расчета предикшена локального игрока, в частности такие вещи как передвижение и ассист в системе прицеливания делаются на основе рейкастов. Более подробнее как работает сетевой код я писал в этой статье habr.com/ru/company/pixonic/blog/415959
Если же вы про то, зачем нам на клиенте хранить историю физики (UnityPhysicsHistorySlice). То в Production-билдах не зачем, вся история храниться в ECS. История физики нужна только для специального режима «локальной симуляции», когда клиент помимо собственно клиентского кода, еще эмулирует сервер. Это довольно сильно ускоряет прототипирование фичей, так как можно разрабатывать игровую логику, без редеплоя сервера.
Физика на клиенте нужна, для расчета предикшена локального игрока, в частности такие вещи как передвижение и ассист в системе прицеливания делаются на основе рейкастов. Более подробнее как работает сетевой код я писал в этой статье habr.com/ru/company/pixonic/blog/415959
Если же вы про то, зачем нам на клиенте хранить историю физики (UnityPhysicsHistorySlice). То в Production-билдах не зачем, вся история храниться в ECS. История физики нужна только для специального режима «локальной симуляции», когда клиент помимо собственно клиентского кода, еще эмулирует сервер. Это довольно сильно ускоряет прототипирование фичей, так как можно разрабатывать игровую логику, без редеплоя сервера.
На кой чёрт вам понадобилось делать симуляции на клиенте?Действительно есть ММО и MOBA игры, которые не используют симуляцию на клиенте (самым ярким примером можно привести Dota 2, где нет предсказания ввода — инпут отправляется на сервер, сервер производит симуляцию, результат (дельта изменений) присылается клиенту — по итогу в случае лага игра «застывает», произвести реверс игровой логики можно только создав карту и став хостом).
Роль симуляции на клиенте выше обозначил автор — это «предикшен локального клиента», то есть предсказание ввода — говоря проще, в играх с быстрым геймплеем (например шутер) клиент не ждет ответа от сервера, чтобы передвинуть сущность игрока или произвести выстрел, он самостоятельно просчитывает логику передвижения (физику) игрока, которая будет просчитана позже и сервером, когда запрос клиента дойдет до него.
При реверсе игр Apex Legend / PUBG можно в том или ином виде увидеть очередь инпутов, размер которой динамически изменяется в зависимости от состояния сети, и timeline произведенных предсказаний — если полученные от сервера данные не сошлись (клиент не просчитал определенные факторы, например оглушение) с данными в timeline, производится rollback — начиная с последнего полученного от сервера фрейма данных идет повторная симуляция вплоть до текущего фрейма клиента.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Физика для мобильного PvP шутера, или как мы из двумерной игру в трёхмерную переделывали