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?
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.
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?
