Синхронизация физики — сложная задача, которая не имеет однозначного решения.
Проблемы проистекают из парадокса: игроки должны быть в одном(синхронизированном) мире; результат ввода каждого игрока должен ему отображаться мгновенно; но игроки разнесены во времени пингом. Так что если два человека умеют воздействовать на один и тот же объект, этот парадокс покажется во всей красе, заставляя предмет телепортироваться в пространстве или резко менять направление движения.
Впрочем, если воздействие на колесо это действие «взорвать машину», это вполне можно синхронизировать.
А вот гильзы хоть и можно синхронизировать, так делать не стоит. Это только засорит трафик.
Если у вас все в порядке с английским, прочитайте комментарии. Тут было дано немало полезных ссылок.
Если же английский для вас проблема — подписывайтесь на меня и ждите дальнейших статей:)
Пока что речь шла только про многопользовательскую игру, по сути, с одним игроком. И рассматривался только вопрос синхронизации состояния сервера и состояния клиента с оговоркой, что сервер авторитарный.
Для такой ситуации описанная схема, пожалуй, самая адекватная. Если клиент не отправлял некорректного ввода и у игрока относительно адекватное соединение, поведение персонажа ничем не будет отличаться от сингл плеера. Никакого лага, никаких задержек, никаких неожиданностей.
В дальнейших статьях будут рассмотрены методы взаимодействия с другими игроками. Если говорить более предметно, речь пойдет об интерполяции позиций врагов.
В гоночных играх действительно правильнее использовать экстраполяцию, т.к. машины обладают большой массой и, как следствие, инерцией.
А вот в шутерах зачастую бывают совершенно непредсказуемые траектории, которые с результатом экстраполяции разойдутся очень быстро и в итоге мы получим весьма заметную погрешность.
А с чем серверу сравнивать команды? Пересылать их от других клиентов серверу и сравнивать показания?)
Не сложно понять, что количество запросов на сервер будет возрастать квадратично. Да и нельзя верить командам от других клиентов.
Это правда. И такая ситуация действительно выглядит нечестной для убитого игрока. Но это максимум честности, который только можно предоставить. Думаю, вы в этом убедитесь в четвертой статье.
Это просто только первые статьи из серий. Конечно же тут покрываются только самые базовые техники.
Но решений пространственно-временного парадокса действительно не так уж и много. Хотя простора для локальных улучшений просто тьма)
Т.е. отправлять команды не только на сервер, но и другим игрокам? Забавно.
Но есть несколько проблем.
Основная проблема, как мне кажется, в ненадежности клиента — он может на сервер отправлять одни команды, а игрокам — другие, тем самым усложняя задачу своим соперникам.
Есть и еще проблемы. Например, компенсация лага, о которой я буду говорить в четвертой статье, будет неприменима в такой игре.
А, ну понятно. Да, в играх завязанных на постоянных взаимодействиях с физикой увы никак не разрешить проблему того, что игроки на самом деле разнесены по времени пингом и это всегда заметно.
Основной ужас таких механик в том, что даже при пинге 50 мс, оружия с долгой перезарядкой, большим уроном и точечной областью применения(Railgun какой-нибудь) становятся жутко неудобными.
Дело в том, что в тот момент, когда игрок выстрелит на сервере, персонаж врага уже убежит с того места, где он был.
Впрочем, тема откатывания состояния сервера будет раскрыта только в заключительной статье.
Проспойлерю, что идеального решения не существует. Причина этого в том, что любые два игрока находятся друг от друга на «расстоянии» в сумму их пингов.
Таким образом если результат действия первого игрока мгновенен, второй игрок на его клиенте еще находится в состоянии из прошлого. Что порождает парадоксы, т.к. хоть на самом деле игроки разделены во времени, мы стараемся делать вид, что они находятся совсем рядом.
Скорее всего это связано с тем, что механизмы компенсации, о которых будет идти речь позже, неприменимы(или плохо применимы) к играм, где на физику одного объекта влияют несколько игроков.
Таким образом вероятно в Rocket League все ваши действия выполняются с задержкой, равной вашему пингу.
Вот этот потрясающий разработчик иногда разбирает сетевые механики популярных игр.
Например тут он рассказывает про Overwatch.
Обновления от сервера к клиенту идут от 20 до 60 раз в секунду обычно. Чем чаще идут обновления — тем комфортней играть, но за счет техник согласования с сервером и локального предсказания, разница между 20 Hz и 60 не очень заметна, а нагрузка на сервера очевидно возрастает.
Проблемы проистекают из парадокса: игроки должны быть в одном(синхронизированном) мире; результат ввода каждого игрока должен ему отображаться мгновенно; но игроки разнесены во времени пингом. Так что если два человека умеют воздействовать на один и тот же объект, этот парадокс покажется во всей красе, заставляя предмет телепортироваться в пространстве или резко менять направление движения.
Впрочем, если воздействие на колесо это действие «взорвать машину», это вполне можно синхронизировать.
А вот гильзы хоть и можно синхронизировать, так делать не стоит. Это только засорит трафик.
Все зависит от компании.
Если же английский для вас проблема — подписывайтесь на меня и ждите дальнейших статей:)
Для такой ситуации описанная схема, пожалуй, самая адекватная. Если клиент не отправлял некорректного ввода и у игрока относительно адекватное соединение, поведение персонажа ничем не будет отличаться от сингл плеера. Никакого лага, никаких задержек, никаких неожиданностей.
В дальнейших статьях будут рассмотрены методы взаимодействия с другими игроками. Если говорить более предметно, речь пойдет об интерполяции позиций врагов.
В гоночных играх действительно правильнее использовать экстраполяцию, т.к. машины обладают большой массой и, как следствие, инерцией.
А вот в шутерах зачастую бывают совершенно непредсказуемые траектории, которые с результатом экстраполяции разойдутся очень быстро и в итоге мы получим весьма заметную погрешность.
Не сложно понять, что количество запросов на сервер будет возрастать квадратично. Да и нельзя верить командам от других клиентов.
Ждите!)
Но решений пространственно-временного парадокса действительно не так уж и много. Хотя простора для локальных улучшений просто тьма)
Но есть несколько проблем.
Основная проблема, как мне кажется, в ненадежности клиента — он может на сервер отправлять одни команды, а игрокам — другие, тем самым усложняя задачу своим соперникам.
Есть и еще проблемы. Например, компенсация лага, о которой я буду говорить в четвертой статье, будет неприменима в такой игре.
Дело в том, что в тот момент, когда игрок выстрелит на сервере, персонаж врага уже убежит с того места, где он был.
Впрочем, тема откатывания состояния сервера будет раскрыта только в заключительной статье.
Таким образом если результат действия первого игрока мгновенен, второй игрок на его клиенте еще находится в состоянии из прошлого. Что порождает парадоксы, т.к. хоть на самом деле игроки разделены во времени, мы стараемся делать вид, что они находятся совсем рядом.
https://habrahabr.ru/post/302394/#comment_9638810
Таким образом вероятно в Rocket League все ваши действия выполняются с задержкой, равной вашему пингу.
Вот этот потрясающий разработчик иногда разбирает сетевые механики популярных игр.
Например тут он рассказывает про Overwatch.
Обновления от сервера к клиенту идут от 20 до 60 раз в секунду обычно. Чем чаще идут обновления — тем комфортней играть, но за счет техник согласования с сервером и локального предсказания, разница между 20 Hz и 60 не очень заметна, а нагрузка на сервера очевидно возрастает.