Многопользовательская игра Javascript - проверка на стороне сервера.

Question

Я начинаю свою работу по созданию многопользовательской игры с использованием HTML 5 / Javascript.

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

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

Итак, просто глядя на что-то простое;Два игрока бегают по пустой карте.

В настоящее время моя идея состоит в том, чтобы

Оба клиента (sockets.io) отправляют свои действия на сервер Node.JS, который затем отвечает с координатами X / Y.Это отлично.Но очевидно, что оба клиента должны знать, где находится другой игрок.

Я думал об этом, создав новую таблицу базы данных для каждой игры и сохранив там игровое состояние, чтобы два соединения node.js могли общаться друг с другом.

Мой вопрос: это лучший способ взаимодействия между двумя соединениями node.js, будет ли это достаточно быстро?Или есть шаблон дизайна для этой конкретной задачи, который мне не хватает?

спасибо

Answer 1

Подход, который вам нужен, следующий:

Каждый клиент отправляет свою координату на сервер через определенные промежутки времени (используя emit). Сервер проверяет эту позицию на достоверность и сохраняет ее в БД. Затем он использует широковещательное сообщение (http://socket.io/#how-to-use - широковещательные сообщения), чтобы отправить эту позицию всем клиентам. Каждый клиент в срок будет обновлять отображаемую позицию персонажа / игрока, который переехал.

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

Вы можете просмотреть некоторые учебники здесь: http://www.nodejs -news.com / nodejs технологий / Nodejs-Socketio-созидательный HTML5-игра /

(Они используют двигатель Impact, но принципы те же)

Answer 2

Создание новой таблицы за игру обычно считается ужасной идеей.

Если вам не нужна настойчивость - т.е. если ваш сервер Node.js заработает, игра может быть потеряна - вы можете просто сохранить игры в памяти, в объекте, скажем, games, который может содержать объект с массивом players, каждая из которых может содержать x и y координаты и т. д.

var games = {
  123019240: {
    players: {
      123: {x: 1, y: 1, name: 'Joe'},
      456: {x: 2, y: 2, name: 'Jimbob'}
    }
  }
};

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

В любом случае, SQL выглядит как неправильный инструмент, а создание новых таблиц по требованию - в еще большей степени. (Однако, если вы используете SQL, рассмотрите макет таблицы с game_id, player_id, x и y и убедитесь, что индекс имеет game_id :))

Answer 3

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

Пример:

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

Eve Online является отличным примером этого.Каждый «регион» - это свой собственный сервер, и когда вы путешествуете достаточно далеко по вселенной, вы прозрачно перемещаетесь на другой игровой сервер.Таким образом, если вы боретесь с кем-то, скорее всего, они находятся на одном сервере.Затем игровой сервер может периодически записывать данные в БД.Это лучший способ, так как пользователь никогда не должен ждать БД.Они общаются напрямую с игровым сервером, игровой сервер время от времени связывается с БД.Самое большее, ваш пользователь потерял бы только несколько секунд данных (как и все остальные на этом игровом сервере).