Mobile Multiplayer Gaming, Part 1: Real-Time Constraints

Print-friendly Version

Developing your mobile software on the Java Platform, Micro Edition (Java ME) puts well over a quarter of a billion mobile handsets at your command. Even better, all these devices are networked. Networking capabilities are built in, as required by the Mobile Information Device Profile (MIDP) specification. This platform has all the hallmarks of a fertile playground for developers' imaginations, including the prospect of real-time, network-based, multiple-player games - but where are all these games?

This article examines the obstacles to writing a successful real-time multiplayer game for mobile devices, and proposes design solutions to help you on your way.

Several kinds of participants in the industry share responsibility for the slow proliferation of multiplayer mobile gaming. Chief among these are the mobile network operators, the mobile gaming consumers, and software developers themselves.

Mobile operators, also known as wireless carriers, are large companies that manage wireless connectivity for hundreds of millions of consumers over broad geographic regions. The last thing they want is another way to complicate their already difficult business. Allowing Java technology to turn their simple phones into sophisticated software platforms was itself a huge step. Allowing software on those devices - especially unsanctioned third-party software - to consume network resources is a leap the operators are only now beginning to contemplate fully. To overcome this barrier, successful networked games must consume bandwidth sparingly, and pass at least some form of certification by operators. Incidentally, the Java Verified program is a good place to start.

Some operators fear the additional strain on their networks. Those that offer flat-rate data billing plans in particular are concerned that they won't recover the cost of each additional kilobyte transmitted. Premium prices or recurring subscription fees for networked games mitigate this concern, but reluctance to promote, or even allow, multiplayer content remains.

Differences between mobile-game consumers and their counterparts in console and PC desktop gaming place another stumbling block in the path toward wider adoption of mobile multiplayer games. The fundamental difference is that mobile-game consumers tend to be "casual gamers," who more closely resemble the general population than hard-core gamers. Unlike their desktop counterparts, who play in marathon sessions, typically at home, they more often play games in short, intermittent bursts, while in a checkout queue or a doctor's waiting room. Where the PC gaming world focuses on the latest release from the Halo or Doom/Quake franchise, most mobile consumers are content with the original Jamdat Bowling that came pre-installed on their handsets several years ago.

Mobile software developers and publishers are wary of networked games too, for the reasons already mentioned and because developing multiplayer games is very expensive. The complexity of the interactions and the sheer number of use cases to implement and verify drive up the cost of development and testing. Add to these conerns the inherent difficulties of creating a compelling gaming experience in a mobile form, especially wrestling with the extremely high latencies common on most wireless networks, and you'll find very little enthusiasm from the management of any software company.

In the time it takes to bring a multiplayer title to market, an accomplished shop can ship several single-player non-networked games. Because multiplayer games thus far don't sell demonstrably more units than single-player games, justifying the extra costs of their development is difficult. The big game publishers move cautiously, and the small development shops that traditionally assume greater risk to bring innovative titles to market have a notoriously difficult time convincing the mobile operators to sell their product.

The outlook is not all gloomy, however. Multiplayer games can succeed in the mobile environment when they're tailored to appeal to casual gamers, and to address network operators' concerns. Let's look at kinds of multiplayer mobile games that have met success in recent years.

The first mode of networked interactivity that attracted mobile operators was the addition of "community" features to standard single-player games. Network-wide high-score lists, tournaments, and limited chat have all been features that could be rolled into existing single-player games. Because these changes were applied to games that were already popular, the publishers assumed little risk, and the operators could quantitatively compare the cost of the increased network activity to the increase in revenue per subscriber. Community-based competitive appeal and word-of-mouth advertising led these experiments to succeed.

Turn-based games soon followed. Because a player's pause to think between turns is usually greater than the latency on the wireless network, turn-based games can be equally compelling in single- and multiplayer modes. Board games like Chess or Checkers consume very little bandwidth between moves and have done well in their multiplayer mobile incarnations.

The number of players is significant. Two-player games are easy to administer because a user needs to connect to only one other user. By contrast, games with more than two players require a virtual "lobby" where players can meet online before joining a game. Because the additional cost and complexity can be prohibitive, several companies exist for the sole purpose of providing this middleware, and some mobile operators provide these services as well. Card games like Hearts and Texas Hold'em are popular examples that do well in the mobile multiplayer space.

