Developing Java-Based Mobile Games
Listing 1.2 shows the game loop of HardDriveCanvas.java. This is a typical game loop that consists of calls to the following methods in a given order: tick( ), input( ), and render( ). The tick( ) method checks whether conditions necessary to stop the game have become true and changes the game state accordingly if so. Method input( ) handles game key (keys assigned for game playing) inputs and performs necessary actions for each key press, such as a game element's movement. The rendering of the game according to its state is handled by the render( ) method.
HardDriveCanvas also uses an instance of javax.microedition.lcdui.game.LayerManager that adds and manages multiple layers of the HardDriveCanvas, each layer representing a sprite. A sprite is a basic visual element of a game, a character that moves around on a game canvas and interacts with other sprites (here, the car or obstacles are sprites that may collide with each other). Each sprite forms a virtual layer, which may be fully or partially transparent, laid on the game canvas; these layers are stacked upon one another. A sprite is an object of the javax.microedition.lcdui.game.Sprite class, which provides the functionality of displaying, transforming, and rotating the sprite along with collision detection for the sprite. The tick( ) method internally uses the collidesWith( ) method of the sprite class to check the collision.
HardDriveCanvas instantiates an object of the ObstacleManager class that renders and moves obstacle sprites on the game canvas and checks whether they've collided with the car sprite.
An ObstacleManager creates and manages obstacles that appear randomly in the car's path. For the sake of simplicity and convenience, ObstacleManager.java has hardcoded values of a maximum number of obstacles appearing at a time in car's path. This value may be modified as desired.
Listing 1.3: Code snippet from ObstacleManager.java
private static final int MAX_OBS = 10; //... ...some code
To create and display obstacles at random positions, ObstacleManager employs a simple strategy. It creates the initial batch of 10 obstacle sprites and uses LayerManager to add these sprites to the game canvas. Then, it sets their position by using randomly generated values of x and y coordinates and starts moving them towards the bottom of game canvas. As soon as each of these obstacles reaches the bottom of the canvas without colliding with the car, its position is again reset by using the same technique while the game score is increased by one. Thus, ObstacleManager re-uses the same obstacle sprites and displays them randomly.
GameOverCanvas is a simple canvas that receives the game duration and game score information from HardDriveMIDlet and displays it.
Readying the Example Game for Distribution
J2ME Wireless Toolkit provides KToolbar, a useful tool for compiling, preverifying, packaging, and testing a mobile application. KToolbar simplifies and automates most of these tasks.
Now that the game code is ready, it needs to be organized in the following directory structure, provided by KToolbar (see KToolbar's User Guide for "Operating with KToolbar"). To achieve this, start KToolbar and create a new project, HardDriveGame, that will contain the HardDrive game app under the apps folder inside J2ME Wireless Toolkit's installation folder.
HardDriveGame (game project name, user-defined) |___src | |___bin | |___classes | |___res | |___lib | |___tmpclasses | |___tmplib
Now, simply copy all four source files of the game app into the src folder and the car.png and obstacle.png icon files in the res folder. KToolbar takes care of everything else.
Now, the following actions will open the corresponding HardDriveGame game project, build it to compile (by using the JDK compiler), and preverify the game application.
Open project button -> choose HardDriveGame -> Build button
If some errors occur during the build process, they are displayed in the KToolbar window. Modify the game source code in the src folder to correct them; debugging has to be done manually because KToolbar does not provide a debugging facility. Otherwise, if no errors occur, a "Build complete" message is displayed in the KToolbar window.
Once the game project is built successfully, it could be run in the Emulator (a KToolbar component that virtually simulates the execution of the application on mobile phones) to test the application.
The game app is now complete and ready to be distributed. To package the game app into a .jar file for distribution using KToolbar, the following actions are to be performed.
Open project button -> choose HardDriveGame -> Project menu -> Package -> Create package / Create obfuscated package
The Create Package menu option will create a standard .jar file, whereas Create Obfuscated Package creates a .jar file of a smaller size than a standard .jar file. Once packaging is complete, the location of the .jar file is displayed in the KToolbar window, along with a .jad (Java Application Descriptor) file created automatically during packaging and used by Emulator while running the game app.
Figure 1.1: Emulator running the example game app
Optionally, the game app's midlet is signed after packaging by using following actions:
Project menu -> Sign
This creates a digital signature for the .jar file, and adds it to the .jad file.
Now, the game app's .jar and .jad files, along with the MANIFEST.MF manifest file, created by KToolbar and grouped together as a midlet suite, are ready to be distributed.
This is how 2D mobile games are developed using Java. You can model your own games on the example given in this article.
Mobile game development has become a lucrative industry with a manifold increase in mobile subscriptions and the number of avid mobile gamers around the world. J2ME and MIDP 2.0 help game developers tap the potential of this industry by providing a platform for developing mobile game conveniently, quickly, and efficiently. MIDP 2.0 dedicates a whole API package for game development that provides readymade building blocks to simplify and quicken mobile game development.
Download the complete source code of the example game app.
- A brief introduction to MIDP 2.0 and what's new in it from developer.com Wireless: "The J2ME Mobile Information Device Profile 2.0".
- An informative article about MIDP 2.0's capabilities in the context of game development: "Games on the Java Platform for Mobile Information Devices"
- A useful article for understanding the basics of midlet programming: "MIDP Programming with J2ME" from developer.com.
- An introduction to J2ME from developer.com "The Basics of J2ME"
The home page of the BREW platform at Qualcomm's Web site.
Toolkits and SDKs
Although J2ME base games can run on all types of handsets, one also can use tools and SDKs (that are again built upon J2ME) provided by handset makers such as Nokia, Siemens, Sony Ericsson, Motorola, and so forth to tap the handset-specific resources and capabilities, and develop games optimized for specific handsets.
3D mobile games
- Java Specification Request (JSR) 184 provides experimental Mobile 3D Graphics API for J2ME.
- SuperScape provides JSR 184-complaint J2ME 3D tools and solutions for device vendors and developers.
About the Author
Mugdha Chauhan is a senior IT consultant and author. Major tech portals including developer.com, IBM developerWorks, CNET Networks, Slashdot, and many eZines regularly publish her work. Her expertise and interests include Java, Linux, XML, and Open Source, along with Wireless application development.
Page 2 of 2