Unity client Framework notes (State mode and Policy mode in game applications), unity Client

Unity client Framework notes (State mode and Policy mode in game applications), unity Client

It took a few days to sort out the client framework of the new game. Although there was a relatively clear direction, it was still a bit confusing at the beginning, but after the final sorting, I personally feel that the code is much refreshed.

This article is not about the teaching of design patterns, but about some of my own ideas and practices. I organized the code into my favorite structure to ensure that the logic and structure are clear, but this does not mean that it is in line with everyone's habits.

I have written one or two articles to discuss the structure of the client and some other people's designs. It can be said that I had a relatively clear direction at the beginning of code writing. Years of experience can also tell me what kind of code is beautiful and what kind of code is bad.

First, I divide the client structure into three layers. One layer is the Display layer. It processes the core combat modules of the game, such as the scenario, role, and skill performance in ARPG. One layer is Logic layer Logic, which processes various game systems, such as resource management, role management, and task management. One layer is the UI Layer, which is composed of various interfaces.

There is no strict division between layers. For example, the logic layer is a single manager, and the display layer also has a single class such as Game or BattleScene. The UI Layer has a UIManager for management. However, the client may be confused if the layers are interspersed with each other. So we made some boundary division. The UI Layer can call the things of the logic layer and the display layer. interfaces interact through events instead of calling each other. The logic layer only processes the logic and does not call the other two layers. The display layer can call the manager of the logic layer to obtain data or communicate with the server.

The above is a big framework or idea. This is not the MVC framework that many people will mention, but a similar set of things based on development experience. The idea is the same, that is, the separation of logic and display is achieved through a reasonable hierarchy. When a place is modified, it will not affect other places. This is the "open and closed principle ". Although some object-oriented principles are well-defined, they are indeed the Guiding Direction of code design.

On the basis of determining the framework, there are still some details that need to be considered. Some of the problems mentioned in the basic upper and lower aspects all have their own advantages and disadvantages. Therefore, I will only describe them and will not make any choice, depends on your habits.

1. Is it necessary to have a globally public DataCenter to save the data, or to distribute the data to various managers? Using the public DataCenter to save data can avoid mutual access between managers. All managers retrieve data from DataCenter and interact with each other through events. However, the inevitable DataCenter will become larger and larger over time. The data held by the manager may cause mutual access between managers. If a player wants to unload the weapon on his or her body, he or she must first obtain the space remaining in the backpack from the item or backpack manager so that the two managers can depend on each other.

2. Is a message a file to process its own logic, or is an id registered to the corresponding manager to process the message data?

3. Do you need to maintain the independence between logical managers to ensure that the game can still be compiled and run without a certain manager?

After sorting out the above structural issues, we began to design the core role and Combat System of the game. This shows the developer's abstract capabilities. If the abstract capabilities are good, they can be put in place in one step. Otherwise, the reconstruction capabilities will be taken into consideration.

My design is as follows (please forgive me for not drawing a uml diagram, and I will just dictate it ...) :

A Role is a class inherited from MonoBehaviour. The base class is Unit (or Actor or Role), and some column-Derived classes such as Player NPC Hero Monster will exist. These are the most basic roles.

Each role will hold a data, such as PlayerData NPCData HeroData. These are logical layer items that are purely data processed and created based on the server message. Such as the player id, blood volume, attack power, etc. are all handled here.

The Unit internally manages the Component of some columns, which describes how to do something, such as MoveComponent AttackComponent AnimationComponent HUDComponent. These Component will derive subclass of some columns, for example, AttackComponent can have MeleeAttackComponent RangeAttackComponet. Player and Monster can combine the Component to achieve the desired effect. When the implementation needs to be modified, you can only focus on the inside of the Component. adding a new behavior is just adding a new Component. At the same time, Component can be shared. For example, many components of Player and Hero are the same, but HUDComponet is different. This is a better combination than inheritance. This design mode is the policy mode. It encapsulates easy-to-change algorithms to easily cope with changes.

The status mode is similar to the policy mode. Sometimes the boundaries between them are not very clear. Some routines can be either a strategy or a State. For example, searching for enemies can be an action or a state of searching for enemies (a layered state machine can be considered to search for enemies while running, and the state can be parallel ).

In my case, each corner class corresponds to the State implementation of some columns. For example, Player has PlayerIdleState PlayerMoveState PlayerAttackState, Monster has MonsterIdleState MonsterMoveState, and State can have public base classes such as UnitMoveState, or not, it depends on how high the State similarity between the Player and Monster is. If there is a large number of repeated code, a base class is considered.

Status mode describes the flow between States, such as what to do when to enter the Idle status, when to enter the Move status, through Status Division, it can ensure that the role is in a certain state at a certain time point, and the logic processing of this state is completed in this state class. In this way, there will be no confusion (for example, writing various IsInState (xxxx) in Update) to achieve the goal of decoupling. At the same time, the flow between States can also be clearly expressed, and our logic will be much clearer. The specific implementation of the state mode is finite state machine, which is an important means to implement AI.

To sum up, my implementation is that the role holds the behavior of some columns, as well as the status of some columns, describes what to do through the behavior, and describes how to do through the status. In this way, the Code originally written in the Player can be dispersed. This decentralization does not make code writing more troublesome, but makes our logic clearer and the code easier to read. If this effect is not achieved, but the code can be called more conveniently if it is written inside the Player, it must be a problem at a certain stage.

I personally do not really advocate design patterns, but I always advertise myself as pragmatism. But looking back, we think that beautiful design is often a pattern. We may be familiar with dozens of design patterns, but the most common ones are infinite. Only by thoroughly understanding these modes in development can we truly understand object-oriented and encapsulation, and understand what is beautiful code and what is elegant design.