From scratch android game programming (second edition) Chapter 5 Summary-Implementation of mine clearance games

Currently, we have learned how to build an Android programming environment, how to display text and images, and how to respond to user events. To sum up, we need to use this knowledge to implement a clearance game.

First, let's talk about the game rule: mine clearance is to find a hidden mine in a rectangle that is divided into several small cells, but it cannot be triggered. Each time you open a cell, the game fails if the following is a mine. If it is not a mine, and there are mines in the eight cells around it, the number of mines around it will be displayed. If there are no mines in the eight cells around it, it is blank. If you think a certain grid is a mine, you can use a red flag to mark it, correctly mark all mines, or open all the grids that are not mines, and then win.

User operations: in windows, users can perform three operations: left-click, right-click, and right-click. You can open a cell by clicking the left button and touch the ray. If you click a blank cell, all the spaces associated with it will be opened. You can right-click a grid and choose not to touch the grid. There are two ways to mark the grid. The first time you click the red flag, you are sure there is a ray. Then, you can click the red flag again to turn it into a question mark, indicating that there may be a ray. Both the left and right keys are valid only in this case, that is, a grid is surrounded by thunder, and all thunder is marked with a red flag. Click the grid to open all unmarked cells. This operation will touch the thunder. That is to say, if the tag is incorrect, the game will fail, so be careful when using it. Because there is no right-click on the phone, we must design an alternative solution. One way is to design a switch icon. After you click on the switch, all operations are considered to be right-click and right-click at the same time. In addition, you can also use the menu key on the mobile phone to hold down the menu key to turn on the switch, releasing the equivalent of closing the switch. To facilitate the game, we can implement two solutions at the same time.

Finally, let's analyze the general idea of the program. Starting from the most intuitive user interface, we need to create a game map based on the display area of the game, a two-dimensional integer array with m rows and n columns, A value in the array corresponds to a grid on the interface. Different values can indicate different States. For example, 0 indicates a blank grid, and 1 indicates a ray around the grid, 2 indicates there are two mines and so on. Because the location of Ray is random, this map needs to be initialized at the beginning of each game. In addition, because this map cannot be directly displayed to users, we need another map of the same size to build it. It also uses different values to indicate whether a grid is opened or marked. In this way, every time we refresh the screen, we will display different pictures based on the values on the screen, that is, the game interface we see. This multi-layer map technology is very common in games. The two maps can be in the same two-dimensional array or two arrays separately. For ease of understanding, we use two arrays to represent them separately. In addition, the remaining number of mines and game time are displayed on the page. The remaining number of mines is the total number of mines minus the number of mines marked by users. This can be a negative value. The game time is a timer started at the beginning of each new game. We know that if you want to display the time in sequence, you must refresh the screen without stopping, but review the previous four chapters, I didn't explain how to refresh the screen cyclically. So here I will introduce a method to use handler to refresh the screen. This method is relatively simple, but not efficient, so we will introduce another more effective method later.

Next, let's look at the response of user events. Although users can also operate on the keyboard, it will lose the pleasure of the game's pursuit of speed. Therefore, we only design a touch screen solution. When a user clicks on the screen, the user first determines the selected page, and then determines the user's operation result based on the user's method and the status of the selected page, change the value of the corresponding grid on the map. After refreshing, the user operation results are displayed on the screen.

In addition, we also need some signs of the game status, such as the game victory, failure, or being in the game. If the game wins, you still need to store records. As we have not mentioned before, we will temporarily discard this function.

In order to reduce the length of the project, the source code is used for direct explanation. The Eclipse project file of the source program has been downloaded along with this article, here is a source program introduction (it is nice to have an MP3 file in the Res/raw directory of the source program ).

First, let's take a look at main. Java

......

@ Override

Protected VoidOnpause (){

/*

*Changes the game status when the program is suspended or exited to end the game loop

*/

Gameview. gamestate = gameview.State_lost;

Super. Onpause ();

}

......

Here we will describe onpause, which is also a brief introduction to the lifecycle of Android programs. The details will be explained in depth. We all know that in a PC, multiple programs can run simultaneously, that is, multiple processes. In mobile phones, the program can still run in multiple processes, but there are some differences: first, the screen, when an application starts, it needs to exclusively occupy the screen. After some program with the interrupt function is run, the current program is invisible. The simplest example is the call. When you are playing a game and suddenly a call comes in, the calling program will occupy the screen and your game will go to the background for running (the onpause event will be triggered at this time). Another difference is that, if a program is transferred to the background for too long and is not activated again, the system will end the program. An event will be triggered before the end (onsaveinstancestate, which will be described later ). In contrast, when the program starts to trigger the oncreate event, we need to check whether the current program is running for the first time or re-running after being destroyed in the background. If it is re-running, we need to load the status information before the program is destroyed.

Here, the onpause method is incorrect, because the game should not be ended when the program is suspended. However, to simplify the code, we will do so for the moment and make improvements later.

The main content of the program is in gameview. java. The source code provided in this chapter contains detailed notes. Please read the source code yourself.

 

This chapter sample program http://u.115.com/file/f1e65e86c1