Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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!

share|improve this question

closed as primarily opinion-based by Byte56 Sep 5 '13 at 20:31

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

    
there is a related thread on gdev forum gamedev.net/topic/565319-turn-based-game-design-help –  zinking Jun 29 '12 at 9:40
    
You can learn from following game server design: developers.google.com/games/services/android/… –  tomash Nov 6 at 16:57

3 Answers 3

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

share|improve this answer
    
maybe you can explain a bit more, egg. I don't know 'elo' –  zinking Jun 26 '12 at 9:19
    
I edited the post to include a link to the Elo system. –  Kylotan Jun 27 '12 at 18:01

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.

share|improve this answer

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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.