Мы стараемся как можно меньше использовать триггеры, потому
что они могут потеряться или дойти до адресата позже, чем мы хотим. Кроме того,
мы отказались от появления новых объектов во время игры — «спавн» происходит
только при старте. Это сильно упрощает сетевой код. Например, если игрок кидает
гранату, а мы «спавним» её в этот момент, то серверу нужно будет отправить
клиенту данные об этом.
В то же время, серверу придётся синхронизировать
информацию о местонахождении гранаты, пока она летит, однако на клиенте её ещё нет. То
есть до тех пор, пока клиент не пришлёт серверу подтверждение о том, что
граната «заспавнилась», её позицию нельзя будет синхронизировать. Это приводит
к визуальным багам.
А в чем суть статьи в разделе Про? По мне, вся статья - это два трюка весьма очевидных (про относительные координаты и желтку стрелку). В остальном какое-то описание UNet-а + три названия самописных класса.
Честно, ожидал большего.
Не дочитал до конца статью, но суть ясна. Подход не новый и называется в народе "Локстеп". По сути статью можно не читать - сразу идите на gafferongames.com. Там инфа по сетевому коду хорошо сложена
за последние 20 лет подходы к синхронизации вообще не изменились. Берете код Quake, читаете статью от Valve и смотрите на архитектуру Tribes. И вы все знаете
Комментарий недоступен
"То есть получая снапшоты, клиент проигрывает их не сразу, а, например, через 100 миллисекунд."
Это ведь получается что в сделали пинг минимум 100 ? Плюс задержки потери пакетов, сети и т.п - будет под 200 ?
Это интерполяция, а не задержка инпута. В том же CS интерполяция 100 мм. Индустриальный стандарт так сказать.
Хочется хоть каких-нибудь чисел - нагрузки на узлы кластера, отдельные машины, в целом кластер. Как тестировали на нагрузку, объем трафика и т.п.