Джаггернаут самоцвет для игрового сервера - PullRequest
0 голосов
/ 14 января 2012

Речь идет о последнем драгоценном камне Джаггернаута (https://github.com/maccman/juggernaut)

. Я думаю об архитектуре, скажем, о «точечных играх». Эта мета-игра очень проста: каждый зарегистрированный пользователь (подписанный на канал, втермины Джаггернаут) - это точка случайного цвета на холсте JS. Пользователь может перемещать свою точку в любом направлении. Вот и все.

Джаггернаут должен транспортировать и передавать все данные для подключенных клиентов.

В настоящее время яПредставьте себе архитектуру как:

1) Клиент (ы) передает координаты точки и идентификатор игрока ([1, [10,299]]) как ajax, например, в Rails.

2) Railsпередает эти данные Джаггернауту

3) Джаггернаут отправляет координаты обратно всем клиентам, которые слушают этот канал.

Juggernaut.publish("coordinates_channel", [1, [10,299]])

Проблемы:

1) Когда мне нужно пиксель-пиксельным движением для объекта 'точка' на холсте js, мне нужно будет отправить слишком много запросов AJAX.Например, если моя точка движется со скоростью 20 пикселей в секунду, мне нужно будет отправлять 20 запросов в секунду.Неприемлемо.

2) Должен ли я обернуть Juggernaut.publish в асинхронный цикл (например, с помощью EventMachine)?Потому что, просто представьте себе 1000 клиентов (1000 точек и постоянный поток данных с обновленными координатами) ...

Или, может быть, я ошибаюсь клиент-сервер, используя гем Джаггернаут?Что вы думаете об этой реализации?

Спасибо.

1 Ответ

3 голосов
/ 14 января 2012

WebSockets / Long polling / другие кометные техники имеют низкую задержку, ваша игра будет отставать.Я видел реализации игр в реальном времени через веб-сокеты, они либо запаздывают, либо игровая механика делается особенной, например, заставляет игроков двигаться очень медленно, чтобы учесть низкую задержку.Классический AJAX окончательно исключен.

Вот некоторые ресурсы по улучшению задержки
Многопользовательская сеть Valve Source
Многопользовательская сеть Unreal Source

...