Компенсация сетевых проблем
Для минимизации влияния пропускной способности и потери пакетов, по умолчанию многопользовательский движок передает данные до 30 раз в секунду. Игры, как правило, рендерятся со скоростью 60 кадров в секунду так что это означает, что данные передаются только примерно каждый второй кадр.
Компенсация для пиров
Пиры получают данные от хоста с указанием данных объекта, например, их позиции. Если они просто сразу отобразить, что было получено движение объекта то оно будет отображено рывками, на каждое обновление каждого второго кадра. Они также перемещались бы нерегулярно, по мере обновления разности в задержках и потерях пакетов.
Для того, чтобы улучшить игровой опыт мультиплеер движок [интерполирует] [4] значения между обновлениями для таких как Х и Y координаты. В случае позиций он будет линейно интерполировать между обновлениями. Например, если данные "перепрыгивают" через кадр, то кадр, который не получил обновлений будет использовать значение на полпути между двумя обновлениями обеих сторон. Это делает движение гладким без необходимости каких-либо дополнительных данных.
Однако рендеринг интерполированного кадра не означает, что известно следующее значение из будущего! Вместо машины времени многопользовательский движок решает эту проблему, добавив искусственную дополнительную задержку 80 мс для пиров. Это означает, что мультиплеер движок может знать о следующих нескольких обновлениях перед тем, что он в настоящее время рендерит. Даже если текущее обновление отсутствует из-за потери пакетов он может быть в состоянии использовать следующее обновление , чтобы интерполировать замену. Даже если плохие условия сети не позволяют обновления для 80 мс, движок может делать экстраполяцию от направления двух предыдущих обновлений. Однако это только догадки и объект может прыгать, если следующее обновление показывает, что объект на самом деле ушёл куда-то еще.
мультиплеер движок позволяет использовать три возможных режима интерполяции для значений: линейная (например, для позиции объекта), угловые (например, для углов объекта), и "none" (для данных, которые не должны быть интерполированы как логическое значение, указывающее, например лазер включен или нет).
изменения задержек
Следует отметить, что задержка может измениться. Например, устройство маршрутизации где-то может быть перегружено и данные между двумя игроками, внезапно становятся перенаправлены по другому пути, который медленнее; или, возможно, новый быстрый путь становится доступным. Задержки иногда могут постепенно уменьшаться в первые минуты после подключения, так как устройства на маршруте постепенно оптимизируют соединения и вычисляют самый быстрый возможный путь. Задержка постоянно переоценивается для обнаружения таких вариантов.
Если задержка уменьшается мультиплеер движок временно запускает игру в очень небольшой перемотке вперед, что уменьшает то, как далеко позади вы видите игру. С другой стороны, если задержка увеличивается движок незначительно замедляет игру в и увеличивает отставание. Это необходимо, чтобы избежать скачков движения, которые происходят при задержке свыше 80ms . Эти приспособления должны происходить достаточно медленно, чтобы быть незаметными и это помогает обеспечить наилучший опыт, даже если качество связи изменяется во время игры.
Компенсация хоста
Хост имеет авторитарную версию игры. Она имеет нулевую задержку так как нет необходимости передавать данные самому себе. Другими словами, хост принимает участие в "реальной" игре ,а пиры делают все возможное для отображения той же самой игры, борясь с задержками и, возможно, нерегулярными обновлениями от хоста. В результате хост имеет небольшое игровое преимущество.
Можно подумать, что хост должен был бы интерполировать между обновлениями позиций объекта, полученных от пиров. Этого не происходит потому, что пиры не должны говорить хосту, где они находятся. На самом деле, хост должен сказать пирам, где они находятся. Причина этого кроется в следующем разделе.
[page=" Предотвращение обмана Если бы пиры сообщали хосту, где они были и что делали в игре, и хост доверял им, пиры могли бы его обмануть. Они бы могли внезапно посылать данные, что они были на другой стороне стены или, что нападающий не смог их достичь и так далее. Чтобы избежать этого
пиры только сообщают хосту их вводные например, какие клавиши со стрелками они в настоящее время удерживают нажатыми. Хост получает это, начинает двигать этого игрока и передаёт данные обратно, сообщая игроку где их расположить."]
Предотвращение обмана
Если бы пиры сообщали хосту, где они были и что делали в игре, и хост доверял им, пиры могли бы его обмануть. Они бы могли внезапно посылать данные, что они были на другой стороне стены или, что нападающий не смог их достичь и так далее. Чтобы избежать этого пиры только сообщают хосту их вводные например, какие клавиши со стрелками они в настоящее время удерживают нажатыми. Хост получает это, начинает двигать этого игрока и передаёт данные обратно, сообщая игроку где их расположить.
Непосредственная проблема состоит в том, что это добавляет задержку ко всем вводным игрока. Если игрок нажимает "лево" с задержкой 100 мс, тогда это будет еще 100мс для обновления хоста с новой позицией игрока, чтобы получить обратно. Это означало бы, все элементы управления пира чувствуют себя очень заторможенно и выполняются только после значительной паузы. Чтобы решить эту проблему, локальная игра пира использует предсказание локального ввода .
Локальное предсказание ввода
Вместо того, чтобы нажав "влево" отправить сообщение на хост, говоря "была нажата", локальная игра этого игрока начинает двигать так или иначе не дожидаясь подтверждения от хоста! Так как хост и пир запустили одну игру, как правило, они совпадают довольно тесно. Так пир получает отзывчивый контроль, и не может обмануть хост: он только отправляет свои вводы и не может претендовать на другое место. Даже если он взломал локальную игру он может только показать себя в неправильном месте по сравнению с данными хоста.
Однако игрока пира неизбежно будет сносить от положения хоста. Есть много мелких ошибок, которые могут накапливаться в сетевом тайминге, частоте кадров синхронизации, измерения дельта-времени и так далее. Пир по-прежнему получает сообщения от хоста говорящие, где он находится, но сообщения задерживаются. В предыдущем примере, пир получает свою позицию от хоста с общей задержкой 200 мс. Для устранения отклонений, мультиплеер движок смотрит на историю объекта и сравнивает, где он был 200мс назад. Другими словами, делается поправка на прошлое, чтобы учесть задержку на хост. Если объект находится в неправильном месте, мультиплеер движок будет постепенно компенсировать его перемещение. Это происходит постепенно, чтобы попытаться сделать это менее заметным. В крайних случаях большая и заметная коррекция будет необходима, но при хороших условиях сети движения совпадают близко и небольшие изменения делаются таким образом, что их трудно обнаружить.
Стоит отметить, что это не ограничивается позиционированием. мультиплеер движок имеет возможность выполнять синхронизацию с любой переменной экземпляра, а не только с X и Y координатами.
Лаг
В условиях плохой сети могут быть очевидные эффекты в игровом процессе. Геймеры обычно называют эти проблемы "лаг". Он может включать в себя грубое движение (когда пуст буфер 80ms обновления), скачки или разрывы в игровом процессе (когда происходит потеря пакетов а при следующем обновлении существенно изменилось состояние игры), игрок вдруг изменяет положение (когда предсказание локального ввода совершает большую ошибку ) или последствия, которые являются игровой несправедливостью (в результате видения каждого игрока с различной задержкой, и авторитарного решения хоста в пользу одного конкретного игрока).
К сожалению, не существует хорошего решения, чтобы навсегда избежать этих проблем кроме как найти лучшее по качеству подключение к Интернету. Эти проблемы обычно возникают только в тяжелых условиях, таких как полная потеря пакетов в течение нескольких секунд или неожиданных и резких временных изменений задержки или PDV. В таких случаях практически невозможны различные методы компенсации, чтобы скрыть это. Иногда это просто реальность связи через Интернет.