Сетевой код — это общий термин , который чаще всего используется геймерами применительно к сети в онлайн-играх и часто относится к проблемам синхронизации между клиентами и серверами. Игроки часто делают вывод о «плохих сетевых кодах», когда у них возникают задержки или когда их входные данные прерываются. Общие причины таких проблем включают высокую задержку между сервером и клиентом, потерю пакетов , перегрузку сети и внешние факторы, независимые от качества сети, такие как время рендеринга кадров или непостоянная частота кадров . [1] [2] Сетевые коды могут быть разработаны для обеспечения синхронного и бесперебойного взаимодействия между пользователями, несмотря на эти сетевые проблемы.
В отличие от локальной игры, где входные данные всех игроков выполняются мгновенно в одной и той же симуляции или экземпляре игры, в онлайн-игре существует несколько параллельных симуляций (по одной для каждого игрока), где входные данные от соответствующих игроков поступают мгновенно, а входные данные для того же кадра от других игроков поступают с определенной задержкой (большей или меньшей в зависимости от физического расстояния между игроками, качества и скорости сетевых соединений игроков и т. д.). [3] Во время онлайн-матча игры должны получать и обрабатывать вводимые игроками данные в течение определенного времени для каждого кадра (равного 16,66 мс на кадр при частоте 60 кадров в секунду ), а если ввод удаленным игроком определенного кадра (например, , кадра номер 10) поступает, когда другой уже запущен (например, в кадре номер 20, на 166,66 мс позже), происходит десинхронизация между симуляциями игроков. Есть два основных решения, позволяющих разрешить этот конфликт и обеспечить бесперебойную работу игры:
Классическим решением этой проблемы является использование сетевого кода на основе задержки. Когда вводимые данные от удаленного игрока поступают с опозданием, игра соответствующим образом задерживает вводимые данные от локального игрока, чтобы синхронизировать два ввода и запустить их одновременно. Эта дополнительная задержка может мешать игрокам (особенно при высокой задержке), но в целом изменение не очень заметно. Однако эти задержки могут быть непостоянными из-за внезапных колебаний текущей задержки. Если задержка между игроками превышает установленное окно буфера для удаленного игрока, игра должна ждать, в результате чего экраны «зависают». Это происходит потому, что сетевой код, основанный на задержке, не позволяет продолжать симуляцию до тех пор, пока не получит входные данные от всех игроков в рассматриваемом кадре. [4] Эта переменная задержка приводит к непоследовательной и неотзывчивой игре по сравнению с игрой в автономном режиме (или игрой по локальной сети ) и может негативно повлиять на производительность игрока в чувствительных к времени и динамичных жанрах, таких как файтинги . [5]
Альтернативой предыдущему сетевому коду является сетевой код отката. Эта система немедленно запускает входные данные локального игрока (чтобы они не задерживались, как в случае с сетевым кодом на основе задержки), как если бы это была офлайн-игра, и прогнозирует входные данные удаленного игрока или игроков вместо того, чтобы ждать их (при условии, что они введут тот же ввод, что и в предыдущем тике). Как только эти удаленные входные данные поступят (предположим, через 45 мс), игра может действовать двумя способами: если прогноз верен, игра продолжается как есть, совершенно непрерывно; если прогноз оказался неверным, состояние игры возвращается, и игровой процесс продолжается из исправленного состояния, что рассматривается как «прыжок» к другому игроку или игрокам (что соответствует 45 мс, как показано в примере). [1] В некоторых играх используется гибридное решение, чтобы замаскировать эти «прыжки» (которые могут стать проблематичными по мере роста задержки между игроками, поскольку остается все меньше и меньше времени на реакцию на действия других игроков) с фиксированной задержкой ввода, а затем используется откат. Откат весьма эффективен для сокрытия скачков задержки или других проблем, связанных с несогласованностью соединений пользователей, поскольку прогнозы часто оказываются верными, а игроки даже не замечают этого. Тем не менее, эта система может вызывать проблемы всякий раз, когда игра клиента замедляется (обычно из-за перегрева), поскольку могут возникнуть проблемы с разломами, приводящие к обмену билетов между машинами по неравным ставкам. Это приводит к появлению визуальных сбоев , которые прерывают игровой процесс тех игроков, которые получают вводимые данные в более медленном темпе, в то время как игрок, чья игра замедляется, будет иметь преимущество перед остальными, получая вводимые данные от других с нормальной скоростью (это известно как одно- боковой откат). [6] Для устранения этого неравномерного потока ввода (и, следовательно, неравномерного потока кадров) существуют стандартные решения, такие как ожидание поступления поздних записей на все машины (аналогично модели сетевого кода на основе задержки) или более изобретательные решения. [ нужна цитация ] решения, подобные тому, которое в настоящее время используется в Skullgirls , которое заключается в систематическом пропуске одного кадра каждые семь, чтобы, когда игра сталкивается с рассматриваемой проблемой, она могла восстановить пропущенные кадры, чтобы постепенно синхронизировать экземпляры игр. на различных машинах. [7]
Сетевой код отката требует, чтобы игровой движок имел возможность возвращать свое состояние назад, что требует внесения изменений во многие существующие движки, и, следовательно, реализация этой системы может быть проблематичной и дорогой в играх типа ААА (которые обычно имеют надежный движок и высокую производительность). -traffic network), как прокомментировал, среди прочего, продюсер Dragon Ball FighterZ Томоко Хироки. [8]
Хотя эта система часто ассоциируется с одноранговой архитектурой и файтингами, существуют формы сети отката, которые также часто используются в архитектурах клиент-сервер (например, агрессивные планировщики, обнаруженные в системах управления базами данных, включают функцию отката) и в других жанрах видеоигр . [1]
Существует популярная библиотека GGPO , лицензированная MIT , предназначенная для реализации отката сети к играм (в основном файтингам). [9]
В онлайн-играх задержка неизбежна, и качество опыта игрока строго связано с ней (чем больше задержка между игроками, тем сильнее ощущение, что игра не реагирует на их действия). [1] Задержка в сети игроков (которая в значительной степени находится вне контроля игры) является не единственным рассматриваемым фактором, но также и задержкой, присущей способу запуска игровых симуляций. Существует несколько методов компенсации задержки , используемых для маскировки или устранения задержки (особенно при высоких значениях задержки). [10]
Одно обновление игровой симуляции называется тиком. Скорость, с которой выполняется моделирование на сервере, часто называют тикрейтом сервера; По сути, это серверный эквивалент частоты кадров клиента , без какой-либо системы рендеринга. [11] Тикратия ограничена продолжительностью времени, необходимого для запуска моделирования, и часто намеренно ограничивается дополнительно, чтобы уменьшить нестабильность, вызванную колебаниями тикрейта, а также снизить затраты на процессор и передачу данных. Более низкий тикрейт увеличивает задержку при синхронизации симуляции игры между сервером и клиентами. [12] Тикрейт для таких игр, как шутеры от первого лица , часто составляет от 128 тиков в секунду (как в случае с Valorant ) , 64 тиков в секунду (в таких играх, как Counter-Strike: Global Offensive и Overwatch ), 30 тиков в секунду ( как в Fortnite и консольном издании Battlefield V ) [13] и 20 тактов в секунду (такие спорные случаи Call of Duty: Modern Warfare , Call of Duty: Warzone и Apex Legends ). [14] [15] Более низкий тикрейт также естественным образом снижает точность моделирования, [11] что само по себе может вызвать проблемы, если зайти слишком далеко или если моделирование клиента и сервера выполняется со значительно разными скоростями.
Из-за ограничений в объеме доступной полосы пропускания и времени процессора, затрачиваемого на сетевое соединение, в некоторых играх приоритет отдается определенным жизненно важным коммуникациям, ограничивая при этом частоту и приоритет менее важной информации. Как и в случае с тикрейтом, это эффективно увеличивает задержку синхронизации. Игровые движки могут ограничивать количество раз, когда обновления (симуляции) отправляются конкретному клиенту и/или определенным объектам в игровом мире, а также снижают точность некоторых значений, отправляемых по сети, чтобы помочь с использованием полосы пропускания. В некоторых случаях эта неточность может быть заметной. [11] [16]
Различные ошибки синхронизации моделирования между машинами также могут подпадать под категорию «проблем с сетевым кодом». К ним могут относиться ошибки, из-за которых симуляция на одной машине протекает иначе, чем на другой, или из-за которых некоторые вещи не передаются, когда пользователь считает, что так должно быть. [2] Традиционно в стратегических играх в реальном времени (таких как Age of Empires ) используются одноранговые сетевые модели, в которых предполагается, что симуляция будет работать одинаково на всех клиентах; Однако если один клиент по какой-либо причине выходит из строя, десинхронизация может усугубиться и оказаться необратимой. [11] [17]
Выбор в игре протокола транспортного уровня (а также его управление и кодирование) также может повлиять на предполагаемые сетевые проблемы.
Если игра использует протокол управления передачей (TCP), задержка между игроками будет увеличена. Этот протокол основан на соединении двух машин, в котором они могут обмениваться данными и читать их. Эти типы соединений очень надежны, стабильны, упорядочены и просты в реализации и используются практически во всех операциях, которые мы выполняем в Интернете (от просмотра веб-страниц до отправки электронной почты или общения в чате через IRC ) . Эти соединения, однако, не совсем подходят для скоростей сети, которые требуются для быстрых игр, поскольку этот тип протокола ( протоколы потоковой передачи в реальном времени ) автоматически группирует данные в пакеты (которые не будут отправляться до тех пор, пока не будет достигнут определенный объем информации). , если только этот алгоритм — алгоритм Нэгла — не отключен), который будет отправлен через соединение, установленное между машинами, а не напрямую (жертвуя скоростью ради безопасности). Этот тип протокола также имеет тенденцию реагировать очень медленно всякий раз, когда они теряют пакет, или когда пакеты поступают в неправильном порядке или дублируются, что может быть очень вредно для онлайн-игры в реальном времени (этот протокол не был разработан для этого типа программного обеспечения). ).
Если вместо этого игра использует протокол пользовательских дейтаграмм (UDP), соединение между машинами будет очень быстрым, поскольку вместо установления соединения между ними данные будут отправляться и получаться напрямую. Этот протокол намного проще предыдущего, но ему не хватает надежности и стабильности, и он требует реализации собственного кода для выполнения необходимых функций для связи между машинами, которые обрабатываются TCP (например, разделение данных по пакетам, автоматическое обнаружение потери пакетов). , и т. д.); это увеличивает сложность движка и само по себе может привести к проблемам. [18]