Netcode - Википедия - Netcode

Сетевой код это общий срок чаще всего используется геймеры для всего, что так или иначе связано с сетью в онлайн игры, часто ссылаясь на проблемы синхронизации между клиентами и серверами. Игроки обычно заявляют о «плохих сетевых кодах», когда сталкиваются с проблемами подключения в игре, хотя причины этих проблем могут быть полностью вне контроля их движка (некоторые распространенные причины: высокий задержка между сервером и клиентом, потеря пакета, перегрузка сети, так далее.). Они могут быть вызваны даже внешними факторами, не имеющими ничего общего с качеством сети, такими как время рендеринга кадра или несогласованность. частота кадров.[1][2] Netcode как термин, как правило, используется только в игровом сообществе, так как он не считается действительным. Информатика срок.[3][4]

Типы сетевых кодов

В отличие от локальной игры, где входные данные всех игроков выполняются мгновенно в одной и той же моделировании или экземпляре игры, в онлайн-игре существует несколько параллельных имитаций (по одному для каждого игрока), в которых входные данные от соответствующих игроков принимаются мгновенно, в то время как входные данные для того же кадра от других игроков поступают с определенной задержкой (большей или меньшей в зависимости от физического расстояния между игроками, качества и скорости сетевых подключений игроков и т. д.).[5] Во время онлайн-матча игры должны получать и обрабатывать данные игроков в течение определенного времени для каждого кадра (например, 16РС в 60FPS ), и если удаленный игрок вводит конкретный кадр (например, кадр номер 10), когда другой уже запущен (например, в кадре номер 20, 160 мс позже), происходит десинхронизация между симуляциями игрока. Есть два основных решения для разрешения этого конфликта и обеспечения бесперебойной работы игры:

На основе задержки

Схема исполнения и синхронизации входов двух плееров (с 90 мс пинг между ними) в онлайн-игре, которая использует сетевой код на основе задержки в одноранговой модели.

Классическим решением этой проблемы является использование сетевого кода на основе задержки. Когда входы удаленного игрока поступают поздно, игра задерживает входы локального игрока на одно и то же время, чтобы синхронизировать два входа и запускать их одновременно. Тот факт, что записи локальных игроков не запускаются мгновенно, может раздражать игроков (особенно когда между ними большая задержка), но в целом изменение не очень заметно. Настоящая проблема этой системы заключается в ее непоследовательности, поскольку задержка входов удаленного плеера может варьироваться в зависимости от текущей задержки, которая может изменяться неожиданно. Когда задержка между игроками настолько велика, что ввод удаленного игрока не может быть отправлен в буфер, скажем, 3 кадра (48 мс), игра должна ждать, в результате чего экраны «замораживаются» (сетевой код на основе задержки не позвольте моделированию продолжаться до тех пор, пока не будут получены входные данные от всех игроков в рассматриваемом кадре).[6] Поскольку эта задержка может быть переменной, это приводит к более непоследовательному и отсутствию реакции по сравнению с автономной игрой (или LAN игра) и может негативно повлиять на производительность игрока в жанрах, чувствительных к времени и быстро меняющихся, таких как файтинги.[7]

Откат

Схема выполнения и синхронизации входов двух игроков (с пингом 90 мс между ними) в онлайн-игре, в которой используется сетевой код отката в одноранговой модели.

Альтернативой предыдущему сетевому коду является откат сетевого кода. Эта система немедленно запускает входы локального игрока (так что они не задерживаются, как в случае с сетевым кодом на основе задержки), как если бы это была автономная игра, и прогнозирует входные данные удаленного игрока или игроков вместо того, чтобы ждать их (при условии, что они сделает тот же ввод, что и в предыдущем тике). Как только эти удаленные входные данные поступают (предположим, например, спустя 45 мс), игра может действовать двумя способами: если прогноз верен, игра продолжается как есть, полностью непрерывно; если предсказание было неверным, игровое состояние возвращается в исходное состояние, и игровой процесс продолжается из исправленного состояния, что рассматривается как «переход» к другому игроку или игрокам (что эквивалентно 45 мс, согласно примеру).[1] В некоторых играх используется гибридное решение, чтобы замаскировать эти «скачки» (которые могут стать проблематичными по мере роста задержки между игроками, поскольку время для реакции на действия других игроков становится все меньше и меньше) с фиксированной задержкой ввода и последующим откатом. . Откат довольно эффективен для сокрытия всплесков задержек или других проблем, связанных с несогласованностью соединений пользователей, поскольку прогнозы часто верны, а игроки даже не замечают этого. Тем не менее, эта система может создавать проблемы всякий раз, когда клиентская игра замедляется (обычно из-за перегрева), поскольку могут возникнуть проблемы с разрывом, ведущие к обмену билетами между машинами с неравной скоростью. Это порождает визуальные глюки это усложняет игровой процесс тех игроков, которые получают входные данные в более медленном темпе, в то время как игрок, игра которого замедляется, будет иметь преимущество перед остальными, получая входные данные от других с нормальной скоростью (это известно как односторонний откат).[8] Чтобы устранить этот неравномерный входной поток (и, следовательно, неравномерный поток кадров), существуют логические решения, такие как ожидание прибытия поздних записей на все машины (аналогично модели сетевого кода на основе задержки) или более изобретательные решения, такие как один в настоящее время используется в Skullgirls, который состоит из систематического пропуска одного кадра каждые семь, чтобы, когда игра сталкивается с рассматриваемой проблемой, она может восстановить пропущенные кадры, чтобы постепенно синхронизировать экземпляры игр на различных машинах.[9]

