Производительность WebSockets - PullRequest
       19

Производительность WebSockets

10 голосов
/ 16 сентября 2011

Я думаю о реализации HTML5 mmog , где задействован быстродействующий объект. Игроки постоянно меняют направление этого объекта, стреляя в него. Я думал о WebSockets и т. Д. ( socket.io ) и canvas .

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

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

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

Я предполагаю, что эта проблема была решена в существующих ммогах.

Есть идеи?

Ответы [ 2 ]

7 голосов
/ 18 октября 2011

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

Например, скажем, ваш быстро бегущий объект движется по экрану слева направо со скоростью 5, и игрок стреляет в него, и он меняет направление, поэтому теперь он движется вверх по экрану со скоростью 5 ( Поворот на 90 градусов).

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

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

У вас всегда будут ситуации, когда эти исправления окажутся довольно большими (например, у кого-то действительно плохое соединение, потеря пакетов, высокая задержка и т. Д.). Именно тогда вы получаете сумасшедшие аномалии, которые люди обычно называют отставанием в онлайн-играх, например, когда объект пропускает большие расстояния или движется очень быстро, чтобы «догнать» его до того места, где он должен быть. Там просто нет возможности быть на 100% в синхронизации все время. Все, что вы можете сделать, это сделать действительно хорошие предположения о том, где все должно быть.

Вот несколько статей с подробностями, удачи!

http://gmc.yoyogames.com/index.php?showtopic=415538 http://www.gamasutra.com/view/feature/3230/dead_reckoning_latency_hiding_for_.php

2 голосов
/ 21 октября 2011

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

Сервер будет принимать данные игрока и определять новую траекторию движущегося объекта, а затемотправлять обновления каждому игроку.Это можно сделать в фиксированных единицах виртуального игрового времени, которые я назову «тиками».

С точки зрения сервера это дает вам цикл, подобный следующему:

  1. Получать входные данные от игроков
  2. Обновлять состояние игры
  3. Распространять изменения игрового состояния на игроков

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

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

Когда на сервер поступает обновление для текущего игрового тика, необходимо применить новое игровое состояние.

Если новая реальная позиция объекта оченьблизко к позиции, которую вы экстраполировали, вы можете просто установить новую позицию и отобразить ее в следующем кадре.

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

...