The game loop is the operational body of a game, and the frame rate is the consequence. A game cannot be made without a defined game loop, and the performance cannot be judged without measuring the frame rate.
These two aspects of game development are common throughout any game development project. However, the scalability and nature of the game loop vary across different devices, and there might be different scales to measure frame rates across different platforms.
For native development, the game loop is created and maintained by developers only. However, in most game engines, the loop is already defined with all the necessary controls and scope.
We will have a detailed look at these two most important parts of game development through the following topics:
- Introduction to the game loop
- Creating a sample game loop using the Android SDK
- Game life cycle
- Game update and user interface
- Interrupt handling
- General idea of a game state machine
- The FPS system
- Hardware dependency
- Balance between performance and memory
- Controlling FPS
The game loop is the core cycle in which user input, game update, and rendering are executed sequentially. This loop ideally runs once per frame. So, the game loop is the most important part of running a game with frame rate control.
A typical game loop has three steps:
- User input
- Game update
- Rendering
A simple game loop
This section checks the UI system of the game for any external input that has been given to the game. It sets the required changes to be made in the game for the next update. On a different hardware platform, this portion of the game loop varies the most. It is always a best practice to create common functionality for different input types to make a standard.
The input system is not considered as part of the game loop; however, user-given input detection is part of the game loop. This system continuously monitors the input system, whether an event has occurred or not.
A user can trigger any event at any point of time during gameplay when an active game loop is running. Normally, there are queues maintained by the input system. Each queue represents different types of possible input events, such as touch, key press, sensor reading, and so on.
The user input monitor checks those queues at a particular interval following the loop sequence. If it finds any event in the queue, it makes the required changes that will have an impact on the next update call in the game loop:
User input working principle
The complete game state is managed and maintained by the game update section of the game loop. This section is also responsible for running the game logic, changes in game states, loading/unloading assets, and setting the rendering pipeline.
The game control is usually managed by the game update section. Usually, the main game manager works at the top level of this game update section. We discussed game program structure in the previous section.
Any game runs a particular state at a time. The state can be updated by either user input or any automated AI algorithm. All AI algorithms work on the game update cycle frame by frame.
As stated earlier, the state can be updated from game update. The state is also initiated and destroyed by the game update. Initialization and destruction happens once per state, and state update can be called once per game cycle.
State update call flow
The rendering section inside a game loop is responsible for setting the rendering pipeline. No update or AI algorithm runs on this section of the game loop.
There was time when a developer had full control over the rendering pipeline. The developer could manipulate and set each and every vertex. The modern age game development system has not much to do with this rendering system. The graphics library takes care of all the control of the rendering system. However, at a very high level, a developer can only set the order and quantity of rendering vertices.
Rendering is one of the most important roles when it comes to frame rate control, keeping other continuous processes constant. Display and memory operations take the most time to execute from the processing point of view.
Typical Android graphics rendering follows the OpenGL pipeline:
