Лаг (видеоигры)

В компьютерах лаг — это задержка ( латентность ) между действием пользователя ( вводом) и реакцией сервера, поддерживающего задачу , которую необходимо отправить обратно клиенту .

Способность игрока переносить задержку зависит от типа игры, в которую он играет. Например, стратегическая игра или пошаговая игра с медленным темпом может иметь высокий порог или даже практически не подвергаться воздействию высокой задержки. Играм с дергающимся игровым процессом, таким как шутер от первого лица или файтинг со значительно более быстрым темпом, может потребоваться значительно меньшая задержка для обеспечения удовлетворительного игрового процесса .

Внутриигровое отображение скорости задержки иногда называют лагометром .

Время пинга

Время пинга — это задержка в сети для прохождения туда и обратно игрока между клиентом и игровым сервером , измеренная с помощью утилиты ping или ее эквивалента. Время пинга — это среднее время, измеряемое в миллисекундах (мс). Чем ниже пинг, тем меньше задержка и тем меньше задержек будет испытывать игрок. Термины «высокий пинг» и «низкий пинг» обычно используются в онлайн-играх, где высокий пинг означает пинг, вызывающий значительную задержку; Хотя любой уровень пинга может вызвать задержку, о серьезной задержке обычно свидетельствует пинг более 100 мс. Это использование представляет собой игровой культурный разговорный язык и нечасто встречается и не используется в профессиональных компьютерных сетевых кругах. В играх, где время имеет решающее значение, таких как шутеры от первого лица и стратегии в реальном времени , всегда желателен низкий пинг, поскольку низкий пинг означает более плавный игровой процесс , позволяя быстрее обновлять игровые данные между клиентами игроков и игровым сервером.

Высокая задержка может вызвать задержку. Игровые серверы могут отключить клиента, если задержка слишком велика, что может нанести ущерб игровому процессу других игроков. Аналогично, клиентское программное обеспечение часто требует отключения, если задержка слишком велика. Высокий пинг также может привести к сбою серверов из-за нестабильности.

В некоторых шутерах от первого лица высокий пинг может привести к тому, что игрок непреднамеренно получит несправедливые преимущества, например, исчезнет из одного места и мгновенно появится в другом, имитируя эффект телепортации, что затрудняет другим игрокам оценку поведения своего персонажа. позицию и, как следствие, сделать игрока более трудным для нацеливания. Чтобы противостоять этому, многие игровые серверы автоматически выкидывают игроков с пингом выше среднего. И наоборот, высокий пинг может сильно затруднить игроку игру из-за возникающих негативных эффектов, затрудняя отслеживание других игроков и даже перемещение своего персонажа.

Вместо использования традиционных ICMP эхо-запроса и ответа сетевых пакетов для определения времени пинга программисты видеоигр часто встраивают собственное обнаружение задержки в существующие игровые пакеты (обычно на основе протокола UDP ).

Некоторые факторы, которые могут повлиять на пинг, включают: протокол связи используемый , пропускную способность Интернета (скорость соединения), качество интернет-провайдера пользователя и конфигурацию брандмауэров . На пинг также влияет географическое положение. Например, если кто-то находится в Индии и играет на сервере, расположенном в Соединенных Штатах, расстояние между ними больше, чем для игроков, находящихся в США, и поэтому передача данных занимает больше времени. Однако количество коммутационного и сетевого оборудования между двумя компьютерами часто бывает более значительным. Например, карты беспроводного сетевого интерфейса должны модулировать цифровые сигналы в радиосигналы , что часто обходится дороже, чем время, необходимое электрическому сигналу для прохождения типичного участка кабеля. Таким образом, более низкий пинг может привести к более высокой скорости загрузки и выгрузки через Интернет.

Причины

Упрощенная архитектура игры

В то время как однопользовательская игра сохраняет основное состояние игры на локальном компьютере, онлайн-игра требует, чтобы оно поддерживалось на центральном сервере, чтобы избежать несогласованности между отдельными клиентами. Таким образом, клиент не имеет прямого контроля над центральным состоянием игры и может только отправлять запросы на изменение на сервер и может обновлять локальное состояние игры только путем получения обновлений с сервера. Эта потребность в общении вызывает задержку между клиентами и сервером и является основной причиной задержки. Хотя может быть множество основных причин, по которым игрок испытывает задержку, их можно резюмировать как недостаточное оборудование на клиенте или сервере или плохое соединение между клиентом и сервером.

