Developing Cutting-Edge Mobile Gamesby David Fox
Games on mobile phones are finally getting interesting. Whether your aim is for fun or profit, you might want to get into the game yourself. But how?
The easiest part of the mobile games business is developing them. By definition, mobile games must be small in scope. As with the heyday of arcade games like Pac Man and Space Invaders, one dedicated person can design and program fantastic little games, usually within weeks, investing cash only in a decent desktop computer and a mobile phone. More often, a programmer may want to team up with an artist, to avoid the embarrassment of monsters that look like toaster ovens.
Of course, you have to lower your expectations. Your game isn't going to compete with the latest PlayStation II extravaganza. Screens are miniscule, around 100-by-100. The dynamic memory is limited; most mobile phones only give you 32K. There's limited network connectivity, with a teeny, tiny 9.6 kilobit per second bandwidth over most networks. And the processor itself is often hundreds of times slower than your average desktop.
The most difficult part of the mobile games business, by far, is deploying. With dozens and dozens of phones and networks out there, tweaking your game for each conceivable platform can be an arduous, entirely unrewarding experience. Luckily, there are already a few companies out there to test and even publish your games, such as Digital Bridges in Scotland, ZIOSoft in Korea, or Picofun in Sweden. Better yet, some standards and game engines are finally starting to emerge, making it possible to write one game that runs many places.
For standard mobile phones, the software platform in which to write your games comes down to two contenders: Java and BREW. More advanced "smartphones" are usually built around either PalmOS or Pocket PC 2002, but that's a topic for another article.
Java 2 Micro Edition
The most popular mobile language is clearly Java. Mobile phone manufacturers have embraced Java in a way that not even PC manufacturers have.
Java runs in a virtual machine, which means that as long as you follow the right procedures, the same Java byte code can run on any supporting platform. The downside to that, however, is that the language is very limited, since it always attempts to please the lowest common denominator. Also, just because a Java game runs on a bunch of phones, it may look and act different, from platform to platform.
Java is also extremely easy to use. It is object-oriented with no pointers, no complicated memory operations, and automatic garbage collection. Most importantly, Java applets cannot access functions or memory outside of their secure sandbox, which means that it is virtually impossible to write malicious code or viruses. Carriers and handset manufacturers like that security, which is part of the reason Java is so pervasive.
Java 2 Micro Edition (J2ME) is an attempt to take the best aspects of standard Java and pare them down for smaller devices such as mobile phones, pagers, and handheld organizers. Most every major mobile phone manufacturer has joined with Sun to create something called the CLDC: The Connected, Limited Device Configuration, along with the MIDP: The Mobile Information Device Profile . A Java applet written for a mobile phone, then, is called a MIDlet.
The first edition of MIDP makes it a little difficult to develop graphically rich games:
- The only mandatory network protocol is HTTP. Some handsets may support sockets or datagrams, but your game can't rely on them if you want to deploy across a large number of phones.
- There are no transparent images. Without transparency, any image that overlaps another image, even a background image, will look blocky.
- You cannot grab, copy, or edit the pixels of RGB images on the fly. This means that graphic effects like fading in, explosions, and dynamic shadows are impossible.
- There is no fill-polygon or fill-triangle method, which makes rendering 3D images quite difficult.
- You cannot copy raw pixel data to the screen (blit). This makes it pretty much impossible to do any texture-mapping or particle effects.
- There is no audio at all, other than simple system beeps. You heard me right; MIDP games are essentially mute.
- There is no floating-point math. This makes some 3D and physics pretty difficult.
- There is no native support or Java Native Interface (JNI). That means you can't dial the phone, work with any of the ring tones, work with any native user interface widgets, etc.
Various device manufacturers have released extension APIs for J2ME. For example, Siemens has an extensive Game API that sits atop MIDP. NTT DoCoMo does not use MIDP, but has a separate Java profile known as I-Appli. And Nokia has its own set of APIs.
These extensions usually offer better sound, transparent graphics, sprite classes, and the ability to access the phone's hardware so that you can flash the backlight when you score a goal or buzz the vibrator when your spaceship explodes.
Also coming down the pike is MIDP 2.0, which has a 2D-gaming graphics functionality built in. MIDP 2.0 also supports richer sound such as ring-tone generation and MIDI. More advanced phones, such as the Nokia Communicator, use something called Personal Java. This is, in essence, similar to the full version of Java used for applets.
Starting To Play Around
It's free and easy to begin playing around with J2ME. There are several commercial development environments that do all the compiling and packaging for you. Metrowerks offers Code Warrior Wireless Studio, and Borland's sells a Mobile Set add-on for JBuilder. In addition, Nokia, Siemens, RIM, Zucotto, and Motorola all offer special SDKs and IDEs for J2ME development.
Sun's own J2ME Wireless Toolkit is free, complete, really easy, and available for Windows, Linux, and Solaris. It also comes with a bunch of source code, including sample games such as Snake, Sokoban, a Tile Sliding game, Pong, and Star Cruiser.
|Sun's Wireless Toolkit|
You can program and test your game using the Wireless Toolkit's built in emulators. Actually loading your game onto a mobile phone differs from handset to handset. Usually, all you need to do is connect your device to your PC and use special synching software to copy the game package over.
Actually selling your J2ME game is trickier. You can try to set up your own Web site and do it yourself, but most people don't have the expertise or desire to download a game and then connect their mobile phones to their computers. In most cases, you'll need to partner up with carriers such as Nextel, NTT DoCoMo, AT&T Wireless, or Sprint. The carrier can push your game to the user via a special set of menus. Each carrier, unfortunately, has their own way of doing things, so striking a deal can take a lot of time.
Qualcomm has created a virtual machine and language called the Binary Runtime Environment for Wireless (BREW). The language is based on C++. Qualcomm has embedded BREW right onto the chipset for CDMA phones. While BREW is a J2ME competitor, in some sense, a Java Virtual Machine can be written in BREW. Qualcomm is actually collaborating with IBM to create a version of Java that sits atop BREW.
Verizon Wireless, the largest network in the United States with 27 million subscribers, has chosen to use BREW over J2ME. Other carriers that have settled on BREW include KTF in Korea (11 million subscribers), and KDDI in Japan (13 million subscribers).
BREW has no sandbox security model, which means you can directly access much of the file system, menus, network sockets, memory, and the screen. Full sprite transparency is also supported. There is also a built in resource file system, making it easy to load up images and audio.
On the downside, the current version of BREW only supports 500 bytes of dynamic memory, with no static data. Actually developing a final BREW app is pretty expensive. The phones that currently support BREW are also on the expensive side and currently have very limited memory compared to some J2ME options. There is also no easy way to debug your app once you've got it running on an actual handset.
One of the biggest advantages of BREW is a well-defined BREW Distribution System (BDS), which standardizes the way applications are purchased online and downloaded to the device. This centralized billing system makes things much easier for the developer as well as the end user.
A typical BREW experiences goes like this: A player uses their phone's menu to enter a "store." The player can usually demo one or two levels of a game, and the game is downloaded right the phone. If the person likes the game, he or she can unlock it or download additional levels then and there. The purchase price appears as a line item on the player's wireless phone bill.
BREW allows the game developer (you) and carriers to negotiate how much to charge for each game and how to charge for it. You can have people subscribe to your game with a monthly fee, purchase it outright, demo a level or two for free, or upgrade. Once a game is purchased, it can expire after a set number of games played, after a set date, after a certain number of days, or after a set amount of playtime. Usually 80 percent of the money that players actually pay will go to the developer, with no muss or fuss.
To use BREW, download the BREW SDK, which is free. This SDK has pretty much everything you need to develop and test your application. To actually get your game onto a phone, however, you'll need to compile your game into binary form that supports the ARM processor. You'll need to buy an ARM BREW Builder to compile, link, and assemble your code. The current cost is $1,500.
|The Emulator - Part of the BREW SDK|
Unfortunately, the costs don't stop there. To become a BREW developer, you must become certified and verified by buying a Verisign certificate ($400 a year). You must also pay Qualcomm $2,500 to test a typical client-server game application before it can even be shown to carriers. The total out-of-pocket investment can come out to 4,650 dollars.
Of course, once your game is out there, the BREW system makes it effortless to collect your revenues.
Most of today's wireless networks suffer from high latency and low bandwidth. Latency is the time it takes for a packet of data to travel from one point to another, and is usually based on distance and number of hops between the two points. Bandwidth is the amount of data that can be sent per second and is usually based on the physical hardware being used to transfer data.
Second-generation (2G) wireless networks exchange data at a rate of only 9.6Kbps. For instance, European mobile phones primarily operate on the Global System for Mobile Communication (GSM), which sends data at 9.6 kbps. Some networks use Time Division Multiple Access (TDMA), which is similar to GSM and has the same 9.6 kbps limit. Most networks in North and South America, Russia, Israel, Eastern Asia, and Central Africa transfer data based on a standard called Code Division Multiple Access (CDMA), which runs at a peppier 14.4 kbps. Although 2.5-Generation (2.5G) and third-generation (3G) networks are slowly being rolled out, it will be years before a critical mass of users is able to operate on them.
To make things even worse, wide-area wireless networks are high latency because of the inherent interference and noise of radio wave communications. Most wireless networks force data packets to hop over many routers. Satellite-based wireless networks generally add even more latency. It is not rare to experience network delays of one or even two seconds.
What all this means is that while multiplayer games are possible, you will need to avoid twitch games, where one player needs to know what another player is up to in real time.
Mobile Positioning and Bluetooth
Coming soon are APIs for positioning and Bluetooth. Mobile positioning allows your app to know where in the physical world the phone is located. This means that your multiplayer tag-fest can actually know if nearby players are hunting you, which can open up a whole new genre of self-aware games. Right now, there are a number of technical and privacy hurdles for most carriers to work out.
Bluetooth is a means of quick-and-easy wireless communication between your phone and other phones, or other devices. That means that two people less than 10 meters apart can play against low-latency games against each other. Imagine sitting on a train and picking up a game of golf with some stranger a few seats away.
The Cutting Edge Hurts
All in all, wireless game development is fraught with its share of hassles, hurdles, and hellholes. But thanks to platforms like J2ME and BREW, you can at least begin to experiment with a nascent genre that seems to be growing at a sensational rate.
David Fox is launching a game company in New York City. He's also the author of numerous books and articles about cyberculture and technology.
Return to Wireless DevCenter