Сетевой код отката требует, чтобы игровой движок имел возможность возвращать свое состояние, что требует модификации многих существующих движков, и, следовательно, реализация этой системы может быть проблематичной и дорогостоящей. AAA типовые игры (которые обычно имеют надежный движок и сеть с высоким трафиком), как прокомментировал, среди прочего, продюсер Dragon Ball FighterZ Томоко Хироки.[10]

Хотя эта система часто ассоциируется с пиринговый архитектуры и файтингов, существуют формы откатной сети, которые также обычно используются в клиент-сервер архитектуры (например, агрессивные планировщики нашел в системы управления базами данных включить функцию отката) и в других жанры видеоигр.[1]

Существует популярная библиотека с лицензией MIT под названием GGPO разработан, чтобы помочь реализовать откат сети к игре (в основном файтинги).[11]

Возможные причины проблем с кодом сети

Задержка

Задержка неизбежно в онлайн-играх, и качество опыта игрока строго связано с этим (чем больше задержка между игроками, тем сильнее ощущение, что игра не реагирует на их действия).[1] То, что задержка сети игроков (которая в значительной степени находится вне контроля игры) является не единственным рассматриваемым фактором, но также и задержкой, присущей способу запуска игрового моделирования. Есть несколько компенсация отставания методы, используемые для маскировки или устранения задержки (особенно с высокими значениями задержки).[12]

Тикрейт

Единичное обновление симуляции игры называется галочкой. Скорость, с которой симуляция запускается на сервере, часто называется тикрейтом сервера; по сути, это серверный эквивалент клиентского частота кадров, отсутствие какой-либо системы рендеринга.[13] Тикрейт ограничен продолжительностью времени, требуемым для запуска симуляции, и часто намеренно дополнительно ограничивается, чтобы уменьшить нестабильность, вызванную колебаниями тикрейта, а также снизить затраты на ЦП и передачу данных. Более низкий тикрейт увеличивает задержку при синхронизации симуляции игры между сервером и клиентами.[14] Тикрейт для игр вроде шутеры от первого лица часто составляет 120 тиков в секунду (например, Valorant дело), 60 тиков в секунду (в играх вроде Counter-Strike: глобальное наступление и Overwatch ), 30 тиков в секунду (как в Fortnite и Battlefield V консольная версия)[15] и 20 тактов в секунду (таковы полемические случаи Call of Duty: Modern Warfare, Call of Duty: Warzone и Apex Legends ).[16][17] Более низкая скорость тика также, естественно, снижает точность моделирования,[13] что само по себе может вызвать проблемы, если зайти слишком далеко или если моделирование клиента и сервера выполняется с существенно различающейся скоростью.

Из-за ограничений в доступной пропускной способности и времени ЦП, которое занимает сетевое взаимодействие, некоторые игры отдают приоритет определенным жизненно важным коммуникациям, ограничивая частоту и приоритет менее важной информации. Как и в случае с тактовой частотой, это эффективно увеличивает задержку синхронизации. Игровые движки могут ограничивать количество раз, когда обновления (симуляции) отправляются конкретному клиенту и / или определенным объектам в игровом мире, в дополнение к снижению точности некоторых значений, отправляемых по сети, чтобы помочь с использованием полосы пропускания . В некоторых случаях эта неточность может быть заметной.[13][18]

Программные ошибки

Различные ошибки синхронизации симуляции между машинами также могут подпадать под действие «проблем сетевого кода». Они могут включать в себя ошибки, из-за которых моделирование на одной машине происходит иначе, чем на другой, или которые приводят к тому, что некоторые вещи не сообщаются, когда пользователь понимает, что они должны быть.[2] Традиционно стратегия в реальном времени игры (такие как Эпоха империй ) использовали одноранговые сетевые модели с блокировкой, в которых предполагается, что моделирование будет выполняться одинаково на всех клиентах; если, однако, один клиент по какой-либо причине выходит из строя, десинхронизация может усугубиться и ее невозможно будет исправить.[13][19]

Протокол транспортного уровня и код связи: TCP и UDP

Смотрите также: Протокол пользовательских дейтаграмм § Сравнение UDP и TCP

