Как работает неткод и что делает его "хорошим" ч. 2

В прошлой части статьи мы обсудили основные понятия, необходимые для понимания неткода, а также разобрались в том, какие сетевые модели лучше всего подходят для определенных типов игр. В этот раз, поговорим о компенсации лагов, регистрации попаданий и основных заблуждений относительно неткода. В конце мы подведем итог, рассказав, какие показатели необходимы игре для того, чтобы ее неткод считался "хорошим".

Компенсация лагов

Каждый игрок подвержен небольшой задержке, которая появляется в результате дистанции до сервера/хоста, количеству переходов, которые должен совершить пакет данных и tick rate и update rate сервера.

Здесь в дело вступает компенсация лагов. Из-за всех этих задержек вы можете увидеть, где игрок был несколько миллисекунд назад и где он находится сейчас. Если игра не старается компенсировать хотя бы часть этой задержки, вы просто не сможете попасть в соперника. По большому счету, вы постоянно будете наводить свой прицел на пустое место.

Несмотря на то что компенсация лагов нужна, чтобы справляться с задержкой сети, многие игры делают ее слишком сильной. Это ведет к крайне неприятным моментам для игроков со стабильным соединением и небольшой задержкой. Примером может стать ситуация, когда игрок с хорошим пингом высовывается из-за укрытия, чтобы выстрелить в игрока с плохим пингом. Из-за слишком серьезной компенсации лагов, игрок с плохим пингом будет видеть своего противника еще до того, как игрок с хорошим пингом на самом деле высунется из-за этого укрытия. Я думаю, все, кто играл в Rainbow 6 Siege, сталкивались с подобной ситуацией.

Несмотря на то что играть с большой задержкой не слишком приятно, попытки компенсировать пинг в 100мс зачастую ведут к плохому игровому опыту для всех пользователей.

DICE стараются в какой-то мере исправить данную проблему, компенсируя лишь небольшую часть задержки игроков. Как только пинг переваливает за определенное значение, сервер перестает компенсировать дополнительную задержку. Это приводит к тому, что игрокам нужно самим подстраиваться под лаги, делая упреждение при стрельбе.

Это в какой-то мере помогает проблеме с получением урона в укрытии. В видео можно пронаблюдать данную механику в действии.

Хотелось бы особенно подчеркнуть, что издателям и разработчикам нужно максимально серьезно подходить к созданию региональных серверов, ведь это напрямую влияет на качество мультиплеерной игры. Причина того, что в некоторых играх много пользователей с высоким пингом, сводится к тому, что в регионах слишком мало серверов. Поэтому у игроков не остается другого выбора, кроме как заходить на сервера с пингом 150 мс.


Регистрация попаданий

Это то, как шутер определяет, попал ли ваш выстрел в кого-то.

Есть два вида регистрации попаданий. Простой и быстрый называется "hitscan", в которых у пуль нет времени полета. По большому счету, вы стреляете из лазеров. Это форма регистрации используется в шутерах с очень маленькими картами, так как время полета пули не является хоть сколько-нибудь значимым фактором при битвах на коротких дистанциях.

В играх вроде Battlefield используется куда более требовательная и сложная система физики и симуляции пуль для регистрации попаданий. У каждого снаряда есть скорость, траектория, и он подвержен нескольким факторам.

Вот так работает регистрация попаданий. Но где проводятся все эти вычисления? Здесь тоже есть несколько вариантов.

Весь процесс может проводиться в вашем игровом клиенте, который потом сообщает серверу (или в p2p другим клиентам), что вы в кого-то попали. Несмотря на то что данный метод предоставляет регистрацию с точностью до пикселя, он достаточно рискован. В основном, потому, что это делает взлом достаточно простой задачей и ведет к появлению многочисленных aim-ботов и хаков урона.

Если игра опирается на регистрацию попаданий на стороне клиента, крайне важно, чтобы сервера проверяли каждое попадание (клиентская часть, серверная авторизация).

Классический метод регистрации попаданий заключается в делегации этой задачи серверу. Клиент сообщает серверу, в каком направлении был сделан выстрел, а сервер обрабатывает эти данные и сообщает игроку, попал ли он. Это, конечно, не исключает возможности появления хакеров, но делает создание всяческих нечестных программ сложнее.


De-sync

В мультиплеерной игре каждый пользователь должен видеть одно и то же. De-sync — это когда у одного игрока дверь открыта, а у другого закрыта. Это случается, когда игра страдает от багов, проблем с производительностью или неполадок в связи между клиентом и сервером (или другими клиентами). К примеру, изменения состояния игры просто не доходят до вашего клиента или данные про взрыв бочки были отправлены, а вот о том, куда она приземлилась после взрыва, нет.


Заблуждения относительно неткода

Если вам кажется, что неткод достаточно сложен для понимания, то вы не одиноки. Вот несколько распространенных заблуждений.

  • Вам просто нужно увеличить tick rate, и высокий пинг перестанет быть проблемой:

Несмотря на то что увеличение tick rate с 30 до 60Гц и уменьшит задержку, это не является решением проблем с высоким пингом, так как то, что сервер будет чаще посылать данные, не заставит их достигать цели быстрее.

  • Вам нужен 100 Мбит интернета, чтобы играть в онлайновые игры:

Когда ваш провайдер старается максимально прорекламировать вам "высокоскоростной интернет", это говорит лишь о ширине канала, где "скорость" относится лишь к тому, насколько быстрее вы сможете завершить загрузки. Но это лишь показатель объема, а не скорости движения данных. Ширина канала не влияет на скорость движения пакетов, так что переход 10Мбит на 100Мбит не слишком-то поможет вам при игре в мультиплеерные игры.

На скорость движения данных влияет Velocity Factor(VF%) кабелей, которые связывают вас с сервером.

Velocity factor описывает скорость, с которой сигнал распространяется по кабелю, в сравнении со скоростью света. У витой пары, к примеру, это значение равно 64, а у оптоволокна VF равен 67. Большинству игр не так уж важно, насколько широк ваш канал, что можно увидеть в графике ниже.

В целом, если взять стандартный канал в 2Мбит/с, то вы не должны столкнуться с особыми проблемами при игре. Конечно же, если вы не пытаетесь параллельно передавать данные.

  • Для игр сойдет и WiFi:

Большинство сетевых проблем в онлайновых играх возникает в локальной сети игрока, и чаще всего они появляются из-за WiFi и электрической сети.

WiFi склонен к помехам: диапазон 2.4Гц зачастую забит, у диапазона 5Гц куда менее эффективная дистанция работы и куда меньше ширина канала, что быстро приводит к перегрузке сети.

Еще одним минусом WiFi является то, что если у вас нет точки доступа MU-MIMO, клиенты не могут "обращаться" к точке доступа одновременно. Это создает серьезную задержку и переменчивый пинг, ведь вашему устройству приходится ждать "своей очереди", чтобы обратиться к точке доступа, что увеличивает вероятность потери пакетов.

Так что, несмотря на то что WiFi это удобно и здорово, его крайне не рекомендуется использовать для онлайновых игр.

  • Call of Duty использует peer-to-peer:

Call of Duty никогда не использовал p2p модель. Некоторые игры CoD использовали только выделенные сервера, другие иногда добавляли к ним клиентские сервера.
 


Ингредиенты хорошего неткода

  • Использование лучшей сетевой модели:

Peer-to-peer - лучший вариант для 1v1 файтингов и спортивных игр, для всех остальных игр с двумя и более игроками и быстрым темпом лучше подойдут выделенные сервера. Хотя они и заметно дороже.

  • Игра должна быть отзывчивой:

Высокий tick и update rate уменьшают задержку и предотвращают появление "супер пуль".

  • Безопасность:

Дизайн должен быть безопасным (никогда не верить клиенту), что должно в какой-то мере предотвратить появление читеров.
К тому же, пользователям не будут особо рады, если игра будет раскрывать их IP остальным игрокам.

  • Низкая задержка — ключ к успеху:

Матчмейкинг должен избегать помещения игроков с различным пингом в одну игру. При использовании модели выделенных серверов, разработчики должны удостовериться в том, что игроки по всему миру смогут получить доступ к серверам с низким пингом. Если этого не сделать, то игроки с 150мс и игроки с 20мс, играющие на одном сервере, будут страдать практически в равной степени.

  • Ограничьте компенсацию лагов:

Даже если матчмейкинг построен так, что в матч будут помещаться игроки с примерно одинаковой задержкой, во время матча может произойти многое, и пинг пользователей может поменяться. Поэтому должен быть разумный лимит того, насколько игра компенсирует лаги, чтобы избежать создания дополнительных неудобств из-за одного игрока с нестабильным соединением.

  • Игра не должна лимитировать владельцев стандартных домашних соединений:

Количество пакетов в секунду может стать куда более серьезным ограничением, чем ширина канала. Когда игра привязывает частоту высылки пакетов клиентом к частоте кадров, это может привести к частоте выше 200Гц. В Quake Champions игроки страдают из-за телепортов именно из-за этой ошибки дизайна. Решением для них стало установление фиксированной частоты кадров на уровне, которое может выдержать их интернет соединение.

  • При появлении проблем стоит сообщить об этом пользователям:

Игроки расстраиваются, когда появляются проблемы с мультиплеерной игрой, и в первую очередь они начинают обвинять саму игру. Создатели должны сказать игрокам, что источником неприятностей является соединение, чтобы они понимали причину неполадок. Также, когда начинаются проблемы с сервером, осведомленность игроков может позволить им вовремя перейти на другой сервер.