Tuesday, November 17, 2009

J2ME - Game API - Introduction

There are only five classes in the javax.microedition.lcdui.game package:

GameCanvas
Layer
Sprite
TiledLayer
LayerManager.

These five classes are enough to provide a platform for the development of games with a wide range of capabilities.

The Layer class is the superclass of the Sprite and TiledLayer classes. This class abstracts the behavior of a visual element in a game. This element can be a sprite, which represents an independent graphic (or a collection of graphics for animation) that can be moved around the game screen, or a tiled layer, which represents a graphic that can be used to create vast game backgrounds with only a handful of images. You can use the Layer classes for positioning and visibility. The subclasses override the paint(Graphics g) method, which has the task of rendering the elements on the screen.

The LayerManager class provides a convenient mechanism to manage the various visual elements of a game (sprites and tiled layers) by rendering the proper layer in the proper order.

The GameCanvas class is made useful by extending the functionality of the Canvas class. It provides an off-screen buffer, to which all rendering operations are done before flushing them on the device screen. It also provides an easy-to-use mechanism to query the current keys being pressed by the user.
The best way to introduce you to these classes is with the help of a working game example, which we will build from the ground up, explaining the various facets of a game. This is helpful whether or not you have programmed a game before, if you are looking to learn how to do it for the wireless devices using J2ME's gaming API.

A quick view on Game development

A game or animation is built according to the principle of repetitively executing a piece of code. This piece of code tracks the value of instance variables and updates the game state accordingly. Based on the game state, the code then draws/paints/repaints the game screen with the elements that make up the game. The values of the instance variables may change because of either user interaction or internal game behavior.

The repetitive execution is effected by putting the repetitive code in an infinite loop. Before entering the loop, an instance variable may be checked to see if the game should still be running, and if not, the loop may be exited. The code in the loop should allow the current thread of execution to sleep every few milliseconds to control the rate at which the update to the instance variables is done (in effect, how fast the game screen should be refreshed).

Implementation of Game Canvas Class

A GameCanvas class is a specialized subclass of the Canvas class that you encountered in the previous installment of this series. GameCanvas is optimized for gaming because it provides a special off-screen buffer in which all painting operations are done. When all painting on this buffer is complete, the buffer is rendered on the device screen by calling the flushGraphics() method. This double buffering has the advantage of producing smooth transitions of moving elements on a screen to counter the flickering that might happen if no buffering were provided. The size of the buffer is equal to the size of the device screen, and there is only one buffer per GameCanvas instance.

The GameCanvas class provides a storage mechanism for the state of game keys, which is a useful way to query user interaction with the game. This provides a simple way of keeping track of the number of times the user has pressed a particular key. Calling the method getKeyStates() returns a bitwise representation of all of the physical game keys, expressed as 1 for pressed and 0 for unpressed, since the last time the method was called. Only the following game states are identified, which is what you would expect, keeping in mind the game keys defined by the Canvas class: DOWN_PRESSED, UP_PRESSED, RIGHT_PRESSED, LEFT_PRESSED, FIRE_PRESSED, GAME_A_PRESSED, GAME_B_PRESSED, GAME_C_PRESSED, and GAME_D_PRESSED.

Define Game Characteristics

On the screen, these constants help define the boundary of the game and its sole element (the couple), as shown in diagram below:


No comments:

Post a Comment