Looking for online multiplayer advice/insight

hey, I'm looking to make a relatively small rts. Main thing holding me back, go figure, is the networking. Wondering if anyone here has successfully made an online rts using GM, and what they've found to work best in terms of the networking.

Like should I build one from scratch, hoping for the best? Should I buy a networking layout from the marketplace? Or should I watch a specific tutorial covering rts networking?

Idk, if anyone can give advice that'd be great!

Btw, I'm not entirely new to GM, but I am new to networking


I would highly recommend first considering the major points of network play in general regarding any client->server->client model.

1) What data will you be transferring to/from users? to/from servers?
2) Will you go direct (configuration per user is high/speed may be good/use for more than a 2 player is questionable)?
3) Will you use Push Connections from cloud? Maybe look up that term if you don't get it. It can help you avoid the headaches of Firewalls.
4) How often will you be transfering state between users? This impacts performance which impacts latency and gameplay.
5) Do you want people to host? Will you make a match maker service in the cloud? Or local on the network? Or Both?
6) How will you implement session management (unique per session)? (You can't just disconnect someone from desynchronizing - if you require perfect sessions, but end up using UDP, you may find yourself with constant "why can't I keep the computers connected to each other" problems.
7) How will you implement message management (order of packets in case you utilize UDP)? How will you dispatch the messages to your system? You MUST utilize some async method, if your game "pauses" waiting for network packets, well we've all seen what that looks like in a game... It makes it really choppy. Consider a delay between processing and receipt. Look at Quake UDP network design Con/Pro for understanding how you can utilize delay to improve usability. (http://fabiensanglard.net/quake3/network.php) This is worth a read, understand what's going on and why.
8) How will you authenticate users into the cloud for any cloud bits? Local authentication may not be necessary for LAN, but absolutely an issue for WAN.
9) For supremely fast updates, consider UDP - there are many blogs on UDP vs. TCP, I highly recommend using both for different purposes, and at the same time.
10) Are you trying for a given platform? Windows, mobile, etc., look at networking aspects from that platform specifically. Look at HTTP from client to cloud - and if you have connection pooling and use keep-alive, can probably manage this effectively using HTTP, efficiently and for a high latency game (chess, it's prob ok) but maybe too slow, too much overhead for yours.

Do not confuse "how you do networking" with game design in regards to networking. Your need for features will help you pick the method. You could use hundreds of different protocols, start with the component design, frequency of updates, then look at which protocols will meet your needs. Finally, don't be in a rush. Proper consistent network functionality will make the rest of the game shine, but without it, a great game becomes unplayable.

If you want to get into the guts, get TCP Illustrated latest revision and master networking including DNS, IPV4/6, TCP, and UDP.


First of all, networking systems wont necessarily do the work for you, they just tend to be a bit more streamlined so it simplifies the process, though generally, they still require a level of understanding of client/server communication, and distributing which processing is happening where.

Networking is fantastic, however as a first project, an RTS is quite a challenging prospect. There are many factors at play: Pathfinding, combat, commands, grouping, buildings, fog of war, etc; All of which can be quite challenging to achieve with a network setup if you haven't done one before.

I'd recommend starting simple. Start with just a room with a few players, where each client controls a player, and they all get synced over the network.

The best tip I can give you in approach to networking is that you should always treat the server process as the thing that actually processes the game. The clients are simply there to act as inputs and outputs. (The input from the client, whether it be commands, movement, pressing a button, performing an action etc; just get passed to the server to process. The server then sends the response of this action back to the client). I picture it as each client being a unique view into the "world" that exists in side the server. The only real processing a client should do is actions that aim to mask the latency of the connection. By this I mean making the game feel like you are playing in a single player game by having responsive feedback and animation, however keeping this separate to what is actually happening behind the scenes on the server.

I'd recommend to try and build something from scratch first, just to nail the basics. After that, you can look into finding a premade layout that better suits the style of game you want to make.