Написание правильного и корректного сетевого кода — задача достаточно простая. Надо только немного подучить и «попробовать» Winsock. Но необходимо так же писать и быстрый код, иначе удовольствия от игры по сети (а, точнее, по модему) особого не получишь. Достаточно вспомнить оригинальный Quake. Если кто пробовал играть в эту игрушку по модему, думаю, не один десяток нелитературных выражений отмочил :).
В данном случае идет речь о соединении клиент-сервер, когда клиент посылает серверу данные о действиях пользователя, а сервер, обработав всех клиентов, рассылает им данные о состоянии игры.
В этом способе связи есть свои преимущества и недостатки.
Преимущества — затруднение cheating-а, клиенту не обязательно иметь навороченную конфигурацию компьютера, ведь ему надо только принять серверные данные о том, что изменилось в игровом мире и что стОит изобразить на экране. К тому же, нет специальной синхронизации для того, чтобы клиенты имели идентичные состояния игрового мира (Например, Doom не был построен по технологии клиент-сервер, каждый компьютер рассчитывал сам различные параметры игры на основе генератора псевдослучайных чисел, и приходилось все это синхронизировать).
Зато, есть очень существенные недостатки, которые практически незаметны при игре по локальной сети, но очень сильно проявляются при игре по модему. Самый главный недостаток — Ping, точнее не он сам ;), а его высокое значение. Ping — это время, за которое пакет от клиента достигает сервера, плюс время ответа сервера, плюс время прохождения пакета от сервера к клиенту. В локальной сети его значение обычно лежит в пределах от 5 до 30 мсек. При игре же по модему, значение ping может быть от 50 (ну это просто идеальные условия) и до бесконечности. Если предположить, что модемная связь будет приемлемой, значение Ping будет зависеть только от "кривости" сетевого кода и от состояния игрового мира (изменения различных параметров игровых элементов).
Таким образом, оптимизация сетевого кода, а точнее оптимизация размера передаваемых данных — очень серьезная и сложная задача.
Но, сначала, конечно же, мы рассмотрим, как все это вообще работает, а уж потом перейдем к оптимизации.
Итак, имеем: соединение посредством Winsock (можно, конечно, использовать DirectPlay, но только, чем меньше у нас посредников, тем быстрее все будет работать, не так ли ?), протокол UDP (TCP соединение в нашем случае использовать можно только в локальной сети, потому что одно из преимуществ протокола TCP — 100%-ая доставка пакетов — в данном случае превращается в огромный недостаток, ведь если пакет не доставлен успешно, его будут посылать еще раз, в состояние игры уже изменилось !).
Примеры построены с использованием открытого исходного кода Quake2. (В качестве отступления от темы, хочу сказать личное мнение об этом коде — код написан достаточно "прямо" и оптимально, безглючно и вообще, легко читается). Было бы также неплохо, если Вы будете периодически заглядывать в документацию к winsock. Полезно сначала прочитать теорию, а потом рассмотреть это на практике.
После успешного выполнения этих действий, библиотека winsock готова Вас обслужить :).
Теперь напишем метод инициализации сокетов.
Сокетов может быть не более 2-ух. Один для сервера, второй — для клиента (для выделенного сервера он не нужен).
Можно завести 2 переменные, server_socket и client_socket, а можно, как сделано в Quake2, создать массив из 2-ух элементов и заголовочном файле описать enumerator:
А в основном файле опишем массив
static int ip_sockets[] = <0,0>; // IP server & client sockets
Напишем общий метод инициализации сокетов, который будет вызываться при самой первой инициализации клиента или сервера.
В методе используется другой более конкретизированный метод инициализации сокетов по протоколу IP. Так же можно сделать инициализацию для протокола IPX.
Ну вот мы и написали методы инициализации сети. Осталось совсем немного — написать методы для посылки/приема пакетов и методы работы с локальным клиентом.
Для этих методов необходимо описание некоторых структур.
Метод посылки пакета:
Метод приема пакета:
Описание класса buffer:
Этот класс предназначен для более удобной работы с массивом данных различных типов.
Осталось только разобраться со способом передачи данных между локальными клиентом и сервером.
Сделаем имитацию работы winsock. В winsock мы можем послать несколько пакетов другому компьютеру, пока он их будет принимать, то есть, надо создать некоторую очередь для пакетов. В Quake2 это реализовано достаточно простым и оригинальным способом — через "закольцованный" массив. Можно это сделать с использованием STL + класс buffer. Но как я уже сказал ранее, код Quake2 написан достаточно оптимально, к тому же, нам не нужны методы класса buffer, нам нужен просто массив и переменная его размера, поэтому для примера используем оригинальный код.
Ну а теперь сами методы:
Ну, и в заключении, методы перевода "наших" адресов в winsock-compatible и обратно.
Эта была первая часть статьи. Здесь был описан низкоуровневый драйвер для работы с сетью. Напрямую он практически не используется движком. Во второй части будет описан класс, с которым непосредственно будет работать движок. В нем будет реализовано несколько интересных вещей, самая главная из которых — возможность 100% доставки "важных" данных (reliable data). Но это будет позже.
«Сетевой код» — один из наиболее важных и сложных составляющих шутеров от первого лица. За последние полгода DICE LA отлично постарались и внесли в него множество улучшений.
Недавно автор канала Battle(non)sense пообщался с одним из активно задействованных в работе над сетевым кодом разработчиков и задал ему множество вопросов о последних изменениях в тестовой ветке Battlefield 4. В этом видео автор объясняет, как работают эти изменения, развеивает некоторые заблуждения и рассказывает, как работает «сетевой код». Перевод от EAshooters.ru.
Текстовая версия:
В течение последнего полугодия DICE LA потратили много времени и усилий на доведение сетевого кода до такого состояния, когда мы можем просто наслаждаться игрой. Было добавлено много новых функций, а существующий код был оптимизирован и доработан.
Поиграв в бф4 сегодня на ПК, я могу с уверенностью сказать, что их работа очень действенно повлияла на игру. Впрочем, положение дел все еще не идеально. Время от времени со мной случаются очень странные смерти, а начисление урона по-прежнему остается проблемой. Правда, над этим работают. Главное — то, что теперь я могу попросту наслаждаться игрой больше чем полгода назад, до всех этих исправлений.
К счастью, DICE LA не остановились после первых нескольких месяцев развития тестовой среды для сообщества. Они до сих пор работают над исправлением и улучшением сетевого кода. Недавно в тестовом режиме вышло немаленькое обновление, призванное еще больше улучшить ощущения от игры.
Впрочем, эти изменения не просто понять, прочитав о них. «Добавлен конус высокой частоты сетевого обновления» — это забавно читать в патчноуте, но четко представить себе, что это такое, сложно.
На прошлой неделе мне выпала возможность пообщаться с одним из разработчиков, которых активно занят работой над изменениями сетевого кода. Как вы догадываетесь, я просто засыпал его вопросами. После этого приятного разговора я получил достаточно четкое представление о том, как сейчас работает сетевой код в тестовом режиме. Так как рано или поздно эти изменения войдут в публичную версию БФ4, я решил сделать это видео и пояснить, как сейчас работает сетевой код.
Давайте освежим память и вспомним основы. Сервер и клиент (которым могут быть как ПК так и консоль), общаются друг с другом. Это общение происходит с интервалами, которые отличаются для отправки данных и их получения. Эти интервалы также называют «тикрейтом». Итак, клиент отправляет серверу 30 обновлений в секунду. Эта частота фиксирована и не изменяется.
Получение обновлений от сервера происходит со значительно более низкой частотой — 10 раз в секунду. То есть одно обновление за 100 миллисекунд. Можно представить, что ваш клиент смотрит наблюдает за остальными игроками в видео с частотой 10 кадров в секунду. То есть это больше похоже на слайдшоу, чем на плавную анимацию. Затем клиент восполняет пробелы между полученными обновлениями, пытаясь предсказать, что делают остальные игроки. Благодаря этому на наших экранах мы видим плавные движения.
Проблема с подобной частотой кадров заключается в том, что картинка, которую вы в данный момент видите, уже достаточно устарела. Это особенно актуально для плотного боя в закрытом пространстве, где часто встречаются расстройства типа убийств за углом. Дело в том, что на экране стрелявшего вы еще не скрылись за углом. Впрочем, и на большой дистанции порой непросто попасть в движущуюся цель — которая может быть не там, где вы ее наблюдаете.
Другая проблема заключается в том, что при 10 обновлениях в секунду любое оружие со скорострельностью выше шестисот выстрелов в минуту стреляет быстрее, чем может обновиться игра. То есть обновлений проходит меньше, чем выпущено пуль. Таким образом происходит ситуация, когда за один кадр вы получаете урон несколько раз — и это очень расстраивает.
Поэтому DICE LA внедрили в Battlefield 4 поддержку высокой частоты сетевого обновления. Таким образом игра может получать обновления 10, 15, 20 и 30 раз в секунду. Основываясь на показателях сетевого соединения, игра определит, какое значение использовать. Вы можете узнать, какая частота используется в настоящий момент, взглянув на оверлей качества сети. Если вы видите цифру 30, то ваш клиент получает от сервера 30 обновлений в секунду. Соответственно, если в графе указана цифра 20, то 20 раз в секунду и так далее. Тем не менее, отправляются данные всегда 30 раз в секунду. Это фиксированное и неизменяемое значение.
Теперь, когда мы освежили память, пора разобраться, где именно действует высокая частота сетевого обновления — это принцип недавно изменился в тестовой ветке Battlefield.
Это — разведчик армии США. Перед ним в виде полусферы действует высокая частота сетевого обновления с радиусом 40 метров. Кроме этого, перед бойцом простирается конус высокой частоты сетевого обновления, направленный в соответствии с направлением обзора. Если внутри зеленой зоны появится враг, то данные о его положении и ориентации будут приниматься с максимально возможной частотой, узнать которую можно в оверлее. В данном случае это 30 обновлений действий врага в секунду.
Кроме того, внутри этого конуса действуют и другие частоты. На расстоянии до 100 метров конус поддерживает максимальную частоту показа позиции и ориентации положения врага. За стометровой отметкой начинается линейный спад частоты сетевого обновления. На отметке в 300 метров конус заканчивается. Это означает, что для территорий снаружи конуса и полусферы мы получаем обновления положения и ориентации врага 10 раз в секунду. Это действительно полезно для перестрелок на больших дистанциях, но разработчики этим не ограничились.
Когда вы вскидываете оружие для прицеливания, то замечаете, что поле вашего обзора сужается, отсекая зоны слева и справа, а вы больше сконцентрированы на том, что расположено на удалении. В этот момент происходит увеличение длины конуса, на расстоянии до 100 метров используется максимальная частота показа позиции и ориентации положения врага. Но на трехсотметровой отметке конус не заканчивается, простираясь за нее. Я не могу сказать вам точное расстояние, потому что масштабирование рассчитывается при помощи множителя, который (если я правильно понял) зависит от угла обзора. Таким образом, конус у разных игроков может слегка отличаться в зависимости от выбранного в настройках угла обзора.
Все это прекрасно звучит в теории — но работает ли на практике? Чтобы выяснить это, я провел несколько тестов, в ходе которых замерил задержку передачи данных положения и ориентации врага на расстоянии 125 и 225 метров. В публичной версии БФ4 на расстоянии 125 метров мне приходится ждать 216 мс, прежде чем я увижу изменение положения врага. В CTE эта задержка уменьшается до 149 мс — то есть благодаря конусу высокой частоты сетевого обновления ускорение составляет 32%. Однако на расстоянии 225 метров все становится еще интереснее. В публичной версии мне пришлось ждать обновления положения врага 300 мс. А в СТЕ задержка составила 150 мс. Это быстрее, чем на расстоянии в 125 метров в публичной версии.
Таким образом, конус высокой частоты сетевого обновления определенно работает. Это значит, что перестрелки на больших расстояниях начнут приносить больше удовольствия — ведь то, что вы видите на экране, теперь гораздо более актуально и точно.
Мы рассмотрели зону высокой частоты сети для пехоты, внутри которой вы получаете информацию о положении и ориентации врага максимально быстро. Я часто повторяю эту фразу потому, все сказанное верно только для команды врага. Позиция и ориентация союзников не обновляется чаще — вне зависимости, находятся они внутри конуса или снаружи, частота обновления составляет 10 Гц. Обычно это не является проблемой — в них нет нужды стрелять.
До сих пор я говорил про обновления положения и ориентации врага. Но что происходит, когда стреляю не я, а в меня? Как влияют зоны высокой частоты сети на то, как я получаю урон?
Скорость получения мной урона не зависит от зоны высокой частоты. Не имеет значения, находится стреляющий по мне внутри зоны или снаружи. Урон я буду получать на самой высокой частоте, вне зависимости от его положения на карте. Поэтому если в 150 метрах справа от меня есть враг, которому удается попасть в меня четырьмя первыми пулями из автомата, то я получу урон с максимально возможной частотой — в моем случае 30 Гц.
Прежде чем мы посмотрим на ширину канала, которая необходима для частоты сети в 30 Гц, давайте пройдемся по изменениям, затронувшим технику. Перед нами танк с полусферой высокой частоты сети радиусом 20 метров. Кроме того, позади него есть вторая полусфера радиусом 10 метров. Она нужна затем, чтобы корректнее обрабатывать коллизии. Помимо этого, существует такой же, как у пехоты, конус. Прильнуть к прицелу в танке нельзя, однако увеличительная опция точно таким же образом изменит конус. Таким образом функционал конуса тот же, только нужно использовать увеличительную оптику.
Так что же у нас с требованиями к ширине канала для BF4 при использовании частоты обновления сети 30 Гц? Во время тестирования я два часа играл на полном сервере на 64 человека в режиме «Большой Захват», логируя трафик TCP и UDP между процессом bf4 и сервером. По итогам этих двух часов средняя скорость загрузки составляла 16 кБ/с и пиками до 20,29 КБ/с. Отправка производилась со скоростью 4 кБ/с с пиковыми значениями 5,4 кБ/с.
После этого я сыграл два часа на полном сервере на 64 человека в режиме «Большой Захват» в тестовой версии и частотой обновления 30 Гц. Там загрузка происходила со скоростью 11 кБ/с (пики до 14 кБ/с). Скорость отправки была 2,7 КБ/с с пиковыми значениями 4,44 кБ/с. Это отчетливое снижение требуемой полосы пропускания, которая требуется для игры в BF4 с максимальной частотой сети 30 Гц. Это обрадует многих игроков со стабильным интернет-соединением, но с небольшой квотой на трафик.
Может ли это открыть дверь для более высоких частот, чем 30 Гц? Надеюсь, однажды это случится.
Вот такие изменения внесли DICE LA в тестовую версию BF4. Вскоре эти правки войдут в публичную версию игры. Если вы играете на консоли, то вполне в праве ждать этих изменений: разработчики заверили меня, что правки затронут все платформы.
Неткод — это стандартный термин, который используют геймеры и разработчики при описании достаточно обширной и сложной темы: сетевых особенностей работы онлайн игр. Для простоты, вы можете считать неткод фундаментом многопользовательской игры, и если фундамент не стабилен, то все здание шатается, и играть в данную игру становиться невыносимо сложно. Когда неткод "хорош", вы скорее всего даже не задумаетесь о нем. Но если он "плох", то что же это значит? Это первая часть перевода статьи, которая поможет вам разобраться.
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.