Что использовать для написания сервера для многопользовательской игры?

Question

[Namor14]

Я работаю над многопользовательской игрой. Начал изучать Unity и уже добился в нем определенных успехов. Но главная проблема в том, что я не могу понять, как создать правильную архитектуру сервера, которая будет отвечать за связь между клиентом Unity и уровнем БД. Ранее я уже работал с HTTP-серверами, используя .Net Core, .Net 6 и 7. Но насколько я понимаю, HTTP-связь между клиентом и сервером для многопользовательской игры совершенно некорректна. Я немного читал о протоколах UDP и TCP и стеке технологий, которые можно использовать для реализации. Я имею в виду веб-сокеты, socket.io, Lingred.Network или SignalR. Но есть 2 вещи, которые я до сих пор не могу понять для себя. Что из этого является наиболее новым для использования, обновляемым, гибким и масштабируемым в будущем, а второе - это то, как настроить серверную архитектуру с одной из этих технологий для легкой разработки и масштабирования игровой логики. Например, мне нужно получить рейтинг, инвентарь и управлять действиями игроков и т. д. Было бы здорово получить совет и абстрактное представление об этой серверной архитектуре или может у кого то есть готовые примеры.

Comments

[Петр]

Ничего нового не изобретено. Есть socket с протаколами UDP и TCP, уже поверх этого из указанного вами (HTTP и web sockets).
А socket.io, Lingred.Network или SignalR просто бибилиотеки, что используют указанное выше

[Namor14]

А какую из етих библиотек лучше использовать? socket.io ето для Node.js. Сервер хочу попробовать сделать на .Net 7.
Lingred.Network на офф странице github давно не обновлялось, а SignalR ето офф либа от Microsoft, но наскольно она юзабельна в моем варианте я не до конца понимаю

[mayton2019]

Ничего не изменилось за лет 30 интернета. TCP масштабируется идеально. Сколько хостов - столько и создавай
сокетов.

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

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

Можешь еще почитать про QUIC/http3 . Мой браузер в режиме отладки иногда показывает
подключение по этому протоколу. Это тоже надстройка над UDP. Ее созадавли для очень быстрых
и дешевых SYN-протоколов соединения. Но эта оптимизация закладывалась для браузеров и я не знаю
насколько она применима в играх.

Http с шифрованием и веб-сокеты - это просто программная надстройка над TCP.

Answer 1

[Василий Банников]

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

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

Socket.io и SignalR сделаны поверх websocket, который является расширением для HTTP и построен поверх TCP.
Lidgren network сделан поверх UDP и сейчас активно не поддерживается.

Прежде чем определить, какой именно тебе протокол и подход будет применим тебе нужно ответить на следующие вопросы:
1. Какие именно данные (сообщения) нужно передавать
2. Сколько их будет генерировать один клиент
3. Сколько клиентов должен держать сервер в рамках одной игровой сессии.
4. Какие задержки допустимы для каждого из типов сообщений.
5. Как себя должна вести игра при потере каких-то сообщений и как ты можешь попробовать их компенсировать
6. Клиентом для тебя является браузер или же десктопное/мобильное приложение, или всё сразу.

После всего этого ты сможешь определить, какой протокол тебе допустим - это будет http, вебсокеты, или вообще что-то кастомное поверх UDP или TCP.
Причём для разных типов сообщений ты можешь использовать разный транспорт. Например, для передачи информации о покупках на внутриигровом рынке ты вполне можешь использовать http, а для передачи уведомлений об этих покупках - websocket, а для передвижений персонажей и их действий во внутриигровом мире - UDP, а для загрузки информации о мире и самих игроках - TCP.

Comments

[Namor14]

Причём для разных типов сообщений ты можешь использовать разный транспорт. Например, для передачи информации о покупках на внутриигровом рынке ты вполне можешь использовать http, а для передачи уведомлений об этих покупках - websocket, а для передвижений персонажей и их действий во внутриигровом мире - UDP, а для загрузки информации о мире и самих игроках - TCP.

Кажись я понял, под разные задачи нужно использоваться разные технологии, которые наиболее подоходящие для етого. В моем случае нужно будет и то и другое и третье.
Например загрузку глобальной статистики можно осуществить с помощью http, а вот внутриигровое соревнование, кто больше соберет шариков, нужно уже делать с помощью TCP, тож же самый внутриигровой чат.
Буду копать как все ето подружить и как к нему подключать клиента
Огромное спасибо.

[Василий Банников]

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

[Namor14]

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

[Василий Банников]

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

[Namor14]

Василий Банников, Согласен, думаю будет и ситуацыя, когда буду таскать их из одного протокола в другой)))
такое во время розработки часто происходит

[Namor14]

Василий Банников, Немного погуглил, порозмышлял и пришел к выводу что буду использовать SignalR для постоянного конекшена клиентов, а HTTP в тех случеях, где можно им обойтись и не нужно двухстороннее соединение.
Только теперь нужно изучить и розобрать, как правильно использовать SignalR в тех маштабах, что я себе замыслил))