Choosing a Debugger
An important regarding
how you finally decide to debug your game is that of choosing a
debugger. A debugger is an invaluable tool in ridding your game of bugs,
and it can directly determine how much time you spend debugging.
Therefore, you should make sure to invest your resources wisely and
choose a debugger that fits your development style.
There are
several third-party integrated development environments that include
built-in visual debuggers for Java. These are very nice and usually
include lots of cool features beyond the ones you just learned about;
definitelylook into getting a full-featured debugger if at all possible.
Just
keep in mind that choosing a debugger that fits your needs is important
in determining how successfully you can rid your code of bugs.
Fortunately, nearly all debuggers perform the basic debugging functions
of single-stepping, supporting watch variables, and using breakpoints.
The Java 2 SDK comes standard with a debugger (jdb)
that performs basic debugging functions such as those you learned about
earlier. It is a command-line debugger, which means that it has no
fancy graphics or point-and-click features but it does get the job done.
If you aren’t ready to commit to a third-party tool, by all means try
out jdb. After you get comfortable with jdb, you might find that it serves your purposes well enough.
Before you can use jdb, you need to compile your code so that it includes debugging information. The Java compiler switch for doing this is -g, which causes the compiler to generate debugging tables containing information about line numbers and variables.
Deploying Mobile Games
Unlike
traditional PC and console games, which are usually distributed on a
CD-ROM, mobile games are typically downloaded and installed directly
over a wireless network. This primarily has to do with the fact that
most mobile phones don’t support removable media such as CD-ROMs, but
they do all have network connectivity. Knowing that your games will be
installed over a network connection, you can probably guess that there
are some installation issues that need to be addressed before you can
make your mobile games available to the general public.
There are actually two options when it comes to downloading and installing mobile games:
Local installation— The MIDlet is transferred from your local computer to your mobile phone over a direct connection such as a USB cable.
Remote installation— The MIDlet is downloaded and installed over a wireless network connection.
Gamer’s Garage
You
will likely need a special cable to perform a “local install” of your
own mobile games to a mobile phone for testing. Most phones use a USB or
serial cable for establishing a direction connection, although you may
find Infrared (IR) or Bluetooth to be a viable wireless option for some
phones. Of course, you will need Bluetooth support on your PC to carry
out a direct Bluetooth connection; you can buy a USB Bluetooth adapter
that simply plugs into a USB port on your PC. |
The second approach still
involves your phone’s AMS, but it retrieves the game from a remote
network connection. In this scenario, you typically visit a website that
has a link to the mobile game’s JAD file. Upon downloading the JAD
file, which includes information about the game such as the size of the
JAR file, you can then continue on by downloading the JAR file itself.
The remainder of the installation then proceeds through the AMS as if
you had transferred the game through a direct connection.
So, to
summarize, the critical difference between the two mobile game
installation options is how a game’s JAR file is acquired. It is either
transferred directly over a local connection or downloaded remotely from
a web server. Because the first approach is almost entirely dependent
on your phone’s own unique AMS, I’ll focus on the second approach, which
is in fact much more important for distributing your mobile games to
end users.
Understanding Over-the-Air Provisioning
The process of downloading and installing a mobile game over a wireless network connection is known as over-the-air provisioning, or OTA provisioning for short.
OTA
provisioning is a fairly new concept in application delivery that is
entirely unique to wireless mobile devices. The general idea is to allow
users to get information about a mobile application before committing
to downloading and installing it. Additionally, OTA provisioning relies
on existing, stable technologies for delivering MIDlet files. More
specifically, mobile games are accessed via web page hyperlinks, and
then downloaded from web servers.
To offer a mobile game
for download and installation via OTA provisioning, you must make it
available on a web server. More specifically, the following files are
typically used when a mobile game is made available for OTA
provisioning:
As you already know, a JAD
file is a small text file that contains a description of a MIDlet or
suite of MIDlets. The JAR file in this case is the game itself, as it
has been packaged for distribution. You are already accustomed to
packaging mobile games into JAR files and creating JAD files to test
them in the J2ME emulator. The only missing ingredient is the HTML or
WML web page that provides a link to the JAD or JAR file.
Construction Cue
In
case you don’t remember, the JAR file for a mobile game contains all
the compiled class files, a manifest file (similar to the JAD file), and
all the resources for the game (images, wave sounds, and so on). |
It is possible to serve
up a mobile game via OTA provisioning using nothing more than a web page
that links directly to the game’s JAR file. However, this isn’t a very
user-friendly approach because it requires the user to download the
entire game before learning any details about it. The purpose of a JAD
file is to provide somewhat of a preview of what the user is getting. I
don’t mean a preview in terms of how the game plays or anything like
that—I simply mean the version of the game, the size of the JAR file,
and so on.
Gamer’s Garage
Don’t
forget that most mobile phone users are charged for how much data they
receive over their wireless data network. This is why JAD files play
such an important role in OTA provisioning: They enable a user to get
information about a game with a minimal transfer of data. |
In
reality, although you can certainly serve your own mobile games
directly from your own websites, it helps immensely to partner with a
game “syndication” company or a wireless carrier. This can be the entire
difference in your game getting noticed by a wide audience or falling
completely off the radar. Partnering with a wireless carrier is a fairly
difficult prospect for a new game developer, but there are several
wireless game and application syndication sites that are worth
considering. JAMDAT Mobile (http://www.jamdat.com/) and MFORMA (http://www.mforma.com/) are two good options that focus solely on games, whereas Handango (http://www.handango.com/) delivers both wireless games and other applications.
Preparing Your Game for Deployment
You’ve already grown
accustomed to packaging MIDlet games into JAR files and creating a JAD
file to go with it. But you haven’t learned how to create a web page
that is capable of providing a link to a downloadable game online. Two
options are available for creating such a web page: HTML and WML. As you
probably know, HTML (HyperText Markup Language) is the standard
language used to create the vast majority of web pages out there.
However, many mobile phones use a smaller, scaled-down version of HTML
known as WML (Wireless Markup Language). WML is ideal for mobile phones
because it limits web pages to a much simpler user interface that is
easier to view on small screens.
Construction Cue
After
packaging a MIDlet into a JAR file, there is an optional step where you
can digitally sign a MIDlet for security purposes. Signed MIDlets are
considered more secure than unsigned MIDlets because their publisher
(you) has been validated and the end user can rest assured that no one
other than the publisher has tampered with the MIDlet. It is a good idea
to sign your mobile game MIDlets before making them available to the
general public.
|
The decision to use HTML
or WML in creating a delivery web page for your games ultimately depends
on the specific mobile phones you are targeting. Fortunately, it is
very easy to hedge your bets and create pages in both languages. The key
element required in a delivery web page regardless of the language of
choice is an anchor tag that provides a link to the game’s JAD/JAR file.
Following is how this line of code is structured:
<a href="http://localhost:2728/HighSeas2/bin/HighSeas2.jad">HighSeas2.jad</a>
Even
if you aren’t too familiar with HTML/WML, it’s not too hard to read
between the lines in this code and see that a URL is being provided that
is linked to the text HighSeas2.jad. In this particular example, the URL is to a local file, as is evident by localhost in the URL. In a web page that is serving up a game on a true web server, the code would look more like this:
<a href="http://www.stalefishlabs/games/HighSeas2.jad">HighSeas2.jad</a>
This code shows how a more traditional URL is provided as a link for the High Seas 2 JAD file.
The hyperlink for the game that is marked up with the <a> tag is coded the same in both HTML and WML web pages. Listing 1 contains the HTML version of the High Seas 2 delivery web page, whereas Listing 2 contains the WML version.
Listing 1. The HighSeas2.html HTML Web Page Includes a Link That Delivers the High Seas 2 JAD File
<html>
<head>
<title>HighSeas2</title>
</head>
<body>
<a href="http://localhost:2728/HighSeas2/bin/HighSeas2.jad">HighSeas2.jad</a>
</body>
</html>
|
Listing 2. The HighSeas2.wml WML Web Page Includes a Link That Delivers the High Seas 2 JAD File
<wml>
<card id="High Seas 2" title="High Seas 2 MIDlet">
<a href="http://localhost:2728/HighSeas2/bin/HighSeas2.jad">HighSeas2.jad</a>
</card>
</wml>
|
It isn’t terribly
important that you understand the code surrounding the hypertext link to
the JAD file in each of these code listings. Just know that the URL in
the links must point to the absolute location of the JAD file on the web
server.
With a suitable web page
now ready to provide users with access to your mobile game, there is one
other important step you must take to make the game available for
successful wireless download. Within the JAD file for the MIDlet, there
is a reference to the JAR file that looks something like this:
MIDlet-Jar-URL: HighSeas.jar
You
must change this JAR file reference to be the exact absolute URL for
the JAR file as it resides on the web server. Assuming the JAR file is
in the same location as the JAD file in Listings 16.2 and 16.3, the following change does the trick:
MIDlet-Jar-URL: http://localhost:2728/HighSeas2/bin/HighSeas2.jar
Again, this URL points to an actual web address and not a local address in a MIDlet that is deployed on a real web server.
You’ve almost
successfully made your mobile game MIDlet ready for prime time. If
you’ve already tried to download and install the MIDlet over the air
from a web page and found that it didn’t work, it’s because you’re still
missing a tweak on your web server settings. Let’s find out how to fix
that!
Tweaking Your Web Server
For a web browser to
successfully serve up JAD and JAR files, it must recognize both types of
files according to their official MIME types. A MIME type is a
recognized file type that helps applications figure out what to do with
files. HTML, GIF, JPEG, and other popular web file formats all have
recognizable MIME types. Because JAD and JAR files are fairly new in the
big picture of browsers and the web, your web server likely doesn’t
currently recognize them by MIME type. For this reason, you’ll need to
configure your web server to recognize the following MIME types:
The
specifics of how to carry out this configuration change on a web server
are unique to your web server software. If you administer your own web
server, just refer to the documentation. If someone else administers
your web server, ask how to go about registering these two new MIME
types.
