Организация игровых комнат на сервере
 

Здравствуйте, как правильно пишутся на серверной стороне игровые румы? То есть у нас на входе имеется массив подкюченных пользователей. которые нужно разметить по отдельным комнатам, чтобы они играли друг с другом. Как это правильно организовывается?, каждая комната по идее должна быть инкапсулирована, со своими таймерами и методами. Первое что приходит в голову - это создание экземпляра класса на каждый рум, но насколько это применимо к серверам?
То есть задача сводится к тмоу, чтобы общий поток запросов-ответов пользователей распределялся по комнатам в которых они играют.
сервер node.js

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

Просто я пытаюсь перейти от понимания работы клиентского кода, к разработке серверного, поэтому возможно вопрос банален или не правильно сформулирован. У меня сейчас есть server.js, который слушает порт и добавляет новых пользователей в массив, так же внутри есть примеру функция newRoom(user1,user2) которая должна создать комнату с двумя этими пользователями где они могут общаться друг с другом. Как такое обычно делается?

хранение информации:
базы данных: текущее -редис, история - монго.....
дублирование информации -причины(защиты от сбоев, увеличение быстродействия....)
построение отношений:
передача параметров и проверки , взятие данных из баз ........

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

печь,хлебопёк, ингредиенты необходимы -это слои
какими печь,хлебопёк, ингредиенты будут -будут различными у всех-это индивидуально

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

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

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

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

я децл невьезжаю о чём ты. Я имел ввиду setTimeout в nodeJs.

пересчёт игроврой ситуации в пошаговую игре лучше к событиям привязывать конечно.

а вот в реалтайм нужно пересчитывать регулярно, и постоянно. Народ то всё время двигается :)

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

или ты о чём ?

DjDiablo,
ты мыслишь примерно как он -общими мерками.
Есть задача, есть решение в зависимости от задачи. нет универсального решения.
Рум. Для чего он? для стратегии? для игры в покер? для RPG? Для обмена фантиками бессрочного? ....
и в зависимости от ответа будет своё решение для взаимодействия , от него варианты архитектуры, а от неё уже будет зависеть варианты реализации.

с чего это.
Как минимум я чётко отделил реалтайм, от пошаговых игр.
Даже мысли небыло предлагать конкретное решение, так как непонятно что он вообще делает.

Спасибо, буду практиковаться