Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I plan to use XNA to build a game project. I'm not entirely sure at the moment if I want to add multiplayer functionality or not, bearing I have a lot of other problems to solve that I'm still new at. I don't want the project to necessarily get out of hand.

My question is, If I head into my project with no plan to add multiplayer support, is it easy to go backwards (It's usually not) and add the necessary code to capture a multiplayer game?

share|improve this question
up vote 24 down vote accepted

Here is sound advice taken from the Zoidcom networking library manual:

If your project is in the planning stage, it is advised to design the project for networking right from the start. Bolting on network code in a late state of the project will most likely either lead to massive refactoring or a large amount of hacking, resulting in hardly maintanable and bug ridden code.

The cleanest way is to implement the whole game as if it were a pure network game. That is, implement code for a dedicated server, and implement this code for being server code only. Implement the game client code in a similar manner. Server and client can run in the same process and don't even need to use a real network socket, but they should be seperate entities and all code should be designed to work that way. When the player jumps, don't alter the player's jump vector directly, but send a 'jump-key-pressed' packet to the server and let the server handle that.

This means that even in a singleplayer game, there is an invisible server running in the background. A multiplayer version of the same game just needs to connect to a remote server instead of the local one et voila, multiplayer done. The advantages of this are:

no seperate code for single and multiplayer the network code is tested and developed during the whole project clean code

Projects using this scheme are almost all games using any of the Quake engines, Civilization 4, Neverwinter Nights and many many more.

For connecting client and server in the same process with zero latency, local sockets can be used. These are provided by Zoidcom and pass packets directly from one ZCom_Control to another, without going through an OS level socket.

share|improve this answer
It sounds like this is a setup for pure server authority which I hate. If your ping to the server is low it plays fine. But when the ping gets too high, the actions on your screen are delayed. I much prefer the method that the source engine uses, the client runs physics and things locally and any action immediately shows up, but the server still checks it to make sure people are not hacking, and if there are any inconsistencies in what should have happened, the server sends the correct state to the player and overrides the clients simulation with new data. – AttackingHobo Oct 30 '10 at 17:27
@AttackingHobo: You're just describing client prediction. You can have client prediction and server authority together just fine, and it doesn't preclude the architecture described in the Zoidcom manual at all. – user744 Oct 30 '10 at 20:28
@AttackingHobo @Joe: And Zoidcom actually supports client-side prediction^^ – Leftium Oct 31 '10 at 5:13

I agree with the advice quoted in Leftium's answer; design it for networking from the start, because you won't be able to add it later.

The first time I tried to make a multiplayer game (I wasn't even trying to make a single player game!), I figured I would first get the game working and then add networking. Bad idea. I was left with a prototype of a really boring single player game and no clue how to transform that into a multiplayer game. I scrapped it entirely and started over, this time writing multiplayer networking code right from the start. Everything clicked.

I'm sure it's not impossible to start with a one-player game and add multiplayer functionality. If you think it through, plan it correctly and make sure you know your strategy then sure, give it a try. I think it would be an interesting puzzle to work through at the very least. But really make sure you know your plan as to how you're going to add networking.

I think there is a middle ground (though I've never tried it). You could write some dummy classes for networking/multiplayer features, and be diligent in using them as you're writing the single player game. Then later, if you decide to implement multiplayer, just fill in the dummy classes and you'd be most of the way done. This very much approaches the server/client method, but you might be able to get away with less work; after all, a single player game is easier to make than a multiplayer game, so if you're going to write your single player game like a multiplayer game then why not just make it multiplayer?

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.