12
\$\begingroup\$

Are there any good references/books to recommend about how to build a turn-base game server? It's something like a chess server for pairing chess players and keep game states. In the past, for example the IGS (for go, weiqi) is a socket based implementation. What are the available contemporary technologies to learn from? Thanks!

\$\endgroup\$
2

3 Answers 3

5
\$\begingroup\$

I don't think there is a particular book about this, since the topic is kinda trivial.

Just imagine a mail-server where players can sent their actions via mail. The server has all the actions performed so far (as mails), which means you have the game state. If you want to reload the gamestate, just execute all the actions inside the mails chronologically. The only thing you have to do is to make sure whose turn it is ... but thats easy too (e.g. turn numbers). No need for contemporary technologies ... a modified mail server/client solution will do.

Pairing ppl can be done via Elo ... but i guess u knew that

\$\endgroup\$
2
  • \$\begingroup\$ maybe you can explain a bit more, egg. I don't know 'elo' \$\endgroup\$
    – zinking
    Jun 26, 2012 at 9:19
  • \$\begingroup\$ I edited the post to include a link to the Elo system. \$\endgroup\$
    – Kylotan
    Jun 27, 2012 at 18:01
2
\$\begingroup\$

If it were me, I'd build it from the ground up with sockets. The amount of data to send is very small, and the turn-based nature makes a little latency unnoticeable.

The real question, in my opinion, is what additional features you need on it. Are the game sessions persistent (can someone drop out and rejoin, can the game be saved, etc)? If you're doing a Civilization style save you probably want to push out the save data to all clients, or have the save done client side with a server-provided key embedded for verification.

Do you need any sort of between-turn reporting, e.g. "Player 2 is moving a unit" or "Your opponent may be AFK"? If so you may end up wanting to keep the socket connections open.

Generally speaking, unless there's some compelling reason to deviate, I'd keep the server as dumb and simple as possible. Leaves less to debug. I also kind of like using plain text protocols, as I can test my servers using telnet without an actual game client (which may be suspect in a given problem), but this does sort of encourage Wireshark manipulation of the data (which you probably will check for anyway).

Edit: If the game only supports 1-on-1 games, peer-to-peer connections may be worth looking at.

\$\endgroup\$
1
\$\begingroup\$

It's important not to overthink what a server is and what it's responsibilities are. In this case, you have a relatively slow acting game, so the server architecture won't be incredibly complicated (vs a faster paced game where you have dead reckoning, etc.). Your server should be listening on a TCP port (might as well skip UDP if you don't require speed anyway) for connected clients to send it packets of information. It accepts the packets, validates them based on the game rules, and sends back a response. In your specific case your server should know who's turn it currently is and reject any attempt by other players to perform actions until it's their turn.

I don't know what technology you had in mind but something this would be easy enough to do in Java with the Kyronet library. Simply send your game actions to the central server (could also be one of the two players), process it, and send back a game update to both players. I'm sure something similar exists for .NET.

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged .