Интерполировать между двумя сетевыми состояниями?

11

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

Я хотел бы знать, как я могу интерполировать между состояниями, чтобы они оказались в правильном положении. Я знаю, где игрока последний раз видели и его текущая скорость, но интерполяция до последнего увиденного состояния заставляет игрока фактически двигаться назад. Я вообще не мог использовать скорость для других клиентов и просто «подталкивал» их в нужном направлении, но я чувствую, что это вызовет неровное движение. Какие есть альтернативы?

c# movement interpolation Вон Хилтс
источник

Ответы:

9

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

Поищите в этой статье все примеры слова «впереди», и я думаю, вы начнете получать картину лучше, чем я, возможно, объяснил выше.

инженер
источник
Итак, вы намекаете на то, что я действительно должен рендерить игрока, как это было 300 мс назад, и интерполировать в будущее? (В отдельном состоянии, когда появится новое состояние; это поменяется)
Вон Хилтс
@VaughanHilts Опять же, пожалуйста, прочитайте статью и комментарии. Гаффер - эксперт в этой области, и он объясняет это гораздо яснее, чем я. Но общая идея заключается в том, что да, ваша имитационная модель впереди, а ваш рендеринг отстает от этого, чтобы учесть эффект, который вы описали. Это далеко не единственное место, где я видел описанную технику.
инженер
2

Когда ты сказал:

эти игроки начинают рассинхронизироваться через некоторое время

это заставляет меня думать, что ваша проблема может быть больше связана с тем, что ваши часы выходят из строя, чем с какими-либо задержками. Если это задержка, она должна быть такой же плохой на старте, как и через 10 минут. Если одни игровые часы будут работать немного быстрее, чем другие, будут некоторые странные артефакты дрожания, которые со временем будут становиться все хуже и хуже. Клиент может симулировать в будущем, когда текущие пакеты поступают с сервера, он оттягивает клиента назад, заставляя объекты перепрыгивать. Запустите еще несколько тестов, чтобы узнать.

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

Джон Макдональд
источник
Дело обстоит не так, дело в том, что я действительно считаю слишком далеко (скачок задержки или что-то в этом духе - пакет для остановки) не получен вовремя, и клиент не может исправить себя вовремя. Я это точно знаю дело в том, что после того, как клиент остановился, я могу DEFINTELAY интерполировать обратно в позицию
Вон Хилтс