Implementation of Game objects (II)

In the previous article, I made a simple description. Another method for implementing game objects is to use common object objects.

Three articles in the essence of game programmingArticleThis article describes the implementation scheme of entity and Entity Management. One article describes four elements of the Entity Management System: defining how entities communicate with Entity messages and implementing an entity-classCodeAnd data entity code, maintain the list of registered entity classes, and the Entity Manager used to create, manage, and send messages.

I have explained the content of the object message before discussing the event mechanism. In fact, this is the difference between calling by interface and message-driven. Now mangos is completely called by interface, therefore, the engine does not have any entity messages. Entity code implementation and Entity Manager are our key points to be discussed.

Another article also mentions the two major problems of using the class-based method to implement game objects. First, it requires that all objects in the system must be derived from a starting point, that is to say, all the object classes have been determined during compilation. This may be an undesirable restriction. If the developer decides to add a new object class, he must understand the base class, to support new classes. Another problem is that all object classes must implement the same underlying functions.

For the second problem, you can use the interface inheritance method to avoid too many methods of the base class. A similar method is used in mangos implementation. The unit and worldobject derived from the object virtual base class are still non-instantiated classes, these two objects define different attributes and methods to implement different types of objects. In the game, the object pointer can be converted down to unit or worldobject based on the actual object type to call the required interface. Although the method is not oo enough, it can also solve the problem. However, the first problem is always unavoidable.

So we have a general object concept. The main method is to classify the interfaces of the original base class into different subclasses, then, we can combine the objects to generate the actual types of Game objects we need. This combination process can be defined by a script, so that the same object type can be generated at runtime, which solves the first problem mentioned above.

The general entity implementation method is available in the current game engine and developmentSource codeYou can also see the shadow. One is bigworld. From the information provided, its engine only provides one entity game object, and then the game content implementers can define different types of entity types through the XML and Python scripts, each type can have different properties and different methods. In this way, the interface defined by the base class is completely transferred to the script definition, with great flexibility.

In addition, there is an entity implementation in cel. According to the cel description, entity can be any object in the game, including objects that players can interact with, such as keys and weapons, or objects that cannot be directly interacted, such as the game world, or even part of the task chain. Entity itself does not have any features, and the specific function implementation needs to be completed by adding property. In simple terms, property defines what entity can do. As for how to do it, it is defined by behavior. Therefore, the final game object in CEL is actually generated by combining multiple properties and multiple behavior in entity.

However, the property in CEL is of little significance to the property in bigworld. The property that can be defined in cel must be provided inside the engine, for example, the pcobject In the example. mesh, pcmove. linear, pctools. inventory and so on, while the property in bigworld is completely customizable. From this perspective, we can regard the property in cel as the logic system of the game, that is, the subclass defined after the interface classification as described above.

The fully customizable property provided by the engine is essentially the same as that used by bigworld. In a game implemented using bigworld, it is impossible to completely define the property for each type of game objects. Based on the code utilization principle, some small classes will be defined first, then, when the entity type is defined, these classes are included in the form of custom property. Of course, I have never used bigworld. the above description is just based on the principle of game implementation.

The description is still abstract. We can use wow and mangos code to describe it. Mangos defines an attribute set for the object. The size of this attribute set and the data to be stored vary depending on the object type. In addition, the game object contains a system that processes different game logics, such as restsystem, floodfiltersystem, and varioussystem. H is defined as an interface group.

If you want to change this structure to the general Entity system we described, you can let the object only provide the interface for property registration and deletion. The property definition here is the same as that in cel, in mangos, restsystem, floodfiltersystem, and varioussystem are also mentioned. Then, the types of Game objects we need, such as player, creature, and item, are also defined in XML files. Different object types can be loaded with different properties, the loading principle is to load the required functions.

After the object definition is completed according to the preceding method, the object implementation also needs to be modified. In the past, client messages were directly handled by the player, and AI also directly called the creature interface to complete some functions. Currently, there are no available methods in the general entity, all implementations are transferred to the property. Therefore, each property must register events and messages of interest. entity forwards a message, to the property that you are interested in. The other implementations are no different.

Of course, let's make another extension so that the property is not only provided by the engine, but also can be defined by the script itself, and these properties can be registered through XML, in this way, the bigworld is completely free. This is actually to transfer many functions implemented in C ++ to Python. This practice can be used as a reference, but it is not necessarily suitable for everyone, at least in my opinion, this implementation can only be implementedProgramSo it is easier for programmers to develop and debug their preferred languages.