13

I am designing a little soccer game where the game engine (that computes player moves etc.) runs on a server, and rendering and keyboard/mouse handling is done by the client. For the server (Haskell) I want to use

  • Happstack for client-server communication
  • Yampa / Reactimate for the game engine

Every 20ms or so, the client should send keyboard and mouse events to the server via HTTP GET, receive the current game status (JSON-encoded ball and player positions) and render it. I am thinking about using SDL infrastructure for the game loop, input handling and rendering.

The server basically runs two threads: A happstack server receives the HTTP GET, puts the keyboard / mouse commands in a queue, reads the current game status from a second queue and answers the HTTP GET request.

The second thread runs a Yampa game engine, as described in the Yampa Arcade paper: The game engine computes the new round as quickly as possible (no ticks) and puts the result in the render queue.

Architecture

General question: Does this look like a feasible architecture?

Specific question: How would one design the server side rendering queue: Would one use a Chan for this? If the game engine is quicker on average than the "ticking" on the client side, the queue will get longer and longer. How could this be handled with Chan?

Your comments are very welcome!

4

3 回答 3

6

Could you explain a bit more about the game itself. When I think of a soccer game I think of a game that requires real-time feed-back where input should be handled instantaneously and I would expect player input information to be sent over the network immediately. 20ms is quite a delay and I believe would be noticeable when the player holds down the key trying to move his/her character it will probably feel jerky the kind of jerky-ness experienced with certain types of garbage collectors.

I also do not understand why you would want to use HTTP for such a game (any game for that matter), almost all games use UDP and I would probably go down this route for your type of game. This tutorial looks great for learning about that kind of stuff.

I would also question your choice of network data format, why would you want a format that would require non-trivial parsing/formating when receiving/sending? I'd imagine that sending lots of data and frequently this would add up significant time. If I was going to use strings I would try to use the simplest format that requires very minimal parsing. On related system that I would work on it was a multi-process real-time system using sockets to communicate, and originally it used xml strings as network data format and it was terribly inefficient and all the processes where all on the same machine.

Regarding Yampa & server-side rendering, so if we think of FRP in the context of games as means of implementing game logic & entities I believe most networked games have server & client entities. Typically objects that are renderable are client entities and non-renderable are server entities, and I guess that some entities have representation on both. So in that case you probably want to have Yampa running on both the server & the client side and I would try to avoid anything related to rendering on the server-side. renderable objects should predominately stick to the client side I believe. Is there a specific reason why you want to have render commands coming from the server?

于 2011-02-12T01:03:40.867 回答
4

If you only want to ever give the latest game state, don't use a chan or a queue, use a samplevar: http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Concurrent-SampleVar.html

于 2011-02-12T01:33:35.517 回答
2

In case you're interested, I also wrote a similar server-client based soccer game in Haskell once. You can find the source code at github (server, client). As I was quite a Haskell beginner back then, I ran into some problems regarding threading (and blogged about them) and never really finished the project, but you can at least see from the code how not to do it. (In the end I ditched the server-client architecture and wrote freekick2.) I do think the architecture itself is feasible, though.

However, like snk_kid writes, I don't know why you'd want to use HTTP. To have it running across a network without (noticeable) latency, you'll probably have to use UDP as well as client side prediction (here's some informative material).

于 2011-02-14T18:42:36.407 回答