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?

  • 4
    \$\begingroup\$ Focus on the multiplayer first. It's such a nightmare to integrate after the fact that you want to base your whole architecture over it. \$\endgroup\$
    – Vaillancourt
    Commented Mar 16, 2017 at 1:33
  • \$\begingroup\$ A challenge with multiplayer is that one must locally maintain a data set that describes a remote peer, and that this data set interacts with the local (single player) data in many ways. Another is that one must synchronize (time between) the peer sessions. This affects the way you describe things in data. Example: Instead of turning on a light by simply changing a value from 0 to 1 right now, you may have to describe it as "light goes/went on 234.2443 seconds after time zero". Multiplayer causes numerous additional issues, so 2nd Alexandres comment above. \$\endgroup\$
    – Stormwind
    Commented Mar 16, 2017 at 2:01
  • \$\begingroup\$ According to the Diablo postmortem talk on GDC, the first Diablo was made without multiplayer in mind. All multiplayer code was introduced later and implemented in two months or so. \$\endgroup\$
    – badunius
    Commented Jan 24, 2020 at 3:32

1 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/server1. 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 time2
  • 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

1Note 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.

2P2P 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.

  • \$\begingroup\$ You stated, that P2P is easier most of the time yet the linked question's accepted answer says otherwise, can you elaborate? In scenario keeping everything in sync across all machines vs. client is just a dumb terminal sending keystrokes, it would appear latter is simpler. \$\endgroup\$
    – wondra
    Commented Mar 16, 2017 at 11:06
  • \$\begingroup\$ Dumb terminal still requires a client/server architecture, using event/message/command patterns, and it's typically not something novice programmers work with. Compare this to directly updating state as it is received from peers. \$\endgroup\$ Commented Mar 16, 2017 at 11:41
  • \$\begingroup\$ I guess it makes sense - if you dont care much about consistency(some of weaker models) or bandwidth. \$\endgroup\$
    – wondra
    Commented Mar 16, 2017 at 16:20

You must log in to answer this question.

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