Как лучше всего синхронизировать игровой движок и сетевой сервер в Haskell? - PullRequest
13 голосов
/ 11 февраля 2011

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

  • Happstack для связи клиент-сервер
  • Yampa / Reactimate для игрового движка

Каждые 20 мс или около того, клиент должен отправлять события клавиатуры и мыши на сервер через HTTP GET, получать текущее состояние игры (позиции мяча и игрока в кодировке JSON) и отображать его. Я думаю об использовании инфраструктуры SDL для игрового цикла, обработки ввода и рендеринга.

Сервер в основном выполняет два потока: сервер happstack получает HTTP GET, помещает команды клавиатуры / мыши в очередь, считывает текущее состояние игры из второй очереди и отвечает на запрос HTTP GET.

Второй поток запускает игровой движок Yampa, как описано в документе Yampa Arcade : игровой движок вычисляет новый раунд как можно быстрее (без тиков) и помещает результат в очередь рендеринга.

Architecture

Общий вопрос: это похоже на выполнимую архитектуру?

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

Ваши комментарии очень приветствуются!

Ответы [ 3 ]

6 голосов
/ 12 февраля 2011

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

Я также не понимаю, почему вы хотели бы использовать HTTP для такой игры (любая игра в этом отношении), почти все игры используют UDP, и я бы, вероятно, пошел по этому пути для вашего типа игры. Этот урок отлично подходит для изучения подобных вещей.

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

Что касается Yampa и рендеринга на стороне сервера, поэтому, если мы рассматриваем FRP в контексте игр как средство реализации игровой логики и сущностей, я полагаю, что большинство сетевых игр имеют серверные и клиентские сущности. Обычно объекты, которые можно рендерить, являются клиентскими объектами, а не рендеримые являются серверными объектами, и я предполагаю, что некоторые объекты имеют представление на обоих. Поэтому в этом случае вы, вероятно, захотите запустить Yampa как на стороне сервера, так и на стороне клиента, и я постараюсь избежать всего, что связано с рендерингом на стороне сервера. Я считаю, что визуализируемые объекты должны преимущественно придерживаться клиентской части. Есть ли конкретная причина, по которой вы хотите получать команды рендеринга с сервера?

4 голосов
/ 12 февраля 2011

Если вы хотите дать только последнее состояние игры, не используйте чан или очередь, используйте сэмплевар: http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Concurrent-SampleVar.html

2 голосов
/ 14 февраля 2011

Если вам интересно, я также однажды написал похожую футбольную игру на основе сервера-клиента на Хаскеле.Вы можете найти исходный код по адресу github ( сервер , клиент ).Поскольку я тогда был новичком в Haskell, я столкнулся с некоторыми проблемами, связанными с многопоточностью (и написал о них ), и так и не закончил проект, но вы можете по крайней мере увидеть из кода, как этого не делать,(В конце концов я отказался от архитектуры сервер-клиент и написал freekick2 .) Хотя я действительно думаю, что сама архитектура выполнима.

Однако, как пишет snk_kid, я не знаюпочему вы хотите использовать HTTP.Чтобы он работал в сети без (заметной) задержки, вам, вероятно, придется использовать UDP, а также прогнозирование на стороне клиента ( вот некоторый информативный материал).

...