мультиплеер с комнатами

[unregistered]

Здравствуйте! Изучаю процесс создания мультиплеера с авторитарным сервером, информации вроде и много, но она рассчитана на тех кто уже в принципе понимает архитектуру сабжа. Я же пока у истоков поэтому многое непонятно. Делал простенькую игру на photon pun, все хорошо, но сервер на стороне клиента на будущее не вариант. Посмотрел photon bolt и как понял - этот тот же самый PUN на ECS (так ли это?) Конечно посмотрел Photon Server, и тут вроде то что нужно, но из за непонимания основных принципов построения сервера изучение затормозилось.

Если можно, далее я напишу как сам все понимаю, и если не правильно, то будет удобно поправить просто цититируя кусок сообщения.
Пусть это будет сервер который обеспечивает и обработку данных игрока и матчмейкинг и сам игровой процесс(экшен). Хотя, конечно, базу игрока и экшен имеет смысл разделить.
Игрок запускает приложение вводит данные авторизации.
Приложение создает с сервером соединение и становится клиентом (peer) при удачной авторизации.
Сервер смотрит в БД по ID клиента и отправляет клиенту его игровые данные (пусть количество монет, навыки, оружие).
На основании полученных данных, клиент формирует сцену с этой информацией и пусть она называется "лобби".
Игрок жмет кнопку "Начать игру".
Клиент отправляет запрос (операцию) на сервер.
Сервер ищет не заполненные комнаты подходящие под игрока и если находит, то присоединяет игрока к такой комнате, а если нет создает новую комнату, присоединяет к ней игрока и игрок ждет заполнения.
После того как комната заполнена, сервер отправляет команду (событие) всем клиентам в этой комнате о начале матча.
Комната - это отдельный поток на сервере в который передаются пиры. Вся обработки физики, состояния мира, обмен событиями и операциями, разделение на команды происходит внутри этого потока.
Комната разрушается по условиям прекращения матча.
Вот это пока первый минимум в котором необходимо разобраться. Все знания планируется применить к Photon Server. Ну и конечно, если есть ресурс раскрывающий сабж с самых азов прошу кинуть ссылку, чтобы я тут меньше мозги вам колупал.

[Saltant]

Можно и так как ты описал сделать, но я не увидел вопроса в твоем тексте.

[unregistered]

Вопрос - правильно ли я понимаю? Конкретнее - комната - это отдельный поток с набором пиров в котором обрабатывается физика? Или комната нечто иное? Может это просто связанные списки? список комнат - список пиров, а дальше цикл. Как оно правильнее организуется? А может сервер создает вообще отдельный инстанси клиент переподключается? Есть какая-нибудь бест практик? условия игры - команды 5x5, разные локации. в целом стандартный шутер.

[Saltant]

Я не использовал Photon для таких задач. По поводу потоков (тред?) то конечно матч в одном треде это проще и даже избавит он случайных косяков, но такой подход более требовательный к ресурсам сервера, если в вашем проекте с этим проблем нет - то хорошо.
Многое зависит от онлайна, если он большой, то проще вообще логинить игроков на отдельном сервере (физическом) и далее передавать сущность в гейм сервер и на логин сервере мутить load balancer. Тем самым получается полностью (почти) снимается нагрузка на игровой сервер где собственно и происходят матчи, потому что как показывает практика огромная нагрузка как раз и идет с логина, а игровой сервер обычно просто "играет в игру" по уже +- понятной нагрузке, хотя опять же стоит понимать про уровень какого проекта мы говорим - это морской бой или какая нибудь mmo.
По поводу игровых комнат как таковых, я вижу это так: На сервере есть hub (channel, room, etc) - к нему подключаются игроки стоящие в очереди на формирование матча (нажавшие кнопку "в бой"), в этот хаб (буду называть хаб короч) передается сущность (entity) игрока тыкнувшего "в бой", в этом хабе в цикле всегда работает балансировщик - получает эту сущность и формирует команду для начала матча (формирует коллекцию с этими сущностями, присваивает ей номер с разбивкой на условные команды, ну типа: боеваяГруппа№1, сущность-Вася-команда№2, сущность-Петя-команда№2 и т.д) далее можно передать эту коллекцию в отдельный тред (а можно и не передавать) где и будут работать с ней все функции предназначенные для ведения боевого матча. Эти функции будут бродкастить все свои команды только сущностям (игрокам) в определенную боевую группу (коллекцию сущностей) и так же игроки - будут бродкастить свои ивенты только в своей коллекции сущностей, ну т.е к примеру игрок Вася стрельнул из пушки - сервак поймал бродкаст, посмотрел что это игрок Вася (его сущность) который находится сейчас вон в той боевой группе - значит надо рассказать всем пацанам с его боевой группы что Вася стрельнул из пушки вон в ту сторону и попал Пете в ногу. Далее клиенты получившие эту инфу, моделируют у себя ситуацию стрельбы Васи в ногу Пети, пуля ломает (на клиенте) горшки за которыми спрятался Петя и кровища из ноги забрызгивает пол. Сервер может сам узнать что горшки разбились, а может и не знать и получит ивент от клиента (от Пети, Васи или кого то другого кто видал это) - и сломает эти горшки уже у всех игроков в матче, если горшки не влияют на урон и работают как декорация, можно и не просчитывать их на сервере и отдать работу такой физики на сторону клиента.

[unregistered]

Спасибо, очень доходчиво. Значит конкретной рецептуры нет, все зависит от нагрузок и сложности обработки действий игроков. Комната или Хаб одинаковые их задача знать о списке клиентов и обеспечивать обмен ивентами и операциями. Их организация зависит от выбранной архитектуры. По поводу load balancer-а тоже подскажите пожалуйста. Я так вижу: есть логин сервер на котром крутиться некий код называемый лоадбалансер. Игрок,подключается к логин - серверу, забирает свои игровые данные, жмет "в бой". load balancer имеет список геймсерверов и знает состояние каждого из них (текущая нагрузка). подбирает самый незагруженный и отправляет клиенту команду на переподключение уже к выбранному игровому серверу. Так примерно выглядит?

[Saltant]

По поводу load balancer-а тоже подскажите пожалуйста. Я так вижу: есть логин сервер на котром крутиться некий код называемый лоадбалансер.

Не совсем так, балансер служит для того чтоб логин сервер клиенты не положили своими запросами, для этого нужны 2 машины (два физ сервера) для логина, между ними распределяется нагрузка логина, если упадет один - второй будет работать пока первый поднимается, упадет второй - первый уже поднялся, примерно такой смысл, чуть подробней можно почитать тут https://uni.dtln.ru/help/124 на примере виртуальных машин.

[unregistered]

Мастер сервер тогда этот то который смотрит состояние логин серверов? Настолько серьезная загрзука по логину, что балансер работает только на логин? Я думал контроль матча задача сложнее...

[Saltant]

Мастер сервер тогда этот то который смотрит состояние логин серверов? Настолько серьезная загрзука по логину, что балансер работает только на логин? Я думал контроль матча задача сложнее...

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