Learn the new features of NetBeans 6 by example part 3rd: Using Mobility to develop games

Applications and their specifications

The Java ME development environment differs from that of desktop and server applications, which specify the Java Virtual machine specifications for various devices defined as a combination of configuration and configuration files. (You can append "extended profile" as needed)

Spec = Configuration + configuration file (+ Extended profile)

Developers define basic Java virtual machine specifications and minimal sets of class libraries in the configuration, with JCP as the standard, CLDC (Connected Limited Device Configuration) For example, and the CDC for example in an embedded machine (Conn ected Device Configuration); profiles are used to define specific categories of (mobile, PDA, etc.), machine-oriented APIs, and other additional parts are defined in the extended configuration file. As a standard set of MIDP (Mobile Information Device profile) configuration files, CLDC is widely used in the mobile phone field.

For example: When developing a mobile Java application for the Japanese market, its specification is a combination of configuration and configuration files, as shown below. () represents versions of various specifications:

Mobile phone operators	Specification combination
NTT DoCoMo I application service	CLDC (1.0 or 1.1) + DoJa configuration file
AU open Application Service	CLDC (1.1) + MIDP (2.0)
SoftBank S! Application Services	CLDC (1.0 or 1.1) + MIDP (1.0 or 2.0) + Jscl/mexa

The DoJa profile of the NTT DoCoMo refers to the DoCoMo-oriented specification of the NTT Foma, which has many versions. The jscl/mexa of SoftBank is defined as the specification that can be extended according to the actual needs of SoftBank terminal, that is, the so-called "extended configuration file".

This article describes the game based on the CLDC 1.1 + MIDP 2.0 application service.

Creating games using APIs

In this case, the 2.0 compliant application uses a game-oriented API, which is included in the Java package javax.microedtion.lcdui.game. The game package, the user interface provides a class definition as follows:

Gamecanvas	Provides a game user interface base.
Layer	Abstract class that represents the visual elements of a game. The following Sprite and Tiledlayer inherit this Layer feature.
Leyermanager	Manage a series of Layer.
Sprite	The basic elements of a game are described by a combination of one or more images. When you combine several images, each image is represented by a movie-like lens, so that all the images are grouped together to represent the actions of the characters.
Tiledlayer	Just like a tiled floor, you can use a segmented picture to show elements. Specifically, it is the use of Tiledlayer can show the game's background and the game's structural parts.

Game Builder

Game builder consists of scene, tile layer, animation layer, can edit the above Layermanager, Tiledleyer, Sprite in the graphics environment.

Figure 1 Game Builder Design Screen

To use Sprite and Tiledlayer in game scenarios and roles, you can use Game Builder to write parts such as backgrounds, roles, and structural parts into graphics. Scripts and character actions, and so on, must all be described by Java programs. The approximate job flow is based on the following considerations:

Prepare image files for background and role prototypes

Import an image file into the game builder

Create tiled and animated layers in the GUI environment of game Builder

Combine tile layers and animation layers with game builder to create scenes

Design role action and game propulsion programs

Suppose the game builder wants to use the tile layer, the Gamecanvas class of the animation layer, or the Gamecanvas extension class as described in the API. The Game Builder saves the edited results in the Java class and automatically generates the getter method for the tiled and animated layers and saves it in the class. Call this fetch method to generate an instance of the tile layer and the animation layer and return it to the calling source, so you can use an instance of the Gamecanvas class to get the object. Finally, when you invoke this Gamecanvas (inheriting) class from the main program that inherits the MIDlet class, which is exactly equivalent to a class containing the Java SE's main method, the development of the game application is accomplished.

The source code of the class that the game builder creates, saves, most can only be used for reference. You can modify it through the game builder, and we reserve a place for you to edit the direct code to append specific processing.

To open the game builder in NetBeans, you need to create a MIDP application project and create a new visual game design diagram in your project. It is better to open the sample project in actual trial time, from the main menu to select the Sample project method: "File" > "New Project" > "Sample" > "Mobility" > "MIDP" > "Simple game created by Game Builder", This allows you to open the game builder.

Next, let's take a look at the summary of these 5 jobs in order.