Стратегия игрового сервера

Я планирую создать основанную на WebGL стратегию в реальном времени, где игроки могут играть вместе. Я использую Node.js для создания игрового сервера и веб-узлов для соединений в реальном времени.

Я нарушил свое мнение о том, что было бы лучшей концепцией для синхронизации клиентов.

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

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

Есть ли у вас другие идеи или предложения по улучшению?

Спасибо!

Ответ 1

В основном вам нужно решить между скоростью и безопасностью.

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

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

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

Это также зависит от того, насколько быстро выполняется игра, объем данных для расчета, скорость сервера и диапазон/соединения и т.д.

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

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

Вот несколько ссылок, которые могут вам пригодиться

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

Стратегия в режиме реального времени

Тема многопользовательского программирования (старый, но все еще со многими полезными ссылками)

Компенсация задержек

Предотвратить многопользовательский обман

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

Книги

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

Ответ 2

Я бы предложил посмотреть эти ресурсы в отношении концепций разработки игр на основе браузера:

Ответ 3

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

В этом подходе важно следить за тем, какой игровой объект "принадлежит" каким клиентом. Клиенты только отправляют обновления (создание, обновление, удаление) из своих собственных объектов и получают обновления других игровых объектов от других клиентов.

Кроме того, вы можете настроить инфраструктуру обмена сообщениями для доставки дополнительных сообщений, таких как "Игрок ввел/оставил" или что-то в этом роде.

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

Ответ 4

У вас должно быть состояние игры и логика на сервере, иначе ваша игра будет широко открыта для обмана. Сервер является конечной властью игрового состояния.

Ответ 5

Не уверен в WebGL, но, насколько мне известно, следующий подход будет хорошим.

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

Этот подход будет специфичен для общих объектов, а не для объектов, специфичных для UI/client.

Ответ 6

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

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

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

Если вы используете node.js для сервера, есть фреймворк с открытым исходным кодом, pomelo. Кроме того, для него есть полная демо-версия исходного кода и онлайн-демо: lordofpomelo