Article source: csdn Author: Chen Wanfei
About the author
Chen Wanfei, male, holds a bachelor's degree in mathematics and software from Central South University. He was a senior programmer and system analyst at Beijing Great Wall Software. He has extensive experience in j2se and j2ee development. Currently working on j2me research. He can be contacted at [email protected]
summary
This article gives a design plan for a Tetris game based on MIDP1.0, and gives the full implementation source code. The biggest feature of the game is screen adaptability. No matter what the screen size of various mobile phones and PDAs, the game can always get the best display effect. The game has been tested on four emulators of J2me wireless toolkit 2.1.
Disclaimer: This game code originally came from a Japanese open source project (see reference 1), and has been significantly modified by the author.
Here are some screenshots of the game:
design
1. Operation process
The operation process of this game is very simple. After the user starts the MIDlet, he enters the main screen of the game and the screen starts to display the welcome screen. After the user presses the [Start] button, he can start playing the game. When the user wants to pause, he presses the [Start] button again, and the game is paused. If the user presses the [Start] button again while paused, the game continues to run. . Anytime the [Exit] button is pressed, the game MIDlet will be terminated.
The game screen flow chart is as follows:
2. Algorithm
MIDP game design essentially uses a thread or timer to generate redraw events, and uses threads and user input to change the game state. This game is no exception. After starting MIDlet, a redraw thread is immediately generated, which draws the screen every 50ms. Of course, there are some optimization measures when redrawing. Not all pixels on the screen need to be redrawn, but there are selections, such as those falling objects that have been fixed on the game canvas (there are 7 types of falling objects in total, consisting of 4 Composed of small bricks, each falling object has a fixed color and can be rotated up, down, left, and right, so there is no need to redraw it. The game canvas is a CommandListener that can accept user keyboard commands and control the left, right, down, and rotation actions of the falling object. The flow control of the entire game is reflected in the paint() method of the game canvas object. paint() draws the current game screen based on the current game state. The welcome screen and Game Over screen are quite simple to draw. Drawing the game pause screen is also quite easy, just set a flag so that when paint() is executed, there is no need to actually perform a redraw action. For the drawing of the screen when the game is running, the falling object needs to be drawn at the current position of the falling object. Before drawing the falling object, determine whether the falling object can still fall. If it can fall, let it fall one space and then draw it. If the falling object can no longer fall, determine whether the game is in Game Over state. If it is in Game If the game is in the Over state, set the game state to the Game over state, so that the canvas will draw the Game Over picture the next time it is redrawn. If the game is not in the Game Over state, fix the falling objects and check the falling objects on the game canvas at the same time. Check all rows below the current row to see if row deletion is required. If row deletion is required, clear the data of the deleted row on the game map, and then draw the deleted row with a background color. Then initialize a new falling object and draw this new falling object. The flow chart of the paint method is as follows:
3.Data structure
This game involves the following data structures.
game area
The game area is a part of the mobile phone or PDA screen. The area is a square, and the side length must be evenly divisible by 16 (because the Russian game area is exactly a square that is 16 small bricks long and 16 small bricks wide). This area should be centered on the screen, both horizontally and vertically. The game area is divided into 2 parts horizontally, one part is 12 small bricks wide to display the game container, and the other part is 4 small bricks wide to display the next falling object and score.
small bricks
Small bricks are part of the drop and game container. Appears as a square, with the side length being 1/16 of the side length of the game area. When each small brick is drawn, 1 pixel will be left on the four sides and drawn in 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 (called BRICK_COLORS in the program) to store these 8 colors. If the id of a certain small brick is 3, then the color of the small brick is BRICK_COLORS[3-1].
falling object
The drop is essentially a square made of 16 small bricks. There are a total of 7 kinds of falling objects, such as those in the shape of "field", the shape of "L", etc. There are 4 rotation variations for each falling object. Each falling object has an ID, ranging from 1 to 7. Because for a falling object, its color is fixed. We can also use the subscript value of that color in the BRICK_COLORS array plus 1 as the id of the falling object.
For example, the "L" shaped falling object has an ID of 3, and its variation is:
So what data structure is used to store a falling object? Let's take an "L" shaped falling object as an example to illustrate:
Because each falling object has four states, we can consider using an array of length 4 to store the four states of a falling object. Each element in the array represents a state of the falling object. So what should be used to represent a certain state of a falling object? As can be seen from the above figure, it is most appropriate to use a 4X4 two-dimensional array to store a state of a falling object. Where colored bricks appear, the value is 1, and where there is only background color and no need to draw, the value is 0. Therefore, the four states of the entire "L"-shaped 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
The game map is used to store fixed tiles on the game container. The game container is 12 small brick units wide and 16 small brick units high, including the two left and right walls and the bottom of the container below. So 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 means that there is a fixed small brick on row i and column j of the game container, and the color value of the small brick is BRICK_COLORS[k-1]. If k=0, it means that there are no bricks in row i and column j.
Therefore, for the following game running time, the value of mapdata 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
There are 3 files in total: src.rar, ketrisgame.jad, ketrisgame.jar Note: src.rar contains all source codes. There are also resource files required for program running in ketrisgame.jar. After installing wtk2.1, put ketrisgame.jad and ketrisgame.jar in the same directory (note that the directory path cannot contain Chinese characters and spaces), double-click the ketrisgame.jad file, You can run the game in the emulator.
References
http://www.javadrive.jp/j2me/game/3/index.html
<j2me in a nutshell>
<Introduction to java mobile phone/PDA programming>