Android Game Development: Building a game framework (4)

6. Game framework

After all the basic work is done, let's finally discuss the game framework itself. Let's take a look at what work we need to do to run our game:

• The game is divided into different screens, each of which executes the same task: Judge user input and render the screen based on input. Some programs may not require any user input, but will switch to the next screen after a period of time (such as the splash interface)
• The screen needs to be managed in some way (for example, we need to track the current screen and switch the next screen at any time)
• The game needs to allow screen access to different modules (such as modules, audio modules, and input modules) so that the screen can load resources, obtain user input, play sound, rendering buffer, and so on. Because our game is a real-time game, we need the current screen to be updated quickly. Therefore, we need a main loop. The main loop ends when the game exits. The number of frames per second becomes Frame Rate (FPS ).
• The game needs to track the status of the window (such as whether the game is suspended or restored) and notify the corresponding handling event.
• The game framework needs to process the establishment of windows and the creation of UI components.

Let's take a look at someCode:

Createwindowanduicomponent ();

Input input =NewInput ();

Graphics graphics =NewGraphics ();

Audio audio =NewAudio ();

Screen currentscreen =NewMainmenu ();

Float lastframetime = currenttime ();


While(! Userquit ()){

FloatDeltatime = currenttime ()-lastframetime;

Lastframetime = currenttime ();

Currentscreen. updatestate (input, deltatime );

Currentscreen. Present (graphics, audio, deltatime );

}

Cleanupresources ();
 

The code first creates the game window and UI component (createwindowanduicomponent () method), and then we instantiate the basic components, which can ensure the implementation of the basic functions of the game. We instantiate our starting screen and use it as the current screen. Then write down the current time.

Then we enter the main loop. When the user wants to exit, we can end the main loop. In the main loop, the time difference between the previous frame and the current frame is calculated to calculate FPS. Finally, the status of the current screen is updated and displayed to the user. The updatestate method depends on the time difference and input status. The present method includes rendering the screen status to framebuffer and playing audio. The present method also needs to know the time difference from the last call to the present.

When the main cycle ends, we need to clear and release various resources.

This is the process of game work: process user input, update status, and present to users.

Game and Display Interfaces

The following interfaces are required during game operation:

• Create a window and ui, and establish an event mechanism
• Enable the main loop of the game
• Tracks the current screen display and updates it in each main loop
• Transfers the events in the UI thread to the main thread and passes these events to the current display interface for synchronous changes.
• Ensure access to all basic game modules, such as input, fileio, graphics, and audio.

The following is the game interface code:

PackageCom. badlogic. androidgames. Framework;

Public InterfaceGame {

PublicInput getinput ();

PublicFileio getfileio ();

PublicGraphics getgraphics ();

PublicAudio getaudio ();

Public VoidSetscreen (screen );

PublicScreen getcurrentscreen ();

PublicScreen getstartscreen ();

}
 

As shown above, the Code contains some getter methods to return the instance of the module.

The game. the getcurrentscreen () method returns the currently activated screen. Then we will use an abstract class androidgame to implement this interface. This method will be implemented in addition to the game. all methods except getstartscreen. In actual games, if we create an androidgame instance, we need to inherit androidgame and reload the game. getstartscreen () method to return an instance of the first display screen.

In order to let everyone know how simple it is to build a game using the above method, the following is an example (assuming we have implemented the androidgame class ):

 
Public ClassMyawesomegameExtendsAndroidgame {

PublicScreen getstartscreen (){

Return NewMysuperawesomestartscreen (This);

}
}
 

It's easy, right? All we have to do is execute the Starting Screen of our game display. We inherit the androidgame class to do other work. From this point of view, the androidgame class will require mysuperawesomestartscreen to update and re-render itself in the main loop. Note that we passed the myawesomegame instance to mysuperawesomestartscreen.

The following is an abstract class screen, which is an abstract class rather than an interface, because we can write some methods used by subclasses in advance to reduce the implementation of subclasses. The Code is as follows:

 //  The screen class  
 
 Package Com. badlogic. androidgames. Framework;

 Public   Abstract   Class Screen {

 Protected   Final Game;

 Public Screen (Game ){

This . Game = game;

}

 Public   Abstract   Void Update ( Float Deltatime );

 Public   Abstract   Void Present ( Float Deltatime );

 Public   Abstract   Void Pause ();

 Public   Abstract   Void Resume ();

 Public   Abstract   Void Dispose ();
}

The constructor receives the game instance and stores it in a final variable accessible to all sub-classes. Through this mechanism, we can accomplish two things:

We can use game instances to play audio, draw a plane, and obtain user input and read/write files.

When appropriate, we can call game. setscreen () to set a new current plane display.

Methods screen. Update () and screen. Present (): they update the plane and display it synchronously. Game instances call them in the main loop.

Method screen. pause () and screen. resume () is called when the game is paused and recovered. The two methods are also called by the game instance and are notified to the current flat display.

Method screen. Dispose (). When the game. setscreen () method is called, screen. Dispose () is called by the game instance. In this way, the game instance destroys the current display screen and releases all related system resources to provide the maximum memory for the new screen window. Screen. Dispose () is the last method for content persistence.