I've pretty much finished coding my game for Xbox. However I want online multiplayer, no matter how hard it is to implement, as playing with strangers/friends over LIVE is what really makes it fun, and the biggest selling point. But I'll need some help... (First time for eveything, eh?)

My game has four characters - which run around, can pick up powerups etc. If there aren't enough human players online then the rest will be filled in with AI. So should I go with peer-to-peer or client/server? I assume all the AI, where powerups spawn and other things is calculated on one computer, and that sends the information to everyone else?

How do I test online? I only want to make it on Xbox, and the book I'm following (Learning XNA 3.0) tests it on Windows...

Lastly, as I've already coded my game, when it's online should I just have a boolean and split the code that would need changing whether it's online or not? Should I just duplicate and edit my existing code for if it's online? I'm struggling with the best approach.

The fact that you have "pretty much finished" coding your game and now want to just slap on some online multiplayer pretty much means you haven't really thought this through or made it a part of your initial design. That's unfortunate, as it means your game will suffer as a result.

The Creators Club site http://creators.xna.com/ has plenty of tutorials and info on networking and multiplayer games, xbox or otherwise. I'd make that your first stop, and then come back and ask specific questions as you run into problems.

Getting it multiplayer when you've already finished it is an easy 3-step process!
1) Start a new project.
2) Design the new project for networking.
3) Copy the artwork and gameplay from the old project.

You could also offer the process up for bids, and select a contractor you can afford and whom you think will actually finish the project.

Okay you've got the point across you need to make the game with Networking in mind. But why? How do you code a game differently that supports both online and offline?

You need to plan carefully how to keep the games on the various machines in sync. It's easiest in the traditional pure client/server architecture:
- everyone tells the server the player input
- server simulates the game
- server broadcasts gamestate to clients (usually smartly, not every object is synced every frame)
- clients display gamestate

That works for all games and is reasonably easy to implement, even when slapped onto a non-network-aware game. Problem with this primitive approach is, of course, that before a player sees the result of his own input, it needs to make a round trip to the server and back; so you definitely need to add extrapolation. Whether you should also apply extrapolation to enemy movements depends on the game. On characters moving around, usually not.

The pure client/server architecture has some disadvantages, however:
- before player A sees player B's action, the command needs to travel over the server, which usually takes longer than if it took the direct route
- mispredictions of your player's movement (say, because another player moved into your way) can be confusing.
- bandwidth requirements are asymetric; the server machine has to push the gamestate to all clients, that can be costy.
- it's hard to impossible to implement host migration in this scheme.

For games with a low number of players, peer to peer networking usually is the better choice. However, with p2p, you have to pick for yourself on a case by case basis where gameplay decisions are made, when and how they are transmitted to the other peers, how to react to conflicts, all that. One particularly tricky example: you probably have some form of (random?) pickup item spawning in your game. If you just let each peer decide where and when to spawn them, chances are two peers will spawn them differently and cause unresolveable conflicts in the game later. So you'd probably want to make that particular decision on the host of the session. Player respawns (and movement), however, can usually be handled by the respective player's machine. That makes it very hard to implement p2p when the game code is already there; you definitely want to know that your game is going to be p2p in the design phase already.