Today, many companies labor fiercely to bring real-time multiplayer gaming to the mobile domain. The compelling hallmarks of these games, however - tens to thousands of subscribers immersed in the same game world, playing in real time for hours on end - cut against the grain of each of the difficulties networked games face in the mobile marketplace. Success will come to those who carefully negotiate each of these obstacles.

The primary headache facing all real-time multiplayer game developers, adequate network performance, becomes a migraine on mobile networks, compounded by the degree to which consumers' expectations for mobile content differ from the norm in the console and PC gaming worlds.

Overall, the foremost and critical problem for a real-time game is the network's latency, the time between sending a request and receiving a response. For PC-based multiplayer games, latencies are measured in tens of milliseconds on a local-area network, and in the hundreds of milliseconds across the Internet. Over mobile operators' networks, by contrast, latencies can chew up thousands of milliseconds. Put simply, the lag between the request and the response can be several seconds, and this level of performance is not expected to improve much in the foreseeable future.

Nothing more directly affects the user's enjoyment of a real-time game than the degree of perceived latency, the delay between issuing a command or action and seeing its results on the screen. Whether there are two players, or two hundred, or two thousand, no one wants to see visible effects of lag on their gameplay, or worse, to lose a game because of it. The development of a real-time multiplayer mobile game must allow for latency in both the game design and the software architecture.

Network bandwidth is another hurdle to overcome. Some mobile operators charge a flat rate for unlimited network use, others charge their subscribers by volume, usually on a per-kilobyte basis. Either way, to satisfy both the players and their mobile operators, data transmission must be kept to a minimum.

Unfortunately, every multiplayer game consumes bandwidth in proportion to the number of connections between players. For a peer-to-peer game, the bandwidth usage grows exponentially with each additional player. A client-server architecture scales more nearly linearly, but introduces a new crop of problems regarding server scalability for what could be tens of thousands of players or more, depending on the size of the operator's network and the popularity of the game.

Mobile operators around the world are focusing on deploying their third-generation networks to alleviate the bandwidth bottleneck and make way for streaming multimedia content. While some of these networks are already being deployed, you can expect the bandwidth situation to improve only over the course of years, not months.

Network issues aside, mobile consumers themselves, their devices, and their expectations of mobile content, impose an equally difficult set of limitations on the design of real-time multiplayer games.

The limited capacity of a mobile device is obviously a challenge, not helped as mobile consumers' tastes and purchasing habits drive the sizes of the devices to smaller extremes with each passing season. While screen resolution is increasing, it barely keeps pace with shrinking screen size. Few expect dimensions larger than quarter-VGA (320x240 pixels) in coming years. Multiplayer gaming demands screen area to represent the competitive landscape, and the more players join a game, the more pixels needed to render game state. Mobile multiplayer user interfaces must be crafted with these constraints in mind.

The whims of the consumers are also manifest in the diversity of mobile device designs. Never has the computing world seen, for a single software platform like MIDP, such a variety of shapes, sizes, and input methods. Some handset manufacturers have diverged greatly from the familiar 12-key number pad configuration, and these variations have proven distressingly popular. Mobile developers must adapt the control methods for their game so that they function effectively across many different hardware designs. Typically, the designer adopts a least-common denominator approach: the fewer controls the better. This strategy is difficult to stick to at best, given the complex design of most multiplayer games.

The casual nature of mobile gaming forces another constraint. The casual pick-me-up-put-me-down mode of play typical of mobile gamers is completely at odds with conventional multiplayer designs, which emphasize congregating in a game lobby until all players are ready to begin a game together. For mobile games, connecting to a multiplayer session needs to be as effortless as possible, with no registration, waiting, or other delays between the user and the thick of the game. The game design should also accommodate players leaving the game intentionally or accidentally, without undue penalty, or disruption to the other players.

For a real-time multiplayer mobile game to be successful, the game design, the user interface design, and the network architecture must all address the challenges unique to the mobile software platform.

Developers with a background in simulation programming, whether in the military or entertainment sectors, are familiar with dead reckoning, a term borrowed from naval orienteering. In that field, dead reckoning is the technique of calculating your present position from a past position and your velocity since, rather than from physical referents such as landmarks or the stars. In multiplayer gaming, very similar techniques effectively address the two sources of network bottlenecks, limited bandwidth and high latency.

A real-time multiplayer game often must manage a large number of game objects, such as vehicles, missiles, or creatures, under the control of many players. To keep each player's view of the game world up-to-date by repeatedly communicating current positions of all these objects requires exchanges of enormous amounts of data between clients and the server. This approach consumes lots of bandwidth and is extremely sensitive to latency.

