Как я могу сделать одноранговую многопользовательскую игру? [закрыто]

Как я могу сделать многопользовательскую игру P2P? Я хотел бы иметь многопользовательскую игру без сервера. Но тогда, как все клиенты знают друг друга?

Почему p2p-протокол так известен в передаче файлов, а не в многопользовательских играх?

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

Самый простой способ реализовать p2p - это лобби. Все клиенты подключаются к хосту в лобби (или в чате). Когда хост готов, игрок нажимает на кнопку start, и все они одновременно входят в игру (обычно используется в стратегических играх). Более сложный подход заключается в использовании «выпадающего списка», при котором игроки могут присоединиться и выйти из середины игры, однако это намного сложнее для реализации в p2p-игре и требует функции, называемой переносом хоста.

В большом количестве игр используется одноранговая сеть, в том числе большинство стратегий, спортивных и гоночных игр. Почти все игры для Xbox360 и PS3 используют P2P-сеть. Клиент-серверная архитектура в основном используется в шутерах от первого лица или в MMO-играх.

Клиент-сервер, как правило, проще реализовать, поскольку только 1 машина не знает всего игрового состояния, клиенты в основном всего лишь средства визуализации с некоторым прогнозом, чтобы все выглядело гладко.

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

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

А если вы новичок в общении, ознакомьтесь с другими замечательными статьями на этом сайте. Гленн - сетевой гений.

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

P2P может передавать тонны данных, но это происходит с довольно высоким пингом, игры должны передавать очень небольшие объемы данных с минимальным временем пинга.

Есть несколько интересных аспектов в одноранговых системах и экшн-играх. Я попытался опубликовать их в качестве комментария в блоге Гленна Фидлера, но, видимо, ему не нравится, когда его ошибают, и вместо этого вытащил всю статью. Это в интернет-архиве, на случай, если вы захотите его прочитать.

Он не позволил комментарии в Интернете, поэтому я процитирую его здесь:

Предложение Peer-to-Peer из первого поста на самом деле является интересной отправной точкой, хотя порой оно несколько наивно: первая возможность - объединить систему со стандартной моделью клиент / сервер с прогнозированием, как описано в вашем посте. об игровой сети. Более низкий пинг P2P резко сократит отставание в предсказании между игроками в зависимости от их местоположения: эффект, вероятно, не будет заметен для большинства игроков в США, но здесь, в Европе, пинг 200+ является нормальным на большинстве серверов, и прямое соединение уменьшит Прогнозирование отставания от европейского сервера.

Подход P2P без сервера немного сложнее: главная проблема с децентрализованными сетями - обеспечение согласованности, особенно если моделирование может пострадать из-за эффектов «бабочки» из-за немного другой синхронизации команд, отправляемых по сети, или из-за проблем с плавающей запятой. Это возможно, по крайней мере, периодически связывая состояние каждого объекта (игроков, NPC, ...). Нет необходимости делать это одновременно для всех объектов, и каждый клиент может завладеть определенными объектами. Объединение в сеть достаточного количества объектов в определенное время должно уменьшить разницу, которая накапливается между каждой синхронизацией объекта, настолько, что она становится неактуальной даже для интервалов синхронизации в секунду или более.

Вторая проблема с системами P2P - это безопасность, но она может быть решена с помощью относительно небольшого исправления в этом случае: клиенты могут использовать свои физические симуляции для сбора информации об уровне ошибок для каждого физического объекта. Физическая манипуляция всегда приводит к большей ошибке, поэтому клиенты просто «голосуют», чтобы отключиться от однорангового узла, контролирующего подозрительный объект. Кроме того, управляющие сообщения для нефизических объектов пересылаются между клиентами в зависимости от их важности: обновления игрока могут передаваться случайным образом, важные и нечастые обновления всегда следует отправлять, но все же случайному игроку. Таким образом, игрок должен будет контролировать большую часть подключенных клиентов, чтобы иметь возможность обманывать любым заметным способом.

[...]

Вы можете найти нить, на которую я ссылаюсь, по адресу http://www.devmaster.net/forums/showthread.php?t=14640 .

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

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

Хорошим примером «истинного однорангового» игрового процесса может служить стратегия в реальном времени, такая как Starcraft.

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

Когда один игрок выполняет действие, команда / ордер ('move zergling to X, Y') может быть отправлена ​​всем остальным игрокам, чтобы они выполнялись во всех случаях симуляции доли секунды спустя.

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

Однако поддерживать синхронизацию игр нетривиально, вы должны использовать фиксированный временной интервал для обновлений игровой логики и должны быть очень осторожны с использованием и заполнением генераторов случайных чисел, чтобы симуляции не расходились!

Было бы немного неискренне утверждать, что он не известен играми, в которых используется большинство игр в реальном времени (серии Star Craft, серии Command и Conquer) и многие игры FPS (Call of Duty: Modern Warfare 2).

Тем не менее, как вы узнаете об игре, зависит от службы поиска / лоббирования, которую вы используете или создаете. Но даже когда кто-то узнает об игре, все равно может быть один или несколько пиров, которые более равны, чем другие. Рассмотрим случай с 3 клиентами, желающими играть, один за открытым натом, 2 за строгим (закрытым) натсом. Открытый узел может принимать соединения от двух других. Но 2 строгих не могут напрямую соединяться друг с другом, им потребуется открытый нат для ретрансляции пакетов. Если открытый игрок выпадает из игры, то нужно будет найти другое реле или игра будет прервана.

Вы также можете проверить Badumna (www.badumna.com), который утверждает, что является одноранговым сетевым решением для онлайн-игр. Похоже, что синхронизация состояния игры осуществляется в распределенном режиме, и, согласно их веб-сайту, появится Flash-версия.

Вы, вероятно, хотите запустить с одним игроком (мы назовем его / ее "Хост") в качестве неавторизованного сервера. Все остальные игроки будут сообщать о том, что они делают на своем конце, с нашим хостом, и хост будет передавать сообщения другим игрокам.

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

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

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

Если вы делаете сравнительно простой mmorpg с низкими системными требованиями, я бы предложил создать внутреннюю программу, которая создает «частоту» на основе содержимого папки игры и того, из чего состоят файлы. Это заставит людей с одинаковой «частотой» играть на одинаковых каналах. Модифицированные, манипулируемые или обычные клиенты будут разделены. Это будет работать только для нативных хаков или модов, но я уверен, что это касается всех «тупых» мошенников. В сочетании с методом проверки ошибок, который упомянул один человек, практически ничего не требуется для модерации. Что касается портов, просто закройте порт 52225 фоновым процессом, который поддерживает подключение к маршрутизаторам без триггерных портов.