There is no written rule or direction to write code in Android, other than the syntactical grammar. However, most developers across the globe follow a few fundamental styles and standards for writing Android code. Android is based on Java, so most of the stylization follows Java standards.
When it comes to Android game development, there are a few design styles that should be followed. They do not cover game design, rather more technical design. These kinds of styles and standards indicate a proper project structure, class structure, and folder/file management.
Typical game design also involves following some rules while working on the Android platform. A few styles are being followed in the industry in terms of game design.
In this chapter, we will have a look at these styles and standards through the following topics:
- The Android programming structure
- Game programming specifications
- Technical design standards
- Game design standards
- Other style and standards
- Different styles for different development engines
- Industry best practices
Android style or recommendation is not a definite programming rule. However, a good programming practice always includes a set of rules. To code in Android, the code structure follows the Android base structure and hierarchy.
Android typically follows the standards and style of Java. So, the Android programming structure is basically Java structure, which follows the OOP style.
Java class formats should be consistent and follow the Javadoc rule; a standard structure should follow this sequence:
- Copyright information
- License information
- Package declaration
- Library imports
- Class description and purpose
- Class definition
- Global variables
- Constructor
- Methods
This is the copyright and license information format:
/* * Copyright (C) <year> authority * * <License information and other details> */
This is the class and method description format:
/* * <Description> * <Purpose> */
Like the coding style, there is no defined call hierarchy. However, in Android gaming, most developers follow a basic approach. In this approach, there are mainly three kinds of classes in the project structure:
- Managers and controllers
- Associates
- Utility classes
A game requires the managers and controllers to implicate game rules and regulations. It is also used to control the behavior of game elements and states. Most games consist of multiple sections or screens, for example, menu, level selection, game play, and so on.
These sections can be termed as states, and the elements used inside these are called associates. Associates may be separate classes by themselves. Utility classes basically support development by providing predefined functionality, such as in-game sound implementation, record store management, common utilities, network connectivity, and so on:
Call hierarchy
Inside the game loop, the main Android game thread loops hand over control to the main game manager. The main game manager is responsible for passing on the thread and rendering control to the required state manager. The main game manager is also responsible for the initialization and destruction of state managers, depending on the current thread. Moreover, the main game manager is active throughout the game cycle and manages the main game activity as well.
State managers are responsible for managing a state (main menu, level selection, in-gameplay, and so on) and all the required associate classes. State managers pass the call to the respective associates to carry out a specific task.
Utility classes are accessible from any layer in the hierarchy, depending on the requirements.
This is a generic architecture that is not mandatory. Many developers design the call hierarchy differently. Everything is good, and the game flow is also running properly without sacrificing the class/data security.