Games using J2ME
Tic Tac Toe
create a quick and dirty Tic Tac Toe MIDlet would create a form
and add it to the display using Display's setCurrent()
Our TicTacToe game will consist of a 3x3 array of characters. Each
square in the grid will be assigned a number, corresponding to the position
on the phone's keypad. When you hit a number, you put either an X or an
O in the array, depending on whose turn it is. So we won't even use any
graphics. We'll simply use the Canvas to draw the array, as a few rows
of Strings. The game continues as so until somebody wins. [Code
Listing: Tic Tac Toe]
goes well, you'll wind up with a fresh, happy TicTacToe.class
file. To test the application out, Sun has been kind enough to release
a nice emulator. Just hit the Build button in the Wireless Toolkit. This
will create the necessary Java classes. Your classes
will also be automatically preverified and packaged into JAR and JAD files.
You can now hit the Run button. You can choose which Device you want to
emulate by playing with the Device pull-down menu.
If you happen
to actually own an i85s phone, you can plug it into your PC and use the
phone's linking software to install the MIDlet directly (the JAR and the
JAD file in the \J2mewtk\apps\TicTacToe directory) into the phone's memory.
This is similar to the way you might install an application on the Palm
In the very near future, Motorola and other mobile phone manufacturers
may make it easy for users to download MIDlets right to their phones,
Of course the real fun of having an application on a mobile phone is networking.
The mobile games that are most likely to be successful will involve lots
of multiplayer ability, bringing players together in ways that nobody
has ever experienced before.
The MIDP specification makes it extremely easy to pass data back and forth.
Many phones support Datagrams, though they are not guaranteed to work
on every device. The most common and easy method of MIDP network communication,
of course, is using HTTP.
Every Motorola i85s phone, for example, has its own static IP address.
Having one phone communicate with another is only a matter of simple peer-to-peer
In addition, the phone can connect to any outside server machine. This
server can be used as a gateway for pretty much any type of game traffic
or other network communication imaginable. For instance, a gateway can
be set up to access an entire database of sports scores, and then stream
only the latest requested scores to a MIDlet.
To connect to a server, simply have the MIDlet use the Connector class:
Datagram dgram = dc.newDatagram(message,
"server" could, of course, be another device. Just create an
endless loop that listens to a port and waits for some data:
= ( DatagramConnection)Connector.open
dgram = dc.newDatagram(dc.getMaximumLength());
reply = new String(dgram.getData(), 0,dgram.getLength());
Datagram protocol is standard, one could write a dastardly-simple server
component in Java Standard Edition (or any other language), running on
any PC. For instance:
DatagramPacket receivePacket = new DatagramPacket(bytesReceived, bytesReceived.length);
simple game can be written with relative ease. For instance, NumberPick.java
is a MIDlet that allows a user to pick a number between 0 and 9. It then
sends this number to a server (at a fictitious machine with the host name
of myserver.com) Note that for the sake of testing, it's a good idea to
set the server to 'localhost' - that way you can run the server and the
client from the comfort of your desktop machine. [Code
Listing: Number Picker]
on the myserver.com machine is NumberServer.java, which simply sits there
and waits for a message on port 9000. If the number is 4, then the server
sends back a simple one-byte "Y" message. Otherwise it sends
back an "N". [Code Listing:
as compelling a game as Unreal or Quake III, but it's a
As you go forth into the world coding games more complicated and sophisticated
than TicTacToe and NumberPick, be sure to remember that
every byte counts! It's exceptionally easy to run out of memory on these
Try to avoid Hashtables and Vectors, and recycle any objects you no longer
need. For example, instead of creating two buttons on two separate screens,
try to merely change the label on an existing button.
Also, avoid using costly operations like string concatenations. Use a
StringBuffer instead. As for interface design, remember your audience
and the limitation of the device. Use few, large, simple components that
require as few keypad presses as possible.
While your application is running, you can sniff out the memory using:
to strategically garbage collect whenever resources fall too low using:
MIDlet classes only contain a basic set of graphic user interface controls,
you might want to opt for a better library.
A site called Trantor in Germany offers a package known as kAWT.
This is a lightweight version of Java's AWT specially tailored for J2ME.
There are versions for the Palm, as well as for MIDP. It allows your MIDlets
to use standard Java widgets such as Panels and Containers and makes the
MIDlet code truly upwardly compatible with applets. The only caveat is
that kAWT will suck away an additional 27K or so of memory.
Finally, I highly recommend you use a code packer or obfuscator to compress
your bytecode as much as possible. A good obfuscator such as IBM's
jax can make your final application as much as 30 percent smaller!
More info about J2ME:
about the MIDP specifically:
great tutorials and sample programs, check out:
Mobile site has lots of articles, tips, and sampleapplications:
Java Network has all sorts of great articles and forums. Here are the
Day's J2ME Archive with tons of sample applications, links to IDEs and
SDKs, and anything else J2ME related. There is also lots of source code: