Design and Implementation of a midp Tetris game

Source: csdn Author: Chen wanfei

Author Profile

Chen wanfei, male, a bachelor of software in China South University, former Senior Programmer and system analyst of Beijing Great Wall software. He has rich j2se and j2ee development experience. At present, we are committed to the research work of j2s. Contact him via chen_cwf@163.net

Summary

This article provides a design scheme for a Tetris game based on MIDP1.0 and provides all the source code. The biggest feature of the game is screen adaptation. Regardless of the screen size of various mobile phones and PDAs, the game always gets the best display effect. The game passed the test on four Simulators of the j2rwireless toolkit 2.1.

Disclaimer: The game code was originally sourced from a Japanese open-source project (see references 1), which has been greatly modified by the author.

Below are several screenshots of the game:

Design

1. Procedure

The operation process of this game is very simple. after starting the MIDlet, the user enters the main screen of the game, and the screen begins to display as a welcome screen. After you press the [start] button, you can start playing the game. When you want to pause, click the [start] button again to pause the game, when paused, press the [start] button to continue running the game. If you press the [exit] button at any time, the game's MIDlet will be terminated.

The flowchart of the game is as follows:

2. Algorithm

In the game design of MIDP, a thread or timer is used to generate a re-painting event, and the game status is changed by thread and user input. This game is no exception. After the MIDlet is started, a re-painting thread is generated immediately and the screen is drawn every 50 ms. Of course, there are some optimization measures when re-painting, not all pixels on the screen need to be re-painted, but there is a choice, for example, the falling objects that have been fixed on the game canvas (there are 7 falling objects, which are composed of 4 small bricks. Each falling object is fixed in color and can be rotated up, down, and down) you do not need to redraw. The game canvas is a CommandListener that allows you to use the user's keyboard commands to control the left, right, down, and rotation actions of the falling objects. The flow control of the entire game is embodied in the paint () method of the game canvas object. Paint () draws the current game screen based on the current game status. The welcome screen and the Game Over screen are quite simple to draw. It is also quite easy for the game to pause the screen, that is, to set up a flag so that the paint () can be executed without actually performing the re-painting action. To draw a picture of the game in the running state, you need to draw a falling object at the current position of the falling object. Before you draw a falling object, determine whether the falling object can fall. If it can fall, let it fall into a grid and draw it again. If the falling object cannot fall down, determine whether the Game is in the Game Over state. If it is in the Game Over State, set the Game status to the Game over State, so that the canvas will draw the Game Over picture during the next re-painting. if the Game is not in the Game Over status, fix the falling objects and check all the rows under the current row of the falling objects on the canvas to see if row deletion is required, if you need to delete rows, clear the data of the deleted rows on the game map, and then draw the deleted rows as a background color. Then initialize a new falling object and draw the new falling object. The flowchart of the paint method is as follows:

3. Data Structure

This game involves the following data structures.

Game Region

The game area is a part of the mobile phone or PDA screen. The area is square and the side length must be divided by 16 (because the Russian game area is just 16 small bricks long, 16 small bricks are square in width ). Whether in the horizontal or vertical direction, the area must be in the center of the screen. The game area is divided into two parts in the horizontal direction, one part is 12 small brick widths, used to display the game container, and the other part is 4 small brick widths, used to display the next falling object and score.

Small bricks

Small bricks are components of falling objects and game containers. Shows a square with a side length of 1/16 of the length of the game area. When each small brick is drawn, the four sides will set a pixel width to be painted white or gray, so that there is a gap between the bricks. Each small brick also has an id ranging from 1 to 8. We can use a color array (BRICK_COLORS in the program) to store these eight colors. If the id of a small brick is 3, the color of the brick is BRICK_COLORS [3-1].

Falling objects

The falling object is essentially a square consisting of 16 small bricks. There are 7 kinds of falling objects, such as "Tian" and "L. Each falling object has four rotation changes. Each falling object has an id ranging from 1 to 7. Because the color of a falling object is fixed. We can also use this color to add 1 in the BRICK_COLORS array as the id of the falling object.

For example, the id of the "L" falling object is 3, and its change form is:

So what data structure is used to store a falling object? Let's take the "L"-shaped falling object as an example to illustrate:

Because each falling object has four states, we can consider using an array of 4 to store the four states of a falling object, each element in the array represents a State of the falling object. So what is used to represent a certain state of a falling object? We can see that it is most appropriate to store a falling object with a 4x4 two-dimensional array. In the position where colored bricks appear, the value is 1, and only the background color is required. The value is 0. Therefore, the four states of the entire "L" falling object can be represented by a 3-dimensional array:

protected int blockpattern3[][][] = {
      {{0, 1, 0, 0}, {0, 1, 0, 0}, {0, 1, 1, 0}, {0, 0, 0, 0}},
      {{0, 0, 0, 0}, {0, 1, 1, 1}, {0, 1, 0, 0}, {0, 0, 0, 0}},
      {{0, 0, 0, 0}, {0, 1, 1, 0}, {0, 0, 1, 0}, {0, 0, 1, 0}},
      {{0, 0, 0, 0}, {0, 0, 1, 0}, {1, 1, 1, 0}, {0, 0, 0, 0}}
};

Game Map

Game maps are used to store fixed bricks on game containers. The game container is a unit with 12 small bricks in width and 16 small bricks in height, including the left and right sides of two walls and the bottom of the container. Therefore, a 16x12 two-dimensional array (called mapdata in the program) is used to store fixed bricks. If mapdata [I] [j] = k (k! = 0 ). then it indicates that there is a fixed small brick on the j column of the game container's I line, and the color value of the small brick is BRICK_COLORS [k-1]. if k = 0, the j column of the I row has no bricks.

Therefore, for the following game runtime, the value of mapdata is {8, 0, 0, 0, 0, 0, 0, 0, 0} {8, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 8} {8, 0, 0, 0, 0, 0, 0, 0, 0} {8, 0, 0, 0, 0, 0, 0, 0, 0} {8, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 8} {, 0, 0, 0, 0, 0, 0, 0}
{8, 0, 0, 0, 0, 0, 0, 0, 0, 0} {8, 0, 0, 0, 0, 0, 0, 0, 0} {8, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 8} {, 0, 0, 0, 0, 0, 0, 0}
{8, 0, 0, 0, 0, 0,} {8, 0, 0, 0, 0, 0,} {8, 0, 0, 0, 0, 7, 5, 1,}
{8, 8, 8, 8, 8, 8, 8, 8, 8 }}

Source code and executable code

There are three files in total: src.rar, ketrisgame. jad, ketrisgame. jar Description: src.rar contains all the source code. Ketrisgame. jar also contains the resource files required for running the program. after wtk2.1 is installed, let ketrisgame. jad and ketrisgame. jar is in the same directory (the directory path cannot contain Chinese characters or spaces). Double-click ketrisgame. jad file to run the game in the simulator.

References

Http://www.javadrive.jp/j2me/game/3/index.html

<J2-in a nutshell>

<Java Mobile Phone/PDA Program Design entry>