В компьютерах задержка — это задержка ( латентность ) между действием пользователя ( вводом) и реакцией сервера, поддерживающего задачу , которую необходимо отправить обратно клиенту .
Способность игрока переносить задержку зависит от типа игры. Например, стратегическая игра или пошаговая игра с медленным темпом может иметь высокий порог или даже быть практически не подверженной высокой задержке. Игра с дерганым геймплеем, такая как шутер от первого лица или файтинг со значительно более быстрым темпом, может потребовать значительно меньшей задержки для обеспечения удовлетворительного игрового процесса .
Внутриигровой индикатор скорости задержки иногда называют лагометром . [ 1]
Время пинга — это сетевая задержка для кругового обхода между клиентом игрока и игровым сервером , измеряемая с помощью утилиты ping или эквивалента. Время пинга — это среднее время, измеряемое в миллисекундах (мс). [ требуется ссылка ] Чем ниже пинг, тем меньше задержка и тем меньше отставание испытает игрок. Высокий пинг и низкий пинг — это общепринятые термины в онлайн-играх, где высокий пинг относится к пингу, который вызывает сильное отставание; в то время как любой уровень пинга может вызвать отставание, сильное отставание обычно обозначается пингом более 100 мс. [2] Такое использование является игровым культурным разговорным выражением и обычно не встречается и не используется в профессиональных компьютерных сетевых кругах. В играх, где время является ключевым фактором, таких как шутеры от первого лица и стратегии в реальном времени , низкий пинг всегда желателен, так как низкий пинг означает более плавный игровой процесс , позволяя быстрее обновлять игровые данные между клиентами игроков и игровым сервером.
Высокая задержка может вызвать задержку. Игровые серверы могут отключить клиента, если задержка слишком велика, и это может нанести ущерб игровому процессу других игроков. Аналогично, клиентское программное обеспечение часто требует отключения, если задержка слишком велика. Высокий пинг также может привести к сбою серверов из-за нестабильности.
В некоторых шутерах от первого лица высокий пинг может привести к тому, что игрок непреднамеренно получит несправедливые преимущества, например, исчезнет из одного места и мгновенно появится в другом, имитируя эффект телепортации, что затрудняет другим игрокам оценку положения их персонажа и, следовательно, делает игрока гораздо более трудной целью. Чтобы противостоять этому, многие игровые серверы автоматически исключают игроков с пингом выше среднего. И наоборот, высокий пинг может сильно затруднить игру из-за возникающих негативных эффектов, затрудняя отслеживание других игроков и даже перемещение их персонажа.
Вместо того чтобы использовать традиционные сетевые пакеты эхо-запросов и ответов ICMP для определения времени пинга, программисты видеоигр часто встраивают собственные средства обнаружения задержек в существующие игровые пакеты (обычно на основе протокола UDP ).
Некоторые факторы, которые могут повлиять на ping, включают: используемый протокол связи , пропускную способность Интернета (скорость соединения), качество интернет-провайдера пользователя и конфигурацию брандмауэров . На ping также влияет географическое положение. Например, если кто-то находится в Индии и играет на сервере, расположенном в Соединенных Штатах, расстояние между ними больше, чем для игроков, находящихся в США, и поэтому передача данных занимает больше времени. Однако объем коммутации пакетов и сетевого оборудования между двумя компьютерами часто более значим. Например, беспроводные сетевые интерфейсные карты должны модулировать цифровые сигналы в радиосигналы , что часто обходится дороже, чем время, необходимое электрическому сигналу для прохождения типичного участка кабеля. Таким образом, более низкий ping может привести к более высокой скорости загрузки и выгрузки в Интернете.
В то время как однопользовательская игра поддерживает основное состояние игры на локальной машине, онлайн-игра требует, чтобы оно поддерживалось на центральном сервере, чтобы избежать несоответствий между отдельными клиентами. Таким образом, клиент не имеет прямого контроля над центральным состоянием игры и может только отправлять запросы на изменение на сервер и может обновлять локальное состояние игры только получая обновления с сервера. Эта необходимость в общении вызывает задержку между клиентами и сервером и является основной причиной задержек. Хотя может быть множество основных причин, по которым игрок испытывает задержку, их можно обобщить как недостаточное оборудование либо на клиенте, либо на сервере, либо плохое соединение между клиентом и сервером. [3]
Проблемы, связанные с оборудованием, вызывают задержку из-за фундаментальной структуры архитектуры игры. Как правило, игры состоят из зацикленной последовательности состояний или «кадров». В течение каждого кадра игра принимает пользовательский ввод и выполняет необходимые вычисления (ИИ, графика и т. д.). Когда вся обработка завершена, игра обновит состояние игры и выдаст вывод, такой как новое изображение на экране и/или пакет для отправки на сервер. Частота, с которой генерируются кадры, часто называется частотой кадров и задержкой (видеоигры), поскольку центральное состояние игры находится на сервере, обновленная информация должна быть отправлена клиентом на сервер, чтобы вступить в силу. Кроме того, клиент должен получить необходимую информацию с сервера, чтобы полностью обновить состояние. Генерация пакетов для отправки на сервер и обработка полученных пакетов может выполняться только так часто, как клиент может обновлять свое локальное состояние. Хотя пакеты теоретически могут генерироваться и отправляться быстрее, это приведет только к отправке избыточных данных, если состояние игры не может обновляться между каждым пакетом. Таким образом, низкая частота кадров сделает игру менее отзывчивой к обновлениям и может привести к пропуску устаревших данных.
И наоборот, то же самое справедливо для сервера. Частота кадров (или тиковая частота) сервера определяет, как часто он может обрабатывать данные от клиентов и отправлять обновления. Этот тип проблем трудно предсказать и компенсировать. Помимо соблюдения минимальных требований к оборудованию и попытки оптимизировать игру для лучшей производительности, нет никаких реальных способов справиться с этим.
Возможно, наиболее распространенный тип задержки вызван проблемами производительности сети . Потери , повреждение или дрожание (устаревший пакет фактически является потерей) могут вызывать проблемы, но эти проблемы относительно редки в сети с достаточной пропускной способностью и отсутствием или небольшой перегрузкой . Вместо этого задержка, связанная с передачей данных между клиентами и сервером, играет значительную роль. Задержка варьируется в зависимости от ряда факторов, таких как физическое расстояние между конечными системами, поскольку большее расстояние означает дополнительную длину передачи и необходимую маршрутизацию и, следовательно, более высокую задержку. Маршрутизация через Интернет может быть крайне косвенной, что приводит к гораздо большей длине передачи (и последующей задержке), чем прямой маршрут, хотя облачный игровой сервис OnLive разработал решение этой проблемы, установив пиринговые отношения с несколькими сетевыми интернет-провайдерами уровня 1 и выбрав оптимальный маршрут между сервером и пользователем. [4] Кроме того, недостаточная пропускная способность и перегрузка, даже если они не настолько серьезны, чтобы вызвать потери, могут вызывать дополнительные задержки независимо от расстояния. Как и в случае с аппаратными проблемами, пакеты, которые поступают медленно или не поступают вообще, не позволят ни клиенту, ни серверу своевременно обновлять состояние игры.
Онлайн-игровые системы, использующие беспроводную сеть, могут быть подвержены значительным задержкам в зависимости от архитектуры беспроводной сети и локальных электромагнитных помех, влияющих на эту сеть. Электромагнитные помехи (например, от микроволновой печи ) могут привести к потере переданных пакетов, требуя повторной передачи, которая влечет за собой задержку. Хотя распространение радиосигнала по воздуху происходит быстрее, чем распространение света по оптоволокну, беспроводные системы часто используются совместно многими пользователями и могут страдать от задержек, возникающих из-за перегрузки сети или из-за сетевых протоколов , которые вносят задержку.
Заметные эффекты отставания различаются не только в зависимости от точной причины, но и от всех методов компенсации отставания, которые может реализовать игра (описано ниже). Поскольку все клиенты испытывают некоторую задержку, реализация этих методов для минимизации воздействия на игроков важна для плавного игрового процесса. Отставание вызывает многочисленные проблемы, такие как точная отрисовка состояния игры и обнаружение попаданий. [5] Во многих играх отставание часто не приветствуется, поскольку оно нарушает нормальный игровой процесс. Серьезность отставания зависит от типа игры и ее присущей толерантности к отставанию. Некоторые игры с более медленным темпом могут выдерживать значительные задержки без какой-либо необходимости компенсации вообще, тогда как другие с более быстрым темпом значительно более чувствительны и требуют обширного использования компенсации для играбельности (например, жанр шутеров от первого лица). Из-за различных проблем, которые может вызвать отставание, игрокам, у которых недостаточно быстрое интернет-соединение, иногда не разрешают или отговаривают играть с другими игроками или серверами, которые имеют удаленный серверный хост или имеют высокую задержку друг от друга. Экстремальные случаи отставания могут привести к обширной десинхронизации состояния игры.
Задержка из-за недостаточной скорости обновления между клиентом и сервером может вызвать некоторые проблемы, но они, как правило, ограничиваются самим клиентом. Другие игроки могут заметить прерывистое движение и подобные проблемы с игроком, связанные с затронутым клиентом, но настоящая проблема заключается в самом клиенте. Если клиент не может обновлять состояние игры достаточно быстро, игроку могут быть показаны устаревшие версии игры, что, в свою очередь, вызывает различные проблемы с обнаружением попаданий и столкновений. [6] Если низкая скорость обновления вызвана низкой частотой кадров (в отличие от настройки на клиенте, как это допускается в некоторых играх), эти проблемы обычно затмеваются многочисленными проблемами, связанными с самой обработкой на стороне клиента . И дисплей, и элементы управления будут вялыми и неотзывчивыми. Хотя это может увеличить воспринимаемую задержку, важно отметить, что это иного рода, чем задержки, связанные с сетью. Для сравнения, та же проблема на сервере может вызвать значительные проблемы для всех вовлеченных клиентов. Если сервер не может или не хочет принимать пакеты от клиентов достаточно быстро и обрабатывать их своевременно, действия клиента могут никогда не быть зарегистрированы. Когда сервер затем отправляет обновления клиентам, они могут столкнуться с зависанием (неотзывчивая игра) и/или откатами , в зависимости от того, какие типы компенсации задержек, если таковые имеются, использует игра.
Задержка из-за сетевой задержки, напротив, часто является меньшей проблемой. Хотя она встречается чаще, фактические эффекты, как правило, меньше, и эти типы задержек можно компенсировать. Без какой-либо формы компенсации задержки клиенты заметят, что игра реагирует только через короткое время после выполнения действия. Это особенно проблематично в шутерах от первого лица , где враги, скорее всего, будут двигаться, когда игрок попытается их застрелить, а предел для ошибок часто невелик.
Существуют различные методы уменьшения или маскировки задержек, хотя многие из них имеют свои недостатки и могут быть применимы не во всех случаях. Если синхронизация невозможна самой игрой, клиенты могут выбрать игру на серверах, находящихся в географической близости от них, чтобы уменьшить задержки, или серверы могут просто решить отказаться от клиентов с высокими задержками, чтобы избежать необходимости иметь дело с возникающими проблемами. Однако это вряд ли оптимальные решения. Вместо этого игры часто будут разрабатываться с учетом компенсации задержек. [7]
Многие проблемы можно решить, просто позволив клиентам отслеживать свое собственное состояние и отправлять абсолютные состояния на сервер или напрямую другим клиентам. [8] Например, клиент может точно указать, в какой позиции находится персонаж игрока или в кого он стрелял. Это решение работает и практически устранит большинство проблем, связанных с задержкой. К сожалению, оно также основано на предположении, что клиент честен. Ничто не мешает игроку изменять отправляемые им данные, напрямую клиенту или косвенно через прокси-сервер, чтобы гарантировать, что он всегда будет поражать свои цели. В онлайн-играх риск мошенничества может сделать это решение неосуществимым, и клиенты будут ограничены отправкой относительных состояний (т. е. по какому вектору он двигался или в каком направлении стрелял).
Поскольку клиентам обычно не разрешается определять основное состояние игры, а они получают его с сервера, основной задачей компенсации на стороне клиента является максимально точная визуализация виртуального мира. Поскольку обновления приходят с задержкой и могут даже отбрасываться, иногда клиенту необходимо предсказать ход игры. Поскольку состояние обновляется дискретными шагами, клиент должен иметь возможность оценить движение на основе доступных образцов. Для этого можно использовать два основных метода: экстраполяцию и интерполяцию . [8]
Экстраполяция — это попытка оценить будущее состояние игры. Как только получен пакет с сервера, положение объекта обновляется до нового положения. В ожидании следующего обновления следующее положение экстраполируется на основе текущего положения и движения на момент обновления. По сути, клиент будет предполагать, что движущийся объект продолжит движение в том же направлении. При получении нового пакета положение может быть немного скорректировано.
Интерполяция работает, по сути, буферизуя игровое состояние и отображая игровое состояние игроку с небольшой постоянной задержкой. Когда пакет с сервера приходит, вместо того, чтобы немедленно обновить положение объекта, клиент начнет интерполировать положение, начиная с последнего известного положения. В течение интервала интерполяции объект будет отображаться плавно перемещающимся между двумя положениями. В идеале этот интервал должен точно соответствовать задержке между пакетами, но из-за потерь и переменной задержки это случается редко.
Оба метода имеют свои преимущества и недостатки.
Часто, чтобы обеспечить плавный игровой процесс, клиенту разрешается вносить мягкие изменения в состояние игры. В то время как сервер может в конечном итоге отслеживать боеприпасы, здоровье, позицию и т. д., клиенту может быть разрешено предсказывать новое состояние игры на стороне сервера на основе действий игрока, например, разрешая игроку начать движение до того, как сервер отреагирует на команду. Эти изменения, как правило, принимаются в нормальных условиях и делают задержку в основном прозрачной. Проблемы возникнут только в случае больших задержек или потерь, когда прогнозы клиента очень заметно отменяются сервером. Иногда, в случае незначительных различий, сервер может даже разрешить «неправильные» изменения состояния на основе обновлений от клиента.
В отличие от клиентов, сервер знает точное текущее состояние игры, и поэтому прогнозирование не нужно. Основная цель компенсации задержки на стороне сервера — обеспечить точные эффекты действий клиента. Это важно, потому что к тому времени, как придет команда игрока, время уже сдвинется, и мир уже не будет в том состоянии, которое игрок видел, когда отдавал свою команду. [9] Очень явным примером этого является обнаружение попаданий для оружия, стреляющего в шутерах от первого лица, где границы невелики и могут потенциально вызвать серьезные проблемы, если не обрабатывать их должным образом.
Другой способ решения этой проблемы — хранить прошлые игровые состояния в течение определенного периода времени, а затем перематывать местоположение игрока при обработке команды. [8] Сервер использует задержку игрока (включая любую присущую задержку из-за интерполяции; см. выше) для перемотки времени на соответствующую величину, чтобы определить, что видел стреляющий клиент в момент выстрела. Обычно это приводит к тому, что сервер видит, что клиент стреляет по старой позиции цели, и, таким образом, попадает. В худшем случае игрок будет настолько отставать, что у сервера закончатся исторические данные, и ему придется начать упреждать свои цели.
Это решение WYSIWYG , которое позволяет игрокам целиться прямо в то, что они видят. Но цена — усугубление эффектов задержки, когда игрок находится под обстрелом: не только его собственная задержка играет роль, но и задержка нападающего тоже. Во многих ситуациях это незаметно, но игроки, которые только что укрылись, заметят, что они продолжают получать сообщения об уроне/смерти от сервера дольше, чем может оправдать их собственная задержка. Это может чаще приводить к (ложному) впечатлению, что их подстрелили через укрытие, и (не совсем неверному) впечатлению о «тормозящих хитбоксах ». [8]
Одна из проблем дизайна, которая возникает из-за перемотки, заключается в том, следует ли прекращать перемотку отложенных команд мертвого игрока сразу после его смерти на сервере или продолжать выполнять их до тех пор, пока они не «догонят» время смерти. Немедленное отключение компенсации не позволяет жертвам посмертно атаковать своих убийц, что соответствует ожиданиям, но сохраняет естественное преимущество движущихся игроков, которые заворачивают за угол, находят цель и убивают ее за меньшее время, чем на круговой обход клиента неподвижной жертвы.
Перемотку можно критиковать за то, что она позволяет высокой задержке одного игрока негативно влиять на опыт игроков с низкой задержкой. Серверы с компенсацией задержек иногда сокращают длину сохраняемой истории игроков или устанавливают ограничения пинга, чтобы уменьшить эту проблему.
Клиенты могут сообщать серверу, что они делают, а сервер доверять данным, которые он получает. Этот метод избегается, если это вообще возможно, из-за его восприимчивости к мошенничеству : это простое дело — направить сетевые данные через второй компьютер, который вставляет сфабрикованные сообщения о попадании или изменяет существующие, метод, который не может быть обнаружен античит- инструментами. [8]
Однако масштаб некоторых игр делает невозможными такие дорогостоящие решения, как перемотка. Например, в Battlefield 3 используется система «гибридного обнаружения попаданий», когда клиенты сообщают серверу, что они попали, а сервер выполняет лишь смутную проверку правдоподобности, прежде чем принять заявление. [10]
В противном случае доверие к результатам клиента имеет те же преимущества и недостатки, что и перемотка назад.
Менее распространенное решение проблемы задержки — ничего не делать на сервере и заставить каждого клиента экстраполировать (см. выше), чтобы покрыть свою задержку. [11] Это дает неверные результаты, если только удаленные игроки не поддерживают постоянную скорость, предоставляя преимущество тем, кто уклоняется вперед и назад или просто начинает/останавливает движение.
Расширенная экстраполяция также приводит к тому, что удаленные игроки становятся видимыми (хотя и не уязвимыми), когда они не должны быть такими: например, если удаленный игрок бежит к углу, а затем резко останавливается на краю, другие клиенты будут делать его бегущим вперед, на открытое место, на время их собственной задержки. С другой стороны этой проблемы, клиенты должны дать удаленным игрокам, которые только что начали движение, дополнительный всплеск скорости, чтобы подтолкнуть их в теоретически точно предсказанное место.
Можно уменьшить восприятие задержки с помощью игрового дизайна . Методы включают воспроизведение клиентской анимации так, как будто действие происходит немедленно, сокращение/удаление встроенных таймеров на хост-машине и использование переходов камеры для сокрытия деформации. [12]
Облачный гейминг — это тип онлайн-игр, в котором вся игра размещается на игровом сервере в центре обработки данных, а пользователь запускает только тонкий клиент локально, который пересылает действия игрового контроллера вверх по течению на игровой сервер. Затем игровой сервер визуализирует следующий кадр игрового видео, который сжимается с использованием сжатия видео с малой задержкой и отправляется вниз по течению и распаковывается тонким клиентом. Чтобы облачный игровой опыт был приемлемым, задержка передачи туда и обратно всех элементов облачной игровой системы (тонкий клиент, подключение к Интернету и/или локальной сети, игровой сервер, выполнение игры на игровом сервере, сжатие и распаковка видео и аудио, а также отображение видео на устройстве отображения ) должна быть достаточно низкой, чтобы пользователь воспринимал игру как запущенную локально. [4] [13] Из-за таких жестких требований к задержке в игру вступают соображения расстояния, связанные со скоростью света по оптоволокну , в настоящее время ограничивая расстояние между пользователем и игровым сервером облачных игр примерно 1000 милями, согласно OnLive . [14] Также существует много споров о задержке, связанной с облачным геймингом. В многопользовательских играх, использующих клиент-серверную сетевую архитектуру, компьютер игрока локально отображает игровую графику, и на сервер отправляется только информация о действиях игрока в игре. Например, когда игрок нажимает кнопку, персонаж на экране мгновенно выполняет соответствующее действие. Однако последствия действия, такие как убийство врага, видны только после небольшой задержки из-за времени, необходимого для того, чтобы действие достигло сервера. Это приемлемо только до тех пор, пока реакция на ввод игрока достаточно быстрая.
При использовании облачных игр вводы игрока могут приводить к коротким задержкам, пока он не увидит ответ. Сначала вводы должны быть переданы на удаленный сервер, затем сервер должен начать рендеринг графики выполняемого действия и транслировать видео обратно игроку по сети, что занимает дополнительное время. Таким образом, игрок испытывает заметную задержку между нажатием кнопки и тем, что он видит, что что-то происходит на экране. В зависимости от навыков и опыта игрока это может вызвать дезориентацию и замешательство, аналогичное задержке слуховой обратной связи , и затрудняет навигацию и прицеливание в игровом мире. При быстром вводе длинного комбинированного движения персонаж на экране не будет синхронизирован с нажатиями кнопок. Это обычно вызывает у игрока сильное замешательство, что приводит к неудаче комбинированного движения.
Дополнительная задержка ввода также может сильно затруднить игру в некоторые однопользовательские игры. Например, если враг наносит удар игроку, а игрок должен блокировать, то к тому времени, как на экране игрока появится сообщение о том, что враг начал атаку, враг уже ударит и убьет игрока на сервере.
Ka le или Kale , / ˈ k ɑː l ɜː / , [15] — игровой сленг и интернет- фраза [16], обозначающая задержку. [15] [16] Это происходит от китайской фразы卡了( пиньинь : Kǎle ) [15] [16] и впервые было использовано на чемпионате Азии по Dota 2 2015 года , когда некоторые китайские игроки набрали ее в чате, чтобы пожаловаться на раздражающие задержки в игре и попросить сделать паузу. [15] По мере того, как китайская сцена Dota 2 становилась популярной, это выражение также стало известно. Многие западные игроки, как профессионалы, так и любители, часто набирают «kale» вместо «lag» во внутриигровом чате и на Twitch . [16] [15]
попадания BF3 использует комбинированную клиент-серверную модель, гибридное обнаружение попадания. Клиент говорит серверу: "Эй, я его подстрелил!", а сервер проверяет положение двух целей и определяет, мог ли игрок обоснованно поразить эту цель, а затем наносит урон.