Проблемы, связанные с оборудованием, вызывают задержку из-за фундаментальной структуры игровой архитектуры. Обычно игры состоят из зацикленной последовательности состояний или «кадров». В течение каждого кадра игра принимает ввод пользователя и выполняет необходимые вычисления (ИИ, графика и т. д.). Когда вся обработка будет завершена, игра обновит состояние игры и выдаст выходные данные, например новое изображение на экране и/или пакет для отправки на сервер. Частоту, с которой генерируются кадры, часто называют частотой кадров и задержкой (видеоигры), поскольку центральное состояние игры находится на сервере, обновленная информация должна отправляться с клиента на сервер, чтобы она вступила в силу. Кроме того, клиент должен получить необходимую информацию от сервера, чтобы полностью обновить состояние. Генерация пакетов для отправки на сервер и обработка полученных пакетов могут выполняться только до тех пор, пока клиент может обновлять свое локальное состояние. Хотя теоретически пакеты могут генерироваться и отправляться быстрее, это приведет к отправке избыточных данных только в том случае, если состояние игры не может быть обновлено между каждым пакетом. Таким образом, низкая частота кадров сделает игру менее отзывчивой на обновления и может заставить ее пропускать устаревшие данные.

И наоборот, то же самое справедливо и для сервера. Частота кадров (или тактовая частота) сервера определяет, как часто он может обрабатывать данные от клиентов и отправлять обновления. Проблемы такого типа трудно предсказать и компенсировать. Помимо соблюдения минимальных требований к оборудованию и попыток оптимизировать игру для повышения производительности, реальных способов справиться с этим не существует.

Возможно, наиболее распространенный тип задержек вызван проблемами с производительностью сети . Потери , повреждение или дрожание (устаревший пакет фактически является потерей) — все это может вызвать проблемы, но эти проблемы относительно редки в сети с достаточной пропускной способностью и отсутствием или небольшой перегрузкой . Вместо этого значительную роль играет задержка, связанная с передачей данных между клиентами и сервером. Задержка варьируется в зависимости от ряда факторов, таких как физическое расстояние между конечными системами, поскольку большее расстояние означает дополнительную длину передачи и требуемую маршрутизацию и, следовательно, более высокую задержку. Маршрутизация через Интернет может быть крайне непрямой, что приводит к гораздо большей длине передачи (и, как следствие, к задержке), чем прямой маршрут, хотя сервис облачных игр OnLive разработал решение этой проблемы, установив пиринговые отношения с несколькими сетевыми интернет-провайдерами уровня 1. и выбор оптимального маршрута между сервером и пользователем. Кроме того, недостаточная пропускная способность и перегрузка, даже если она не настолько серьезна, чтобы привести к потерям, могут вызвать дополнительные задержки независимо от расстояния. Как и в случае с аппаратными проблемами, пакеты, которые доставляются медленно или не доставляются вообще, не позволяют как клиенту, так и серверу своевременно обновлять состояние игры.

Системы онлайн-игр, использующие беспроводную сеть, могут работать со значительной задержкой в ​​зависимости от архитектуры беспроводной сети и местных электромагнитных помех, влияющих на эту сеть. Электромагнитные помехи (например, от микроволновой печи ) могут привести к потере переданных пакетов, что потребует повторной передачи, что приводит к задержке. Хотя распространение радиосигнала по воздуху происходит быстрее, чем свет по оптоволокну, беспроводные системы часто используются многими пользователями и могут страдать от задержек, возникающих из-за перегрузки сети или из-за сетевых протоколов , которые вносят задержку.

Эффекты

Заметные последствия задержки различаются не только в зависимости от точной причины, но и от всех методов компенсации задержки, которые могут быть реализованы в игре (описаны ниже). Поскольку все клиенты испытывают некоторую задержку, реализация этих методов для минимизации воздействия на игроков важна для плавного игрового процесса. Задержка вызывает множество проблем, таких как точная визуализация состояния игры и обнаружение попаданий. Во многих играх лаги часто не одобряются, поскольку они мешают нормальному игровому процессу. Серьезность задержки зависит от типа игры и присущей ей терпимости к задержке. Некоторые игры с более медленным темпом могут допускать значительные задержки без какой-либо компенсации вообще, тогда как другие с более быстрым темпом значительно более чувствительны и требуют широкого использования компенсации для игры (например, жанр шутеров от первого лица). Из-за различных проблем, которые могут возникнуть с задержкой, игрокам с недостаточно быстрым подключением к Интернету иногда не разрешается или не рекомендуется играть с другими игроками или серверами, которые имеют удаленный хост-сервер или имеют высокую задержку друг с другом. Крайние случаи задержки могут привести к значительной десинхронизации состояния игры.

