What to prioritize if you're implementing mobile multiplayer

Ernest Woo wanted to make a real-time multiplayer game work over 3G -- a unique challenge for anyone, but an especially difficult one for someone who in his own words "had no idea how to make a multiplayer game." His solution, ultimately used in his mobile game ErnCon (pictured), took the unique approach of integrating existing network techniques together into a method that should prove useful to iOS and Android developers alike. Now Woo is sharing his findings with our game developer community, outlining his process from prototyping on one of his old games, "abusing" Java, finding the right matchmaking service, and familiarizing himself with the tried-and-true Quake III Networking Model. As a taste, here are Woo's top four considerations for finding a networking model that will work over 3G connections for up to eight players: 1. Network Address Translation (NAT). Because ErnCon must be playable over 3G, I had to figure out how to traverse Symmetric NAT typical of cellphone carriers. After researching UDP Hole Punching and other NAT traversal techniques, I settled on the simpler solution of a client-server architecture where the servers always have a public IP address, i.e. the servers are not NAT'ed themselves. No special NAT traversal tricks are required for communications to a public server. 2. Simple network model. Without experience developing a real-time multiplayer game, I sought information on how other games implemented their networking layer. Quake III's network model, which I ultimately chose, proved to be much easier to understand, with its simpler notion of sending entire game-state updates delta compressed from the last known received state. 3. Reduced chance of exploits. As an indie developer, I don't have the resources to implement robust cheat detection. The architecture of the game itself must be resilient to hackers, as any data controlled by the client is ripe for exploit. A client-server architecture satisfies this concern by making the server the sole authority for all game data. 4. Worldwide server deployment. A real-time multiplayer game using a client-server architecture will not run well if all players in the world are connecting to servers located in a single location. To reduce lag and improve the game-play experience, servers must be strategically provisioned around the world. Players have to be segregated into regions so that geographically close players are always playing on the same servers. Amazon Web Services (AWS) was a boon for me allowing me to provision servers in various places including the US, Europe, Southeast Asia, and South America. All of this is expanded in Woo's full feature article on the network development of ErnCon, in which he details exactly what methods he used to get global, eight-player multiplayer real-time gaming up and running in his game. It's live now on Gamasutra.