Turn a single player game into multiplayer game

Question

hobbyist / indie dev here and I was wondering about network programming and making a game capable of multiplayer.

So basically I just haven't touched on network programming yet and really don't know much and have very little experience with coding multiplayer games. So with that in mind I have a project I want to make and I have all the key points pretty much on paper and a clear vision of what I want to make, I am also going to end up recruiting help (for such things as multiplayer capability more than likely as well as other aspects) since this is outside the scope of my ability to do alone.

I do not plan on having this game hosted by a central server I control and am leaning heavily on the side off a type of p2p connection like minecraft / starbound / terraria (I think those are p2p anyway) with that in mind is it extremely important that I code / build the game with multiplayer from the ground up or might I be able to work on other systems first such as game mechanics and the procedural world creation first and might it be easy to basically create a multiplayer system ontop of the game?

I guess the question is kind of broad but what it boils down to is might it be critical to focus on the networking / multiplayer first or is it a safe and(or) common practice to implement it later in development?

Answer 1

First, you should read through Gaffer on Games's article What every programmer needs to know about game networking. It covers all the important parts on typical networking architectures and their pros and cons. There's also some decent answers here: Limitations of p2p multiplayer games vs client-server. But basically you have two architectural choices: P2P or client/server¹. It's an important decision since it has huge consequences, like how well you can handle cheating, or compensate for latency, all of which depend on your game; there is no "right" choice.

The reason why you need to be aware of all this is that it also affects your choice on whether to build your game with networking in mind from the start, or build it in later:

• P2P is much easier to build later than client/server, especially if the game's architecture was not designed with clear separation of concerns from the start, like mixing game logic with rendering. As someone who's added client/server networking into such a game, I can attest to it being a huge amount of work.
• Client/server is harder to work with, especially if you are a small team. Any game feature might involve multiple decoupled systems, and additional decisions on how it will be handled: by the client, by the server, by both, and how. For programmers not familiar with this, it can slow down progress.
• However, for the most demanding networked games, client/server is pretty much mandatory, given the severe limitations of P2P.

This is all covered in the Gaffer on Games article I linked at the start. Here's the relevant real-life experience from id's Doom/Quake games:

• Doom came with P2P networking, which worked well on LANs but was unplayable for the typical online connections at the time (14.4Kbps modems).
• Quake was written as a pure client/server architecture from the start, and networking was trivial. Online multiplayer was playable but typical clients experienced so much latency that they had to suffer a degraded experience
• QuakeWorld, which included client-side prediction, meant that players with high latency can still play with a decent experience, and this model became the industry standard since

So what this all boils down to is four choices, ranked from easy to hard:

• Write game with P2P networking from the start
• Write game first, add P2P networking later
• Write game with client/server networking from the start
• Write game first, add client/server networking later

And with the following considerations:

• P2P is easier most of the time²
• Client/server is mandatory for online networking for certain genres (action, MMO)
• Writing with networking from the start is easier, and much easier if you choose to do client/server
• But keep in mind the caveat that game development is risky, so there's an advantage to making a game as fast as possible to test its viability

¹Note that when I say "client/server" I'm assuming you also do client-side prediction. Pure client/server, i.e. dumb clients, isn't too hard. Most of the difficulty comes from client-side prediction and how you reconcile client and server discrepancies.

²P2P can be harder if you want to handle things that it's not well-suited for, like drop-in/drop-out. But the "classical" P2P lockstep model as used by Doom is dead-easy, it simply requires sharing state across all the players.