MERCH!
Giant Bomb - a website about video games and the people that make them

Where the Hell is my Online Co-op!? Part 1 of ???

by fobwashed

Have you ever played a game that had local multiplayer and wondered why the hell you can't play it online with your friends over Xbox live or PSN? Play me with your friends, just not online... Or, other times, wondered why the hell it's taking so long for a developer to deliver that very feature in a timely manner since it was promised? While I can't really speak to all games, I've not gotten a...

Have you ever played a game that had local multiplayer and wondered why the hell you can't play it online with your friends over Xbox live or PSN?

Play me with your friends, just not online...

Or, other times, wondered why the hell it's taking so long for a developer to deliver that very feature in a timely manner since it was promised?

While I can't really speak to all games, I've not gotten a small taste of implementing some basic multiplayer into a game. The following is my own personal experience and is in no way comprehensive. Hell, I'm totally new to this so I'm sure I'm doing a lot of it wrong and badly, but I think some of what I've learned is fairly solid and should at the very least, explain some of what's going on behind the screen.

What I'm writing is in regards to XBL

The game I've been writing networking code for is currently being written specifically for the 360. I'm not certain what the requirements or overhead on PSN/PC games are but I'm going to assume that they're probably fairly close to the restrictions I'm currently working with. Still, I think it's a good idea to put forth that these numbers are for an Xbox Live game.

Latency and Ping

I'm sure anyone worth their salt in online gaming knows about the almighty ping and latency. Everyone's experienced a laggy game and I'll first get the basics out of the way. I've been playing online games since it was just starting out with dial up modems and even I had some revelations when it came to the actual numbers of why my ping is what it is. Those of you already in the know, pat yourselves on the back and scroll on down. For the rest of us, here's a quick and dirty breakdown of how your ping got to what it is. (BTW, ping is the time it takes from data to get from your computer, to another computer over the internet).

Light speed, still not fast enough!

First we'll start with the speed of light (186,282 miles per second), which, while fast as all shit, is still slow enough to measure. To travel a mere 1,000 miles, it takes 5 milliseconds. Also, we're talking about the speed of light here, not the speed that data travels down a cable. Signals travelling down fiber or copper network will slow to around 60% the speed of light. On top of sheer distance, data doesn't tend to go directly from one computer to another. Every router in its path will add around another 5ms. I'd say when I'm playing any online game be it starcraft, counter-strike or whatever, I consider anything below 20 ping amazing (with the server or host being in the same county), 30~40 very solid and when given the option stay away from anything higher than around 60. When I used to play more DoTA, if I had over 100 ping, I'd definitely notice the lag in between my clicks and the game's responses.

XBL recommends

The text involving implementing multiplayer into an XNA game reads that the recommended limit be 8kb a second. The reason for this specifically, I don't know but I do know that during the Halo 3 beta in 2007, Bungie Studios reported that 1% of consoles on Xbox Live have less than 8kb downstream and 8kb upstream. 50% had less than 42k downstream and 44kb upstream. Yes, 1% isn't much, but it does mean that for every hundred people who actively play online (since the data is specifically from a beta to a hardcore online focused FPS, I'd have to guess this number may actually be higher) will have a bad or unplayable game if you decide to break that recommended limit. On top of this, Xbox games are expected to function with at least 1% packet loss and 200ms ping.

Xbox doesn't even give you the entire 8kb...

Here's a breakdown of how expensive it is to send information, and how damn quickly you can fill that 8kb per second limit. Say you have a game that runs at 30 FPS with 8 players and you want to send the player's position (Vector 3 (X,Y,Z coordinates)), their velocity (another Vector 3) and whether or not they're doing something (a true/false boolean). Also, on Xbox, you always have to factor in the possibility of voice (since even if you're not using voice in this game, you may be in a chat lobby) adding an additional 500bytes a second.

