In this article we'll walk you through how you can make your mobile web game resilient to poor network conditions. Many excellent developers are used to developing games for the desktop environment, but often don't think about network reliability when they implement their apps. When you find that your app freezes up over a cellular network you can shrug and blame the carrier, or you can roll up your sleeves and fix the problem. We'll teach you how to fix such problems and discuss the creation of multiplayer games that play great even in areas where the user's cellular coverage is not great.
It turns out that some of the old methods from way back came in handy when I recently wrote the cellular-network-friendly networking code for Moblyng's Social Poker Live. I have a few years experience working on games over questionable network connections, including 28.8k - 56k modems.
Before we dive into what the issues are and how to solve them, I'd like to quickly review the game so you can see what I'm talking about is a solution we used in a feature rich, live production quality title.
Social Poker Live is a multiplayer poker game that can be played in real-time, over any internet connection on iOS and Android mobile devices (phones and tablets), and it's resilient to spotty network conditions.
For example, you can play the game on Caltrain going from San Francisco to Redwood City, and will recover going through tunnels and the like.
Of course, the game also runs well on a desktop, but in this article we'll focus on the mobile experience. Try out Moblyng's Social Poker Live on your iOS or Android phone at http://poker.moblyng.com.
Here are some screenshots of the typical user experience, starting with the loading screen, all the way to the winning screen. One neat feature is that we'll discover which of your Facebook poker pals are online, and ask you if you'd like to join their table. Here is what that looks like:
I'd like to encourage you to load the game in Chrome, bring up the developer tools, look at the Network tab, and go back to the game to sit at a table. You'll see the data passed back and forth between the client and the server, including packet identifiers and acknowledgements that we'll talk about in the rest of the article.
Traditional web technologies are decent with issuing requests to servers. The client knows when it wants some piece of information and hits the server with an HTTP request, and as a result the server scrambles to offer up the request as quickly as it can.
In multiplayer games the game client knows it wants game updates as quickly as possible, but it doesn't know when to ask for such information. This doesn't fit well with a model where the client has to initiate the request for data. When do you ask for an update?
You could just hit up the server once a second with an active poll request. Your operations manager could also decide to hit you once a second over your noggin because that's not efficient for neither the client or the server. All hitting aside, you won't get sub-second response times -- especially over a cellular network.