I have a turn-based strategy game which already has a multiplayer server/client layer that works fine on local network (where one server is set up and players connect to it).

I would like to extend this architecture to allow players to play via Internet, but I don't want to have a dedicated game server for that, especially due to performance issues. The game's AI is runs on the game server of course, and multiple games with computer players would "kill" the machine.

I would like to have some kind of "central connection point" server that does not run the game logic, state or AI but can be used by players to find servers hosted by other players. How can I implement this?

  • \$\begingroup\$ This is much better, however your "suggested approach" is still effectively an answer to your question. I've removed it from the question, you should post it as a potential answer. This will allow you to see how many people think your approach is a good idea (based on the answers upvotes) and also address your desire to get alternative approaches to the broader topic. (You can view the edit history to copy-paste your original suggested approach so you don't have to re-type it). \$\endgroup\$
    – user1430
    Dec 10, 2013 at 16:39

2 Answers 2


Having some kind of central "meta server" or "locator server" is pretty standard practice, and they are pretty generic and straightforward (even though entire middleware solutions, such as GameSpy, used to be popular in the early days of internet gaming).

A locator server just maintains a list of known active game servers that can accept connections, probably in a very simple database table (or entirely in-memory if you really want to be simple). Consequently:

  • A game server, when it starts up, will send a message to the locator server with some basic information about itself, such as the IP and port it's running on, how many players spots are available for joining, and what the gametype (if applicable) is.

  • The game server will send a "close game" message when it either fills up or is cancelled. The locator server should probably also time-out entries as well, to handle cases where the game server just crashed outright.

  • A game client can then request, from the locator server , the list of all games. Often this list is refreshed from the server every few seconds while the player is on the "join a game" screen in the client.

At the bare minimum, that's all a locator server needs to do. When a player elects to join a listed game, the client can attempt a direct connection to the server using the information reported from the locator server -- you don't need to shuffle state between the two by way of the locator at all.

However, a locator server can be useful to act as a third-party in NAT punch-through (alternate explanation) scenarios as well, which does involve transferring more information between the locator as a third-party, though never full game state.

You could use it to pass through complete game state updates and act as a proxy, although in that case while the locator itself is still very straightforward to implement, it's potentially moving a lot more data around and that won't scale as well to a larger number of clients and servers. If that's what you're after (effectively avoiding the need for the game client and game server to ever talk directly), then you'll probably want to additionally have the locator server responsible for talking to a bunch of proxy servers you run. Each of these proxy servers exist solely to act as the intermediary for communication between a game client and server, which never talk directly. The proxies also must periodically communicate with the locator some information about how many games they are managing, for load-balancing purposes.

The game client and server still use the locator server to establish an initial connection, but the locator immediately negotiates with which proxy is least-loaded at the time and messages are sent to the game client and server to "talk to proxy 32" (or whichever). The game client and server will then use proxy 32 (or whichever) to rely communication about game state updates and so on, until the game ends.

It's quite likely your game won't be high-traffic enough to actually warrant needing a whole fleet of proxies, but if you do intend to avoid having a direct communication between the client and server for some odd reason (which seems unnecessarily complex), you should probably at least design the locator and proxying aspects of the intermediate server as separate. Just in case.

You don't want to have your game become suddenly popular, and then have your network infrastructure fall over when the surge of new players happens.

  • \$\begingroup\$ Thank you Josh. The main reason why I was thinking about this was to find a way how to connect two computers in different local networks (not mutually connected). Therefore the first suggestion that client can communicate directly with server probably wouldn't work. The second part about NAT punch-through is very interesting and this might be a way through. I am rethinking it now and potentially better would be to have a web server which will keep the state and with every turn, this state gets updated. Therefore wouldn't be any direct connection between client and game server. \$\endgroup\$
    – Pavel
    Dec 13, 2013 at 15:48

I've rethought things a little, and I am now considering having a web server which will keep the state and with every turn, this state gets updated. Therefore wouldn't be any direct connection between client and game server.

The Game server (where AI will run) will act in this architecture as another client and locator will be the primary source of the current state (lets call it Internet server).

This would be the process:

  1. First player starts the multiplayer game. This creates new process "AI server" on the same machine and calls Internet server telling it that a new game is created. The direct connection between the player's app (let's call it client 1) and AI server is closed.
  2. AI server and client 1 start to communicate with Internet server exclusively.
  3. Every move goes through the Internet server and it updates its state. All connected clients (right now AI server and client 1) ask periodically for state update.
  4. When AI player should play, the AI server simply starts sending its turns like any other client.
  5. When a new client wants to play, it simply downloads the state from Internet server and list of clients is updated.
  • \$\begingroup\$ What is the reason for having the "AI server" run independently from the client but on the same client machine? That just seems like an over-complication compared to hosting the server components in-process (they client and server aspects of the process can still communicate by way of your central server). \$\endgroup\$
    – user1430
    Dec 13, 2013 at 16:21
  • \$\begingroup\$ It's also worth noting that you aren't accounting for scalability in this solution since you are using a single machine to route all traffic (which may not be a problem up until the day is actually is a problem because your game has become popular, at which point it is debilitating). \$\endgroup\$
    – user1430
    Dec 13, 2013 at 16:22
  • \$\begingroup\$ Hi Josh, I agree that it might work in single process. For local-network game I use separate windows service, because it can theoretically sit on different machines (i.e. AI server can be a dedicated machine). I would like to stick with that solution, because in that case I can continue with this architecture and use it in future (players could have dedicated machine for AI). But yes, it is possible to have it in one process indeed (like single player game works currently). \$\endgroup\$
    – Pavel
    Dec 13, 2013 at 18:59
  • \$\begingroup\$ Yes, you are totally right in the second comment. However this is just a few lines of code to have a list of possible servers instead of just one. The rest would work exactly the same. I want to test internet game for now and I have a server ready for this purpose. In future, there can be list of servers and players can potentially create their own (if IP is public, etc). \$\endgroup\$
    – Pavel
    Dec 13, 2013 at 19:01

You must log in to answer this question.

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