Мультиплеер в Our Empire Remake

Мультиплеер, я даже уже начал примерно всё понимать как там всё работает, но, сложно представляю геймплей, где 10 игроков, и каждый ходит минуту, даже так игроку нужно ждать 10 минут до своего хода — (c) SK, источник.

Представляю концепт, предлагающий объяснение как запрограммировать мультиплеер в Our Empire, а также несколько предложений, как же всё-таки его можно будет оформить (спойлер: все варианты предполагают продолжительную партию). Возможно эта статья как-то повлияет на мнение об отказе от мультиплеера.

Учётные записи

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

Для самой-самой базы, достаточно хранить три параметра:

• Уникальный идентефикатор (ID). Система сама будет его генерировать.
• Контактные данные пользователя (e-mail, Телеграм и т. п.). После ввода пользователем, требуется подтверждение валидности указанных данных (например что почта существует).
• Пароль от учётной записи.

Все остальные параметры, типа имя, достижения и т. п. относятся к профилю, публичному профилю. Эти данные необязательны для работоспособного мультиплеера.

Архитектура мультиплеера: «звёздная топология»

Для того чтобы легко объяснить, что я хочу предложить, я буду ссылаться на топологии компьютерной сети.

За основу многопользовательской игры для Our Empire я предлагаю взять тип звёздной топологии. К сути, наглядный пример:

После нажатия на кнопку «Найти игру», игра пошлёт в систему уникальный идентефикатор своего игрока, и она [система] запомнит, что конкретно этот игрок ищет игру.

Когда наберётся достаточное количество доступных игроков (например 3-4), система создаст "лобби". Для каждого лобби будет сгенерирован случайный ID, например типа a6fdfd1f13967a2a31453e21cbe6b1798d04987e9cc2afcc066056996fcae581 (конкретно здесь использован хэш. SHA3-256, но это вообще не суть). Идентефикатор лобби обязательно должен быть скрыт от игроков, ибо по нему можно будет манипулировать игрой.

После того, как система посчитает что набор игроков идёт уже достаточно времени и что к этому моменту набралось достаточно игроков, она [у себя] запишет данные игрок - страна и отправит игре уведомление, что игра готова начаться. Любая игра просто сгенерирует файл сохранения (насколько мне известно, .oe) и отправит его содержимое на сервер (можно даже в уже закодированном виде).

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

Конец примера.

То есть суть [звёздной топологии в этом примере] заключается в том, что есть подключения (пиры) и центральный сервер с API (например по адресу api.ourempire.pro), к которому обращаются пиры.

У ЯП C# есть официальные модули и сторонние библиотеки для запросов к API. У Unity C# есть официальная библиотека: UnityWebRequest API.
Да и сама по себе система API очень простая: ключ - значение (JSON).

Плюсы такой системы:

• Независимость от обновлений игры, в том числе от изменений структуры файла сохранения.
• Быстрая скорость, отсутствие сложных операций и важных, в том числе персональных данных.
• Читерство почти невозможно.
• Не нужно сильно или даже средне модифицировать код игры. Игра не начнёт больше весить. Плюс часть затрат берёт на себя удалённый сервер.

Стиль игры

Имеется в виду один на выбор. Ну или несколько; не я решаю.

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

"Горизонт событий"

Есть конечное время — например 19:00 по МСК — и есть порядок стран, по которому игроки (в порядке очереди) делают ходы ЛИБО первыми обрабатываются запросы от тех, кто первым нажал на кнопку окончания хода. Всё банально и просто.

• Плюсы:
• Каждый игрок точно знает, что имено в фиксированное время игра входит в горизонт событий и гарантированно наступает следующий ход.
• Система проверенна во множестве ВПИ по Our Empire.
• Минусы:
• Сложность с определением порядка хода и его балансировкой. Дополнительные трудности, если используется второй вариант порядка обработки ходов.

"Рация"

Определяется порядок стран, кто после кого совершает ход.
Один игрок делает ход. После отправки своего хода, его игра отправляет системе сигнал, а система отправляет сигнал игре следующего пользователя. Следующий ход наступит тогда, когда все по очереди сделают свой ход.
Можно ограничить время, которое даётся каждому игроку, на совершение хода.

• Плюсы:
• Крайне легко в реализации.
• Некоторые ВПИ по Our Empire работали по такой системе.
• Минусы:
• Сложность с определением порядка хода и его балансировкой.
• Неизвестно, сколько придётся ждать своей очереди.

Послесловие

В целом хочу уточнить, что я тоже не эксперт, и с таким никогда не работал. Говорю то, что сам знаю и что могу предполагать.

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

Если у кого-то есть идеи, как можно дополнить концепт, то пишите мне в ЛС.