Выбор игры транспортный уровень протокол (а также его управление и кодирование) также может влиять на воспринимаемые сетевые проблемы.

Если в игре используется Протокол управления передачей (TCP) увеличится задержка между игроками. Этот протокол основан на соединении между двумя машинами, в котором они могут обмениваться данными и читать их. Эти типы подключений очень надежны, стабильны, упорядочены и просты в реализации и используются практически во всех операциях, которые мы выполняем в Интернете (от просмотра веб-страниц до электронной почты или чата через IRC ). Эти соединения, однако, не совсем подходят для сетевых скоростей, которые требуются в играх с быстрым действием, поскольку этот тип протокола (Протоколы потоковой передачи в реальном времени ) автоматически группирует данные в пакеты (которые не будут отправляться до тех пор, пока не будет достигнут определенный объем информации), которые будут отправлены через соединение, установленное между машинами, а не напрямую (жертвуя скоростью ради безопасности). Этот тип протокола также имеет тенденцию очень медленно реагировать, когда они теряют пакет, или когда пакеты прибывают в неправильном порядке или дублируются, что может быть очень пагубным для онлайн-игры в реальном времени (этот протокол не был разработан для этого типа программного обеспечения. ).

Если вместо этого в игре используется Протокол пользовательских датаграмм (UDP) соединение между машинами будет очень быстрым, потому что вместо установления соединения между ними данные будут отправляться и приниматься напрямую. Этот протокол намного проще, чем предыдущий, но ему не хватает надежности и стабильности, и он требует реализации собственного кода для обработки необходимых функций для связи между машинами, которые обрабатываются PCT (например, разделение данных на пакеты, автоматическое обнаружение потери пакетов. , контрольная сумма, так далее.); это увеличивает сложность двигателя и само по себе может вызвать проблемы.[20]

Смотрите также

внешняя ссылка

Рекомендации

  1. ^ а б c d Huynh, Мартин; Валарино, Фернандо (2019). Анализ моделей непрерывной согласованности в файтингах в режиме реального времени.
  2. ^ а б «Обращение к« сетевому коду »в Battlefield 4». EA Digital Illusions CE. Март 2014 г.. Получено 2014-03-30.
  3. ^ «Список терминов по программированию и информатике». Лабутопедия.
  4. ^ «Термин компьютерного программирования». Компьютерная надежда.
  5. ^ "Netcode [p1]: Fightin 'Words". ki.infil.net. Получено 2020-12-07.
  6. ^ Персонал, Ars (18.10.2019). «Объяснение того, как файтинги используют сетевой код на основе задержки и отката». Ars Technica. Получено 2020-12-07.
  7. ^ Pinnacle. «Разница между сетевым и сетевым киберспортом». Pinnacle. Получено 2020-12-01.
  8. ^ Ли, Джеральд (2020-04-08). Анализ: почему откат сетевого кода лучше (YouTube).
  9. ^ Холмы, Дакота 'DarkHorse' (29.04.2020). «Skullgirls получает улучшенное обновление сетевого кода, изначально созданное фанатом игры». EventHubs. Получено 2020-12-11.
  10. ^ Холмы, Дакота 'DarkHorse' (10.12.2020). «Эпоха сетевого кода на основе задержки может окончательно закончиться в файтингах, в зависимости от того, что SNK сделает с The King of Fighters 15». EventHubs. Получено 2020-12-10.
  11. ^ Пуш, Рики (18.10.2019). «Объяснение того, как файтинги используют сетевой код на основе задержки и отката». Ars Technica. Получено 2020-12-14.
  12. ^ «Методы компенсации задержки при проектировании и оптимизации внутриигрового протокола клиент / сервер». Сообщество разработчиков Valve. Получено 2020-12-11.
  13. ^ а б c d «Исходная многопользовательская сеть». Клапан. Получено 2014-03-30.
  14. ^ "Titanfall, de l'importance d'un bon tickrate". gamekult.com. 2014-03-29. Получено 2014-03-30.
  15. ^ «Выявлена ​​частота запросов сервера Battlefield V и почему это важно». www.glitched.online. Получено 2020-12-05.
  16. ^ Дэвисон, Итан. «Сверхбыстрые серверы Valorant массово привлекают стримеров и профессионалов. Вот почему». Вашингтон Пост. ISSN  0190-8286. Получено 2020-12-05.
  17. ^ «Насколько плох сетевой код Apex Legends по сравнению с Fortnite и PUBG?». Дексерто. 2019-11-23. Получено 2020-12-05.
  18. ^ «Нереальная сетевая архитектура». Эпические игры. Получено 2014-09-07.
  19. ^ Гленн Фидлер. «Что нужно знать каждому программисту об игровых сетях». Получено 2014-09-08.
  20. ^ Фидлер, Гленн (2008-10-01). "UDP против TCP". Gaffer в играх. Получено 2020-12-14.