Задержка из-за недостаточной скорости обновления между клиентом и сервером может вызвать некоторые проблемы, но они обычно ограничиваются самим клиентом. Другие игроки могут заметить прерывистые движения и подобные проблемы у игрока, связанного с затронутым клиентом, но настоящая проблема заключается в самом клиенте. Если клиент не может обновлять состояние игры достаточно быстро, игроку могут быть показаны устаревшие версии игры, что, в свою очередь, вызывает различные проблемы с обнаружением попаданий и столкновений. Если низкая частота обновления вызвана низкой частотой кадров (а не настройкой на клиенте, как это допускают некоторые игры), то эти проблемы обычно затмеваются многочисленными проблемами, связанными с самой обработкой на стороне клиента . И дисплей, и элементы управления будут работать вяло и не отвечать на запросы. Хотя это может увеличить воспринимаемую задержку, важно отметить, что она другого типа, чем задержки, связанные с сетью. Для сравнения, одна и та же проблема на сервере может вызвать серьезные проблемы для всех задействованных клиентов. Если сервер не может или не желает достаточно быстро принимать пакеты от клиентов и своевременно их обрабатывать, действия клиента могут никогда не регистрироваться. Когда сервер затем отправляет обновления клиентам, у них может возникнуть зависание (игра не отвечает) и/или откат , в зависимости от того, какие типы компенсации задержки, если таковые имеются, используются в игре.

Задержка из-за задержки в сети, напротив, часто не является проблемой. Хотя это более распространено, фактические эффекты обычно меньше, и такие типы задержек можно компенсировать. Без какой-либо компенсации задержки клиенты заметят, что игра реагирует лишь через короткое время после выполнения действия. Это особенно проблематично в шутерах от первого лица , где враги, скорее всего, будут двигаться, когда игрок пытается в них выстрелить, а вероятность ошибки часто невелика.

Решения и компенсация задержек

Существуют различные методы уменьшения или маскировки задержек, однако многие из них имеют свои недостатки и могут быть применимы не во всех случаях. Если синхронизация невозможна самой игрой, клиенты могут выбрать игру на серверах, находящихся в географической близости от них, чтобы уменьшить задержки, или серверы могут просто отказаться от клиентов с высокими задержками, чтобы избежать необходимости справиться с возникшими проблемами. Однако вряд ли это оптимальные решения. Вместо этого игры часто разрабатываются с учетом компенсации задержек.

Многие проблемы можно решить, просто разрешив клиентам отслеживать свое состояние и отправлять абсолютные состояния на сервер или напрямую другим клиентам. Например, клиент может точно указать, в какой позиции находится персонаж игрока или в кого он стрелял. Это решение работает и почти устранит большинство проблем, связанных с задержками. К сожалению, это также основано на предположении, что клиент честен. Ничто не мешает игроку изменять отправляемые данные непосредственно на клиенте или косвенно через прокси, чтобы гарантировать, что он всегда достигнет своей цели. В онлайн-играх риск мошенничества может сделать это решение невозможным, и клиенты будут ограничены отправкой относительных состояний (т. е. по какому вектору он двигался или в каком направлении стрелял).

Клиентская сторона

Поскольку клиентам обычно не разрешается определять основное состояние игры, а они получают его от сервера, основная задача компенсации на стороне клиента — максимально точно отобразить виртуальный мир. Поскольку обновления приходят с задержкой и могут даже быть удалены, клиенту иногда необходимо предсказать ход игры. Поскольку состояние обновляется дискретными шагами, клиент должен иметь возможность оценить движение на основе доступных выборок. Для этого можно использовать два основных метода; экстраполяция и интерполяция .

Экстраполяция — это попытка оценить будущее состояние игры. Как только пакет от сервера получен, положение объекта обновляется до нового положения. В ожидании следующего обновления следующая позиция экстраполируется на основе текущей позиции и движения на момент обновления. По сути, клиент будет предполагать, что движущийся объект будет продолжать двигаться в том же направлении. При получении нового пакета положение может немного скорректироваться.

Интерполяция работает, по существу, буферизуя состояние игры и отображая его игроку с небольшой постоянной задержкой. Когда приходит пакет от сервера, вместо немедленного обновления положения объекта клиент начинает интерполировать положение, начиная с последней известной позиции. В течение интервала интерполяции объект будет плавно перемещаться между двумя позициями. В идеале этот интервал должен точно соответствовать задержке между пакетами, но из-за потерь и переменной задержки такое случается редко.

Оба метода имеют преимущества и недостатки.

