Let me explain in advance that this architecture was taught to the author by the author of Qilin Chess Framework @麒麟 子 大 神. The Qilinzi boss gave a set of chess sub-interface engineering learning based on FGUI + Laya Air, and Ques spent a while. Learned from the code and preliminary summarized the basic model of the layered game architecture, because it is only preliminary learning, and there are some other modules Quice temporarily not added (such as the network module), below Quice shares this set of game architecture (here (Only introduce the theoretical summary, do not paste the specific code).
1. Basic model of layered architecture:
First UI layered architecture diagram:
In the layered architecture, we split the UI into six levels: game, hub, popup, notice, alert, and mask:
GAME: Mainly used to place game scenes visible to players, such as game pre-loading scenes, lobby scenes, etc.
HUB: Generally it's the buttons floating above the scene, the player information bar and the like
POPUP: Game pop-up layer such as game end interface, etc.
NOTICE: Generally, it is a lock screen prompt, such as a prompt that the server is connecting to the server when the network is reconnected. Or when loading the interface, it prompts a loading
ALERT: belongs to a special pop-up layer, pop-up confirmation prompt box and the like
MASK: The mask is generally used in conjunction with the pop-up layer. For example, when a prompt box appears, the other parts except the prompt box will be darkened. There is a fading effect.
Each level of the above layer is gradually from low to high on zOrder. Generally, we will mark each layer with an enumerated type.
Second, the layered management model:
In a layered architecture, a Master-Scene-UI management method is adopted. In addition to the more general ones like Alert, they are put into the Basic package. Generally, we will make each UI (including the GAME layer) into a separate package in FGUI
Each UI will have a Master component, a Scene component, and a Page component:
These three components all inherit from a common parent class master, scene, and page, and are managed by master_manager, scene_manager, and ui_manager, respectively, and the relationship between these three types of components is:
1.master_manager is responsible for managing scene_manager
2.scene_manager manages ui_manager
3.ui_manager manages the specific display and deletion of each layer
All configuration information is written into a separate class and passed into the master_manager manager during initialization. Here, Ques directly pastes the global map in the hall subproject:
After the UI is displayed, the specific game business logic is written in the page component of each UI.
Three, simple demonstration of examples:
After Kryss's preliminary study, he implemented the layered architecture with a simple backgammon game. Here is a simple demonstration:
1. It can be seen that we separate the package into various UIs (including game scenes and suspended on the scene) and public components. The following shows the UI parts of the lobby scene and game scene. We usually hang on the GAME layer.
2.Alert said above that it is a special pop-up layer. It is different from the POPUP layer. It is a prompt box that can be reused. It is used many times in many places, and the POPUP layer is completely different for each UI.
3. At the end of the game, Ques made a separate prompt box UI and put it in the POPUP layer. After calling the Alert UI, call the end UI, and use the mask when calling. The content changes in the code part, such as "The game is over, xx won!"
Readers can divide the UI according to this basic layering according to their needs. This is a preliminary summary of Kyth's current layered architecture.
Welcome to the Khys article.