that'll be 7(players) * 30(fps) * (12(vector3) + 12(vector3) + 1(bool) + 51) + 500(voice) = 19k.

Yup, sending those three simple things to 7 people in an 8 player game once a frame will put you over the limit two fold. Oh, and that 51 that's crammed in there, that's the header that automatically gets added to every packet you send which contains some basic data that all packets need. Specifically

20bytes IP header

8bytes UDP header

16bytes Microsoft Live Encryption

7 bytes XNA framework Overhead

so I suppose if you were to not be using XNA, you'll be saving yourself a whopping 7 bytes off the header that I'm fairly certain would be used up by something else in your own framework.

Anyway, due to that expensive overhead, sending absolutely no information and empty packets to 7 players 30 times a second would end up costing around 13kb per second. Still over the limit >,< Oh, and we still haven't talked about the possibility that your data isn't even guaranteed to end up where you're sending it, in the order you're sending it.

Packet Loss

It's somewhat shameful to admit, but I only just recently learned the difference between TCP and UDP. I've been setting up port forwarding for years just plugging in numbers, but never knew what the difference between the two were. Here's a very, VERY basic explanation of the difference. TCP is network data, that is considered reliable. What this means is, every bit of data sent TCP is confirmed and accounted for. If some data gets lost along the way, it will be sent again and again and again until the sender gets confirmation that the information was received in it's entirety on the other end. UDP on the other hand, is just fire and forget. One computer sends it, and we hope it gets to where it's going, but if it doesn't, meh. . . it's forgotten for all time and eternity. Now, the reason why all data doesn't reliably always get delivered? I don't know, but the typically, 2% of sent packets (little bundles of data) get lost with the high end average being around 10%. Oh, and when using UDP, data sent later may get to it's destination sooner than something sent previously or vice versa. Basically, it's a 90+% crapshoot that the data will or won't get to it's intended location, in or out of order when using UDP. Why doesn't everyone and everything just use TCP you may ask.

A SHORT AND LONG EXPLANATION OF WHY EVERYTHING ISN'T SENT USING RELIABLE OL' TCP

The short answer? Speed. The long answer? Since TCP always confirms that the packet has reached it's destination, there's that amount of extra latency. Any time any portion or the entirety of the packet is lost, it is resent. This takes time. In addition to that, TCP sorts packets in the correct order once it arrives at the location it was getting to. So, say you're playing a game and you're moving from spot A to spot D and you're sending TCP information at each point in that movement. The computer sends the information in the order A, B, C and D. The receiving computer, due to internet wackyness, receives A, then D, then B and finally C. The receiving end may already have the final destination (D) but will not acknowledge it until it has all the packets in between (B and C). There may be games in which the positions in between are necessary but in most cases where speed is more important than order (say any racing game or FPS), only the most recent position is required. Predictive algorithms will fill in the motion between A and D and when B and C arrive, they'll be discarded. In games where quick response is necessary, that additional latency is killer. If any of those in between packets were lost during a TCP type exchange, that'd increase the amount of latency to unplayable levels.

What does all this shit have to do with my goddamn co-op?!

Well, that brief lesson in network data was just a primer to put forth that it is goddamn hard to make a multiplayer game. Hell, when I started and began reading about all this shit I had to put up with, I'm blown away that games like Halo and CoD work at all. But, for now, we'll keep it stupid simple because honestly, that's all I know. I'll talk about what I'm doing to implement multiplayer into my game and even being as rudimentary as it is, how goddamn hard it is.

When I began writing this, I thought I'd just spit out some stuff real quick and explain the situation. . . but it's something I'd like to go into a bit more depth about. This being the case, I'm gonna have to split this up into a second post that details a little bit what goes into writing network code (at least my rudimentary shitty network code), and some more insight into how much hell it is to try to compensate for latency and lost packets. I'll be back later in the week as soon as I have time to write it out properly -_-;; Sorry to those who skipped ahead and found nothing!