Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
July 15, 2019
arrowPress Releases

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Matching up players in online games.

by Bram Stolk on 02/23/13 04:40:00 pm

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


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.

Related Jobs

DMG Entertainment
DMG Entertainment — Beverly Hills, California, United States

Game Engineer
Giant Army
Giant Army — Remote, Washington, United States

Graphics Developer for Universe Sandbox
Build A Rocket Boy Games
Build A Rocket Boy Games — Edinburgh, Scotland, United Kingdom

Senior Animation Programmer
Build A Rocket Boy Games
Build A Rocket Boy Games — Edinburgh, Scotland, United Kingdom

Gameplay Networking Programmer - All Levels

Loading Comments

loader image