Нет, не отличается. В статье описан механизм компенсации лагов следующим образом:
Сервер оставляет стрелка в том положении, в котором он находится; а весь остальной мир меняет на то состояние, которое клиент отображал в момент выстрела, т.е. возвращает назад во времени.
Сервер обрабатывает выстрел и получает его результат.
Сервер возвращает весь мир в текущее состояние времени.
Сервер применяет результат выстрела и рассылает обновления по клиентам как обычно.
Т.е. сервер применяет результат выстрела уже в настоящем времени.
Да, это не честно по отношению к лагающим, но компенсация лага не для честности существует, а для того чтобы лагающие вообще могли играть и вешать хэдшоты.
Если хотите, можете применять выстрелы в прошлом, флаг вам в руки разбираться с применением ввода остальных игроков, потому что там нехилые временные парадоксы возникнуть могут. И иногда получаются настоящие петли времени, из которых не очень понятно как выходить.
Обычно речь идет о применении в настоящем времени, но рассчете в прошлом. Что плохого будет в противоположном случае?
Пусть есть игроки A, B и C. А выстрелил в B, но у него большой пинг. B выстрелил в C, его сигнал мгновенно дошел и игрок C умер, что и отобразилось на клиенте. Потом дошел сигнал от A, игрок B умер в прошлом, а значит C ожил. Выглядит как странный лаг.
Допустим, это не выстрел, а удар в рукопашной с последующей анимацией броска через спину с прогиба. Второго игрока надо телепортировать? «Эй, парень, ты тут уже полсекунды на земле лежишь, нажми кнопку встать!»
Поэтому обычно такое мощное взаимодействие не делают)
Глобально правила для многопользовательских игр такие: на один физически объект(положение и вращение) единовременно может влиять не более 1 игрока.
В противном случае пинг от 50 ощущается просто отвратительно сильно.
Медленнее?? Это очень неожиданное явление. Сомневаюсь, что это возможно, речь обычно идет о задержке, а не замедлении. Возможно вам начинают посылать пакеты более редко, так что движение визуально получается более гладкое, из-за этого и появляется ощущение замедленности.
Вот всей этой канители с оживаниями никто не делает. Если человек мертв в настоящий момент на сервере, пришедшая команда на выстрел уже не сработает.
Если игрок убит, он не будет воскрешен даже если выяснится, что его убийцу «убили» раньше.
А если рассматривать программные хаки, так гораздо удобнее для реализации предоставленных уязвимостей, скажем, отображать всех врагов вне зависимости от того, видны ли они. Все равно эта информация скорее всего доходит до клиента.
Или классический AutoAim, который по зажатию кнопки будет целиться в голову врага.
А это не имеет никакого отношения к механизму лагокомпенсации:)
Не знаю как для пуль(хоть скорее всего для них рейкаст пускают), а долго летящие проджектайлы, такие как баллистические снаряды, прогнозируются с помощью экстраполяции. Valve например вообще не заморачиваются с лаг компенсацией проджектайлов. пруф
Т.к. они и так не мгновенно летят, а значит каждый человек допускает возможность того, что он промахнулся)
А вам не хватает указанных техник, при которых игра играбельна даже при пинге в 2 секунды и обновлениях сервера раз в секунду?:)
Или вы имеете в виду альтернативы?
Да, разумеется так можно обмануть систему. Правда профита на практике немного выйдет. Максимальный пинг, который бы я поддерживал у себя на сервере — секунда. И то кратковременно. Как показывает практика, с пингом 500 играть просто нереально.
Вы успеете понять что надо делать по команде вашего друга за полсекунды? А ведь ваш друг еще должен тратить свой самый ценный ресурс — внимание на то чтобы следить за происходящим вокруг вас. На закуску. Скорость реакции среднего человека на внезапное событие 250 мс. Можете проверить вашу скорость реакции вот тут. Таким образом пока ваш друг отреагирует на событие + пока вы отреагируете на сообщение друга, пройдет в лучшем случае 500 мс. Знакомое число? И это мы считаем, что друг вас уколол иголкой, а не словами сказал.
А еще с пингом 500 играть банально не удобно. Обычно если два игрока отправляют команды на убийства друг друга, в живых остается тот, чья команда дошла до сервера быстрее.
Код демки находится в не самом лучшем состоянии. Так что его выкладывать не будем, а то научится кто-нибудь на свою голову. А вот вопрос о хостинге WebGL примера думаем.
Скорее всего слишком много ваших пакетов потерялось.
Интерполяция — это нахождение промежуточного положения между двумя крайними точками, так что она тут никак не поможет.
А экстраполяция не применяется в шутерах для положений персонажей.
Прочитайте предыдущую часть для более подробного объяснения.
Что значит «Интерполирует предыдущие состояния других игроков»? Клиент получает положение и вектора других игроков и расчитывает новое положение?
Интерполяция — это значит, что клиент, условно говоря, передвигает врага между двумя устаревшими кадрами.
Прочитайте предыдущую часть для более подробного объяснения.
Может быть такая ситуация. Стрелок целится в голову жертвы по версии стрелка. По версии жертвы она успела уйти в сторону. Как будет разруливаться такая ситуация? Тот кто раньше сообщил свое состояние (малый пинг) тот и полбедил?
Прочитайте и первую часть тоже. Сервер авторитарный. Что говорит сервер — то и правда.
Сервер для определения попадания откатывает время назад, так что если стрелок с точки зрения его клиента попал, он скорее всего попадет.
Сервер должен должен интерполировать состояние между кадрами, между которыми интерполирует игрок. Это не вполне одно и то же, так как буфер кадров для интерполяции может быть больше чем на два кадра:)
А вот интересно, при довольно сложном мире, где много объектов, которые могут на что-то влиять, как это осуществляют? Меняют ли состояние всех объектов? Или как-то выбирают те, которые могут влиять?
Очевидно, ответ зависит от конкретной ситуации. Если у вас шутер с комнатами по 15 человек и меняются только свойства игроков, можно смело откатывать весь мир.
Если у вас MMO с интерактивным миром, стоит откатить только небольшое окружение игрока.
Во-первых, обычно анимация смерти начинается только после получения стейта с сервера, где говорится, что игрок умер (обратите внимание, в нашей демке сделано именно так.)
А далее разные игры обрабатывают такие ситуации по разному:
Оба игрока умирают(т.к. оба игрока совершили выстрел пока еще были живы и оба попали в своего врага).
Игрок, команда которого дошла до сервера первой, остается вживых. Т.е. когда команда на выстрел доходит до сервера, сначала сервер проверяет, жив ли игрок в данный момент времени, и только если жив проводит рейкаст в прошлом.
В нашей реализации мы позволили себе отойти от описанного в статье и внедрили интерполяцию на сервере при выстреле. Так что даже при TickRate = 1 и простой траектории врага попадание было идеальным (хоть конечно и выглядело это отвратительно).
Я пожалуй опишу эту технику в этой статье.
Т.е. сервер применяет результат выстрела уже в настоящем времени.
Да, это не честно по отношению к лагающим, но компенсация лага не для честности существует, а для того чтобы лагающие вообще могли играть и вешать хэдшоты.
Если хотите, можете применять выстрелы в прошлом, флаг вам в руки разбираться с применением ввода остальных игроков, потому что там нехилые временные парадоксы возникнуть могут. И иногда получаются настоящие петли времени, из которых не очень понятно как выходить.
Пусть есть игроки A, B и C. А выстрелил в B, но у него большой пинг. B выстрелил в C, его сигнал мгновенно дошел и игрок C умер, что и отобразилось на клиенте. Потом дошел сигнал от A, игрок B умер в прошлом, а значит C ожил. Выглядит как странный лаг.
Поэтому обычно такое мощное взаимодействие не делают)
Глобально правила для многопользовательских игр такие: на один физически объект(положение и вращение) единовременно может влиять не более 1 игрока.
В противном случае пинг от 50 ощущается просто отвратительно сильно.
Если игрок убит, он не будет воскрешен даже если выяснится, что его убийцу «убили» раньше.
А если рассматривать программные хаки, так гораздо удобнее для реализации предоставленных уязвимостей, скажем, отображать всех врагов вне зависимости от того, видны ли они. Все равно эта информация скорее всего доходит до клиента.
Или классический AutoAim, который по зажатию кнопки будет целиться в голову врага.
А это не имеет никакого отношения к механизму лагокомпенсации:)
Но пока никаких годных материалов специализирующихся на гонках не видел.
Т.к. они и так не мгновенно летят, а значит каждый человек допускает возможность того, что он промахнулся)
Или вы имеете в виду альтернативы?
Вы успеете понять что надо делать по команде вашего друга за полсекунды? А ведь ваш друг еще должен тратить свой самый ценный ресурс — внимание на то чтобы следить за происходящим вокруг вас. На закуску. Скорость реакции среднего человека на внезапное событие 250 мс. Можете проверить вашу скорость реакции вот тут. Таким образом пока ваш друг отреагирует на событие + пока вы отреагируете на сообщение друга, пройдет в лучшем случае 500 мс. Знакомое число? И это мы считаем, что друг вас уколол иголкой, а не словами сказал.
А еще с пингом 500 играть банально не удобно. Обычно если два игрока отправляют команды на убийства друг друга, в живых остается тот, чья команда дошла до сервера быстрее.
Вместо полета пули выполняется один рейкаст, как бы предполагая что скорость пули бесконечна.
Интерполяция — это нахождение промежуточного положения между двумя крайними точками, так что она тут никак не поможет.
А экстраполяция не применяется в шутерах для положений персонажей.
Прочитайте предыдущую часть для более подробного объяснения.
Интерполяция — это значит, что клиент, условно говоря, передвигает врага между двумя устаревшими кадрами.
Прочитайте предыдущую часть для более подробного объяснения.
Прочитайте и первую часть тоже. Сервер авторитарный. Что говорит сервер — то и правда.
Сервер для определения попадания откатывает время назад, так что если стрелок с точки зрения его клиента попал, он скорее всего попадет.
Очевидно, ответ зависит от конкретной ситуации. Если у вас шутер с комнатами по 15 человек и меняются только свойства игроков, можно смело откатывать весь мир.
Если у вас MMO с интерактивным миром, стоит откатить только небольшое окружение игрока.
А далее разные игры обрабатывают такие ситуации по разному:
Я пожалуй опишу эту технику в этой статье.