Стратегия игрового сервера Концепция

Question

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

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

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

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

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

Спасибо!

Answer 1

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

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

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

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

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

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

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

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

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

Реальныесетевая стратегия времени

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

Компенсация лага

Предотвратить мошенничество в мультиплеере

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

Книги

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

Answer 2

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

• Многопользовательские игры с HTML5: готовы ли мы?
• Многопользовательские игры HTML5 в реальном времени с Node.js
• HTML5 Игры 0.3: Видя будущее

Answer 3

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

Answer 4

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

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

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

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

Answer 5

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

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

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

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

Answer 6

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

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

Этот подход будет характерен для общих объектов, а не для объектов пользовательского интерфейса / клиента.