Networking Techie Stuff

So I've been thinking about what's going to make this game special, and so far I've come up with pretty much the only thing being the multiplayer environment.  Many games can be played with 2 players, but it takes some special networking considerations to make sure that a 3+ player game works properly.

First, let's talk about what's actually happening when you play a multiplayer game like Call of Duty: Black Ops or something.  First, the little messages that pop up saying stuff like "connecting to servers" or something like that are one indication of how the game is running.  If you were playing Domination mode with 24 players, it would be hell to program an architecture in which each XBox connects to every other XBox and opens two connections (one for me to tell you what I'm doing, one for you to tell me what you're doing - it would be pretty bad if only one person could actually perform an action at a time) and have the machines maintain a consistent state for what the game looks like.  Trying to create a p2p game like that would result in so many synchronisation problems that the game wouldn't run well, be prone to cheating everywhere and would be a complete fail.

And so they took a server architecture route.  You only need to tell the server what you're doing, and the server tells you everything else that's going on with all of the other players.  2 connections instead of 48.  The server also acts as the master and so all synchronising that needs to be done, the server does.  It's just a better model for this type of network.

If you're confused about what I mean by "synchronisation" consider what actually happens between your controller and the game.  I'm sure you've seen your latency at some point at something like "42ms".  That's the delay for commands you issue to get to the server and back (a round-trip latency). 

Consider what happens if you're actually playing a game.  You move your character forward by pressing up on the left control stick.  Guess what?  Your character doesn't actually start moving forward until about 21ms later.  You strafe right using the right control stick.  Again, you don't actually start doing that until about 21ms later.  You stop moving? Doesn't happen for another 21ms. 

I'm sure you've been in laggy games before and you've experienced moments where you go "how could that guy even have seen me from there?" or "I totally stabbed that guy but he killed me first? This is bull".  The reason is that what you see on your screen doesn't always match up perfectly with what the server thinks is happening, but the server gets the last say.  If your lag is up at almost 1 second say, that's half a seconds worth of extra walking forward that you don't personally see on your screen, but the server thinks you're doing it.  Half a second is a pretty long time, especially if you're doing something like creeping up on some guys who you know are around a corner.  To them, it looks like you're a noob who walked out around a corner and didn't see them because that's what the server said you did.

So the question becomes, what actually needs to be sent between a server and a client, and what needs to be sent from the client to the server?  Most of the time, they just send changes.  This is to minimise the amount of information being sent.  For example, instead of having to tell the server everything about the state of every button and dongle on your controller, when you walk forward in COD, you just send the server a message to say, "I'm now pressing forward".  When you stop you say, "I'm now not pressing forward".  Think about what happens when you lag very badly in a game of COD.  If you're walking forward and you see the connection interrupted overlay, when you reconnect, you're 30 feet farther forward than what you last saw.  That's because you never sent the message "I'm now not pressing forward" and so the server just assumes you're still pressing forward.  Only changes are sent.

The server only sends you changes about where your enemies are, what new specials are in play etc.  It doesn't tell you how to render anything or where anything is - just the changes.  That's all that's important to the game.  Your own xbox does the rendering of what it receives after interpreting what was sent.  In fact, the servers probably have no idea what they're actually looking at - it's just sets of numbers and letters that it knows how to send route through different ports to all the players playing.

Now, I do know that it's a bit more complicated than that, but that's generally what's going on when you play a multiplayer game.  With 2 player games you really don't need to worry about most of that stuff because there's only 2 people - one of those clients can act as the temporary host and the chances of de-synchronisation is much lower.  The number of calculations needed is much lower. 

This is how I need to create my game - with servers to connect to and information only being sent between server and client about what changes are being made.  The really cool thing about this kind of design though, is that I can actually make the game transmit all of its information in plain text - that way you can have the game playable not only multiplayer, but it could be played between different cell phone operating systems.  The only thing a phone needs to consider is rendering, input and transmission of what changes there are to input.  With text, that means the server shouldn't care what kind of phone is being transmitted to and as long as the phone can interpret text, the program should be able to understand what the server is telling it to render.