You will be controlling only one person directly in the game. But, you can issue vague command like to build something here or attack at this square.

So I'm trying to make a multi-player roguelike game. However, I have a bit of a problem understanding how to do sending and receiving data to the server.

Was wondering how would I use threads to do this?

I have two c++ project. One is for the server and one is for the client. I can create multiple client and connect it to server.

So do I just create threads on the server for each player to listen for client input. So I would wait for say 100ms for the input and then send it to update game, then repeat again?

I just want to know how to design it. I could probably work out how to do the detail myself. Just need the big picture.

So I was thinking that if I have say two threads for networking. One for listening to client input, one for sending updated stuff to the client. Although, maybe you need to do networking on one thread and you can't separate them like you can't have openGL on two threads.

  • \$\begingroup\$ See: gamasutra.com/view/feature/3094/… \$\endgroup\$ Aug 2, 2013 at 18:52
  • \$\begingroup\$ I would do that. However, you will only be controlling one person. So I don't think I need to do that. \$\endgroup\$
    – pangaea
    Aug 2, 2013 at 21:28

2 Answers 2


You mentioned it's a roguelike, will it be turn-based or real time ? Generally if you are going for a real-time game with timing critical elements, you should be placing the commands player make slightly to the future to compensate for the latency. This can be few hundred milliseconds at most.

Typically each client on the server has a thread. This thread handles reading the data and sending the response to the particular client. If you're planning on storing game logic on the server, then you'll need a common data storage with concurrency handling. Look into mutex/semaphore for more information on how to do this.

Another option is to have the server merely as a message conveying service. This means that you should encode your player movements into actions that will be sent, through the server, to the other players in the game. The games themselves are then responsible for maintaining a synced state.

Both of these approaches are valid and it really depends on how you want to do it. If you want to have a master process besides the server but on the clientside, you could set it so that the creator of the game has "additional privileges" such as spawning the monsters to a dungeon. Something a server would randomly do, but assuming you want to have a generic message delivery server and include all the game specific stuff on the side of the game.

As for receiving the data on the server side, depending on whether you're using UDP or TCP, you could simply have the thread listen to the socket all the time and attempt to read a packet (Åin the format you define) and react to it when it arrives.

A good thing to realize is that you generally don't have to sync up all the data, but only the stuff that has changed. If timing is not critical, you could simply be transmitting deltas (i.e. what has changed) all the time.

One thing to consider in a design like this is that sometimes someone is late due to network lag or something. If a command is missed, how will this be fixed. You should design your game so that a) the actions can be calculated from the past or b) implement a resync (i.e. send all objects across to all players; pause the game for a short while meanwhile).

And then there's the approach I first encountered in Unity was to divide the communication into delta updates and RPC calls. Big stuff like killing a monster, picking up an item, etc. will go through RPCs. However, stuff like exact player movement uses delta updates and movement prediction (the latter one means that the drawing thread can use the previous movement to interpolate to the direction it assumes the entity is moving to).

As for the communication itself, you could either use polling or simply listen to the server socket all the time for updates. In this case, you might want to utilize non-blocking IO in C++ (full duplex). Here's a thread from StackOverflow: https://stackoverflow.com/questions/4675824/how-to-implement-a-full-duplex-channel-over-tcp-with-a-single-thread)

I know a lot of this is vague but your question is a bit broad as well. I recommend you try to narrow your question down a bit by providing more detail in the future.


For the love of all that is right in the world, do not create one thread per client. Java perpetrated that disaster of a design by not giving you much of a choice in earlier versions but there's no reason to bring it into modern C++ code.

You want a form of multiplexing. You can listen to a collection of sockets and react when data is available in any of them. All on a single thread. You can send data on those sockets without needing another thread. Most AAA games put this into a single dedicated networking thread for latency reasons, but it works just as well on the main thread for most games.

The hard part you need to deal with is how you're actually going to architect the game. Note that many (most?) RTS games use a lock step form of networking, meaning the server sends out the next "frame" state to each client and waits for some kind of synchronization event before doing the next. This does mean that if a client starts to lag, all the clients will experience equivalent lag. Put a cap on how much lag you'll tolerate before considering a client de-synchronized (and either needing to resync the whole state or just disconnecting the client). There are of course many other ways of networking a game, though most the articles I can think of tend to be focused more on latency-sensitive shooters or large-scaled MMOs and may not necessarily be good advice for your project.

Note also that many articles are just really out of date. TCP for instance is a perfectly good choice for networking in a game like an RTS, especially with lock-step networking, and is even the protocol of choice for many smaller MMOs. Despite this, almost every article around on networking is about building a custom UDP protocol.

In short, do the absolute simplest thing possible until you have hard evidence that you need something more complicated.


You must log in to answer this question.

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