Как стать автором
Обновить

Особенности установления соединения между участниками сетевой игры типа «равный к равному»

Время на прочтение 10 мин
Количество просмотров 10K
Всего голосов 12: ↑11 и ↓1 +10
Комментарии 10

Комментарии 10

Основы tcp/ip для чайников, т.е. начинающих гейм-девелоперов?
Тут только то подмножество информации по сетям, которое может пригодиться начинающим геймдевелоперам при реализации данной задачи.
Это такие азы, что не зная лучше из дома не выходить
Для кого-то это азы. Но возможно кому-то этот пост сэкономит время.
Я придерживаюсь немного другого мнения, поэтому хочу дополнить статью.

типа «равный к равному» (peer-to-peer)

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

Полностью ошибочный абзац. p2p — это когда каждый игрок подключается к каждому. Соответственно, сервера тут нет, а архитектура актуальна на сетевом уровне, а не игровом.
Трафик не зависит от сложности игрового мира

Опять же, как связан тип соединения с игровым процессом? Это разные уровни.
Объём трафика имеет порядок N²

M*(N-1)+ΣMi, где M — сложность игрового мира игрока, Mi — сложность игровых миров остальных игроков, N — количество игроков.
Игрок A запускает программу игры на своём компьютере в режиме сервера

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

Если кто-то это читает, то он должен знать, что сервер в данном случае никакого отношения к игре не имеет. Это другой сервер (подбора игроков), который запущен локально параллельно с игрой. Поэтому с таким же успехом можно купить сервер в каком-нибудь амазоне, избавиться от 90% проблем из этой статьи, а игра всё-равно останется p2p.
Если все игроки находятся в одной локальной сети, то установить соединения «каждый с каждым» достаточно просто.

Достаточно использовать топологию «шина», а точнее, один единственный broadcast адрес.

В статье описано создание режима «локальной сети» и «выделенного сервера», но никак не «онлайн мультиплеера». Для последнего в любом случае требуется сервер. А если у вас есть сервер, тогда все эти танцы вокруг udp и определения адресов становятся не нужны.
Да, конечно, в случае архитектуры клиент-сервер и выделенного сервера всех этих проблем (симметричный NAT, отключенный NAT loopback) не будет. Там будут другие проблемы (компенсация лагов из-за передачи клиент-сервер-клиент, оптимизация трафика из-за передачи всего или части состояния игрового мира). Но в этой статье я описал архитектуру peer-to-peer (перевод «равный к равному» взял из Википедии). И пришлось на практике столкнуться с этими проблемами, и разбираться как их решать.
Надеюсь, вы их решили. Расскажите, как ваши игроки узнают и передают ip/порт между собой без сервера? Сидят в дискорде?
В случае если ни один из игроков не имеет публичного IP-адреса, то игроки узнают свои внешние сервера у публичных STUN-серверов. А потом обмениваются своими внешними адресами через хостинг с веб-сервером. Этот подход я и описал в данной статье.
Спасибо. Освежил память.
Каждая «засада» из описанных знакома по отдельности, но всё вместе сильно ограничивает возможности.

З.Ы. ни разу не «сетевик» и, тем более, не геймдев. Хотя реализация p2p своими руками без сервера или сайта давно гложет извилину м/у ушами.
Спасибо! Очень полезная статья
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории