Если стороны обмениваются только командой «иди сюда», а путь каждая сторона рассчитывает сама, то даже при небольшом расхождении персонаж или монстр идёт другим путём, а потом его утягивает на правильное место.
Почему При перемещении кликом и преследовании монстром отправляется только точка назначения, а путь клиент рассчитывает сам → Следствие Из-за различий в данных ландшафта, столкновений с другими персонажами или порядка расчёта объект идёт не тем путём, что на сервере → На экране Монстр проходит сквозь стену и вдруг перескакивает на другое место, персонаж после клика как бы скользит и меняет направление
Основной ответственный Команда разработки · Разработка сервера · Совместно Команда разработки · Разработка клиента
Команда разработки: задачи
Сервер: отправлять вместе с целью промежуточные точки пути (вейпоинты), периодически синхронизировать позицию. Клиент: плавно сводить расхождение, использовать те же данные ландшафта, что и сервер.
На графике
Случайные всплески · число и расстояние коррекций позиции по объектам
Где смотреть
Записывать для каждого объекта разницу между позицией от сервера и позицией, рассчитанной клиентом, и отмечать на карте точки, где происходили коррекции. Если периодически сравнивать контрольные суммы результатов расчёта пути или позиций с обеих сторон, можно найти момент, когда началось расхождение
Подтверждает
Коррекции сосредоточены на определённом рельефе (пороги, узкие проходы, склоны) или в людных местах и повторяются в тех же точках даже у игроков с нормальными сетевыми метриками
Опровергает
Если коррекции бывают где угодно, но только в моменты всплесков потерь и джиттера, проблема в подключении. Если один монстр одновременно дёргается на экранах нескольких игроков, проверить, не находится ли управление монстром у тормозящего клиента
Чем проверить
Нужны логи и метрики игрового сервера или клиента
Подробнее
Это одна из причин, почему игры с перемещением кликом и таб-таргетом малочувствительны к пингу. Однако одинаковый результат у обеих сторон не гарантирован, поэтому обязательно нужен механизм, который время от времени синхронизирует позицию. Результаты вычислений с плавающей точкой могут немного отличаться в зависимости от типа CPU, компилятора и его настроек оптимизации (в том числе между debug- и release-сборками). В схемах вроде lockstep и роллбэка, где стороны обмениваются только вводом и считают, что результаты расчёта у них совпадают, эти мелкие различия накапливаются, и состояние игры на двух экранах может разойтись (desync).
Источники
Deterministic LockstepGaffer On Games Даже если на одной машине расчёт детерминирован, на другом компиляторе, ОС или CPU результаты с плавающей точкой могут отличаться
State SynchronizationGaffer On Games Если отправлять вместе с вводом и состояние, стороны можно синхронизировать и без полного детерминизма
Peeking into VALORANT's NetcodeRiot Games При потерях пакетов или когда два персонажа пытаются встать в одну точку, симуляции сервера и клиента расходятся, и нужна коррекция
Floating Point DeterminismGaffer On Games Даже один и тот же код с плавающей точкой может давать разные результаты в зависимости от компилятора, архитектуры CPU и сборки (debug или release). Известен случай, когда CPU AMD и Intel выдавали немного разные значения трансцендентных функций
/fp (Specify floating-point behavior)Microsoft /fp:fast может менять порядок операций с плавающей точкой или объединять их, и результат будет отличаться от других настроек /fp, а операции, объединённые в FMA, тоже могут давать результат, отличный от раздельного умножения и сложения