Отклик только после ответа сервера (модель запрос-ответ) Request-response (no client-side feedback)

ID причины sy-request-response · Основной ответственный Команда разработки · Разработка клиента · Совместно Команда разработки · Разработка сервера

Открыть карточку в основной версии с иллюстрациями и экспериментами →

После нажатия кнопки нет ни анимации, ни звука, пока не придёт ответ сервера. Скорость отклика становится равна пингу.

Почему Умения, перемещение и подбор предметов проигрываются только после подтверждения сервера → Следствие С момента нажатия никакой реакции в течение пути туда и обратно плюс ожидания тика → На экране При пинге 150 ms каждое действие запаздывает примерно на 0,2 с

Симптомы: Задержка ввода
Факторы: Задержка
У кого: Только у меня
Когда: Всегда, При определённом действии
Ответственные: Основной ответственный Команда разработки · Разработка клиента · Совместно Команда разработки · Разработка сервера
Команда разработки: задачи: Клиент: анимацию, звук и эффекты запускать сразу при нажатии (опережающий фидбек), результат (урон, награду) показывать только после подтверждения сервера, перемещение и базовую атаку предсказывать и применять сразу, а получив от сервера коррекцию позиции, повторно применять от этой позиции ещё не подтверждённый ввод. Сервер: самому рассчитывать перемещение по полученному вводу и отправлять коррекцию, только если расхождение с позицией, предсказанной клиентом, превышает порог.
Цифры для ориентира: Время отклика ≈ пинг + половина интервала тика + один кадр. На 20-тиковом сервере при пинге 150 ms около 190 ms.
На графике: Высоко с самого начала · время от ввода до начала анимации, RTT (пинг)
Где смотреть: Писать в лог клиента в development-сборке время нажатия кнопки, начала первой анимации и звука и прихода ответа сервера и смотреть рядом с внутриигровым RTT. Менять пинг, добавляя задержку через эмуляцию сети в движке (Unreal NetEmulation.PktLag) или через tc netem в Linux на тестовом сервере, и замерять
Подтверждает: Анимация всегда начинается в момент прихода ответа сервера, время от ввода до анимации равно RTT плюс ожидание тика и растёт ровно на добавленную задержку
Опровергает: Если анимация начинается сразу при нажатии, а запаздывает только результат вроде цифр урона, архитектура нормальная. Если даже при низком пинге задержка больше интервала тика, это двойное ожидание тика или проблема с кадрами на клиенте
Чем проверить: Нужны логи и метрики игрового сервера или клиента
Подробнее: Для игр, где быстрая реакция не нужна (пошаговые, карточные, idle-игры), эта модель самая простая и надёжная. Проблема возникает, когда в игре с управлением в реальном времени так же сделаны перемещение и даже базовая атака.

Источники

Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
Клиент, который ждёт только результата от сервера, при задержке 500 ms показывает каждое действие лишь через 500 ms. Решается клиентским предсказанием и серверной коррекцией
Using Gameplay Abilities in Unreal Engine Epic Games
Local Predicted выполняется сразу при нажатии, а окончательно решает сервер. В Server Initiated предсказания нет, и тот, кто применяет способность, видит задержку
Understanding Networked Movement in the Character Movement Component for Unreal Engine Epic Games
Клиент предсказывает и сохраняет перемещения, сервер присылает коррекцию, только если ошибка превышает допуск (MAXPOSITIONERRORSQUARED), и после коррекции клиент повторно применяет сохранённые перемещения
Using Network Emulation in Unreal Engine Epic Games
Тестирование с минимальной и максимальной задержкой и долей потерь пакетов на сервере и клиенте, в консоли задаётся, например, как NetEmulation.PktLag
tc-netem(8) — Linux manual page iproute2
Инструмент для тестирования, который добавляет к исходящим пакетам задержку и джиттер (delay TIME JITTER) и потери (loss random PERCENT), имитируя реальную сеть

Смотрите также

Тот же слой: Архитектура синхронизации

Причины с тем же симптомом (Задержка ввода) на других слоях

Нагрузка на рендеринг при большом скоплении игроков L1 Процесс игрового клиента
Узкое место: обработка пакетов в главном потоке L1 Процесс игрового клиента
V-Sync и очередь рендеринга L1 Процесс игрового клиента
Энергосбережение и тепловой троттлинг L2 ОС и устройство клиента
Другие приложения на устройстве забирают пропускную способность L2 ОС и устройство клиента
Задержка дисплея, устройств ввода и генерации кадров L2 ОС и устройство клиента
Перегруженный радиоканал Wi-Fi L3 Домашняя сеть
Bufferbloat (очередь в роутере) L3 Домашняя сеть

Карточка в основной версии с иллюстрациями и экспериментами