• Интерполяция гарантирует, что объекты будут перемещаться только между допустимыми позициями и будут давать хорошие результаты с постоянной задержкой и без потерь. Если отброшенные или неупорядоченные пакеты переполняют буфер интерполяции, клиенту придется либо заморозить объект на месте до прибытия нового пакета, либо вместо этого вернуться к экстраполяции. Обратной стороной интерполяции является то, что она приводит к рендерингу мира с дополнительной задержкой, что увеличивает необходимость реализации той или иной формы компенсации задержки.
• Проблема с экстраполяцией позиций достаточно очевидна: невозможно точно предсказать будущее. Он будет правильно отображать движение только в том случае, если движение постоянно, но это не всегда так. Игроки могут произвольно менять скорость и направление. Это может привести к небольшому «искажению» по мере поступления новых обновлений и исправления предполагаемых позиций, а также вызвать проблемы с обнаружением попаданий, поскольку игроки могут отображаться в позициях, в которых они на самом деле не находятся.

Часто, чтобы обеспечить плавный игровой процесс, клиенту разрешается вносить мягкие изменения в состояние игры. Хотя сервер в конечном итоге может отслеживать боеприпасы, здоровье, положение и т. д., клиенту может быть разрешено предсказывать новое состояние игры на стороне сервера на основе действий игрока, например, позволяя игроку начать движение до того, как сервер ответит. команде. Эти изменения, как правило, будут приняты при нормальных условиях и сделают задержку в основном прозрачной. Проблемы возникнут только в случае больших задержек или потерь, когда прогнозы клиента очень заметно отменяются сервером. Иногда, в случае незначительных различий, сервер может даже допустить «неправильные» изменения состояния на основе обновлений от клиента.

Серверная часть

В отличие от клиентов, сервер знает точное текущее состояние игры, и поэтому в таком прогнозировании нет необходимости. Вместо этого основная цель компенсации задержки на стороне сервера — обеспечить точные эффекты действий клиента. Это важно, потому что к моменту поступления команды игрока время уже пойдет, и мир уже не будет в том состоянии, в котором игрок видел при подаче команды. Ярким примером этого является обнаружение попаданий из оружия, стреляющего в шутерах от первого лица, где поля невелики и потенциально могут вызвать серьезные проблемы, если с ними не обращаться должным образом.

Перемотка времени назад

Другой способ решить эту проблему — сохранять прошлые состояния игры в течение определенного периода времени, а затем перематывать местоположение игроков при обработке команды. Сервер использует задержку игрока (включая любую внутреннюю задержку из-за интерполяции; см. выше), чтобы перемотать время на соответствующую величину, чтобы определить, что видел стреляющий клиент в момент выстрела. Обычно это приводит к тому, что сервер видит, что клиент стреляет по старой позиции цели и, таким образом, попадает. В худшем случае игрок настолько отстанет, что на сервере закончатся исторические данные, и ему придется начать опережать свои цели.

Это решение WYSIWYG , которое позволяет игрокам нацеливаться непосредственно на то, что они видят. Но цена — усугубление последствий задержки, когда игрок находится под огнем: свою роль играет не только его собственная задержка, но и атакующего. Во многих ситуациях это незаметно, но игроки, которые только что укрылись, заметят, что они продолжают получать сообщения о повреждении/смерти с сервера дольше, чем может оправдать их собственная задержка. Чаще всего это может привести к (ложному) впечатлению, что стреляли через укрытие, и к (не совсем неточному) впечатлению о «запаздывающих хитбоксах ».

Одна из проблем дизайна, возникающая при перемотке, заключается в том, следует ли прекратить перематывать отложенные команды мертвого игрока, как только он умирает на сервере, или продолжать выполнять их, пока они не «догонят» момент смерти. Отключение компенсации немедленно предотвращает посмертное нападение жертв на своих убийц, что оправдывает ожидания, но сохраняет естественное преимущество перемещения игроков, которые поворачивают за угол, захватывают цель и убивают ее за меньшее время, чем поездка туда и обратно к клиенту неподвижной жертвы.

Перемотку можно критиковать за то, что она позволяет высокой задержке одного игрока негативно влиять на впечатления игроков с низкой задержкой. Серверы с компенсацией задержки иногда уменьшают длину хранимой истории игрока или устанавливают ограничения на пинг, чтобы уменьшить эту проблему.

Доверительные клиенты

