Sponsored By

Matching up players in online games.

Be careful how you match up the participants in an online game session, or: why 300,000km/sec is sometimes slow.

Bram Stolk, Blogger

February 23, 2013

3 Min Read

I am currently reading up on cartography. I need to visualize the earth in such a way that distances are accurately depicted. The way to do this is to map the globe using Interrupted Sinusoidal Mapping. Why am I so interested in distances at the moment? It is because of multiplayer gaming.

One of my goals for 2013 is to release a multiplayer game. And writing multi player action games is hard. Especially if you consider that my games always have a strong theme in physics simulation. Distributing a physics simulation is so hard, I consider it unsolved and probably intractable as well. Games typically use hacks, tricks and fakery to give the illusion of a shared experience in a virtual world with simulated physics.

What makes multi player game development hard is not bandwidth restriction, but the network latencies. In action based games (not turn based) you want immediate responses to player input. This player input needs to be communicated over the network to other parties. Even at speeds that are near the speed of light, this communication takes a very long time from the computer's point of view.

The speed of light in vacuum is roughly 300,000km/sec. This seems really fast, but if a UDP packet needs to take a one-way trip to a player 15,000km away, it would take 0.05 seconds. And guess what, in 0.05 seconds our game will have rendered three frames at 60fps. Now this is under ideal circumstances. What if the information needs to make a round trip? Then it is already 6 frames. It gets worse with the latencies introduced by the network equipment. And what if the packet makes a detour to another hub, or worse a satellite hop? And worse of all, a UDP packet can get lost altogether.

As a game programmer, I have no control over the network equipment at a player's home and at his provider. I do have control on how I match up my players though. I cannot afford to have an online match where one player is in Europe and another is in Australia. The limited speed of the signal and the long distance will create large delays between when information is sent and when it is received. I need to do the match-making in my game lobby based on geography. And while doing that, I might just as well communicate this local nature of opponent selection to the players. So I am going to visualize the pool of potential opponents for the player using a mapped globe that accurately depicts distances.

To divide the globe into player pools, I was considering using time zones. This would give 24 partitions. But in a single timezone, there is a long north-south distance. So I will split those at the equator. As there are no gamers on the North and South Pole, the resulting 48 zones should be relatively compact.

The multi player gaming API in Apple's iOS is part of GameKit. It is hard to determine how Apple servers work when matching up players. I hope they take locality into account when matching players. But I have not been able to determine whether they actually do this. So I think I have to do the region encoding myself. There is a hook in iOS for this in the GKMatchRequest class. This class lets you divide players with the playerGroup property. And using the queryPlayerGroupActivity:withCompletionHandler: method of GKMatchMaker I could even visualize player activity on the globe map.

Keep an eye out on my blog, to follow my progress in this venture. And wish me luck, I need it. There is very little documentation on distributed simulations. The main resource on this subject is seven years old and available at Gaffer on Games. I will leave you with a sneak peek at my new game.

Read more about:


About the Author(s)

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like