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?

2 Answers
2

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.

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.
–
AttackingHoboOct 30 '10 at 17:27

8

@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.
–
user744Oct 30 '10 at 20:28

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?