Android Game Development: Building a game framework (1)

Generally, the basic framework of game development includes the following modules:

Window Management: This module creates, runs, pauses, and restores game interfaces on the Android platform.

Input: This module is closely related to the Windows Management Module and is used to monitor and track user input (such as touch events, button events, and accelerator events ).

File I/O: This module is used to read assets files, audios, and other resources.

Image module (graphics): in actual game development, this module may be the most complex part. It loads images and draws them to the screen.

Audio module (audio): This module loads audio frequencies on different game interfaces.

Networking: This module is required if a game provides the multiplayer game networking function.

Game framework: This module integrates the above modules and provides an easy-to-use framework to easily implement our games.

 

Each module is described in detail.

 

1. Window Management

We can think of a game window as a canvas that can draw content on it. The window management module is responsible for customizing windows, adding various UIS, and receiving input events from various users. These UI components may be accelerated through hardware such as GPU (such as OpenGL ES ).

This module is designed not to provide interfaces, but to integrate with the game framework.CodePost. What we need to remember is the applicationProgramStatus and window events must be handled by this module:

Create: The method called when the window is created.

Pause: The method called when the application is suspended due to write silence.

Resume: The method called when the application is restored to the foreground.

 

2. input module

In most operating systems, input events (such as touch screen events and button events) are scheduled through the current window (dispatched), and the window further distributes these events to the selected components. Therefore, we only need to pay attention to component events. The UI APIs provided by the operating system provides an event distribution mechanism, so that we can easily register and listen for events. This is also the main responsibility of the input module. There are two ways to handle events:

Polling: in this mechanism, we only check the current status of the input device. The previous and subsequent statuses are not saved. This type of input event processing is suitable for processing touch-screen button events, but not for Tracking text input, because the order of key events is not saved.

Event-based handling: This mechanism provides the memory function for event processing, and is suitable for processing text input or other operations that require key-per-order.

On the Android platform, there are three main input events: Touch Screen events, button events, and accelerator events. The first two events are applicable to both round robin and event-based processing, events on the accelerator are usually polling.

There are three types of touch screen events:

Touch down: The Mobile Phone Touch Screen occurs.

Touch drag: Occurs when you drag your finger. Previously, the touch down event was generated.

Touch up: Occurs when the finger is raised.

Each touch event has auxiliary information: the position of the touch screen, pointer index (used to track and identify different contacts when multiple touch points are used)

 

There are two types of Keyboard Events:

Key down: Triggered when you press the keyboard.

Key up: Triggered when the keyboard is released.

Each key event also has auxiliary information: Key-down event storage key code, key-up event storage key code and the actual UNICODE character.

 

The accelerator event. The system keeps polling the accelerator status and identifies it with three coordinates.

 

Based on the above introduction, some interfaces of the input module are defined below to poll touch screen events, button events, and accelerator events. The Code is as follows:

Input. Java

 Package Com. badlogic. androidgames. Framework;

 Import Java. util. List;

 Public   Interface Input {

 Public  Static   Class Keyevent {
 Public   Static   Final   Int Key_down = 0;
 Public   Static   Final   Int Key_up = 1;

 Public   Int Type;
 Public   Int Keycode;
 Public   Char Keychar;
}

 Public   Static   Class Touchevent {
 Public   Static   Final   Int Touch_down = 0;
 Public   Static   Final   Int Touch_up = 1;
 Public   Static   Final   Int Touch_dragged = 2;

 Public   Int Type;
 Public   Int X, Y;
 Public   Int Pointer;
}

 Public   Boolean Iskeypressed (Int Keycode );

 Public   Boolean Istouchdown ( Int Pointer );

 Public   Int Gettouchx ( Int Pointer );

 Public   Int Gettouchy ( Int Pointer );

 Public   Float Getaccelx ();

 Public   Float Getaccely ();

 Public   Float Getaccelz ();

 Public List <keyevent> getkeyevents ();

 Public List <touchevent> gettouchevents ();
}

The preceding definition includes two static classes: keyevent and touchevent. Both the keyevent class and the touchevent class define constants of related events. Keyevent defines several variables that store event information: type, keycode, and Unicode character (keychar ). The same is true for touchevent, which defines the location information (X, Y) and the ID of an output touch point. For example, if you press the first finger, the ID is 0, and the ID of the second finger is 1. If you press the two fingers, the finger 0 is released, and the finger 1 is kept, when another finger is pressed, ID: 0.

The following is the polling method in the input interface: input. the input parameter of iskeypressed () is keycode, and returns the Boolean value of whether the corresponding key is pressed; input. istouchdown (), input. gettouchx () and input. gettouchy () returns whether or not the given pointer index is pressed and the corresponding horizontal and vertical coordinate values. Note that when the corresponding pointer index does not exist, the coordinate value is undefined. Input. getaccelx (), input. getaccely (), and input. getaccelz () returns the coordinates of the respective accelerometer. The last two methods are used based on the event processing mechanism. They return the keyevent and touchevent instances to record the information triggered by the last event, the latest event is at the end of the list.

Through these simple interfaces and classes, we have built our input interfaces. Next, continue to analyze the File Processing content (file I/O ).

 

3. file I/O)

Reading and Writing files is a very important function in game development. In Java Development, we mainly focus on inputstream and outputstream and their instances. They are the standard methods for reading and writing files in Java. In game development, resource files such as configuration files, images, and audio files are read. File writing is generally used to save user progress and configuration information.

The following is an interface for reading and writing files:

Fileio. Java

  package  COM. badlogic. androidgames. framework; 
  Import  JAVA. io. ioexception; 
  Import  JAVA. io. inputstream; 
  Import  JAVA. io. outputstream; 
  Public   interface  fileio {
  Public  inputstream readasset (string filename)  throws  ioexception; 
  Public  inputstream readfile (string filename)  throws  ioexception; 
  Public  outputstream writefile (string filename)  throws  ioexception; 
}

in the above Code, we pass a file name as a parameter and return a stream. The specific execution will be reflected in the implementation of the interface. At the same time, we will throw an ioexception to prevent read/write errors. After reading and writing, we need to close the input and output streams. The asset file is read from the APK file of the application. Other files are generally read from the built-in memory or sdcard, which correspond to the three methods in the above Code.