Most important disadvantages of the p2p model:
- not suitable for large numbers of players. While the data packets each peer has to send to the others are usually small, each one carries the massive XBLA and UDP overhead. You have the same problem on the server in server/clinent models, but if you educate your players about the issue, only those with a strong network will host games for many players.
- assuming you have control over the servers in the server/client model (you don't in XNA), the p2p model is more prone to cheating via code hacks (unlikely on the XBox) or network stream modification.

So yeah. If you never wrote a networked game before, it's unlikely your code is in the right shape to slap networking over it. Your chances are best if you go with a client/server model.

FlukeDude:

How do you code a game differently that supports both online and offline?

These references helped me with coding a networked game:

The Network Architecture: Client/Server sample in the education catalog

The other networking examples in the education catalog

Shawn Hargreaves networking blog posts

EDIT - forgot the most important one - used the Network Game State Management sample as the framework for the game

The main problem is making rules decisions. I don't know what your game is, but when you have multiplayer on a single machine, you know that you can make decisions based on the state that you see the player objects in. With networking, the data you will get for remote players will be several frames old compared to the data you have for the local players. Even worse, the data you have on another machine will be new for that player, but old for the other players -- so the data is not the same on any two machines. Thus, if you need to make decisions for things like "who picked up this health pack" or "did I hit that other guy," then you have to be very careful about how you make those decisions, on what machine you make them based on what the action is, and how the results of the decision are broadcast to other machines.
This is very different from how you structure a single-machine game, even when it's a single machine with multiple players. That's why we're saying that you probably have to start over.
For example, in a shooter type game, it's often common to draw explosion effects when the local player hits a remote player on the local player's screen, but you may want to have the game server (or the remote player) actually make decisions about whether hitpoints are reduced. Thus, you will update the hitpoints bar of the target at a different time (typically when receiving a property update) than you will detect/show hit explosion effects.

Thanks. I still can't see the problem with just doing:

FlukeDude:

Thanks. I still can't see the problem with just doing:

if (NetworkMode)

{

//network gameplay

}

else

{

//normal gameplay

}

The tricky part is deciding where to put those if statements and expanding the comments to code ;)

Seriously, it's harder to get a network program running than it is to get a program running on a single machine.  I think the best plan is jwatte's simple 3 step process using the network game state management sample for step 1.

Just dive in (save a backup).  The earlier posts in this thread will make more sense after you've run into some of the issues yourself.

With four players only, you could use a similar network architecture as us.

Most people wouldn't suggest this solution since it can generate a lot of bandwidth, it can react badly to packet loss, it can cause a big delay in player inputs, and you have to be careful that everything done is synchronized (random numbers, relying on animations or sound ending, etc.)

Here's the general idea.

• Send your inputs to all other players using Reliable packets.
  • I know, some people are probably grinding their teeth right now thinking it's a bad idea, but it works quite well!
• Every player simulates the game, there is no server implied, except maybe for game start or game end.
• Make sure the size of the inputs you send are under 8kbps in the worst case (for our game, the worst bandwidth usage case is 2 consoles, where one has three local players).

One other thing you need to do is to delay inputs usage. That's necessary in order to work well with the network latency. You can use the maximum RoundTripTime on the network for this and determine how long you should delay inputs (has to be sent to other players, obviously).

So far, our online tests have proven it to be a good solution, even with bad network conditions applied (500ms + 10% packet loss for example is still playable).

Of course, this is still a lot of work to integrate in a finished game, making sure the players are synchronized, making sure inputs delaying works well, etc.

A server-client solution might be faster to implement, and to get something working more quickly, but won't give you the same simulation on every machine as easily as the solution proposed. You'll have to determine which events to send, do some prediction on the clients, etc.

So, I hope this gives you enough information to choose between the different solutions!

As far as how to test this, for the development part, I've done my tests PC v.s. Xbox, using System Link. But of course, once the network code was ready, I tested with my friends online (who all need to have XNA AND Live Gold memberships).

Finally, you will want to listen to http://www.microsoft.com/downloads/details.aspx?FamilyId=07BC861A-BB03-4D25-B93E-FAFB390B75FB&displaylang=en.

This talk saved us! Really!

One thing you *could* do is to take your entire game you have now, and call it the "server."

Remove all the drawing commands, but leave everything else the same.

Instead of calling GamePad.GetState(), you'd have an input queue for game control state, that you would receive from the network.

30 times a second, or whatever, package up the changed state for each entity, and send it across the wire to all connected players.

Then, write a second "game" (that really runs parallel with the "server" on the "host" machine), where all it does is display/draw data based on what it receives from the server, and poll/send input data to the server from the user. It also contains the front-end code for hosting/joining multi-player games, setting up a single-player game, etc.

I've actually seen this done before, and it works for small numbers of players, although it is not network optimal (those state broadcasts are bloated), and it also introduces round-trip lag into all commands (which is a problem for a fast-paced game played with one player in Boston and the other in Honolulu...)