A powerful and flexible way to control the performance of special effects through game logic parameterization

Currently, most 3D games have a tool called "special effect Editor". Art can use this tool to edit and generate rich and gorgeous special effects. A special effect is often composed of multiple elements. The number of elements sometimes reaches 10 or more. Each element can be one of multiple types, such as particle system, model, strip, and announcement board. Each special effect element type has a large number of configurable parameters, such as the number of particles, lifetime, color, speed, position, and emission type. All parameters (including parameter change methods, such as key frames) of each element in the edited special effect file have been set. You only need to load this special effect file when the game is running, parse the data as scheduled and control the image engine performance. In this way, we have obtained a special effect module with strong performance and flexibility.

 

However, as we increase our requirements on the performance of the game, we are no longer satisfied with simply playing back the effects of the special effects based on the set parameters, but hope that the performance of the special effects will be linked to the game logic, make certain parameters of some special effect elements dynamically change with the game logic. For example, we have an engine tail smoke special effect, including a white smoke particle system, a black smoke particle system and a bulletin board. We want this special effect to correspond to a logic variable "intensity", which is a floating point number expressed by fpower. We hope that the emission speed of the white smoke particle system will change with the intensity, the size and lifetime of the black smoke particle system will change, and the size and transparency of the announcement board will change. In the face of such requirements, the most direct solution is to provide a method that can traverse all the elements inside the special effect. During the traversal process, different interfaces are reversed based on different types of elements, then, call these interfaces to modify different parameters of different elements. Unfortunately, this method is very poor. I think it is not good enough. I would like to cite two of the most fatal disadvantages: First, open a large number of interface functions to set the internal state of elements, second, set the special effect element parameters based on fpower.CodeYou must have a good understanding of the internal structure of this special effect. You need to know which particle system is smoke, which is smoke, which is announcement board, and which elements are irrelevant.

 

The following proposes a solution. This solution is only an assumption currently, and no special effect system is implemented based on this solution. But if you understand it, you will think it is very powerful and flexible, while maintaining the low coupling between the special effect system and other parts of the engine, you can easily implement this solution in other engines.

 

For ease of understanding, you must always note that this scheme is similar to the usage of constant registers in the shader System of the graphic API. We open up a vector4 array with 10 units for each special effect object (called constants []) as the constant register array of the special effect object, the content of each cell in the array can be interpreted as a 3D vector, a color, four floating point numbers, and four integers. You can choose to bind the parameters of all the special effect elements that can be edited in the editor to one of the constant constants [0], or choose not to bind them. If the parameter is floating-point, retrieve constants [0]. X for use. If the parameter is a 3D vector, the constants [0]. XYZ is used as the vector3 type, and the color is used as vector4. You can choose one of several fixed binding methods, such as adding, multiplying, or replacing (that is, assigning values ). In this way, the actual value of this parameter is obtained after the value set in the special effect editor is computed with the value in the bound constant register. In the previous example, the game logic can set the intensity value fpower to the constant register constants [0] of the special effect. The special effect editor binds the Smoke Emission speed parameter to constants [0, the particle size and lifetime of the black smoke are bound to constants [0]. The size and transparency of the announcement board are bound to constants [0]. The binding method is set to multiply, in this way, when the fpower of the game logic changes, the special effect system will change the parameters related to the relevant elements in the way set by the editor. The game logic does not need to understand the internal structure of the special effect, you do not need to access the logical object to obtain the values that interest the special effects.

 

Using this method, the coupling between the logic and the special effect is extremely low. The logic does not need to know the composition of the special effect, and the special effect does not need to call the engine or logical interface to request data. For example, if we want to synchronize some position parameters in the special effect with the position of an NPC, we only need to logically set the position of the NPC to the constant register of the special effect, at the same time, bind these parameters to the constant register through the special effect editor, and set the binding method as an alternative.

 

At present, this solution is only limited to theory, and there are many other aspects that can be expanded and improved. For example, the binding method can expand more types, or even replace them with expressions or scripts. If you have any good or new ideas about this article, you can contact me.