Создание многопользовательского сервера на го?

Question

[Artem0071]

Задача: сделать небольшую многопользовательскую WEB игру.
Описание: есть некоторое множество комнат. В каждой из комнат некоторое кол-во игроков. Каждый игрок может двигаться WASD + стрелять. При попадании в игрока - игрок исчезает.

Вопросы:
1) раз мы делаем через WEB, то используем веб-сокеты? Есть ли какие-то еще интересные и практичные варианты для моей цели? Так же, интересует максимальное кол-во игроков? Как я понимаю это 64к человек на сервер? Или же нет?
2) Как стоит разделять комнаты? Делать все в одном инстансе или для каждой комнаты свой отдельный? Хранить на одном сервере или для каждой комнаты свой личный?
3) Если на разных инстансах (или собственно серверах), то как в итоге соединять людей в них? В БД хранить порт комнаты на сервере или как то еще?
4) Как при запуске GOшного инстанса сохранять и манипулировать им? Как указывать игрокам к какому подключаться?
5*) Каким образом работает Agar.io? Если открыть вкладку WS то там пусто, каким образом общаются клиенты?
6*) Где и что можно посмотреть про именно архитектуру таких приложений?

PS. Под инстансом я говорю о запущеном бинарнике приложения
PPS. Тут вопрос именно про логику создания сервера, а не игры в частности (но если это важно, то это 2D с видом сверху)

Answer 1

[Владимир Коротенко]

Go язык общего назначения, так что все возможно.
Плюсы его в простоте. Одном бинарнике, то есть все отлично

1) раз мы делаем через WEB, то используем веб-сокеты? Есть ли какие-то еще интересные и практичные варианты для моей цели? Так же, интересует максимальное кол-во игроков? Как я понимаю это 64к человек на сервер? Или же нет?

Я бы рекомендовал UDP. Один порт и все, пробивание файрволов и серых адресов описано.
Кроме того в случае TCP добавляете второй IP и получаете N * 65000

2) Как стоит разделять комнаты? Делать все в одном инстансе или для каждой комнаты свой отдельный? Хранить на одном сервере или для каждой комнаты свой личный?

Все зависит от вашей логики. Я бы посоветовал мастер сервис, который раскидывает игрокам по воркерам и мигрирует с одного инстанса на другой как игрока так и комнату.

3) Если на разных инстансах (или собственно серверах), то как в итоге соединять людей в них? В БД хранить порт комнаты на сервере или как то еще?

В бд хранится общая конфигурация, в редисе текущий кэш для быстрого доступа

4) Как при запуске GOшного инстанса сохранять и манипулировать им? Как указывать игрокам к какому подключаться?

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

Comments

[Владислав]

Почему постоянно считают что ограничение в 64к на один IP?
Это максимальное количество портов, но у сервера слушается всего 1 порт.
По факту, это каждый клиент может открыть с сервером по 64к соединений с одного IP на каждый порт сервера, а для сервера нет ограничений, кроме как упереться в систему ввода/вывода и в потребление памяти на каждое соединение.

Просьба, перестать заблуждаться и вводить в других в заблуждение)
https://stackoverflow.com/questions/2332741/what-i...

[Станислав Бодро́в]

Я бы рекомендовал UDP. Один порт и все, пробивание файрволов и серых адресов описано.

Не совсем понятно про пробивание сетевых фильтров (файрволов) пакетами UDP. И серых адресов.

Кроме того в случае TCP добавляете второй IP и получаете N * 65000

Что за случай такой?

[Владимир Коротенко]

Станислав Бодро́в,
1 вопрос
https://en.wikipedia.org/wiki/UDP_hole_punching

2 вопрос
Это тот случай когда сервер должен держать кучу открытых к клиентам.

[Vitsliputsli]

Владимир Коротенко,
1) Имеется ввиду обход ограничений на подключение извне, если клиент за NAT? Из выражения "пробивание сетевых фильтров" мало что понятно.
2) Зачем между 1 сервером и 1 клиентом более 65000 соединений?

Answer 2

[Станислав Бодро́в]

Создание многопользовательского сервера на го? Задача: сделать небольшую многопользовательскую WEB игру.

Не вижу препятствий. Есть куда более сложные проекты на это языке.

1) раз мы делаем через WEB, то используем веб-сокеты?

Тут дело хозяйское. Можешь хоть на webRTC делать.

Так же, интересует максимальное кол-во игроков? Как я понимаю это 64к человек на сервер?

Смотря какие будут сервера. Серверам вообще всё равно сколько будет на них игроков.

2) Как стоит разделять комнаты? Делать все в одном инстансе или для каждой комнаты свой отдельный?

На уровне MVP нет. Пусть хоть хоть как-то заработает. Потом по мере роста желательно раскидать. Чтобы можно было балансировать нагрузку: в одной комнате может быть пусто, в другой густо и надо как-то ресурсы гибко предоставлять.

3) Если на разных инстансах (или собственно серверах), то как в итоге соединять людей в них? В БД хранить порт комнаты на сервере или как то еще?

Есть синхронный вариант, есть асинхронный. Но лучше MVP слепить. А потом смотреть варианты. Слишком много возможных нюансов, которые надо будет брать в расчёт.

4) Как при запуске GOшного инстанса сохранять и манипулировать им? Как указывать игрокам к какому подключаться?

Это уже про оркестрацию. Есть один проектик как раз на Go, который этим занимается.

PS. Под инстансом я говорю о запущеном бинарнике приложения

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

Comments

[Vitsliputsli]

Тут дело хозяйское. Можешь хоть на webRTC делать.

Это как?

[Станислав Бодро́в]

Можно так, можно вот так

Answer 3

[rPman]

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

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

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

На практике многие разработчики плюют на валидацию, пишут как получится (к примеру берут синглпеерный движок который ничего не проверяет типа старый unreal engine, пилят на его основе AAA MMRPG а потом получают читеров, которые кастуют любые скилы любым классом или летают или проходят сквозь стены и т.п.)