If the game relies on dead reckoning, however, clients need transmit only changes to the velocities of the objects under their players' control. The exact position of each object is extrapolated from its last known location and velocity. Going further, clients can exchange simple deterministic instructions like "Follow this ship" or "Orbit that planet." As long as all clients and the server agree on how to interpret the instructions, sophisticated object behavior can be communicated in very little data.

In this way, even a game with a large number of objects can operate on limited bandwidth, as long as most of the objects are fairly static or don't change course too often. Delayed updates due to poor latency are usually perceived as slight course corrections. At worst, an object might hop to a slightly different position due to the difference between the calculated position and the modified velocity.

The trick is that exactly the same simulation runs on the server and all clients. Here is where Java technology particularly shines. The same simulation code written in the Java programming language that runs on the server can also execute on the clients. Because Java ME is a subset of the Standard Edition programming interfaces, simulation logic that is carefully written to use only the core language packages, java.lang and java.util, excluding the collections framework, can execute on an industrial-strength server as well as on each of the mobile device clients.

Because each simulation is running in parallel, synchronizing only user-initiated changes to the game state, the simulation must be deterministic. Nothing can be left to chance or randomness. Each instance of the simulation, whether on the server or one of the clients, must be able to calculate precisely the position of each game object at any given point in time.

Eliminating all randomization from the game design is challenging because many designs have at their core some element of chance in the game play. Arguably, some game designs benefit from the elimination of chance, which reduces the game dynamic to pure strategy and tactics. Also, in a real-time multiplayer game, the actions of the players themselves introduce a great deal of entropy and chaos into the game world. If, on the other hand, some randomization is essential to the game's character, it can use a pseudo-random number generator seeded with the same key across all instances of the simulation. The results are effectively indistinguishable from genuinely random events.

I like to say that expectation management is the key to everything, and it's especially true in mobile application development. If your users expect a real-time first-person shooting game like Half-Life, they will inevitably be disappointed - but, as I described earlier, mobile gamers differ from hard-core gamers, and are largely open to new and different kinds of gaming experiences.

The milieu of the game connotes most powerfully what players expect of it. A multiplayer game that takes place in the ammo-littered corridors of an alien-infested spaceship suggests high degrees of interactivity, while a battle between sailing ships in a pirate adventure implies a slower pace. The game's setting is often communicated up front, in the title of the game and in the opening splash screen that most users see before they purchase the game. A successful game will strike a reasonable compromise between a captivating setting and a compelling user experience.

The kind of user interface also goes a long way toward setting and managing user's expectations. A real-time action game, where the player uses the buttons on the keypad to control movement of a single unit on the field, running, jumping, and shooting in response to fast changes of the screen state, emphasizes real-time reaction speeds to units belonging to other players in the game. Such an interface has difficulty hiding the effects of network latency. For contrast, consider a real-time strategy game, where the player issues orders to one or more units on a battlefield. The slower pace allows users to react to other players actions in real time even under poor network conditions; delays in receiving updates from other players are rarely noticed.

The intermittent connectivity of wireless networks and the highly interruptible nature of mobile gaming sessions - receiving a phone call in the middle of the game is a common occurrence - require consideration in the game's design. A real-time game must allow players to disconnect and reconnect without significant disadvantage. A strategy game, for example, could have the server take control of a disconnected player's units until that player has a chance to reconnect. Likewise, the game's user interface should make it easy to resume playing in the same game session against the same opponents after an unanticipated disconnection.

Finally, mobile users expect a higher degree of community from games they play on their primary communications device. Because friends' recommendations are the biggest driver in mobile device and game purchases, mobile gamers are very likely to want to play against people they know well. Buddy lists, challenges, and in-game chat capabilities go a long way to glossing over network complications affecting gameplay.

Conditions prevailing in today's mobile software marketplace hinder the success of mobile multiplayer gaming in general, and real-time multiplayer games in particular. Developers confront poor network performance and radically different design expectations for mobile gaming. Certain tried-and-true network programming techniques like dead reckoning can help you meet these challenges. Careful game design can mitigate the remaining difficulties, though these impose constraints on what kinds of designs are possible. Successful multiplayer games are those that pay careful attention to the unique characteristics that distinguish the mobile software platform.

Michael Powers is Chief Technology Officer of Mpowerplayer Inc., a leading provider of technology solutions to the mobile gaming industry. You can play the game featured in this article and many others from leading publishers, right on your desktop, with the free Mpowerplayer emulator, available at http://mpowerplayer.com.