Стратегия игрового сервера
Я планирую создать основанную на WebGL стратегию в реальном времени, где игроки могут играть вместе. Я использую Node.js для создания игрового сервера и веб-узлов для соединений в реальном времени.
Я нарушил свое мнение о том, что было бы лучшей концепцией для синхронизации клиентов.
Одной из возможностей было бы отправить на сервер только заказы пользователей (движущиеся объекты, здания и т.д.), которые отправят их всем другим клиентам. Но здесь у меня проблема с задержкой. Я думаю, что игры будут получать асинхронный путь.
Другая возможность - это рассчитать игру на сервере. Клиенты по-прежнему отправляют инструкции на сервер, но сервер отправляет теперь все измененные состояния всех подразделений и зданий клиентам с большим интервалом. Проблема заключается в том, что большой объем данных и насколько быстро это может быть...
Есть ли у вас другие идеи или предложения по улучшению?
Спасибо!
Ответы
Ответ 1
В основном вам нужно решить между скоростью и безопасностью.
Предоставление клиенту задания и вычисление выполняется быстрее, но данные находятся под угрозой, поскольку клиент может манипулировать данными.
С другой стороны, сервер делает все задание медленнее, но данные более безопасны.
Вы можете выбрать двойной подход, решите позволить клиенту рассчитать только некоторые данные, синхронизировать и затем проверить его достоверность, а остальные - на сервере.
Это также зависит от того, насколько быстро выполняется игра, объем данных для расчета, скорость сервера и диапазон/соединения и т.д.
Вы должны прототипировать оба метода и попробовать некоторые тесты для эмуляции загрузки клиента и серверов.
Если игра небольшая, я бы выбрал более серверную работу. С другой стороны, для очень сложной игры лучше всего использовать больше работы для клиента. В любом случае, я думаю, что компромисс всегда необходим.
Вот несколько ссылок, которые могут вам пригодиться
Введение в многопользовательское игровое программирование
Стратегия в режиме реального времени
Тема многопользовательского программирования (старый, но все еще со многими полезными ссылками)
Компенсация задержек
Предотвратить многопользовательский обман
Первая ссылка помогла мне многое в те дни, и imho по-прежнему остается одним из лучших ресурсов, доступных на эту тему.
Книги
Многопользовательское игровое программирование
Ответ 2
Я бы предложил посмотреть эти ресурсы в отношении концепций разработки игр на основе браузера:
Ответ 3
К сожалению, у меня нет опыта в онлайн-играх, основанных на WebGL, но обычно это хороший подход, позволяющий логике игры исполняться на стороне клиента и синхронизировать результаты.
В этом подходе важно следить за тем, какой игровой объект "принадлежит" каким клиентом. Клиенты только отправляют обновления (создание, обновление, удаление) из своих собственных объектов и получают обновления других игровых объектов от других клиентов.
Кроме того, вы можете настроить инфраструктуру обмена сообщениями для доставки дополнительных сообщений, таких как "Игрок ввел/оставил" или что-то в этом роде.
Эта концепция оказалась полезной для созданной мной игры, и я надеюсь, что она так же полезна для вас.
Ответ 4
У вас должно быть состояние игры и логика на сервере, иначе ваша игра будет широко открыта для обмана. Сервер является конечной властью игрового состояния.
Ответ 5
Не уверен в WebGL, но, насколько мне известно, следующий подход будет хорошим.
- Инициализировать все объекты (которые являются общими для игроков) на сервере и запускать их
- При запуске клиента он запросит весь обработчик (связанный с конкретным клиентом) для объектов, запущенных на сервере.
- клиент будет отображать объекты в пользовательском интерфейсе для всех получаемых рендереров.
- Когда клиент делает какое-либо обновление в пользовательском интерфейсе, изменения будут уведомлены на сервере, а сервер будет соответствующим образом обновлять объект.
- Когда объекты, общие между игроками, изменяются одним игроком, каждый игрок (клиент) будет уведомлен о внесении изменений в пользовательский интерфейс.
Этот подход будет специфичен для общих объектов, а не для объектов, специфичных для UI/client.
Ответ 6
Из соображений безопасности вся логика должна быть на стороне сервера, и все обновления данных находятся на сервере.
Но клиент может сначала предсказать некоторую логику и воспроизвести анимацию, которая называется прогнозом клиента.
Серверная сторона отвечает за проверку клиентской логики, если нет обмана, все сделано.
Если кто-то обманывает, сервер может сказать клиенту вернуться в правильное состояние.
Если вы используете node.js для сервера, есть фреймворк с открытым исходным кодом, pomelo.
Кроме того, для него есть полная демо-версия исходного кода и онлайн-демо: lordofpomelo