Unity Client Framework Note II (Thinking of Component entity development mode)

Unity's Entity-component-system is very beautiful and very flexible. Many articles also promote the development model of this component entity. Because it fits into one rule: use combinations rather than inheritance.

But the actual development process, limited to my personal ability, to achieve an equally beautiful component-based MMO framework is a very difficult thing.

This article is a personal development process of some thinking, in fact, the so-called beautiful framework is different from each other, and is not necessarily necessary, can be used in a familiar way to quickly complete the development of the project is enough. As long as the development process will not feel awkward, the code will not be disgusting to themselves or others, planning to modify the needs of the time will not be dozens, the later will not be difficult to debug the bug, then is the beautiful framework.

In theory, the so-called ECS is an entity, holding a set of component, and then through a series of system to maintain the logic between the scheduling components. Components are relatively independent, and the ideal way to do this is through event messaging. From this point, unity has been very beautiful, gameobject can bind arbitrary monobehaviour, the script component has a unified portal, and can send messages through SendMessage, You can also use getcomponent to get a specific component and call its function directly.

I decompile a lot of lines to get started with the source code, almost not entirely dependent on the component model for development, more or rely on a set of inheritance system to complete. My own feeling here is that the low-level or logical-independence function is suitable for the component mode, and the logic interaction is very complicated, and it is counterproductive to rely too much on the component mode to achieve the "ideal" effect.

For example, in theory ECS, entity should be like gameobject, only maintain the component, do not contain any other logic or code, all need to dispatch logic should put in system, it will pay attention to its responsible component. However, in my opinion, this instead of cutting the logic, in the actual project, it is difficult to do this separation, or make the code very scattered, difficult to maintain. When looking for bugs, it will not be easy because of such code separation, but because the structure of the scattered caused by the situation can not be started.

and the message communication between components, when the game is all implemented in a component way, and the components through the message to complete the call or parameter passing. Such code is hard to write and difficult to maintain. It is not intuitive where events are thrown, who should accept the event, and what parameters are held. Although it achieves a flexible effect, the side effects are obvious, and the code is filled with various events, which makes it difficult to understand the context of the game by simply viewing, tracking, and debugging.

"Domination" is implemented in this way, a entitycontroller, which contains all the components, and provides the corresponding interface. It can decide which component to create through the corresponding configuration file. While external only maintain a entitycontroller, whether it is soldier or building, it is an entity, but a hook is soldierattackcomponent, One of the hooks is buildingupgradecomponent, which produces different behavior. This way of implementation gave me some inspiration, because it is in some way in line with ECS. But it has to be said that this way of implementation is also very wonderful, Entitycontroller is very large, although it does not maintain the specific logic, but only the maintenance of component interface let its code reach thousands of lines, not to mention its conceptual huge.

The realization of Eternity Warrior 3 is relatively orthodox and is a component mode I can accept at this stage. However, strictly speaking, this is not a component pattern, but rather a combination of implementations that replace inheritance. It has a actioncontroller, which holds a variety of agents, such as Aiagent attackagent moveagent, and so on, the main external interaction with Actioncontroller, Internally, the code and functionality are distributed through these agents.

Unity's official game "Archangel" seems to me very low. Promotional video is cool, but the actual game play is very slag, whether it is the picture performance, or the game playable. Have to say, professional to do the game and professional to do the engine is really not a job. In its code, as Unity's official game, it didn't reflect unity's most advanced productivity, which is a low burst. Its pathfinding is a * path finding Pro, the interface is Ngui, animation is the old animation system animation, code organization strongly relies on interface design, an actor inherits from Ibuffable Ihealthable Itakedamage and so on interface, It's Orthodox, but there's no bright spot.

Some Japanese and Korean leaderboard game, such as "White Cat" "Iron Knight Regiment", in fact, the code structure is not beautiful, a stageobj has thousands of lines. From this point of focus on the structure is meaningless, so many of the best-selling games, in fact, the implementation of a bit inflexible. Their habits, easy to use, is enough.

There are lots of other games, but they're pretty much the same. Apart from the realization of some wonderful work, basically it is through the inheritance system to complete the basis of the object abstraction, and then through the components of the object in the larger or independent function of the extraction out. such as state components, AI components, animation components, role attributes, and so on.

In addition, one thing is very unified, is the use of finite state machines, basically all games are through the FSM to complete the role of the state flow, ARPG especially so. A few parts of the game's AI section may use the behavior tree. Barely seen through the behavior tree, not relying on the state machine to control the role. In my thinking, the behavior tree has to traverse the whole tree every time, both in terms of design and efficiency, which is not suitable for the behavior description of the game character. And the behavior tree is good at the AI aspect, the general simple game through the state machine to maintain is enough.

Unity Client Framework Note II (Thinking of Component entity development mode)