Войти
В онлайн - играх, лаг заметная задержка ( задержка ) между действием игроков (вход) и реакции сервера, поддерживающего игру, которая должна быть отправлена обратно на клиента.
Способность игрока терпеть отставание зависит от типа игры. Например, стратегическая игра или пошаговая игра с медленным темпом может иметь высокий порог или даже не зависеть от большого лага. Игра с подергивающимся геймплеем, такая как шутер от первого лица со значительно более быстрым темпом, может потребовать значительно меньшего лага для обеспечения удовлетворительного игрового процесса.
Ping time - это сетевая задержка для двустороннего обхода между клиентом игрока и игровым сервером, измеренная с помощью утилиты ping или ее эквивалента. Ping time - это среднее время, измеряемое в миллисекундах (мс). Чем ниже пинг, тем меньше задержка и меньше задержка будет у игрока. В онлайн-играх часто используются термины « высокий пинг» и « низкий пинг», где « высокий пинг» означает пинг, вызывающий серьезную задержку; в то время как любой уровень эхо-запроса может вызвать задержку, серьезное отставание обычно обозначается эхо-запросом более 100 мс. Это использование является разговорным языком игровой культуры и обычно не встречается и не используется в профессиональных компьютерных сетевых кругах. В играх, где время играет ключевую роль, таких как шутеры от первого лица и стратегии в реальном времени, всегда желателен низкий пинг, поскольку низкий пинг означает более плавный игровой процесс, позволяя быстрее обновлять игровые данные между клиентами игроков и игровым сервером.
Высокая задержка может вызвать задержку. Игровые серверы могут отключить клиента, если задержка слишком велика и может нанести ущерб игровому процессу других игроков. Точно так же клиентское программное обеспечение часто требует отключения, если задержка слишком велика. Высокий пинг также может привести к сбою серверов из-за нестабильности.
В некоторых играх-шутерах от первого лица высокий пинг может привести к непреднамеренному получению игроком несправедливых преимуществ, таких как исчезновение из одного места и мгновенное появление в другом, имитируя эффект телепортации, что затрудняет другим игрокам оценку его персонажа. положение и, следовательно, значительно затрудняет нацеливание на игрока. Чтобы противостоять этому, многие игровые серверы автоматически удаляют игроков с пингом выше среднего. И наоборот, высокий пинг может очень затруднить игру для игрока из-за возникающих негативных эффектов, что затрудняет отслеживание игроком других игроков и даже перемещение их персонажа.
Вместо того, чтобы использовать традиционные сетевые пакеты эхо-запроса и ответа ICMP для определения времени пинга, программисты видеоигр часто встраивают собственное определение задержки в существующие игровые пакеты (обычно основанные на протоколе UDP ).
Некоторые факторы, которые могут повлиять на пинг, включают: используемый протокол связи, пропускную способность Интернета (скорость соединения), качество интернет-провайдера пользователя и конфигурацию межсетевых экранов. На пинг также влияет географическое положение. Например, если кто-то находится в Индии и играет на сервере, расположенном в Соединенных Штатах, расстояние между ними больше, чем для игроков, находящихся в США, и поэтому для передачи данных требуется больше времени. Однако количество коммутации пакетов и сетевого оборудования между двумя компьютерами часто бывает более значительным. Например, карты беспроводного сетевого интерфейса должны преобразовывать цифровые сигналы в радиосигналы, что часто дороже, чем время, необходимое электрическому сигналу для прохождения типичного участка кабеля. Таким образом, более низкий пинг может привести к более высокой скорости загрузки и выгрузки из Интернета.
Упрощенная игровая архитектура В то время как однопользовательская игра поддерживает основное игровое состояние на локальном компьютере, онлайн-игра требует, чтобы оно поддерживалось на центральном сервере, чтобы избежать несоответствий между отдельными клиентами. Таким образом, клиент не имеет прямого контроля над центральным игровым состоянием и может только отправлять запросы на изменение на сервер и может обновлять локальное игровое состояние только путем получения обновлений с сервера. Эта потребность в общении вызывает задержку между клиентами и сервером и является основной причиной отставания. Хотя может быть множество основных причин, по которым игрок испытывает отставание, их можно резюмировать как недостаточное оборудование на клиенте или сервере или плохое соединение между клиентом и сервером.
Проблемы, связанные с оборудованием, вызывают отставание из-за фундаментальной структуры игровой архитектуры. Как правило, игры состоят из зацикленной последовательности состояний или «фреймов». Во время каждого кадра игра принимает вводимые пользователем данные и выполняет необходимые вычисления (AI, графика и т. Д.). Когда вся обработка завершена, игра обновит состояние игры и произведет вывод, такой как новое изображение на экране и / или пакет, который будет отправлен на сервер. Частота, с которой генерируются кадры, часто называется частотой кадров. Поскольку центральное состояние игры находится на сервере, обновленная информация должна быть отправлена от клиента на сервер, чтобы вступить в силу. Кроме того, клиент должен получить необходимую информацию от сервера, чтобы полностью обновить состояние. Создание пакетов для отправки на сервер и обработка полученных пакетов может выполняться только так часто, как клиент может обновлять свое локальное состояние. Хотя пакеты теоретически могут быть сгенерированы и отправлены быстрее, чем это, это приведет к отправке избыточных данных только в том случае, если состояние игры не может быть обновлено между каждым пакетом. Следовательно, низкая частота кадров сделает игру менее отзывчивой на обновления и может заставить ее пропускать устаревшие данные.
И наоборот, то же самое верно и для сервера. Частота кадров (или тиковая частота) сервера определяет, как часто он может обрабатывать данные от клиентов и отправлять обновления. Проблемы такого типа сложно предсказать и компенсировать. Помимо соблюдения минимальных требований к оборудованию и попытки оптимизировать игру для повышения производительности, нет реальных способов справиться с этим.
Возможно, наиболее распространенный тип задержек вызван проблемами производительности сети. Потери, повреждение или дрожание (устаревший пакет фактически является потерей) могут вызвать проблемы, но эти проблемы относительно редки в сети с достаточной пропускной способностью и без перегрузки или с небольшой перегрузкой. Вместо этого важную роль играет задержка, связанная с передачей данных между клиентами и сервером. Задержка зависит от ряда факторов, таких как физическое расстояние между конечными системами, поскольку большее расстояние означает дополнительную длину передачи и необходимую маршрутизацию и, следовательно, более высокую задержку. Маршрутизация через Интернет может быть чрезвычайно непрямой, что приводит к гораздо большей длине передачи (и, как следствие, задержке), чем при прямом маршруте, хотя облачный игровой сервис OnLive разработал решение этой проблемы, установив пиринговые отношения с несколькими сетевыми интернет-провайдерами уровня 1. и выбор оптимального маршрута между сервером и пользователем. Кроме того, недостаточная пропускная способность и перегрузка, даже если они недостаточно серьезны, чтобы вызвать потери, могут вызвать дополнительные задержки независимо от расстояния. Как и в случае с аппаратными проблемами, пакеты, которые поступают медленно или не приходят вообще, не позволяют клиенту и серверу своевременно обновлять состояние игры.
Системы онлайн-игр, использующие беспроводную сеть, могут иметь значительную задержку в зависимости от архитектуры беспроводной сети и локальных электромагнитных помех, влияющих на эту сеть. Электромагнитные помехи (например, от микроволновой печи ) могут вызывать потерю передаваемых пакетов, что требует повторной передачи, что приводит к задержке. Хотя распространение радиоволн по воздуху происходит быстрее, чем по оптическому волокну, беспроводные системы часто используются совместно многими пользователями и могут страдать от задержек, возникающих из-за перегрузки сети или из-за сетевых протоколов, которые приводят к задержкам.
Заметные эффекты запаздывания различаются не только в зависимости от точной причины, но также и от всех без исключения методов компенсации запаздывания, которые может реализовать игра (описанных ниже). Поскольку все клиенты испытывают некоторую задержку, реализация этих методов для минимизации воздействия на игроков важна для плавного игрового процесса. Задержка вызывает множество проблем, таких как точное отображение состояния игры и обнаружение попаданий. Во многих играх задержка часто не одобряется, потому что она мешает нормальному игровому процессу. Степень задержки зависит от типа игры и присущей ей терпимости к лагу. Некоторые игры с более медленным темпом могут терпеть значительные задержки без какой-либо необходимости в компенсации, тогда как другие игры с более быстрым темпом значительно более чувствительны и требуют широкого использования компенсации, чтобы в них можно было играть (например, в жанре шутера от первого лица). Из-за различных проблем, которые могут вызывать задержки, игрокам с недостаточно быстрым подключением к Интернету иногда не разрешается или не рекомендуется играть с другими игроками или серверами, которые имеют удаленный серверный хост или имеют высокую задержку друг с другом. Крайние случаи задержки могут привести к значительной десинхронизации состояния игры.
Задержка из-за недостаточной скорости обновления между клиентом и сервером может вызвать некоторые проблемы, но обычно они ограничиваются самим клиентом. Другие игроки могут заметить резкие движения и аналогичные проблемы с игроком, связанным с затронутым клиентом, но настоящая проблема заключается в самом клиенте. Если клиент не может обновить состояние игры в достаточно быстром темпе, игроку могут быть показаны устаревшие представления игры, что, в свою очередь, вызывает различные проблемы с обнаружением попаданий и столкновений. Если низкая частота обновления вызвана низкой частотой кадров (в отличие от настройки на клиенте, как позволяют некоторые игры), эти проблемы обычно затмеваются многочисленными проблемами, связанными с самой обработкой на стороне клиента. И дисплей, и элементы управления будут вялыми и невосприимчивыми. Хотя это может увеличить воспринимаемую задержку, важно отметить, что она отличается от задержек, связанных с сетью. Для сравнения, одна и та же проблема на сервере может вызвать серьезные проблемы для всех задействованных клиентов. Если сервер не может или не желает достаточно быстро принимать пакеты от клиентов и своевременно их обрабатывать, действия клиентов могут никогда не быть зарегистрированы. Когда сервер затем отправляет обновления клиентам, они могут зависать (игра не отвечает) и / или откатываться, в зависимости от того, какие типы компенсации задержки, если они есть, используются в игре.
Напротив, задержка из-за задержки в сети часто не является проблемой. Хотя это чаще встречается, фактические эффекты обычно меньше, и эти типы задержек можно компенсировать. Без какой-либо компенсации задержки клиенты заметят, что игра реагирует только через короткое время после выполнения действия. Это особенно проблематично в шутерах от первого лица, где враги могут двигаться, когда игрок пытается стрелять в них, и вероятность ошибки часто мала.
Существуют различные методы сокращения или сокрытия задержек, хотя многие из них имеют свои недостатки и могут быть применимы не во всех случаях. Если синхронизация невозможна самой игрой, клиенты могут выбрать игру на серверах в географической близости от себя, чтобы уменьшить задержки, или серверы могут просто отказаться от клиентов с высокими задержками, чтобы избежать необходимости решать возникающие проблемы. Однако это вряд ли оптимальные решения. Вместо этого игры часто разрабатываются с учетом компенсации лагов.
Многие проблемы можно решить, просто позволив клиентам отслеживать свое собственное состояние и отправлять абсолютные состояния на сервер или напрямую другим клиентам. Например, клиент может точно указать, в какой позиции находится персонаж игрока или в кого он стрелял. Это решение работает и практически устраняет большинство проблем, связанных с задержкой. К сожалению, он также основан на предположении, что клиент честен. Нет ничего, что мешало бы игроку изменять данные, которые он отправляет, напрямую клиенту или косвенно через прокси, чтобы гарантировать, что они всегда будут поражать свои цели. В онлайн-играх риск обмана может сделать это решение невыполнимым, и клиенты будут ограничены отправкой относительных состояний (т. Е. По какому вектору оно переместилось или выстрелило).
Поскольку клиентам обычно не разрешается определять основное состояние игры, а скорее получать его от сервера, основная задача компенсации на стороне клиента - максимально точно отрисовать виртуальный мир. Поскольку обновления приходят с задержкой и даже могут быть сброшены, клиенту иногда необходимо предсказать ход игры. Поскольку состояние обновляется дискретными шагами, клиент должен иметь возможность оценить движение на основе доступных образцов. Для этого можно использовать два основных метода; экстраполяция и интерполяция.
Экстраполяция - это попытка оценить будущее состояние игры. Как только пакет от сервера получен, позиция объекта обновляется до новой позиции. В ожидании следующего обновления следующая позиция экстраполируется на основе текущей позиции и движения во время обновления. По сути, клиент будет предполагать, что движущийся объект продолжит движение в том же направлении. При получении нового пакета положение может быть немного скорректировано.
Интерполяция по существу буферизует состояние игры и отображает состояние игры игроку с небольшой постоянной задержкой. Когда приходит пакет от сервера, вместо немедленного обновления позиции объекта клиент начинает интерполировать позицию, начиная с последней известной позиции. В течение интервала интерполяции объект будет плавно перемещаться между двумя положениями. В идеале этот интервал должен точно соответствовать задержке между пакетами, но из-за потерь и переменной задержки это бывает редко.
У обоих методов есть достоинства и недостатки.
Часто, чтобы обеспечить плавный игровой процесс, клиенту разрешается вносить мягкие изменения в состояние игры. В то время как сервер может в конечном итоге отслеживать боеприпасы, здоровье, положение и т. Д., Клиенту может быть разрешено прогнозировать новое игровое состояние на стороне сервера на основе действий игрока, таких как разрешение игроку начать движение до того, как сервер ответит. к команде. Эти изменения обычно принимаются при нормальных условиях и делают задержку в основном прозрачной. Проблемы возникнут только в случае больших задержек или потерь, когда предсказания клиента очень заметно отменяются сервером. Иногда, в случае незначительных отличий, сервер может даже разрешить «неправильные» изменения состояния на основе обновлений от клиента.
В отличие от клиентов, сервер знает точное текущее состояние игры, и поэтому в прогнозировании нет необходимости. Основная цель компенсации задержки на стороне сервера - вместо этого обеспечить точный эффект действий клиента. Это важно, потому что к тому времени, когда пришла команда игрока, время сдвинется, и мир больше не будет в том состоянии, которое игрок видел, отдавая свою команду. Ярким примером этого является обнаружение попаданий для оружия, стреляющего в шутерах от первого лица, где поля невелики и потенциально могут вызвать серьезные проблемы при неправильном обращении.
Другой способ решить эту проблему - сохранить прошлые игровые состояния в течение определенного периода времени, а затем перемотать назад местоположения игроков при обработке команды. Сервер использует задержку игрока (включая любую присущую задержку из-за интерполяции; см. Выше), чтобы перемотать время на соответствующую величину, чтобы определить, что стреляющий клиент видел во время выстрела. Обычно это приводит к тому, что сервер видит, что клиент стреляет в старую позицию цели и, таким образом, попадает. В худшем случае игрок будет настолько отставать, что на сервере закончатся исторические данные, и ему придется начинать опережать свои цели.
Это решение WYSIWYG, которое позволяет игрокам целиться прямо в то, что они видят. Но цена - усиление эффектов задержки, когда игрок находится под огнем: не только его собственная задержка играет роль, но и их атакующий тоже. Во многих ситуациях это незаметно, но игроки, которые только что укрылись, заметят, что они продолжают получать сообщения о повреждениях / смерти от сервера дольше, чем их собственная задержка может оправдать. Это может чаще приводить к (ложному) впечатлению, что они прошли сквозь укрытие, и (не совсем неточному) впечатлению « медленных хитбоксов ».
Одна из дизайнерских проблем, возникающая при перемотке, заключается в том, следует ли останавливать перемотку отставших команд мертвого игрока, как только они умирают на сервере, или продолжать их выполнение, пока они не «догонят» время смерти. Отключение компенсации немедленно не дает жертвам посмертно атаковать своих убийц, что оправдывает ожидания, но сохраняет естественное преимущество перемещения игроков, которые завернут за угол, захватят цель и убьют их за меньшее время, чем поездка туда и обратно к стационарному клиенту жертвы.
Перемотку можно критиковать за то, что высокая задержка одного игрока негативно влияет на качество воспроизведения игроков с низкой задержкой. Серверы с компенсацией задержки иногда сокращают длину сохраняемой истории игроков или устанавливают ограничения на пинг, чтобы уменьшить эту проблему.
Клиенты могут сообщать серверу, что они делают, а сервер может доверять получаемым данным. Этого метода избегают, если это вообще возможно, из-за его восприимчивости к мошенничеству : просто направить сетевые данные через второй компьютер, который вставляет сфабрикованные сообщения о попаданиях или изменяет существующие, метод, который не может быть обнаружен средствами защиты от мошенничества.
Однако огромный масштаб некоторых игр делает невозможными вычислительно дорогостоящие решения, такие как перемотка назад. В Battlefield 3, например, используется система «гибридного обнаружения попаданий», когда клиенты сообщают серверу, что они попали, и сервер выполняет лишь неопределенную проверку правдоподобия, прежде чем принять заявку.
В остальном доверие к результатам клиента имеет те же преимущества и недостатки, что и перемотка.
Менее распространенное решение задержки - ничего не делать на сервере и экстраполировать каждого клиента (см. Выше), чтобы покрыть свою задержку. Это дает неверные результаты, если удаленные игроки не поддерживают постоянную скорость, предоставляя преимущество тем, кто уклоняется назад и вперед или просто начинает / прекращает движение.
Расширенная экстраполяция также приводит к тому, что удаленные игроки становятся видимыми (хотя и не уязвимыми), когда они не должны быть такими: например, если удаленный игрок бежит в угол, а затем резко останавливается на краю, другие клиенты будут отображать их бегущими вперед, в открытое пространство, на время их собственной задержки. С другой стороны, клиенты должны дать удаленным игрокам, которые только начали двигаться, дополнительный прирост скорости, чтобы подтолкнуть их к теоретически точному предсказанному местоположению.
Можно уменьшить восприятие лагов с помощью игрового дизайна. Методы включают воспроизведение анимации на стороне клиента, как если бы действие произошло немедленно, уменьшение / удаление встроенных таймеров на хост-машине и использование переходов камеры для скрытия деформации.
Облачные игры - это тип онлайн-игр, в которых вся игра размещается на игровом сервере в центре обработки данных, а пользователь запускает только тонкий клиент локально, который перенаправляет действия игрового контроллера вверх на игровой сервер. Затем игровой сервер предоставляет следующий кадр игрового видео, которое сжимается с помощью низкой задержки сжатия видео и направляется вниз по течению и распакованное тонким клиентом. Для того, чтобы облачный игровой процесс был приемлемым, задержка в оба конца всех элементов облачной игровой системы (тонкий клиент, подключение к Интернету и / или локальной сети и игровому серверу, выполнение игры на игровом сервере, видео и аудио) сжатие и декомпрессия, а также отображение видео на устройстве отображения ) должны быть достаточно низкими, чтобы пользователь воспринимал игру как локальную. Согласно OnLive, из-за таких жестких требований к задержке в игру вступают соображения расстояния, связанные со скоростью света через оптическое волокно, что в настоящее время ограничивает расстояние между пользователем и игровым сервером облачных игр примерно 1000 милями. Также много споров вызывает отставание, связанное с облачными играми. В многопользовательских играх с использованием сетевой архитектуры клиент / сервер компьютер игрока визуализирует игровую графику локально, и на сервер отправляется только информация о действиях игрока в игре. Например, когда игрок нажимает кнопку, персонаж на экране мгновенно выполняет соответствующее действие. Однако последствия действия, такие как убийство врага, видны только после небольшой задержки из-за времени, которое требуется для того, чтобы действие достигло сервера. Это приемлемо только до тех пор, пока отклик на ввод игрока достаточно быстрый.
При использовании облачных игр действия игрока могут привести к коротким задержкам до тех пор, пока он не увидит ответ. Входные данные сначала должны быть переданы на удаленный сервер, затем сервер должен начать рендеринг графики выполняемого действия и передавать видео обратно на проигрыватель по сети, что требует дополнительного времени. Таким образом, игрок испытывает заметную задержку между нажатием кнопки и тем, что что-то происходит на экране. В зависимости от навыков и опыта игрока это может вызвать дезориентацию и замешательство, подобное отложенной акустической обратной связи, и затруднить навигацию и прицеливание в игровом мире. При быстром вводе длинного комбинированного хода экранный символ не будет синхронизироваться с нажатиями кнопок. Обычно это вызывает сильное замешательство у игрока, в результате чего комбинационный ход оказывается неудачным.
Дополнительная задержка ввода также может затруднить игру в некоторые одиночные игры. Например, если враг атакует игрока, и ожидается, что игрок блокирует его, то к тому времени, когда на экране игрока будет показано, что враг начал атаку, враг уже нанесет удар и убьет игрока на сервере.
