Комментарии 19
1.А почему вы используете в input структуре такие емкие типы данных? Разве нельзя обрезать лишние байты?
- Насколько мне известно, в мобильной сети чаще происходят групповые ошибки. Поэтому, если потерялся какой-то пакет, то и следующие несколько с большой вероятностью потеряются. Получается, что повторную отсылку лучше выполнять с каким-то периодом. А если за это время придёт ответ от сервера, то вообще можно не выполнять.
- Почему вы не используете относительно временную метку?
- Вы предотвращает повторную пересылку ранних пакетов, когда сервер уже ответил на более поздний?
Такие типы данных использованы для удобства. Наш упаковщик данных режет лишние байты и биты. Если посмотрите на пример его вызова packer.PackUInt32((uint)((s.AimMagnitudeCompressed — min)/step), CalcFloatRangeBits(min, max, step)) — второй аргумент — это как раз количество значимых бит. В каждом компоненте мы помечаем допустимые значения, а автоматический генератор создаёт на основе этого оптимальный код для передачи по сети с использованием упаковщика.
По остальным вопросам:
- Размер серии вводов в пакете не превышает 200 байт. Потому следить за тем, что сервер уже получил, а чего нет, с точки зрения трафика, избыточно. Проще отправлять всё подряд и надеяться, что данные, сдублированные несколько раз рано или поздно будут доставлены. Если же нет, то тут либо дисконнект, либо слишком поздно досылать ввод. Сервер его уже все равно не примет.
- Относительно чего? Не совсем понял. Временная метка у нас только одна — номер тика симуляции.
- Нет. В этом случае сервер просто отбрасывает ввод игрока, т.к. если сервер обработал более поздний тик, чем клиент, значит клиенту надо подстроить свою локальную симуляцию под тики сервера так, чтобы опережать его на необходимое для досылки данных время. Этот процесс хорошо описан в нашей предыдущей статье.
Приятно читать и осознавать что все (кроме дельта-комперссии) сделано так же:D
На тему задержек: мы вот с такой проблемой сталкиваемся: у Wi-Fi роутера иногда случается буфферизация, которая на 0.1-0.4 секунды задерживает пакеты, а потом выдает их все пачкой. (Пакеты — UDP, проверяли с помощью wireshark)
Вроде причина такая: сети 2.4 GHz очень уж плотно населяют наш мир. И две точки на соседних каналах не могут говорить одновременно. Так что если кто-то посторонний начинает активно орать в эфир, наша точка стоит и ждёт своей очереди.
В пользу этой теории говорит тот факт, что подобных провисаний на роутере 5GHz не наблюдается.
Вы с таким сталкивались? Какое у вас решение этой проблемы?
Мы сталкивались с этой проблемой на ранних этапах и довольно быстро поняли, что если несколько пакетов не приходят подряд из-за сетевого уровня, то тут ничем не поможешь, кроме локального предсказания на клиенте, интерполяции и т.п. Всё это, по сути, клиентские уловки для маскировки задержек и лагов.
Единственное, что могу сказать — проблемы потери нескольких пакетов подряд при игре в реальных условиях (через мобильные сети, публичные wi-fi точки) — сильно преувеличены. Мы это видим на основе определённых данных, которые собираем в процессе тестирования. Если же wi-fi эфир действительно нагружен до предела, то все сетевые игры будут лагать. Как пример — на той же перегруженной wi-fi сети смотрели на Clash Royale и игра вела себя крайне нестабильно. Попробуйте поиграть в Overwatch на такого рода соединении.
… И хотя WebRTC позволяет удобно отправлять ненадёжные «беспорядочные» данные из браузера в браузер, он терпит крах, когда требуется передача данных между браузером и выделенным сервером.
Проблема возникает из-за чрезвычайной сложности WebRTC. Причины этой сложности понятны: WebRTC в первую очередь был разработан для обмена данными peer-to-peer между браузерами, поэтому для обхода NAT и передачи пакетов он в худшем случае требует поддержки STUN, ICE и TURN.
Всё верно. Мета серверы используют Java и соответствующий стек технологий. Об этом тоже планировали рассказать в будущих статьях.
developers.google.com/games/services/cpp/realtimeMultiplayer
Что-нибудь можете про него сказать?
Именно 200мс пинг? Разве региональные сервера эту проблему не решают?
Клиент-серверное взаимодействие в новом мобильном PvP-шутере и устройство игрового сервера: проблемы и решения