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

Я хочу создать игру с двумя игроками в понг, в которой используются веб-порты и node.js-сервер. socket.io используется как на клиенте, так и на сервере. До сих пор мой единственный опыт заключается в создании чат-приложения.

Это моя первая попытка многопользовательской игры, поэтому я не очень хорошо знаком с сетевыми играми. Если сервер отслеживает:

Каждая позиция, в которой находится мяч, и как часто или когда?
Движение игрока, игрок перемещается влево или вправо, что, если я нажму и удерживаю некоторое время, как я могу справиться с этим? Должен ли я отправлять как pressHoldStartPosition и pressHoldStopPosition? Я думаю, это легко, если я разрешаю только нажатие, но не удержание.

Мои мысли:

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

Ответ 1

Клиенты рассчитывают - ничего - если вы не хотите, чтобы он предсказал следующий шаг игры * (сервер anwser). Вся игра работает на сервере, который является единственным и заслуживающим доверия источником данных и вычислений. В понг-играх, где есть менее 10 объектов, вы можете отправлять данные довольно часто (интервал 50 мсек.). Для шара я послал [x, y, скорость или угол] для весла [x, y]. Затем интерполируйте (оживить во времени - 50 мс) между старыми (x, y на клиенте) и новыми (x, y, которые вы только что получили с сервера).
Не отправляйте миллионные копии проигрывателя - скорее отправляйте по одному пакету каждый период времени (100 мсек.), содержащий информацию, такую как "игрок нажимает" на 100 мс или "позиция игрока" на ( 32, 100), тогда проверить серверную сторону было возможным это перемещение и принять его или отклонить.

Возможно, этот поток поможет вам в вашем приключении:

Многопользовательская игра для JavaScript, построенная с помощью Node.JS - Разделение игроков

[* 1] Предположение - механизм компенсации задержки, который вы можете реализовать позже. В упрощенном виде это означает, что сервер и клиент разделяют некоторые логические коды игры, а когда клиент не имеет текущих данных с сервера, он пытается имитировать то, что происходит в реальной игре.

Ответ 2

Вы найдете книги, книги, об игровых сетях.

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

Состояние сущности, такое как мяч или игроки, обычно содержит информацию, такую как положение, скорость, состояние кнопки (клавиша вниз/клавиша вверх).

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

Ответ 3

Существует сайт stackexchange, посвященный разработке игры: https://gamedev.stackexchange.com/

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

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