Unity Client Framework notes (state mode and policy mode in game application)

Recently spent a few days combing the new game's client framework, although it has a relatively clear direction, but at the beginning of the writing is still a bit confusing, but after the final carding, the personal feel the code a lot more refreshing.

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

I've written one or two articles before about the structure of the client, and also spit out some other people's designs. It can be said that I have a relatively clear direction at the beginning of writing code, many years of experience can tell me what kind of code is beautiful, what kind of code is bad taste.

First of all, I divide the client structure into three layers, one layer for the display layer, and it deals with the core battle modules of the game, such as the scene, character, and skill performance of ARPG in this layer. The first layer is logical layer logic, which handles the various systems of the game, such as resource management, role management, task management, etc. are all placed on this layer. The first layer is the UI layer, which is made up of various interfaces.

There is no strict division between the layers, such as the logic layer is the individual manager, the display layer will have a game or battlescene such as a monomer class, the UI layer will have a uimanager to manage. But if each layer is interspersed with each other, it can cause confusion for clients. So there are some dividing lines. The UI layer can invoke the logic layer and the display layer, and each interface does not run between calls, but interacts with events. The logic layer handles almost nothing but the logic, not the other two layers. The display layer can invoke the manager of the logical layer to fetch data or communicate with the server.

The above is a big frame or thought, this is not a lot of people will mention the MVC framework, but based on the development experience summed up a set of similar things. Anyway, the idea is consistent, that is, through a reasonable level of division to achieve the separation of logic and display, when a place changes, will not affect other places. This is the "opening and shutting principle". While some of the principles of object-oriented are very dogmatic, it is indeed the guiding direction of code design.

On the basis of the framework determination, there are some details of the design needs to consider, basically the following are some of the problems are the pros and cons, so I only describe, do not choose, specific to the personal habits.

1, do you want a global public datacenter to save the data, or to spread the data inside each manager? By using a common datacenter to save data, you can avoid mutual access between managers, all managers are fetching data from datacenter, and managers interact through events.  But the inevitable datacenter will grow more and more large over time. While the manager holds the data, it may cause mutual access between the various managers. If the player wants to remove the weapon, they must first get the remaining space from the item or the Backpack manager, so that the two managers depend on each other.

2, the message is each message a file to handle its own logic, or to register an ID to the corresponding manager to process the message data?

3, whether to maintain the independence between logical managers, to ensure that a certain manager is removed, the game can still be compiled and run?

After these structural problems have been combed out, the game's core character and battle system design has begun. This embodies the developer's ability to abstract, if the abstract ability is good, you can one step, otherwise you will value the ability to construct.

My design is as follows (please forgive me not to draw UML diagram, just dictate ...) ）：

A role is a class that inherits from Monobehaviour, the base class is a unit (also called actor or role), and there are columns of derived classes such as player NPC Hero Monster, and so on. These are the most basic roles.

Each character will hold a data, such as Playerdata Npcdata Herodata, and so on, these are the logical layer of things, is pure data processing, based on the server's message creation. such as the player's ID, blood volume, attack and so on are dealt with here.

The unit internally manages some of the columns ' component, which describe what to do, such as Movecomponent attackcomponent animationcomponent hudcomponent, etc. These component derive a subclass of columns to implement a specific behavior, such as attackcomponent can have meleeattackcomponent rangeattackcomponet, and so on. The player and monster can synthesize the specific effects they want to achieve with these component groups. And when the implementation needs to be modified can only focus on component inside, adding a new behavior is simply to add a new component. At the same time component can be shared, such as player and hero many component are the same, but Hudcomponet is not the same, this is the combination than inheritance superior place. This design pattern is the strategy mode. By encapsulating the variable algorithm, it achieves the effect of calmly coping with the change.

Very similar to the policy pattern is the state pattern. There are times when the boundaries between them are not very clear, and some routines can be said to be either a strategy or a state. For example, to search for an enemy, this can be a behavior, or a search for the enemy state (you can consider a layered state machine, so you can run while searching for enemies, the state can be parallel).

My side of the deal is that each role class will correspond to the status implementation of some columns, such as the player has playeridlestate playermovestate playerattackstate, and Monster has Monsteridlestate Monstermovestate,state can have a common base class such as unitmovestate, or no, this depends on the player and monster the state of the degree of similarity, if there is a lot of duplicate code, then consider a base class.

State mode describes the flow of a state, such as what should be done in the idle state, when to enter the move state, through the state Division, you can ensure that the role at a certain moment in a certain state, and this state of logic processing in the state class is completed. In this way there will be no confusion (such as writing various isinstate (XXXX) in the update) to achieve the purpose of decoupling. At the same time the flow between States can be clearly expressed, and our logic will be much clearer. The specific implementation of state mode is the finite state machine, which is a very important means to implement AI.

A summary of my implementation is the behavior of the character holding some columns, as well as the state of some columns, what to do by the behavior description, and how to do it through the state description. This makes it possible to scatter the code that was originally written inside the player. This dispersion does not make it much more cumbersome to write our code, but it makes our logic clearer and the code easier to read. If this effect is not achieved, but it is felt that if the code is written inside the player can be more convenient to call, then it must be a certain part of the problem.

I personally do not advocate design patterns, always advertised as pragmatism, but looking back, we think that beautiful design is often a pattern. Dozens of design patterns we may be familiar with only a few of the most commonly used in the infinite. Really thoroughly understand these patterns in development before you can really understand object-oriented, encapsulation, but also understand what is beautiful code, what is elegant design.

Unity Client Framework notes (state mode and policy mode in game application)