Network Gaming

Now that you've seen what's basically available, I'd like to spend a minute going over the types of features you can develop with the communications you have available. More important, I want to give you a clear idea of what is and isn't possible.

Latency and Dropouts

I hate to throw cold water on anything, but don't get your hopes up too high with plans for multiplayer games, especially if you're dealing with anything in real time. Due to their nature, MIDs are not like broadband-connected PCs. In the real world you can expect low bandwidth (less than 20 Kbps even on so-called high-speed networks), very high latency (one to five seconds), and more dropouts than a physics course. These limitations don't mean you can't implement some great features based on wireless communications; you simply have to work within the limits.

Probably the most common mistake is to make a game that attempts to reflect a shared experience in real time. A good example of this is a multiplayer tank game. If two players face each other at nearly the same time and press the fire button, it's quite likely the messages relating to each command will arrive at a server up to five seconds late. Likewise, updates to the movement path of the tanks would be very erratic. These types of transmission delays (along with dropouts) would make the game pretty much unplayable.

Unfortunately, things don't really get any better on newer 3G networks. Although the overall throughput (the volume of data flowing to the phone) increases, the latency (the time it takes for data to get from the server to the phone and back) is more or less the same as current networks. Maybe 4G will do better, but don't hold your breath.

The Cost Factor

Another aspect to consider is the cost of mobile data transmissions. Unlike typical Internet connections, mobile carriers commonly charge users by the kilobyte for all traffic. The rates for this vary between $0.01 and $0.50 per kilobyte (yes kilobytenot megabyte), so you're not talking about an insubstantial amount of money. Writing a game that uses a constant stream of data could potentially leave your player with a very large bill at the end of the month.

Practical Uses

That's all the bad news out of the way. The good news is you've got HTTP by default on all your MIDs. It might not be fast, but it's still enough to add some excellent features to your games. Take a look at some practical uses.

Meta-Games

A common method of utilizing the network for a J2ME game is to add any one of a number of extensions that broadly fall into the category of meta-games. A meta-game is essentially a part of your game play that exists above and beyond the actual game on the device. A classic example of this is an online high-scoring system. You can play the normal game standalone; however, you can choose to upload your score and see your ranking against all other players. The rank competition is a game in itself!

Another common meta-game is to join groups of players into competing factions or clans. This might be as simple as unified scoring or as complex as having maps containing territories over which they fight.

All these types of meta-games are optional, so players who either cannot or don't want to incur the expense of network communications are not excluded from playing your gamethey just don't participate in the greater meta-game.

By their nature, meta-games typically require very little bandwidth, with most communications occurring to update the state of play at any point in time. Because this is an optional component it's most commonly implemented as a separate feature the user needs to select, such as a Check My Online Ranking menu item.

New Content

Another excellent use of the network is to dynamically download new content for your game. This can include new graphics, levels, or any other data your game might use. Once you have downloaded the content, you can store the extra content in the MID's RMS, and you're not using precious JAR space.

The actual mechanics of how and where you make downloadable content available are again something you would want to discuss with your publisher or distributor.

Non-Real-Time Games

Non-real-time games (maybe you should term them unreal-time games) are simply games that don't pretend to operate in real time. A common example of this is any turn-based game, such as chess. Non-real-time games work well with mobile networking because they do not rely on low-latency and they generally don't require large amounts of bandwidth.

You're not limited to only turn-based games, though. As long as your game design allows a fair amount of time between transmissions and you don't constantly download data, you'll probably be okay. A strategy game, for example, could give players a certain number of moves per day (rather than enforcing turns). At the end of a game day, the server would then move everything simultaneously and return the results back to the players.