Как работает неткод и что делает его "хорошим"
Неткод - это стандартный термин, который используют геймеры и разработчики при описании достаточно обширной и сложной темы: сетевых особенностей работы онлайн игр. Для простоты, вы можете считать неткод фундаментом многопользовательской игры, и если фундамент не стабилен, то все здание шатается, и играть в данную игру становиться невыносимо сложно. Когда неткод "хорош", вы скорее всего даже не задумаетесь о нем. Но если он "плох", то что же это значит? Это первая часть перевода статьи, которая поможет вам разобраться.
Netcode - это сборное понятие, которое объединяет множество аспектов сетевых игр. В этой статье мы последовательно разберем каждый из них, чтобы вам было проще понять, что является составляющими хорошего и плохого неткода. Для начала, несколько важных терминов, которые скорее всего не раз всплывут при обсуждении неткода.
Термины, которые вам нужно знать
Пинг
Вы когда нибудь видели фильм "Охота за "Красным Октябрем", где пинг (пульс активного сонара) применяли для измерения дистанции между советской и американской подлодками?
Пинг, который можно увидеть в таблице результатов онлайн игр работает сходным образом.
Когда ПК или консоль "пингуют" сервер, они посылают ICMP (Internet Control Message Protocol) эхо-запрос игровому серверу, который затем отвечает, возвращая ICMP эхо-ответ.
Время между отправкой запроса и получением ответа является вашим пингом до игрового сервера. Это значит, что с пингом в 20ms вашим данным требуется 10ms, чтобы добраться до сервера и столько же чтобы вернуться.
Высокие значения пинга значат, что существует некая задержка или лаг. Поэтому все игроки стараются заходить на сервера с наименьшим пингом, чтобы сделать свой игровой процесс наиболее отзывчивым.
Маршрутизация
Пакет данных движется с более или менее одинаковой скоростью, поэтому пинг игрока напрямую зависит от дистанции между игровым устройством и сервером. Но так как провода не идут от вашего компьютера к серверу напрямую, а проходят через несколько промежуточных пунктов, то маршрут до сервера, который находится в соседнем городе может быть куда быстрее, чем до сервера, расположенного в паре километров от вас.
Другим фактором, который влияет на время, за которое данные достигают сервера, является количество переходов, которые пакету данных необходимо совершить. Каждый дополнительный переход увеличивает риск потери данных.
Существуют программы вроде WTFast, которые предоставляют "быстрые" (короткие) маршруты, в которых куда меньше переходов. Правда, эффективность данных сервисов зависит от вашего местонахождения и вашего провайдера. Если ваш провайдер предоставляет короткие/быстрые маршруты, то программы вроде WTFast будут малоэффективны, и временами их использование лишь увеличит задержку. Поэтому перед тем как приобрести платную подписку на один из этих сервисов, вам стоит удостовериться в том, что это принесет хоть сколько-нибудь ощутимую пользу.
Потеря пакетов
Нет никакой гарантии, что ваш пакет данных дойдет до цели. Когда он исчезает, это называется потерей пакета, что является серьезной проблемой для всех приложений, работающих в реальном времени, вроде онлайн игр, ведь повторная отправка пакета серьезно увеличивает задержку. Что может быть причиной потери пакета?
- Источник проблем в вашей локальной сети
- Проблема в сетевом интерфейсе вашего PC или в драйвере
- Помехи или перегрузка вашего WiFi или линии электропередач.
- Проблема в сетевом порте или кабеле
Потеря пакетов также может быть вызвана проблемами с прошивкой роутера или уменьшением пропускной способности канала.
Стандартными решениями подобных проблем является обновление прошивки или покупка маршрутизатора, который приоретизирует данные от приложения реального времени вроде Edge Router X.
Если же потеря пакетов происходит за пределами вашей домашней сети, то вам остается лишь обратиться к вашему провайдеру и надеяться на лучшее.
Частота обновления
Кроме задержки, которая появляется в следствие необходимости данных проделывать определенный путь (Ping), есть еще и дополнительный показатель того, насколько часто игра принимает и отсылает данные.
Если игра посылает и отправляет обновления с частотой 30Гц (30 обновлений в секунду), то время между обновлениями будет больше, чем при 60Гц. Поэтому с увеличением частоты обновления вы уменьшаете задержку, которая накладывается поверх пинга.
Низкая частота обновления влияет не только на задержку, она также может стать причиной "супер пуль", когда один выстрел из оружия наносит намного больше урона, чем должен. Подобное также называют "смерть в 1 кадр". И давайте немного подробнее остановимся на том, как это работает.
Давайте предположим, что сервер посылает 10 обновлений в секунду, что является нормой для множества кастомных серверов Call of Duty. При этой частоте, время между обновлениями составляет 100мс. За это время оружие с скорострельностью 600 выстрелов в минуту выпускает 2 пули.
Поэтому если 2 пули попадают в игру, урон от обеих пуль будет отослан в одном обновлении, и игрок может получить двойной урон от одного выстрела. Это и есть так называемая "супер пуля".
После этого описания становится понятно, почему высокая частота обновления необходима не только для уменьшения задержки, но и для того, чтобы игрокам было приятно проводить время в игре. К тому же при высокой частоте обновления небольшие потери пакетов не являются серьезной проблемой, а вот при низкой могут привести к серьезным проблемам.
Tick rate
Tick rate или частота симуляции показывает, сколько раз за секунду игра обрабатывает и создает данные.
В начале каждого тика сервер начинает обработку полученных данных и создает симуляцию того, что делали игроки, куда они двигались и в кого стреляли. Потом он отправляет результат клиентам и ждет начала следующего тика. Чем быстрее сервер завершает тик, тем раньше клиенты получают новые данные от сервера, что уменьшает задержку между игроком и сервером. Это ведет к куда более отзывчивой регистрации попаданий.
Симуляция с частотой 60Гц создаст задержку меньше, чем при 30Гц, так как это уменьшает время между шагами симуляции. Частота в 60Гц позволяет серверу создать 60 обновлений в секунду, что в сравнении с 30Гц уменьшит задержку в отсылке и прием данных примерно на 33мс.
При tickrate, равном 60Гц, у сервера есть примерно 16.66мс, чтобы завершить очередной шаг симуляции. Поэтому на серверах, работающих с фиксированным tick rate, крайне важно, чтобы сервер мог завершить симуляции раньше окончания или хотя бы в пределах заданного времени.
Когда сервер не справляется с проведением симуляции за этот промежуток времени, то результат становится заметен моментально, и геймплей начинает пестрить самыми разнообразными проблемами от телепортов игроков и незасчитанных попаданий до отказа физики и "резиновых" моделей.
Сетевые модели
Закончив с основной терминологией, пора перейти к структуре, по которой работает большинство онлайновых игр. При выборе сетевой модели у разработчиков есть три возможных варианта, каждый со своими плюсами и минусами.
1. Выделенный игровой сервер
С этой моделью разработчики могут подключить компании вроде i3d или использовать облачные сервисы вроде AWS от Amazon, Azure от Microsoft или Cloud Service от Google, чтобы создавать игровые сервера, к которым будут подключаться пользователи.
В этой модели игровой сервер работает на мощном железе и предоставляет достаточную ширину канала, чтобы нормально взаимодействовать со всеми игроками, подключенными к нему. Анти-чит и проблему регистрации попаданий игроков с высоким пингом гораздо проще контролировать из-за централизованности данного подхода.
Минусом выделенных серверов является то, что если игра не строится вокруг комьюнити, которое будет поддерживать и оплачивать эти сервера, то издателю или разработчику придется раскошелиться на их содержание.
Второй проблемой является то, что если игра выходит по всему миру, то разработчик должен удостовериться в том, что любой пользователь, купивший игру, сможет получить доступ к серверу с относительно низкой задержкой. Если этого не сделать, то разработчики заставят множество игроков пытаться играть на огромных пингах, что будет крайне плохо воспринято комьюнити.
Итог:
Выделенные сервера являются идеальным выбором для быстрых онлайн игр с более чем двумя участниками, но в то же время и самыми дорогим, ведь разработчикам приходится отдавать серьезные деньги профессиональным компаниям для поддержания серверов и предоставления достаточно широкого канала соединения.
2. Клиенсткие сервера
Другим подходом, который иногда путают с peer-to-peer, является использование ПК или консоли одного из игроков для создания игры, делая его и игроком и сервером одновременно.
Эта модель позволяет студиям сэкономить на выделенных серверах и позволяет игрокам из удаленных регионов играть с друзьями на относительно низком пинге (если они находятся недалеко друг от друга).
Одним из многих недостатков такой системы является то, что игрок, выступающий сервером, получает определенное преимущество, ведь он играет без лагов. Поэтому иногда возникают ситуации, что он может видеть противника , когда тот не видит его, и он частенько может выстрелить первым. К тому же хост может искусственно повышать задержку у всех других игроков, давая себе еще большее преимущество.
Второй проблемой является то, что при таком соединении игроки зачастую используют свой стандартный интернет канал. В худшем случае, компьютер хоста подключен через Wi-Fi, и тогда появляются многочисленные проблемы с обновлением, потери пакетов и плохая регистрация попадания. Это также накладывает ограничения на частоту обновления игры, ведь большинство интернет соединений будут страдать при 10+ игроках и частоте обновления в 60Гц.
К тому же, хост может видеть IP всех подключенных к его игре пользователей, что открывает простор для многочисленных манипуляций вплоть до DdoS'a. Да и античит хоста может вызывать определенные вопросы. Но самой раздражающей частью клиентских серверов является то, что при выходе хоста из игры все на несколько секунд замирает, пока игра не найдет того, кто станет новым хостом.
Итог: разработчики могут выбрать данную модель только для того, чтобы сэкономить, а уж никак не затем, чтобы дать игрокам возможность наслаждаться игрой.
3. Peer-to-peer
Эту модель чаще всего можно увидеть в файтингах, где матч происходит 1 на 1. Но она также есть в некоторых мультиплеерных играх вроде Destiny и For Honor, в которых в матче участвует больше двух игроков.
То, как разработчики реализуют модель выделенных и клиентских серверов, не слишком-то различается от игры к игре. То же нельзя сказать о peer-to-peer, так как существует множество различных версий. В играх Destiny, к примеру, некоторая часть симуляций производится на выделенных серверах.
Общим для всех P2P систем является то, что все клиенты напрямую взаимодейстуют друг с другом. В результате, все игроки могут видеть IP адреса всех участников матча, что зачастую не слишком-то приветствуются стримерами, которые опасаются DdoS'a. Другой проблемой игр вроде For Honor и Destiny является то, что при использовании P2P в играх с количеством участников больше двух, трафик заметно увеличивается, что может стать проблемой для пользователей со слабым соединением.
В сравнении с выделенными серверами, peer-to-peer также уменьшает способность разработчиков повлиять на появление в игре читеров и проблемы игроков с высоким пингом.
Итог: Для файтингов или спортивных симуляторов P2P подходит идеально, потому что выделенные сервера лишь увеличили бы задержку, а клиентские сервера дали бы одному из игроков некое преимущество.
Но когда дело доходит до игр с 2+ игроками и быстрым темпом геймплея, то единственным адекватным выбором остаются выделенные сервера из-за ширины канала, хороших мощностей по обработке данных, а также высокой частоты обновления и tick rate.