I'm writing a real time strategy game in Rust. In this game each player controls one of two armies facing off on a battle zone. To better understand the gameplay, my project is an open source version of Close Combat games.

I will work on the network part soon, and I have some questions about that. This is my theoretical design:

  • Game playable as 2+ players (but not a lot, max 6 players)
  • One player act as "Server"
  • Other players are "Client" of the "Server" part
  • The Server part own the game state and logic (soldiers positions, players orders, path finding, which gunshot kill another soldier, etc.)
  • The client part send to the Server part all the player state change requests (like soldier move request)
  • The server send to the clients all the state changes (new soldier position, sound to play, etc)

To communicate between server and clients I' considering using ZMQ sockets (I already use it in another project, but I don't know if it is a good choice for game design):

  • Clients connects on Server REQ/REP to be able to send theirs "state change requests" (like soldier move request)
  • Clients connects on Server PUB/SUB to receive all state changes

This design is correct? Do you have comments about that?

  • 3
    \$\begingroup\$ StackExchange works on a one question per post model, so I've pruned out your second question. The terms to search for to find existing answers about that second part are "NAT traversal" or "NAT hole-punching". \$\endgroup\$
    – DMGregory
    Mar 6, 2022 at 12:39

1 Answer 1


First, there are already libraries out there that can help you create this kind of setup without having to code too much on your end. Depending on your engine, there are various options like FishNetworking, or Mirror on Unity. As far as I know, Photon is the most used in Unity. Other engines like Unreal already offer multiplayer networking.

Now, my opinion on your design. The first part about building the netcode is sound for an RTS. You're sending RPC when the client needs to send information to the server and the server is sending the state based on a tick rate that you can configure.

One comment for the "client-server" would be that calculating the pathfinding of all the units on it could end up consuming a lot of CPU on that specific player. So, you could run into some issues there. The more units you have, it can become too heavy for your average computer to handle.

I don't know much about ZMQ sockets, nor how performant they'd be for an RTS game. That said, in an RTS, there can be a lot of things happening at the same time (every single unit can move in a different direction at the same time through pathfinding) so messages between the client and the server have to be optimal. I don't know if ZMQ can offer you that, so if you can run some tests as to how much traffic these connections can generate on ZMQ, you would have a better idea of whether you can use it or not.


You must log in to answer this question.

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