Извините, ничего не найдено.

Nikich · 15.07.2015, 02:27

Кто подскажет, почему в геймдеве так редко используются peer-to-peer соединения? Я, видимо, чего-то не понимаю, ведь это крутая фича: геймеры могли бы играть друг с другом без внешних IP адресов и всяких хамачи.

Nex · 15.07.2015, 03:05

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

moka · 15.07.2015, 03:41

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

Также у p2p проблемы в NAT'ом, и обход не всегда прост, соеденится с сервером за публичным IP намного проще.

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

Ну и последний пункт - с точки зрения бизнеса, в идеале разраб хочет контролировать серверную часть и зависимость от своего сервиса, чтобы на этом деньги зарабатывать. У p2p есть куча усложнений например с читами и не честным качем, далее ММО элемент будет почти не возможен, и будет куча куча дырок в такой системе.

В общем, это не так и круто как оно может показаться.

RBK · 15.07.2015, 03:44

Я думаю основная проблема - NAT.

Arton · 15.07.2015, 14:31

О да, NAT это большая проблема, не говоря уже о разных провайдерах интернета у игроков.

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

Кстати больше проблем возникает когда у игроков домашние роуторы. Не умеют настраивать из-за этого сложности.

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

Igor · 15.07.2015, 15:43

Используются - например, для скачивания обновлений. (как минимум, танки и вов) Имхо, идеальное решение - от сервера достаточно получить хеш-сумму для верификации, а скорость загрузки от других игроков может быть намного выше, чем с сервера (например, у меня внутри локалки скорость загрузки торрентами может достичь 10мегабайт в секунду, и извне скорость раз в десять меньше). Да и не сможет централизованный сервер сразу всем игрокам обновление раздать по-быстрому.
P.S. если не ошибаюсь, соединить друг с другом двух пользователей без внешнего ip, если есть внешний сервер, вполне можно. (В смысле, оба подключаются к серверу, а потом сервер делает какой-то финт и трафик начинает идти сразу от первого ко второму, сервер нужен только для создания соединения) Я про это читал, но реализовывать не пробовал

Nikich · 15.07.2015, 16:51

Вот я тоже долгое время думал, что NAT -- это проблема. А на днях работал с WebRTC и оказалось, что есть куча методов соединить юзеров без внешних адресов и мы с этим довольно таки часто сталкиваемся (скайп, торренты).
Даже если P2P архитектура и не всегда допустима, все равно непонятно, почему разработчики не реализуют обход NAT'a.

moka · 15.07.2015, 17:31

Сообщение от Igor

Используются - например, для скачивания обновлений. (как минимум, танки и вов) Имхо, идеальное решение - от сервера достаточно получить хеш-сумму для верификации, а скорость загрузки от других игроков может быть намного выше, чем с сервера (например, у меня внутри локалки скорость загрузки торрентами может достичь 10мегабайт в секунду, и извне скорость раз в десять меньше). Да и не сможет централизованный сервер сразу всем игрокам обновление раздать по-быстрому.
P.S. если не ошибаюсь, соединить друг с другом двух пользователей без внешнего ip, если есть внешний сервер, вполне можно. (В смысле, оба подключаются к серверу, а потом сервер делает какой-то финт и трафик начинает идти сразу от первого ко второму, сервер нужен только для создания соединения) Я про это читал, но реализовывать не пробовал

torrent

Сообщение от Nikich

Вот я тоже долгое время думал, что NAT -- это проблема. А на днях работал с WebRTC и оказалось, что есть куча методов соединить юзеров без внешних адресов и мы с этим довольно таки часто сталкиваемся (скайп, торренты).
Даже если P2P архитектура и не всегда допустима, все равно непонятно, почему разработчики не реализуют обход NAT'a.

Реализуют тем кому нужно.
Просто p2p - не панацея логически с точки зрения сети и ответственности за данные и принятия решений в логике приложений.

Nex · 18.07.2015, 14:07

Player.IO. Сетевые архитектуры

Igor · 18.07.2015, 23:45

Имхо, можно построить читероустойчивую п2п архитектуру, если использовать наработки из криптографии. Подробнее напишу завтра, когда обдумаю получше. Основная идея в том, чтобы при возникновении разногласий устраивать "суд " и кикать виноватого. Если "для разборок" не использовать внешние сервера, то нужно, чтобы читеров было меньше половины. Если привлекать ' главный сервер', то, в принципе, достаточно одного не читера, чтобы банить остальных раз за разом. Криптография будет нужна для некоторых деталей реализации

moka · 19.07.2015, 00:50

Криптография? Речь идет о читах - что есть логическая задача, не криптографическая. Или ты о сверения "хеш сум" вычислений - как часть механики обмена результатами?

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

Igor · 19.07.2015, 13:06

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

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

Клиент к каждому исходящему сообщению добавляет хэш состояния мира, а потом подписывает своим закрытым ключом. Зачем? Чтобы сторона, получившая сообщение, могла впоследствии предъявить его "судье" - подпись гарантирует, что сообщение отправил именно первый клиент, и что оно не было изменено.

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

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

Например, есть цепочка состояний A->B->C, причём разногласия в состоянии B, а в А - нет.
Клиент подписал все исходящие сообщения, а так же подписал сообщение о том, что он получил данные от других игроков.
Тогда "судья" просто может взять состояние А, взять входящие на тот момент сообщения, вычислить состояние B и сравнить его с состоянием у игрока.

Если состояние игрового мира большое (по количеству информации), можно разбить его на независимые кусочки (или частично независисые) и передавать хэш каждого кусочка - тогда для проверки не надо будет загружать всё состояние целиком.

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

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

Главный сервер всё ещё нужен, но нагрузка на него будет на порядки меньше.

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