Клиенты могут сообщать серверу, что они делают, и сервер может доверять получаемым данным. Этого метода избегают, если это вообще возможно, из-за его подверженности мошенничеству : достаточно просто направить сетевые данные через второй компьютер, который вставляет сфабрикованные сообщения о попадании или изменяет существующие - метод, который не может быть обнаружен средствами защиты от мошенничества .

Однако огромный масштаб некоторых игр делает невозможными вычислительно затратные решения, такие как перемотка назад . В Battlefield 3 , например, используется «гибридная система обнаружения попаданий», при которой клиенты сообщают серверу, что они попали, а сервер выполняет лишь неопределенную проверку правдоподобности, прежде чем принять утверждение.

В противном случае доверие к результатам клиента имеет те же преимущества и недостатки, что и перемотка назад .

Заставьте клиентов экстраполировать

Менее распространенное решение задержки — ничего не делать на сервере и заставить каждого клиента экстраполировать (см. выше), чтобы покрыть свою задержку. Это приводит к неверным результатам, если только удаленные игроки не поддерживают постоянную скорость, предоставляя преимущество тем, кто уклоняется вперед и назад или просто начинает или останавливает движение.

Расширенная экстраполяция также приводит к тому, что удаленные игроки становятся видимыми (хотя и не уязвимыми), хотя это не должно быть так: например, если удаленный игрок подбегает к углу, а затем резко останавливается на краю, другие клиенты будут отображать его бегущим вперед, на открытое пространство. на время их собственной латентности. С другой стороны этой проблемы, клиентам приходится давать удаленным игрокам, которые только начали двигаться, дополнительную скорость, чтобы подтолкнуть их к теоретически точно предсказанному местоположению.

Дизайн

Уменьшить ощущение отставания можно с помощью игрового дизайна . Методы включают воспроизведение анимации на стороне клиента, как если бы действие произошло немедленно, уменьшение/удаление встроенных таймеров на хост-компьютере и использование переходов камеры для сокрытия деформации.

Облачные игры

Облачные игры — это тип онлайн-игр, в которых вся игра размещается на игровом сервере в центре обработки данных, а пользователь запускает только тонкий клиент локально , который перенаправляет действия игрового контроллера на игровой сервер. Затем игровой сервер визуализирует следующий кадр игрового видео, которое сжимается с использованием сжатия видео с малой задержкой , отправляется дальше по потоку и распаковывается тонким клиентом. Чтобы качество облачных игр было приемлемым, необходимо обеспечить двустороннюю задержку всех элементов облачной игровой системы (тонкого клиента, подключения к Интернету и/или локальной сети, игрового сервера, выполнения игры на игровом сервере, видео и аудио сжатие и распаковка, а также отображение видео на устройстве отображения ) должны быть достаточно низкими, чтобы у пользователя возникало ощущение, что игра работает локально. из-за таких жестких требований к задержке в игру вступают соображения расстояния, связанные со скоростью света через оптическое волокно , что в настоящее время ограничивает расстояние между пользователем и игровым сервером облачных игр примерно до 1000 миль По данным OnLive, . Также существует много споров по поводу отставания, связанного с облачными играми. В многопользовательских играх, использующих сетевую архитектуру клиент/сервер, компьютер игрока отображает игровую графику локально, и на сервер отправляется только информация о внутриигровых действиях игрока. Например, когда игрок нажимает кнопку, персонаж на экране мгновенно выполняет соответствующее действие. Однако последствия такого действия, как убийство врага, видны только после небольшой задержки из-за времени, необходимого для того, чтобы действие достигло сервера. Это приемлемо только в том случае, если реакция на действия игрока достаточно быстрая.

При использовании облачных игр ввод данных игроком может привести к небольшим задержкам до тех пор, пока он не увидит ответ. Входные данные сначала должны быть переданы на удаленный сервер, затем сервер должен начать рендеринг графики выполняемого действия и передать видео обратно игроку по сети, что занимает дополнительное время. Таким образом, игрок испытывает заметную задержку между нажатием кнопки и тем, как что-то происходит на экране. В зависимости от навыков и опыта игрока это может вызвать дезориентацию и замешательство, подобное задержке слуховой обратной связи , а также затруднить навигацию и прицеливание в игровом мире. При быстром вводе длинной комбинации символ на экране не синхронизируется с нажатием кнопок. Обычно это вызывает у игрока сильное замешательство, что приводит к провалу комбинационного хода.

Дополнительная задержка ввода также может сильно затруднить игру в некоторые одиночные игры. Например, если враг наносит удар по игроку и ожидается, что игрок заблокирует удар, то к тому времени, когда на экране игрока появится сообщение о том, что враг начал атаку, враг уже нанесет удар и убьет игрока на сервере.