Design and implementation of a MIDP Tetris game _java Programming

Article Source: csdn Author: Chen Wanfei

Author Introduction

Chen Wanfei, Male, South Central University, a number of soft department of Bachelor, has been Beijing Great Wall software senior programmers, systems analyst. Have a wealth of j2se,j2ee development experience. Currently committed to J2ME research work. You can contact him through the chen_cwf@163.net.

Summary

This paper gives a design scheme of Tetris game based on MIDP1.0, and gives all realization source code. The biggest feature of the game is the adaptive screen, regardless of the variety of mobile phones, PDA screen size, the game always get the best display results. The game was tested on 4 simulators of J2ME Wireless Toolkit 2.1.

statement: This game code originally originated from a Japanese open source project (see Resources 1), the author has greatly modified.

The following is a screenshot of the game:

Design

1. Operation Process

The operation of the game is very simple, the user started MIDlet start, that is, into the game main screen, the screen began to show as Welcome screen. The user presses the [Start] button, can start to play the game, when the user wants to pause, click the [Start] button again, the game pauses, in the case of pause Press [start] button, the game continues to run. Any time you press the [Exit] button, the game MIDlet will terminate.

The game screen flowchart is as follows:

2. Algorithm

MIDP's game design, in essence, is to use a thread or timer to generate redrawing events, using thread and user input to change the game state. This game is no exception, after starting MIDlet, immediately generated a redraw thread, the thread every 50ms drawing screen. Of course, there are some optimizations when redrawing, not all the pixels on the screen need to be redrawn, but there are choices, such as those that have been pinned down on the canvas (a total of 7 falling objects, consisting of 4 small bricks, each of which has a fixed color and can rotate up or down) without redrawing. Game Canvas is a commandlistener, you can accept user keyboard commands, control the drop of the left, right, move down, rotate action. The whole process control of the game is embodied in the paint () method of the game canvas object. Paint () According to the current game status, draw the game screen at that time. Welcome screen and Game over the painting is quite simple. The game pauses the picture to draw is also quite easy, is establishes the mark, lets the paint () execution time without actually performing the redraw movement. For the game in the running state of the drawing of the picture, you need to drop in the current position, draw a falling object. Before drawing the falling object, to determine whether the drop can still fall, if you can go down, let it fell a grid, and then to draw, if the falling things can not be dropped, then judge whether the game is in game over state, if it is in game over state, then set the game state for game over state , so the canvas in the next redraw will be painted game over the screen. If the game is not in the game over state, then the falling object fixed down, while checking the game canvas up and down the current row of all the rows below, to see if the need for row delete action, if you need to delete the row, Clears the deleted row data from the game map, and then draws the deleted row into the background color. Then initialize a new drop and draw the new drop. The flowchart for the Paint method is as follows:

3. Data structure

This game involves the following several data structures.

Game Area

The game area is part of a cell phone or PDA screen, which is square, and the side length must be divisible by 16 (because the Russian game area is just 16 small bricks long, 16 small bricks wide square). The area is centered on the screen, whether horizontally or vertically. The game area is divided horizontally into 2 parts, some 12 small bricks wide, to display the game container, the other part of the 4 small brick width, used to display the next drop and score.

Small Bricks

Small bricks are part of falling objects and game containers. Performance for a square, side length for the game area side long 1/16. When each small brick is drawn, 4 sides will leave 1 pixels wide and be painted white or gray so that there is a gap between the bricks. Each small brick also has an ID, which is 1 to 8, respectively. We can store the 8 colors with an array of colors (called Brick_colors in the program). If the ID of a small brick is 3, then the color of the small brick is brick_colors[3-1].

Falling objects

A falling object is essentially a square of 16 small bricks. There are 7 kinds of falling objects, such as "Tian", "L" zigzag and so on. There are 4 kinds of rotational changes in each of the falling objects. Each drop has an ID of 1 to 7, respectively. Because for a falling object, the color is fixed. We can also use this color in the brick_colors array of subscript value plus 1, as a drop of the ID.

For example, the ID of the "L"-shaped drop is 3, and the change is in the form of:

So what data structure is used to store a drop, and we use the "L"-shaped drop as an example to illustrate:

Because each drop has four states, we can consider using an array of length 4 to store 4 states of a drop, each of which represents a state of the falling object. So what does it mean to indicate a certain state of a falling object, as you can see from the diagram above, that it is most appropriate to use a 4x4 two-dimensional array to store a falling object. Where the colored bricks appear, the value is 1, and only the background color, no place to draw, and a value of 0. Therefore, the 4 states of the entire "L"-shaped drop can be represented by a 3-D 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 a game container. The game container is a width of 12 small brick units, high for 16 small brick units, including left and right 2 wall and bottom of the container bottom. So use a 16x12 two-dimensional array (called MapData in the program) to store the fixed bricks. If Mapdata[i][j]=k (k!=0). Then it means that there is a fixed small brick in the I row J column of the game container, and the color value of the small brick is brick_colors[k-1]. If k=0 indicates that I row J column has no bricks.

So for the following game run-time, the MapData value is {{8,0,0,0,0,0,0,0,0,0,0,8}{8,0,0,0,0,0,0,0,0,0,0,8}{8,0,0,0,0,0,0,0,0,0,0,8}{ 8,0,0,0,0,0,0,0,0,0,0,8}{8,0,0,0,0,0,0,0,0,0,0,8}{8,0,0,0,0,0,0,0,0,0,0,8}
{8,0,0,0,0,0,0,0,0,0,0,8} {8,0,0,0,0,0,0,0,0,0,0,8} {}{8,0,0,0,0,0,0,0,0,0,0,8}{8,0,0,0,0,0,0,0,0,0,0,8}
{8,0,0,0,0,0,0,0,0,1,1,8} {8,0,0,0,0,0,0,0,0,1,1,8} {8,0,0,0,0,0,7,7,5,1,1,8} {8,0,5,0,0,7,2,5,5,1,1,8}
{8,8,8,8,8,8,8,8,8,8,8,8}}

Source Code and executable code

A total of 3 files:src.rar, ketrisgame.jad, ketrisgame.jar Description: Src.rar has all the source code. The Ketrisgame.jar also has the resource files required for the program to run. After installing wtk2.1, let Ketrisgame.jad and Ketrisgame.jar be in the same directory (the directory path cannot contain Chinese and space to remember), Double-click the Ketrisgame.jad file to run the game in the emulator.

Resources

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

<j2me in a nutshell>

<java Mobile phone/PDA program Design Introduction >