Defective Logic E = MC Hammer

SquadBots: XBox Live Multiplayer Completed

Last night I played SquadBots over XBox Live for the first time.  I wasn’t sure ANYTHING was going to work, as this is the first time I’ve written XNA netcode.  But it did, and in grand style. You know, except for all the bugs.

More and more I’m starting believe the old adage “Busy people are productive people”.  I had an unvoiced fear that I would not be able to complete sprint 1 on time.  Sprint 1 consisted only of getting the base game, which supported only local multiplayer, to work over XBox Live.  The work pattern seems to be: I estimate 8 hours, push it off for a week, worry about it for four days because I’m not making any progress, then finally pound it all out in three hours.  These results do nothing but encourage my procrastination.

After reading up on XNA net-code, playing with different ways of implementing a network game, I have to say that the most productive example of a network playable game that I was able to get my hands on was the NetRumble game template from the Creator’s Club Online Website.  It’s not exactly the type of game we’re making, but it provided more than enough examples of network processing and event responses.  This really helped me break some shit.

What we should be doing
Typically, in a host-oriented multiplayer environment, players will send their intentions to the host.  The host then processes these inputs, determines an outcome, and send that outcome out to all players involved in the game.

In a “host” driven game we can at least assume that if there is a discrepancy between the player’s game information, that the host is always right.

What we are actually doing
Because SquadBots is only two players, we’re getting away with a few shortcuts.  We’re allowing the active player to do all the normal calculations as he would in a local multiplayer game and simply send the updates to the other player.  The local code calculates whether particular game events need to occur and then updates the local board unilaterally, meaning each client updates it’s own game board based on their own unilateral calculations and we’re going on faith that those results are always the same.

The risk in this approach, of course, is that if the clients become out of sync somehow (lost packets, etc) we are in trouble.   With this in mind, we’re using SendDataOptions.ReliableInOrder to maximize net message integrity.  This is the most expensive “packet option” performance-wise, and therefore, is normally avoided.