Pull to refresh

Comments 13

Из заголовка статьи:

 Открытый бесшовной мира 

Ну прям и не знаю, что это. Наверное, великий и могучая русским языка?

Чем Ваша реализация отличается от реализации бесшовного мира в облаке, либо на кластере?

Почему бы не отдать функции выделения ресурсов ОС, а бесшовный мир строить в предположении, что нет ограничений вычислительных ресурсов?

Я не совсем понял ваш вопрос.

Данный сервис - это авторитарный сервер и с ним можно работать по API в разных движках (unity, unreal engine , godot и др). Тк сервер авторитарный в нем содержится все информация о коллайдерах, вычисляются все механики и он рассылает пакеты которые интерпретирует клиент (изменяет полоску жизней, двигает существ и тд). Сервер работает только с массивами данных.

Такие авторитарные сервера могут быть объединены в некий пул физических серверов и между ними можно переходить и в идеале это на клиенте не должно быть заметно что игрок разлогинелся в одном сервере и залогинелся в другом

По идее бесшовность и распределение по физическим машинам нужна для динамического управления нагрузкой на сервер. Тогда в разные моменты времени каждый сервер обрабатывает разные размеры карт. У вас такое заложено?

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

Заложено и реализовано. Есть сервер который обсчитывает физику и взаимодействует с websocket сервером . Физически они находятся на одной машине только это 2 разных процесса работающие на отдельных ядрах процессора (в будущем к серверу обсчитывающему физику планирую подключить вычисления на GPU).

Чат пока не реализован но это уже клиент будет соединятся с дополнительным websocket сервером (тк к игре это относится косвенно)

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

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

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

Я к тому что это реализовал уже.

Но там бой как комнаты с игроками (если я все правильно понял) , а я стремлюсь что бы все игроки могли встретится играя на разных серверах

Я про то, что во время перехода игрока между серверами он может временно быть одновременно на двух серверах, виртуально, чтоб игроки этих серверов в момент перехода его ощущали как бы на их сервере. Это как DSG коробки с двумя сцеплениями

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

Плавность добивается в клиенте т.к. свое дело сервер сделал, но переподключение требует времени. Этот переход я сгладил, но еще не опубликовал статью про экстрополяцию. В ней будет это видео и переход на тайминге 1:16 уже плавный:

Sign up to leave a comment.

Articles