… regardless of which network framework you are using, there are some important concepts and challenges that you need to understand before going any further.
I wrote this article since it’s rather common that we have to set expectations or misconceptions straight.
Online Multiplayer Game Development is hard!
The saying goes that multiplayer is far harder than singleplayer game development.
I would argue that the challenges grow linearly with player counts at first.
You can expect a 1v1 game to be twice as challenging and time consuming compared to a singleplayer game. A four player game may be four times as challenging, especially if it’s a competitive game with high demands on cheat prevention.
If you’ve never made a game before, your first game should almost certainly not be an online multiplayer game. Why? Because for a first timer the “hardness scale” growth is not linear but quadratic.
If you’ve made singleplayer games before and now you’re attempting your first online multiplayer game, do not to reach for the skies. Be realistic!
A competitive 1v1 game or a cooperative 2-4 players game is what you should aim for. If this sounds boring let’s talk again when you’re done. 
Pick the right networking tech stack!
Easy, just use … 
Nope. Sorry. There’s no definitive answer, and opinions don’t matter! The best choice depends heavily on the type of game you are trying to make, its requirements and your skillset.
Just one thing: if it’s your first multiplayer game the network tech doesn’t matter, it just needs to work and be easy to use, right?
But if you still think it will matter even for your first game, your design is very likely far outside the scope of your current skillset (see above) or you’re simply concerning yourself with the wrong priorities. You’re better off just using the tech that is well documented, popular and supported - then get started!
What goes into making the tech and design decisions and other things you need to be aware of before starting the project are explained in this must-watch video:
One does not simply add multiplayer later …
This point is also stressed in the above video but it’s important enough to stress it again. It’s also a common fallacy.
No, you can’t! Not “simply” anyway. Not even mediumly. Or reasonably challengingly.
A multiplayer game has fundamentally different architectural requirements than a singleplayer game. Adding multiplayer later is tantamount to rewriting the entire game logic, possibly even requiring significant design changes to core mechanics with repercussions throughout the entire codebase and even assets! Thus:
Either the sequel of your game will have online multiplayer, or you will create a multiplayer game from the start. Anything between the two options is going to waste a lot of time and will be very frustrating. For you, and possibly for your players too.
Bandwidth is the biggest limiting factor
With all the horsepower we have in our pockets, let alone the one sitting on our desks (or laps), Internet speed is a comparatively very limited, precious resource.
The average person when they learn you have 10 Mbit/s Internet:
In all fairness, they’re most likely to have that look of sheer and utter indifference of a pubescent person.
You may be fortunate enough to utilize a 50/5 MBit/s landline (downstream/upstream) but your players won’t. Look up the average bandwidth of your target audience - your game needs to stay sufficiently below that to provide a good experience for most players.
On mobile, the continuous upstream limit is best kept far, far below 100 KiB/s. Less than 10 KiB/s would be ideal.
On desktop, the limit can be closer to 1 MiB/s but do keep in mind that the host’s upstream bandwidth limits client-hosted games and that this upstream rate scales linearly with the number of players.
Therefore client-hosted games supporting more than 4 players are rare, and those supporting more than 8 players practically do not exist.
And for server hosted games? Well, it may be a cost factor on your hosting invoice.
Do the math!
When it comes to bandwidth, nothing could be easier to calculate up-front.
Ignoring any optimizations (byte packing, compression) and overhead (packet header, protocol, etc) you can quite easily estimate your expected traffic with simple math.
Let’s say you have 100 networked units, each must send their position and their Y rotation every update. Your network tick rate is a high 60 Hz because you want this to be a competitive game.
A float is four bytes. A position is three floats. The Y rotation is another float. That’s 12+4 bytes plus 8 bytes added to uniquely ID (identify) the Netcode object.
All of this is per unit. Per tick. Per player. And I assume you said you wanted to have at least 16 of these in your game. The math for the host’s or server’s upstream rate is thus:
12+4+8 bytes * 100 units * 60 times per second * 16 players = 2,304,000 Bytes/s
That’s a sustained 2,2 Mbit/s upstream rate for the server or host. Now when it comes to Internet speeds, those are typically measured in Bits/s, not Bytes! That’s one eighth! Therefore the above upstream rate would require the host to have an Internet upstream rate of at least 18 Mbit/s!
That math is sufficiently accurate for a quick reality check of the peak bandwidth requirements. Consider that if a unit doesn’t move or rotate it’s likely just not going to send an update. But if most of them move, the game will stutter or may even disconnect due to congestion.
Use RuntimeNetworkStatsMonitor
The RuntimeNetworkStatsMonitor for NGO provides you with important insights into how much data goes through the wire.
You can configure its thresholds so any numbers that are too high are printed in red. Be sure to put this in your scene with a hotkey to toggle it on/off, and keep an eye on it. It’s easier to optimize bandwidth as you’re working on a feature. And if you wrote some code that would require Gigabit Internet, you’ll spot it right away and may have to optimize or scale down that feature.
Other networking frameworks have similar monitors.
Use Network Simulator
The NetworkSimulator for NGO allows you to make your (Multiplayer Playmode) game run as if it were played through an actual Internet connection.
It’s best to always have network simulating enabled and set to an average rate that you expect players to have, ADSL for instance or 4G for mobile. This prevents you from always seeing and building for the optimal, almost zero latency use case that players may at best experience in a wired LAN. Developing under an average end-user scenario is best practice, otherwise you’re building the game in an Ivory Tower.
But be sure to also test optimal cases as well as the low end from time to time. Doing so may reveal surprising issues that you wouldn’t catch otherwise prior to release.
Other networking frameworks ought to have similar network simulators.
Networked Physics is the Holy Grail (don’t try this at home)
Dynamic Rigidbody physics simulation over the network is practically infeasible due to the latency between physics simulations respectively the default behaviour is actually that all physics is simulated on the server/host, and thus clients cannot directly interact with the physics world.
Case in point: you will not find any networked games that use simulated physics behaviour for gameplay with the sole exception of “whacky physics” party games which make the “whacky” part of networked physics a core part of their gameplay.
Networked character controllers should thus be kinematic controllers, not dynamic rigidbodies. If you try the latter, you will notice stuttering movement and constantly penetrating into colliders and back out and similar things.
At most what is reasonably achievable with networked physics are 1v1 games like Tennis or Air Hockey, where you can transfer ownership of the play object (ball, puck) at the time it crosses sides. This will then allow each player to directly (locally) interact with the physics object without latency.
But as soon as players can directly interact with each other there is no good solution to the networked physics problems besides developing your own deterministic, minimalistic, and special purpose Rigidbody physics simulation, as they have done for Rocket League for instance.
Networked physics IS rocket science and the following presentation is a must-watch for anyone attempting to use networked physics in order to understand how non-trivial the problem space really is:
It’s okay (reasonable) if you decide not to pursue that networked physics game idea afterwards.
MMOs aren’t made by yours truly
Any multiplayer game that scales to beyond a few dozens concurrent players and/or has a persistent online world is effectively far outside the scope of what a single human being can hope to create and publish. Period.
I will not provide rationale here but food for thought:
Try finding those MMO (or alike) games that were solely created (and released!) by a solo developer. I heard of only one supposedly made by a solo dev, but was actually a community effort of a dozen contributors.
You’re likely going to come up empty handed or maybe a single prominent example from decades ago. Ask yourself: what’s the reason for this?
Same reason you won’t find an average person constructing an airplane! What do MMOs and airplanes have in common? We all know them, we know the principles of how they operate and how they are being built, but they are nevertheless extremely complex and absurdly challenging to build.
If your neighbour told you one day he’s going to construct an aircraft, what’s your response? Likely the same you’ll get from seasoned developers if you tell them you’re going to create an MMO.
The number one reasons MMOs are so rare these days
One word: cost.
The upfront investment is absurdly high already, but the running costs require skillful engineering in order to operate the MMO cost effectively. It’s all custom tech when it comes to servers and the services surrounding them (including player support) because everything needs to be created with cost efficiency in mind above all else. For this reason, you’ll practically not find an MMO middleware.
Just one penny per hour per player per server might make the difference between a net profit or a net loss. Means you not only need the engineering skills, you also need to be good at math, business and spreadsheets if you aim to create one yourself.
Or be rich. That’ll do too. 
Here’s one recent example: 
