Entity special effect configuration method and device, equipment and medium

Abstract

The invention relates to an entity special effect configuration method and device, equipment and a medium. The method comprises the steps that in response to a special effect configuration request, a special effect configuration list is obtained, and the special effect configuration list is a special effect identifier set obtained by screening based on a special effect configuration rule associated with a game entity; in response to an identifier selection event for the first special effect identifier, generating a resource application request corresponding to the first special effect identifier; obtaining an updated special effect identifier corresponding to the resource application request according to a special effect configuration rule, and determining an association mapping relationship between the first special effect identifier and a special effect configuration part corresponding to the game entity; and updating a special effect configuration list based on the updated special effect identifier and the special effect configuration rule, obtaining a corresponding first special effect resource according to the association mapping relationship, and updating the image of the special effect configuration part based on the special effect rendering image corresponding to the first special effect resource. The response speed and the rendering efficiency of the special effect configuration process and the real-time performance and the accuracy of the final visual performance can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of game interaction, and in particular to an entity special effect configuration method and device, equipment and medium. BACKGROUND

[0002] In today's role-playing games, it has become a common requirement to provide users with the function of configuring the personalized appearance of game entities such as game characters, game pets or game mounts. A game entity usually contains multiple visual regions that can be independently configured, such as the body parts of a character, and different parts of equipment and vehicles, etc. Users can achieve a high degree of customized configuration through painting, patterns and decals, etc. In the traditional implementation scheme, a set of special effects that can be selected is usually displayed when the player enters the configuration interface, and after the player makes a selection, the resource loading and graphic rendering operations required for applying the special effect are performed. In this process, if there are configuration conflict restrictions between different special effects, the verification logic is often handled outside or after the main selection and application process.

[0003] However, this method has certain limitations in its running logic. On the one hand, since a very large set of optional data may be loaded or prepared in the initial stage of game loading, and a complex global verification needs to be triggered independently after each application operation to update the interface state, this can easily lead to problems such as sluggish interface response and unsmooth operation feedback, resulting in network lag and unstable game frame rate. On the other hand, after applying a special effect resource and updating the game entity, since recalculating and updating the global available resource list is often treated as an independent post-processing operation, it can lead to a loss of synchronization between the visual state of the entity model and the logical state of the configuration interface within a time window. After the user successfully applies a new appearance, the visual representation of the game entity changes immediately, but the optional list on the interface may not be refreshed immediately, which can lead to technical defects such as inconsistency between the front-end and back-end states or inconsistency between the final rendering effect and the design rules, thereby significantly affecting the player's gaming experience.

[0004] Therefore, the existing game configuration system still has a lot of room for improvement in providing players with a smoother and more abundant special effect configuration experience. SUMMARY

[0005] The present application aims to solve the above problems and provide an entity special effect configuration method and its corresponding device, equipment, non-volatile readable storage medium, and computer program product.

[0006] According to one aspect of the present application, an entity special effect configuration method is provided, comprising: In response to a special effect configuration request for a game entity, a current available special effect configuration list is obtained, wherein the special effect configuration list is a special effect identifier set obtained by screening a special effect configuration identifier library based on at least one special effect configuration rule associated with the game entity; In response to an identifier selection event of a first special effect identifier in the special effect configuration list, a resource application request corresponding to the first special effect identifier is generated based on the event; According to the special effect configuration rule, an updated special effect identifier corresponding to the resource application request is obtained, and an association mapping relationship between the first special effect identifier and a corresponding special effect configuration part of the game entity is determined; Based on the updated special effect identifier and the special effect configuration rule, the special effect configuration list is updated, a corresponding first special effect resource is obtained according to the association mapping relationship, and an image of the special effect configuration part in a game scene is updated based on a special effect rendering image corresponding to the first special effect resource.

[0007] According to another aspect of the present application, an entity special effect configuration device is provided, comprising: A request response module is configured to obtain a current available special effect configuration list in response to a special effect configuration request for a game entity, wherein the special effect configuration list is a special effect identifier set obtained by screening a special effect configuration identifier library based on at least one special effect configuration rule associated with the game entity; An identifier selection module is configured to generate a resource application request corresponding to a first special effect identifier in the special effect configuration list based on an identifier selection event of the first special effect identifier; An association mapping module is configured to obtain an updated special effect identifier corresponding to the resource application request according to the special effect configuration rule, and determine an association mapping relationship between the first special effect identifier and a corresponding special effect configuration part of the game entity; A special effect updating module is configured to update the special effect configuration list based on the updated special effect identifier and the special effect configuration rule, obtain a corresponding first special effect resource according to the association mapping relationship, and update an image of the special effect configuration part in a game scene based on a special effect rendering image corresponding to the first special effect resource.

[0008] According to another aspect of the present application, an entity special effect configuration device is provided, comprising a central processing unit and a memory, wherein the central processing unit is used to call a computer program stored in the memory to execute the steps of the method described in the present application.

[0009] According to another aspect of this application, a non-volatile readable storage medium is provided, which stores a computer program implemented according to the entity effect configuration method in the form of computer-readable instructions, wherein the computer program, when invoked by a computer, executes the steps included in the method.

[0010] According to another aspect of this application, a computer program product is provided, comprising a computer program / instructions that, when executed by a processor, implement the steps of the method.

[0011] First, this application reduces the amount of data that needs to be processed during the initial stage of resource loading and each interaction by retrieving only the set of available effect identifiers dynamically filtered based on the current configuration rules when responding to configuration requests, instead of loading all optional data. This effectively reduces the instantaneous load on memory and network resources, thereby improving the loading speed of the configuration interface and the smoothness of operation response, which helps to improve the frame rate stability of game operation and further optimizes the interface lag problem caused by the complexity of data in traditional methods. Second, this application tightly integrates and sequentially links the processing of resource application requests with the updating of the configuration list. After responding to the user selection event and determining the mapping relationship between the effect and the entity part, it can synchronously obtain the updated effect identifiers and refresh the available list in real time according to the same set of configuration rules. This ensures the continuity from the user confirming the application of the effect to the update of the interface list status, eliminates the time difference between visual feedback and the interface logical state, and solves the technical defect of temporary asynchrony between the front-end and back-end states caused by asynchronous post-processing in traditional solutions, thereby improving the reliability of the system state. Furthermore, this application establishes a real-time linkage mechanism between special effects identifiers, configuration rules, resource loading, and part mapping, enabling the entire configuration process to form a highly efficient and collaborative closed loop. This not only ensures that special effects resources are accurately matched and rendered to the target parts, achieving precise updates to visual effects, but also ensures that subsequent user-accessible options always conform to the latest configuration constraints through rule-driven real-time list updates. Therefore, this application improves the efficiency of the configuration process and the smoothness of the interface while avoiding rendering errors or rule conflicts that may be caused by inconsistent states, thus providing users with a more consistent, reliable, and personalized configuration experience that meets design expectations. Attached Figure Description

[0012] Figure 1 This application provides an exemplary network architecture; Figure 2 A flowchart illustrating one embodiment of the entity special effects configuration method of this application; Figure 3 This is a schematic block diagram of the physical special effects configuration device of this application; Figure 4This is a schematic diagram of the structure of a physical special effects configuration device used in this application. Detailed Implementation

[0013] The technical solution of this application can be widely applied to various network architectures to adapt to different types and scales of game applications. In a network architecture such as... Figure 1 In the typical network architecture shown, the player's terminal device accesses the game service cluster via the network. This cluster consists of multiple game servers 81. A microservice architecture manages and maintains the operational resources of these game servers 81, providing multiple service instances. Each service instance is responsible for a different service. For example, some service instances can be used to maintain the front-end service for the terminal device 80 to access the game, while others can each be responsible for the gameplay service of one or more maps in the game's world map, providing players with corresponding map dungeon gameplay. The player's terminal device 80 has a computer program product installed and running according to the character interaction control method of this application, or the terminal device can be connected to a cloud server container, where the computer program product runs. After the computer program product runs, it accesses the game service cluster, enabling the player to control their in-game character through the terminal device, interact with various service instances of the game, and explore and interact with different maps.

[0014] Each service instance can maintain a real-time connection with the player's terminal device 80 via the network, handling various events and interactions in the game, such as player character movement, attacks, and item usage. The server provides necessary data support to the terminal device to ensure smooth game operation. This data includes, but is not limited to, map model datasets, which contain map model data for each map and resource model data for its scene resources, such as buildings, player character models, non-player character models, and various other creature or non-creature models, used by the terminal device 80 to render and generate corresponding real-time images. Based on the received map model dataset, the terminal device 80 can generate high-quality real-time images and display them in the graphical user interface, presenting the corresponding game scene to the player. Players obtain visual information about the game through real-time images of the game scene, thereby implementing gameplay.

[0015] This application not only applies to the gaming experience for single players but can also be extended to multiplayer online game environments. In multiplayer games, multiple players' (users') terminal devices simultaneously connect to the game service cluster. Each service instance needs to handle interaction requests from multiple players and update the game status in real time. This application ensures that each player receives consistent and high-quality character interaction control in multiplayer game scenarios, while optimizing the resource utilization of servers and terminal devices and improving the overall operational efficiency of the game system.

[0016] In an exemplary application scenario of this application, consider a massively multiplayer online role-playing game (MMORPG) where players can freely explore a vast open-world map and control their character to enter various specific dungeon maps to complete quests. In this game, the player character can frequently switch between different maps, such as switching from a bustling city map to a mysterious dungeon map, or from one room to another.

[0017] The technical solution of this application can be applied to various distributed software systems that support online interaction and virtual avatar customization. Its typical deployment environment includes clients and servers interconnected via a network. In an exemplary architecture, the client, as the terminal for user interaction, is mainly responsible for the presentation of the graphical user interface, the capture of local input events, and the real-time rendering of the game scene; while the server, as the central hub for data and rules, is responsible for maintaining a globally consistent resource identifier library, managing complex configuration constraint logic, and coordinating the state synchronization between multiple clients. Therefore, this architecture is suitable for application scenarios such as large-scale multiplayer online games and virtual social platforms that require real-time and compliant control over a large amount of user-generated content.

[0018] In an exemplary application scenario, a user can interact with a game entity in a virtual environment, consisting of multiple independently configurable parts, such as a vehicle, character, or equipment. Different parts of each game entity can be associated with different visual effects. These effects exist as digital resources and are referenced and managed through unique effect identifiers. A server-side defined set of effect configuration rules can be used to constrain the combination logic between different effects, such as mutual exclusion based on copyright, visual conflicts, or functional limitations. When a user wishes to personalize the entity's appearance, the game system will work collaboratively according to this architecture to complete the entire process from interface operation to visual updates.

[0019] In one embodiment of this application, a game entity refers to an object in a virtual environment that can be independently identified and manipulated. Its visual model typically consists of multiple logical parts. Special effects configuration rules are a set of logical conditions defining the associations and constraints between special effects identifiers or between special effects identifiers and entity states; these rules are the core decision-making basis driving the entire configuration process. Special effects identifiers are unique references associated with specific visual resource data, and their collection constitutes the system's special effects configuration identifier library. Part mapping relationships establish corresponding links between special effects identifiers and specific logical parts of game entities, ensuring that visual resources can be accurately applied to target areas. These concepts collectively constitute the technical basis of the specific implementation methods described below.

[0020] After providing a general overview of the exemplary network architecture and application scenarios of this application, as well as some basic concepts, the following will continue to describe several specific embodiments of this application.

[0021] Please see Figure 2 The entity special effects configuration method of this application, in some embodiments, includes the following steps: Step S3100: In response to a special effects configuration request for a game entity, obtain a list of currently available special effects configurations, wherein the special effects configuration list is a set of special effects identifiers obtained by filtering a special effects configuration identifier library based on at least one special effects configuration rule associated with the game entity.

[0022] When a player controls a game character to move around in a virtual game world, the game screen typically displays the player's character and other entities, such as the player's mount, vehicle, or pet; in racing games, this could be the player's vehicle, aircraft, or other means of transportation; in strategy games, it could be combat units commanded by the player. When a player wants to interact with a specific game entity, they can indicate their intention by pressing a preset interaction key or clicking a specific interactive control on the screen. Once this interaction intention is captured by the game system, it can switch from the current display of the game world to a user interface focused on managing that game entity. This user interface can specifically display changes to the entity's appearance, modifications to its structure, or other custom configurations. When a player performs an action to enter this interface, that action is recognized as a request for special effects configuration for that game entity.

[0023] In this implementation, the special effects configuration rules are a set of predefined logical conditions on the game server side, used to manage the compatibility and availability of special effects. These rules can take various forms, such as rules based on digital rights management (DRM) stipulating that paint jobs from different copyright collaborations cannot be equipped simultaneously; rules based on visual conflict stipulating that certain large-pattern paint jobs cannot coexist with detailed paint jobs on specific parts; or rules based on game progress stipulating that certain advanced paint jobs can only be unlocked after players achieve specific accomplishments. All these rules together constitute the constraints that determine which special effects a player can use in the current state. The special effects configuration identifier library is a collection stored in the server database, containing unique identifiers corresponding to all special effects available to players in the game. Each identifier points to a set of specific graphic resource data, such as texture files and material parameters. The game system can process only the identifier itself, rather than directly processing the massive data resources it points to.

[0024] When the game system responds to the effect configuration request, the client sends a network request to the server. This request includes at least the unique identifier of the current player and the unique identifier of the game entity to be configured. Upon receiving the request, the server first determines the subset of rules applicable to the entity type based on the entity identifier, and then retrieves all effect identifiers already owned by the player, as well as any effect identifiers that may currently be equipped on the entity, based on the player identifier. Subsequently, the server uses this information as input to run the aforementioned effect configuration rules for logical filtering. The filtering process essentially uses the player's owned effect identifier library as the complete input set and excludes identifiers that are unavailable due to conflicts with currently equipped effects or because the player has not met the unlocking conditions.

[0025] Ultimately, the remaining effect icons after filtering constitute a dynamically generated list of currently available effect configurations that is only valid for the current player and the current entity state. The server sends this list data back to the client, which then parses it and visualizes it in a custom interface, such as presenting it to the player in the form of an icon grid or list. This list is not static; it updates dynamically as the player's equipment status changes, ensuring that all available options presented on the interface always conform to the rules and logic defined in the backend.

[0026] In another implementation, the game client stores locally the special effects configuration rules associated with the current game entity and the special effects configuration identifier library that the player already owns. When a special effects configuration request is received, the client directly performs real-time filtering and calculation on the locally stored special effects configuration identifier library according to the local special effects configuration rules, and excludes identifiers that conflict with the current state of the entity or do not conform to the rule constraints, thereby generating and displaying the list of currently available special effects configurations locally in real time.

[0027] Step S3200: In response to the identifier selection event of the first special effect identifier in the special effect configuration list, generate a resource application request corresponding to the first special effect identifier based on the event.

[0028] In the custom configuration interface of the game screen, the list of currently available special effects configurations can be presented in a visual form, such as a row of scrollable icons or a grid panel. When the player explicitly selects a specific special effect icon from the list by hovering the cursor, clicking or touching, the game system can trigger an identifier selection event for the unique code associated with that special effect. The unique code of the selected special effect is called the first special effect identifier. The player can confirm the selection by pressing the confirmation button or double-clicking the icon.

[0029] Once the identifier selection event is captured by the game system, the client can begin collecting the data necessary to generate the resource application request. This data may include a unique player identifier to identify the current operator, a unique game entity identifier to determine the configuration target, the entity's currently equipped effect identifiers, and the first effect identifier just selected. Additionally, the data may include effect identifiers with the same preset tags as the first effect identifier. The client retrieves this data from its local cache or the current interface state. Then, according to a preset data structure format, the client assembles the collected information into a complete data packet, which constitutes the payload of the resource application request.

[0030] In one implementation, the structure of the resource application request can clearly convey to the server the core intent of "which player", "which entity", and "which effect to apply". After the corresponding data packet is assembled, the client will call the corresponding application interface through its network communication module to send the encapsulated resource application request to the game server to request the server to perform the corresponding operation.

[0031] In one implementation, to assist the server in making more accurate mutual exclusion judgments, the resource application request may also include a list of other special effect identifiers currently equipped by the game entity or the client's local rule version identifier. For example, if the current game entity is a motorcycle, the client may attach all the paint scheme identifiers currently equipped on the front, rear, and sides of the motorcycle when sending the request, so that the server can perform global rule calculations based on the complete state.

[0032] Step S3300: Obtain the updated effect identifier corresponding to the resource application request according to the effect configuration rules, and determine the association mapping relationship between the first effect identifier and the corresponding effect configuration part of the game entity.

[0033] After parsing the resource application request and obtaining the first effect identifier, the game server can determine other effect identifiers that need to be changed due to the application operation. The set of these identifiers can be used to construct the update effect identifier, determine which specific parts of the game entity the visual resource corresponding to the first effect identifier should be attached to, and establish a corresponding association mapping relationship.

[0034] To determine which effect identifier to update, the server first retrieves all effect identifiers currently equipped by the game entity. Then, the server calls the effect configuration rules associated with that entity, using the first effect identifier and the entity's currently equipped effect identifiers as input for rule calculation. The corresponding rules can include forward mutual exclusion checks, which identify all other identifiers explicitly mutually exclusive with the first effect identifier in the effect configuration rules. For example, if the first effect identifier is "Brand A Theme Paint Job," and the rule defines it as mutually exclusive with "Brand B Theme Paint Job," then the "Brand B Theme Paint Job" identifier will be included in the update effect identifier set, and its state needs to be updated to unavailable. Rules can also include reverse release checks, which analyze currently equipped effect identifiers. Since the first effect identifier is about to be equipped, this may release mutual exclusion locks triggered by certain existing equipment states. For example, if the game entity is currently equipped with "Fire Emblem Paint Job," and the paint job rule specifies that it is mutually exclusive with "Ice Emblem Paint Job," causing the latter to remain disabled. If the first effect identifier is "General Neutral Coating," which is not mutually exclusive with either of the other two, then when "Fire Emblem Coating" is replaced by "General Neutral Coating," "Ice Emblem Coating" should be undisabled because the mutual exclusion source disappears. Therefore, the "Ice Emblem Coating" identifier will also be included in the updated effect identifier set, and its status needs to be updated to available. The server calculates by executing the above rules and finally summarizes a set containing all effect identifiers that need to change their available status, i.e., the updated effect identifiers.

[0035] In determining the association mapping relationship, the server queries its predefined resource type attribute based on the first effect identifier. This attribute defines the logical attachment point type of this effect resource on the game entity model. For example, the attribute of a paint job resource might be defined as "applicable to flat areas." Simultaneously, based on the unique identifier of the game entity, the server obtains all configurable logical parts of the entity model and their attributes. For example, parts such as "left side panel," "right side panel," and "upper surface of the hood" might be marked as "flat areas." The server then executes matching logic, comparing the resource type attribute of the first effect identifier with the attributes of each logical part of the entity. Logical parts with matching attributes are identified as the target effect configuration parts for that effect. Finally, the server generates and records a list of correspondences between the first effect identifier and one or more target effect configuration part identifiers, thus completing the establishment of the association mapping relationship.

[0036] In one implementation, the calculation of updating effect identifiers can be based on more refined rules. For example, the mutual exclusion rule is not global but related to the location. So, assuming the rule stipulates that "front paint A" and "side paint B" are mutually exclusive, when "side paint B" is applied, only the "front paint A" identifier needs to be added to the update set, while the paint of other locations is not affected.

[0037] In one implementation, when establishing the association mapping relationship, if certain effect identifiers are directly associated with specific model bone names or mesh names in the resource definition, such as "left front wheel hub decal", then the server does not need to perform attribute matching when establishing the mapping. It can directly bind the effect identifier to the part identifier named "left front wheel hub" in the entity part data.

[0038] Step S3400: Update the special effect configuration list based on the updated special effect identifier and the special effect configuration rules, obtain the corresponding first special effect resource according to the association mapping relationship, and update the image of the special effect configuration part in the game scene based on the special effect rendering image corresponding to the first special effect resource.

[0039] Since the first effect identifier, when applied to a game entity, might replace some existing effects on that entity, the corresponding effect configuration rules must be updated based on the other effects currently configured on the game entity and this new first effect. Therefore, after processing and generating the updated effect identifiers and their associated mappings, the server sends this data back to the requesting client. Upon receiving this data, the client can then execute subsequent UI updates and visual rendering processes.

[0040] The client first needs to update its locally maintained list of effect configurations based on the received update effect identifiers. Each identifier in this set includes its target state that needs to be changed. The client searches its memory or cache for entries in the currently displayed effect configuration list that match these identifiers and synchronizes the state of these entries with the target state sent by the server. If the update effect identifiers include identifier X and its state "disabled", the client grays out or adds a disabled mark to the icon corresponding to identifier X in the list, making it unclickable. If the update effect identifiers include identifier Y and its state "undisabled", the client restores the icon corresponding to identifier Y to normal display and allows interaction.

[0041] Subsequently, the client can further load resources and update graphics based on the association mapping relationship issued by the server. Since the association mapping relationship clarifies which one or more effect configuration parts of the game entity the first effect identifier should be applied to, the client can find the corresponding game entity instance in the game scene according to the target part identifier in the mapping relationship, and locate the specific part node or rendering component on the entity model. At the same time, the client initiates a resource loading request to the game's content management system based on the first effect identifier.

[0042] The first special effects resource can be a specific graphics data asset pointed to by the first special effects identifier, such as a texture set containing diffuse and normal maps and material parameters that define its visual performance characteristics. After the client loads the corresponding special effects resource data, it can inject it into the graphics rendering control unit associated with the previously located entity part, such as replacing the texture on the original material ball or modifying specific parameters of the shader.

[0043] Once the first special effects resource is successfully applied to the corresponding special effects configuration part of the game entity, the client will drive the graphics rendering engine to redraw the model of that part. The graphics rendering engine will recalculate the pixel color, lighting response and other visual effects of that part based on the new resource data, and integrate the results into the current game scene. As a result, players can immediately observe in the custom interface or the game world scene that the appearance of a specific part of the game entity has been updated to the rendered image after the application of the new special effects. For example, the panel on the side of the motorcycle displays a brand new pattern and texture.

[0044] In one implementation, updating the effects configuration list can be performed in parallel with resource preloading to improve efficiency. While updating the list status according to the update flag, the client can immediately begin asynchronously loading the first effects resource based on the associated mapping relationship. This allows the preparation of the first effects resource to occur simultaneously with the interface refresh, further shortening the overall waiting time for the player from clicking confirm to seeing the final effect. Furthermore, regarding the application method of effects resources, for example, for some simple color-changing effects, the corresponding first effects resource may only be a set of RGB color values. When applying it, the client only needs to assign the color values ​​to the corresponding color attribute of the material sphere of the entity part, without loading external texture files.

[0045] As can be seen from the above embodiments, the technical steps of this embodiment can effectively overcome the technical defects of traditional solutions, such as slow interface response, inconsistent states, and display errors. First, by dynamically filtering and issuing a set of available effect identifiers based on the server-side effect configuration rules only when needed, this application can reduce the amount of data initially loaded by the client, avoiding interface lag and memory pressure caused by processing a large set, thereby improving the loading speed of the configuration interface and the smoothness of operation response. Second, by integrating effect selection, rule verification, and state update into a coherent closed-loop process, when the player selects an effect, the server-side centralized rule calculation is immediately triggered, determining in real time all relevant effect identifiers and precise part mapping relationships that need to change the state due to this operation, ensuring the atomicity and global consistency of logical state changes. Furthermore, the client synchronously refreshes the visual state of the local effect configuration list based on the updated data issued by the server, ensuring that the available options displayed on the interface are always synchronized with the latest rules in real time, solving the problems of delayed interface feedback or disconnect between front-end and back-end states. Simultaneously, based on precise mapping relationships, the client can efficiently locate and load corresponding graphics resources and accurately apply them to designated parts of game entities, driving the rendering engine to immediately update the visual appearance in the scene. Therefore, this application not only ensures low latency from user operation to visual feedback, providing a smooth and consistent personalized configuration experience, but also ensures the compliance and display accuracy of effects combinations across a massive number of clients through centralized rule management. This improves the game system's response efficiency and reliability while providing users with highly consistent and instantly visible custom effects.

[0046] Based on any embodiment of the method in this application, in response to a special effects configuration request for a game entity, a list of currently available special effects configurations is obtained, wherein the special effects configuration list is a set of special effects identifiers obtained by filtering a special effects configuration identifier library based on at least one special effects configuration rule associated with the game entity, including: Step S3110: In response to the configuration interaction operation triggered by the special effect configuration entry for the game entity in the game interface, the special effect configuration request is generated based on the player identifier of the game player and the entity special effect identifier of the game entity, so that the client sends the special effect configuration request to the server.

[0047] In the game interface, the effects configuration entry can be a pre-defined, interactive visual element. This entry can take various forms, such as an interactive hotspot attached to a 3D model of a game entity, displaying a tooltip icon when the player character approaches, a fixed button on the user interface, or integrated into a contextual menu. By executing a specific input command, such as pressing a designated key, clicking the button, or selecting a corresponding menu item, the player completes a configuration interaction for this entry. This action is captured by the client program and interpreted as the player's explicit intention to configure effects for that specific game entity.

[0048] The client then generates a structured network request based on this intent. First, it extracts the unique player identifier corresponding to the account currently controlling the game character from the local session state. This identifier is assigned by the server and stored on the client when the user logs in. Simultaneously, the client needs to determine the target object of this operation, i.e., obtain the unique entity identifier of the game entity the player is pointing to. This identifier can be read directly from the entity the player is currently focusing on, or it can be obtained from the parameters passed when opening the configuration interface. The client program uses the corresponding player identifier and entity identifier as core parameters and assembles them according to the data format agreed upon with the server. The content contained in the assembled data packet represents the complete context of this request, clearly defining "who" wants to configure "which item." This data packet can then be defined as an effects configuration request.

[0049] After generating the special effects configuration request, the client can send the data packet to the game server through its integrated network communication module. The sending process can call a well-encapsulated network application interface, which is responsible for handling the underlying connection management, data serialization and transmission protocol, and send the special effects configuration request to the logical service endpoint on the server that is dedicated to handling custom functions, thereby formally initiating a remote service call.

[0050] Step S3120: The server determines the applicable identifiers corresponding to the player identifier and the entity effect identifier contained in the effect configuration request based on the effect configuration rules, and sends the effect identifier set composed of all the applicable identifiers to the client.

[0051] After receiving a special effects configuration request from a client, the server first parses the request, extracting the key player and entity identifiers. These two identifiers serve as the basis for all subsequent data queries and logical judgments by the server, respectively indicating the source player of the request and the specific game entity to be manipulated. Next, the server executes the core data processing flow, which determines the currently available set of special effects identifiers based on the special effects configuration rules. These rules are predefined on the server side and are used to manage the availability and mutual exclusion of all special effects within the system. The specific forms of these rules can be diverse. For example, they can be a mutually exclusive list based on copyright ownership, stipulating that themes from different commercial partners cannot appear on the same entity simultaneously; they can also be a design rule based on visual hierarchy, stipulating that large-area coverage paint and small-area detail decals have an overlapping relationship and cannot be displayed simultaneously; or they can be an unlocking condition based on game progress, such as requiring players to first achieve a specific ranking in a competition before unlocking the corresponding champion paint. The corresponding special effects configuration rules can exist in the server's database or file system in the form of data tables, configuration files, or script logic.

[0052] In this implementation, during the determination of applicable identifiers, the server first queries the player data database based on the extracted player identifiers to find all effect identifiers that the player has acquired and has the right to use, forming a player-held identifier library. Simultaneously, based on the extracted entity identifiers, the server queries the entity state database to find the effect identifiers currently equipped on each part of the entity, forming the entity's current state set. Then, the server uses the player-held identifier library as the original complete set to be filtered, and executes filtering logic using effect configuration rules and the entity's current state set as joint filtering conditions. This filtering logic evaluates each identifier in the original complete set, checking whether it conforms to all relevant rules. Specific evaluation content includes, but is not limited to: checking whether the identifier is mutually exclusive with any identifier in the entity's current state set; checking whether the identifier itself has unmet unlocking prerequisites such as player level and task completion status; and checking whether the application of the identifier would violate the restriction rules based on the number of entity parts. Only when an identifier passes all rule checks, does not conflict with the current entity state, and its own unlocking conditions are met, will it be determined as an applicable identifier. Finally, all the approved and applicable identifiers are aggregated, forming a real-time and dynamic set of special effects identifiers.

[0053] After calculating the set of effect identifiers, the server needs to return it to the client. The server-side program serializes the data corresponding to the effect identifier set, converting it into a standardized data format suitable for network transmission. Then, the server sends out the encapsulated data packet through the established network connection channel with the requesting client. After receiving this data packet, the client can deserialize and parse it to reconstruct the list of effect identifiers sent by the server, and update the user interface accordingly, displaying all currently available and rule-compliant effect items to the player.

[0054] Through the above implementation method, this application first establishes a clear and efficient data channel at the initial stage of the player initiating configuration intent. The client accurately captures the interactive operation and immediately encapsulates the request containing key identity information and sends it to the server. After receiving the request, the server performs authoritative calculations based on centrally managed special effect configuration rules. By querying the player's status and the entity's current equipment, it dynamically filters out the set of applicable identifiers that meet all constraints. This places the complex rule logic and status verification entirely on the server side for unified execution, ensuring the global consistency and authority of the calculation results, while avoiding the large amount of data overhead and computational delays caused by the client needing to load and process the entire special effect identifier library. Furthermore, the server distributes the filtered set of special effect identifiers to the client, enabling the client interface to quickly respond and display an option list that accurately adapts to the current status, improving the smoothness of interface rendering and operation, effectively alleviating network transmission pressure and local processing burden, realizing a fast, accurate, and state-synchronized process from player operation to interface display, and optimizing the response efficiency and user experience of the configuration system.

[0055] Based on any embodiment of the method in this application, in response to an event selecting an identifier for a first effect identifier in the effect configuration list, a resource application request corresponding to the first effect identifier is generated based on the event, including: Step S3210: In response to the identifier selection event triggered by the selection operation of the first effect identifier in the effect configuration list in the game interface, obtain the configuration status data corresponding to the first effect identifier and the entity effect identifier corresponding to the effect resource currently configured by the game entity.

[0056] When a player interacts with the game's effects configuration interface, the interface displays a list of effects configurations in the form of a visual array of elements. For example, each available effect may be presented as a row of scrollable icons or a dense grid of thumbnails. Players can make a selection by moving the cursor and clicking on an icon or by directly touching an option on the screen. This specific user interaction is captured by the game interface's input listening module and immediately converted into an internal system event. This event is defined as an identifier selection event. The core data payload of the identifier selection event is the unique code bound to the icon selected by the player. This code is called the first effect identifier.

[0057] In this implementation, after the identifier selection event is triggered, the game system needs to prepare necessary context information for subsequent requests to the server or local logical judgments. Therefore, the game system needs to obtain two types of key data at this time. The first type is the configuration status data corresponding to the first effect identifier. The configuration status data describes the attributes of the effect itself and its current state. Its content includes, but is not limited to, the applicable part type of the effect, the copyright or theme group it belongs to, and the definition of its mutual exclusion relationship with other effects. The purpose of obtaining this data is to enable the server or client to perform rule calculations based on these inherent attributes. The game system uses the first effect identifier as a key to query the effect attribute configuration table pre-loaded from the server to obtain this data. For example, when a player selects a paint job representing a brand co-branded logo, the game system can find out that the paint job's configuration status data contains its brand group information by querying.

[0058] The second type of data to be acquired is the entity effect identifier corresponding to the effect resources currently configured for the game entity. An entity effect identifier refers to the set of unique identifiers for each effect already active on various parts of the game entity. The purpose of acquiring these entity effect identifiers is to accurately reflect the overall effect configuration status of the game entity to the server, allowing the server to perform a global mutual exclusion check based on the relationship between all existing configured effects and the desired new effects. The game system can read the list of effect identifiers attached to all configured parts from the memory object responsible for managing the state of the game entity instance, thus obtaining the entity effect identifier set. For example, if a motorcycle entity currently has armor plating on its front bumper and paint scheme B on its left and right side skirts, then the entity effect identifier set obtained by the game system at this moment will include the identifiers for armor plating and paint scheme B.

[0059] Step S3220: On the client side, corresponding resource configuration data is generated based on the first special effect identifier, the player identifier, and the entity special effect identifier. The resource application request is generated based on the resource configuration data and the configuration status data, so that the client can send the resource application request to the server.

[0060] After capturing the identifier selection event and collecting the necessary data on the client side, the first step is to integrate key information to generate resource configuration data. Resource configuration data is a structured data block whose core function is to completely encapsulate the player's intent and current state for precise server processing. This data block can contain at least three elements: first, the unique code representing the effect selected by the player, i.e., the first effect identifier; second, the player account credentials used to authenticate the source of the request, i.e., the player identifier; and third, a list of codes reflecting all the effects currently equipped on the game entity, i.e., the entity effect identifier set. For example, when a player selects a new rear spoiler decal for a sports car, the resource configuration data includes the identifier of this new decal, the player's account ID, and a list of identifiers for all other decals and paint jobs currently installed on the car's body, wheels, etc.

[0061] After generating resource configuration data, the client combines it with previously acquired configuration status data and assembles it into the final network communication message, which corresponds to obtaining the resource application request. The configuration status data provides its own rule attributes, such as the applicable entity and its copyright category. Following a pre-agreed data contract format with the server, the client program uses the resource configuration data as the main framework and incorporates related configuration status data as auxiliary attribute fields, forming a complete request payload containing the operational intent and rule context. Once assembled, the client can invoke its network communication services, such as using a dedicated API module responsible for interacting with the game server, to send the serialized resource application request data packet through an active network connection. This sending action is typically a remote call to a specific processing endpoint on the server. Thus, the client completes the process of transforming the player's local selection into a formal request carrying sufficient contextual information for the server to make an authoritative decision.

[0062] The above embodiments ensure that the state information used by the server for rule calculation is comprehensive and real-time by accurately responding to interface operations and instantly obtaining the attribute data of the first special effect identifier and the complete set of equipment status identifiers of the entity. This avoids judgment errors caused by missing or outdated information from the source. Based on this, the client integrates the core operation intent, player identity, and precise context state into structured resource configuration data and further encapsulates it into resource application requests that conform to network transmission standards. This provides a technical bridge for transforming user interaction logic into standardized service calls. It not only ensures that the request payload sent to the server contains all necessary and unambiguous decision information, enabling the server to perform accurate and efficient rule verification and state calculation, but also reduces unnecessary interaction rounds and redundant data transmission between the client and server through one-time encapsulation and single-transmission optimization. This reduces the impact of network latency on operational smoothness and improves the response speed and processing reliability of the entire configuration process.

[0063] Based on any embodiment of the method in this application, obtaining the updated effect identifier corresponding to the resource application request according to the effect configuration rules, and determining the association mapping relationship between the first effect identifier and the corresponding effect configuration part of the game entity, includes: Step S3310: The server receives and parses the resource application request, and obtains the first special effect identifier, the player identifier, and the entity special effect identifier contained in the request.

[0064] When a client sends a resource application request over the network to the server, it is first received by the network service or application interface endpoint on the server responsible for handling such requests. This endpoint can be a service process listening on a specific port or a specific routing address defined on the server. The raw data received by the server is a data stream encapsulated according to a specific protocol format. The server then immediately parses this data stream. The purpose of parsing is to extract a few key data items necessary for subsequent logical calculations from the structured request payload. The parsing process follows a data exchange format pre-agreed between the client and the server. For example, if the request format is JSON, the server will call a JSON parsing library to convert the received string into an in-memory object or dictionary, and then retrieve the corresponding value by accessing the specified key. If the request uses a custom binary protocol, the server will read the corresponding fields from the byte stream according to a predefined length and order.

[0065] Through parsing, the server clearly obtained three core data points. The first is the first effect identifier, which is a string or number code that uniquely represents the specific effect that the user wants to apply. The second is the player identifier, which is a credential used to uniquely identify the user account that initiated the request, such as a user ID or account name. The third is the entity effect identifier, which is usually a set of identifiers in the form of a list or collection, representing the codes of all effects that have been configured and are active on various parts of the target game entity at the time the request is initiated.

[0066] Step S3320: Based on the special effect configuration rules, determine the mutual exclusion relationship between the first special effect identifier and the entity special effect identifier, and select the identifier whose status needs to be changed from the special effect configuration identifier library according to the determination result, so as to form the updated special effect identifier.

[0067] After acquiring key data, the server can further determine mutual exclusion relationships based on the effect configuration rules to ascertain which other effects' availability needs to be changed for this application. Mutual exclusion determination involves the server inputting the first effect identifier and each identifier in the entity's effect identifier set into a pre-loaded effect configuration rule engine for logical comparison. Since effect configuration rules define compatibility relationships between different effect identifiers or combinations of effect identifiers, for example, one rule might stipulate that an effect identified as "Paint Series A" is mutually exclusive with an effect identified as "Paint Series B" and cannot be equipped simultaneously; another rule might stipulate that when an effect identified as "Decal_Event Sponsor X" is equipped, an effect identified as "Decal_Event Sponsor Y" will be automatically disabled. The server can then determine, one by one, whether such conflict relationships exist between the first effect identifier and each currently equipped effect identifier of the entity, according to the effect configuration rules.

[0068] Based on the mutual exclusion determination, the server filters out those icons whose status needs to be changed from the entire effect configuration icon library. One filtering process is direct mutual exclusion leading to disabling, meaning that the addition of the first effect icon causes some previously available effects to become unavailable. For example, if the first effect icon is "Fire Theme," and the rule indicates that it is mutually exclusive with "Frost Theme," then regardless of whether "Frost Theme" is currently equipped on the entity, its status needs to be marked as disabled, and therefore it is filtered out. Another filtering process is release due to mutual exclusion removal, meaning that because the first effect icon replaces a certain existing equipment, the blocking of some other effects by that existing equipment is lifted. For example, if an entity was originally equipped with "Dark Style," and the paint rule blocked "Light Style," when the user chooses to replace "Dark Style" with the new "Neutral Style," the blocking condition of "Light Style" disappears, and its status should change from disabled to available, so it is also filtered out.

[0069] The server aggregates all effect identifiers that need to change state due to the above two situations, whether from available to disabled or from disabled to available, into a set. This set is called the update effect identifier. It can be accurately described as all effect items that need to be visually updated on the client interface to maintain rule consistency. The final set of update effect identifiers may include: identifier A, state needs to be changed to disabled; identifier B, state needs to be changed to available.

[0070] Step S3330: Based on the predefined part configuration information of the game entity, determine at least one target part identifier that matches the type of special effect resource represented by the first special effect identifier.

[0071] After determining the updated effect identifier, the server uses the predefined part configuration information of the game entity to determine the specific attachment location of the effect resource to be applied. Part configuration information can be structured data stored on the server side, bound to a specific game entity type. It defines all logical areas of the entity model that can be configured with effects; these logical areas are called parts of the entity model. Each part has a unique part identifier. For example, for a motorcycle entity, its part configuration information might define the following parts: front fairing, left side panel, right side panel, rear spoiler, seat, etc., each with a corresponding identifier. For a suit of armor, its parts might include a helmet, chest plate, gauntlets, leg guards, etc. Part configuration information can exist in the form of a data table or configuration file, thus clearly defining the name, identifier, and possible type label of each part.

[0072] Furthermore, the server needs to match the special effect resource type represented by the first special effect identifier with the aforementioned part configuration information. The special effect resource type is an attribute describing the artistic and technical applicability of the special effect. It can be a simple label, such as applicable to a flat surface or a window area, or a set of more specific constraints applicable to a rectangular area with a width greater than its height. The server can obtain its resource type by querying the resource definition data corresponding to the first special effect identifier. The server first loads the part configuration information corresponding to the target game entity, obtains a list of all configurable parts and their attributes, and then compares the resource type attribute of the first special effect identifier with the attributes of each part in the list. The matching logic can be based on tag matching, that is, each part in the part configuration information has a preset type tag, and the server looks for parts whose tags match the special effect resource type. For example, if the resource type of the first special effect identifier is side painting, the server looks for parts in the part configuration information whose tags correspond to side painting, such as the left panel and the right panel; or it can be based on precise matching of geometric or functional names, for example, if the special effect resource type directly specifies the bone name of the target part, the server directly looks for parts in the part configuration information whose identifiers are the same as the bone names.

[0073] The server will then find one or more matching parts, and the identifiers of these parts will be determined as target part identifiers. For example, for a special effect of a general planar area resource type, the server can match multiple part identifiers such as hood and door. Finally, the server outputs a list containing at least one target part identifier, which indicates which specific locations on the game entity the visual resource represented by the first special effect identifier should be configured.

[0074] Step S3340: Establish the association mapping relationship between the first special effect identifier and the at least one target part identifier, so that the server synchronously sends the updated special effect identifier and the association mapping relationship to the client.

[0075] After the server obtains the set of updated effect identifiers representing other effects whose state needs to be changed due to this operation, and the list of target part identifiers representing the specific locations where the first effect identifier should be placed, it needs to establish a clear directional relationship between these two types of information. This allows the server to create a binding relationship between the first effect identifier and its corresponding part. Establishing this mapping relationship means that the server generates a data structure in its memory that clearly records the correspondence between the first effect identifier and each specific target part identifier. This relationship can be understood as a pairing declaration, indicating that a certain effect resource needs to be applied to a specific part of an entity. If the first effect identifier is the code representing "carbon fiber texture," and the target part identifiers are determined to be "hood" and "front bumper," then the server will generate a record indicating that the "carbon fiber texture" code is associated with the "hood" identifier and the "front bumper" identifier, respectively. This mapping data structure can be a list of key-value pairs or an object containing an array of main effect identifiers and sub-part identifiers.

[0076] After establishing the mapping relationship, the server enters the data synchronization phase. The server packages the updated effect identifier set with the newly established mapping relationship, along with necessary metadata, into a response data packet. This packet is a complete, client-oriented instruction set, containing both the update effect identifiers that the client needs to update in its interface display and the mapping relationship guiding the client on how to correctly render the new effects. The server then sends this packaged response data packet through the network connection with the client, thus completing the authoritative processing of this resource application request on the server side. It atomically and comprehensively delivers the calculated state change results and resource location instructions to the client, ensuring that the client can operate based on the same authoritative and complete instruction set when subsequently updating the interface and rendering models. This guarantees a high degree of consistency between the client's local state and the server's authoritative state, as well as the accuracy of visual rendering.

[0077] Through the synergistic effect of the above embodiments, the server first accurately parses the request, obtaining the clear data foundation required for all judgments. Furthermore, by performing mutual exclusion calculations based on unified rules, it accurately deduces all other special effects states affected by the current operation, thereby generating an updated set of special effects identifiers. This ensures strict consistency in rule execution and avoids state conflicts caused by scattered logic. Simultaneously, the server precisely matches special effects resources to specific locations based on the predefined structure of the entities, generating clear association mapping relationships and ensuring that visual resources are correctly placed. Finally, the server integrates the state change list and position mapping relationships and synchronizes them to the client all at once. This reduces repeated communication between the client and server, allowing the client to update interface options and entity appearances simultaneously based on a complete instruction, thereby improving system processing efficiency and ensuring accurate synchronization between interface states and the final rendering result.

[0078] Based on any embodiment of the method in this application, the effect configuration list is updated based on the updated effect identifier and the effect configuration rules, and the corresponding first effect resource is obtained according to the association mapping relationship. The image of the effect configuration part in the game scene is then updated based on the effect rendering image corresponding to the first effect resource, including: Step S3410: The client receives the updated effect identifier and the associated mapping relationship sent by the server, and updates the availability status of the corresponding effect identifier item in the effect configuration list maintained locally on the client according to the updated effect identifier.

[0079] After receiving the server's processing result, the client first performs an interface state synchronization operation. The client receives the server's response data packet through the network module. This data packet contains the updated effect identifier set and its associated mapping relationship. The client parses the data packet and extracts the updated effect identifier set. This set is a data structure containing multiple entries. Each entry explicitly specifies an effect identifier and the new available state that identifier needs to be changed to, such as enabled or disabled. Subsequently, the client updates its locally maintained effect configuration list based on this set. The effect configuration list is the data source for all optional effect items currently displayed to the player in the configuration interface. It can exist in the client's memory as an array or list data structure. Each item in the list records an effect identifier, its current available state, icon reference, and other information. The client iterates through each entry in the updated effect identifier set, using its contained effect identifier as an index to search for the corresponding item in the local effect configuration list. Once found, the available state recorded in that item is updated to the new state specified in the entry.

[0080] State updates can be implemented in several ways. One approach is to directly modify the attribute values ​​of the data model. Another approach involves driving visual feedback in the user interface. When the data model changes, the client notifies the interface layer to redraw, causing the corresponding effect icon to immediately turn gray on the interface, or to have a disabled icon overlaid on it, or to be temporarily removed from the selectable area. For example, if the server-issued update flag indicates that the effect "flame decal" should be disabled, the client will mark its status as disabled in the list, and the corresponding flame icon on the interface will then darken and become unclickable.

[0081] Step S3420: Based on the target part identifier in the association mapping relationship, locate and load the first special effect resource bound to the first special effect identifier, apply the first special effect resource to the model part indicated by the target part identifier corresponding to the game entity, and drive the graphics rendering engine to update the visual appearance of the part in the game scene.

[0082] In this implementation, since the association mapping relationship indicates the binding relationship between the first effect identifier and one or more target part identifiers, the client first parses this relationship to obtain a list of specific target part identifiers. These target part identifiers are logical location codes predefined by the server based on the entity structure. Next, the client needs to locate the corresponding specific part on the game entity model. Based on the target game entity instance found in the current game scene, the client queries the entity model's data structure. This data structure contains information on all configurable parts of the model, with each part containing its logical identifier and a reference to a rendering component. The client compares the target part identifier with the logical identifier in the entity part information to find one or more perfectly matching specific parts. These specific parts are typically represented in the game engine as specific model meshes, sub-model nodes, or mounting points. For example, if the target part identifier is the left shoulder armor, the client will find a mesh or bone node named "left shoulder armor" on the armor entity model.

[0083] Once the location is established, the client uses the first effect identifier as a resource index to request the loading of the corresponding first effect resource from the game's content management system or resource manager. The first effect resource is a specific digital graphic asset, which can be a texture file, a prefab containing texture and material parameters, or a set of shader code and parameter combinations. The loading process can be asynchronous, meaning that data is read from the disk or network cache without blocking the main thread. For example, if the first effect identifier points to a tiger head decal resource, the client loads the corresponding texture file and the material parameters defining its transparency and gloss.

[0084] Furthermore, the client injects the first special effects resource data it has loaded into the graphics rendering control unit associated with the previously located specific model part. One injection method is material replacement, which replaces the original material ball of the target part with the newly loaded material ball; the other is texture or attribute injection, which only assigns the newly loaded texture to a certain texture sampling channel of the existing material ball of the target part, or modifies its color, metallicity and other attribute parameters. For example, for the target part, the car door, the client can assign the tiger head decal texture to the decorative texture channel of the car door material ball.

[0085] Finally, after the resources are successfully applied, the client calls the interface provided by the graphics rendering engine to notify the engine that the rendering data for the target area has changed. The graphics rendering engine then performs redraw calculations for that area, re-lighting, shading, and pixel rendering based on the new resource data, and outputs the results to the frame buffer. This causes the appearance of the target area corresponding to the game entity in the game scene to be refreshed immediately, presenting a visual image with new effects. As a result, the user can immediately see the newly applied tiger head decal on the side panel of the motorcycle in the garage interface or after returning to the game world.

[0086] Through the embodiments of this application, the client can efficiently and synchronously complete two key tasks—updating the interface state and applying visual resources—by receiving a complete instruction package from the server in a single transaction. First, the client refreshes the availability status of each option in the local effect configuration list based on the updated effect identifier, ensuring the user interface accurately reflects the latest available range that conforms to all rules in real time, eliminating any delay or discrepancy between the interface display and the server's logical state. Simultaneously, the client precisely locates the specific part of the game entity model based on the associated mapping relationship and loads the corresponding effect resources, applying them to the correct rendering unit. This drives the graphics engine to update the visual effects of that part in real time, enabling rapid and synchronous completion of interface interaction feedback and changes in the appearance of the 3D model. This further shortens the waiting time from user confirmation to seeing the final result, ensuring visual accuracy while providing a smooth, coherent, and immediate configuration experience.

[0087] Based on any embodiment of the method in this application, it further includes: Step S3510: Obtain the rule version identifier corresponding to the special effect configuration rule, associate the rule version identifier with the currently available special effect configuration list and store it in the client, so as to construct the configuration status data based on the rule version identifier and the first special effect identifier.

[0088] In this implementation, the client can obtain a rule version identifier corresponding to the server-side effect configuration rule. The rule version identifier is a unique marker generated and maintained by the server, such as an incrementing number, timestamp, or hash value, representing a specific state of the server-side effect configuration rule at a certain point in time. Whenever the server makes any modifications or updates to the rule, such as adding a new mutual exclusion relationship or adjusting the unlocking conditions, the version identifier will change accordingly to identify the new version of the rule.

[0089] When the client successfully retrieves the list of currently available effect configurations from the server, it simultaneously receives a currently effective rule version identifier from the server along with that list. The client associates this rule version identifier with the received effect configuration list and stores them together in local memory or a persistent cache. This associated storage allows the client to bind the version identifier to the list data. Specifically, this can be achieved by creating a data structure that holds both a reference to the list data and the version identifier value, ensuring that the correct version information is always referenced in subsequent processing. The purpose of establishing this associated storage is to build accurate configuration state data when the user subsequently selects effects. When the user selects the first effect identifier in the game interface, the client needs to prepare the data to send to the server. At this time, the client retrieves the previously saved rule version identifier from local storage and combines it with the user's selected first effect identifier as part of the configuration state data.

[0090] Configuration state data is a collection of information used to encapsulate the current operation context. It includes at least a first effect identifier and a rule version identifier. When the client subsequently generates a resource application request, the request will carry this configuration state data, so that the server can know the rule version that the client is using when making a selection.

[0091] Step S3520: When the server receives the resource application request, it verifies whether the rule version identifier contained in the request is consistent with the currently effective rule version identifier, and performs the mutual exclusion relationship determination based on the verification result of the consistent identifier.

[0092] In this implementation, after receiving a resource application request from a client, the server parses the complete content of the request. During parsing, the server extracts the rule version identifier attached by the client, which is filled in by the client based on its locally cached rule version information when initiating the request. Subsequently, the server initiates a verification process to obtain the version identifier corresponding to the latest and most effective effect configuration rule it currently maintains. This currently effective rule version identifier can be stored in the server's memory cache or recorded in the system configuration table of the database. The server can compare the rule version identifier carried in the client's request with its own obtained currently effective rule version identifier, for example, comparing whether the two strings are completely identical or whether the two numeric values ​​are strictly equal.

[0093] The purpose of the verification is to confirm whether the version of the effect configuration rules used locally by the client when initiating the application request is synchronized with the latest and most authoritative version of the rules on the server. Only when the two are completely consistent is the verification result considered to be consistent. The consistent verification result is a necessary prerequisite for the server to execute subsequent core business logic, namely the mutual exclusion relationship determination. This means that the server can be sure that the list of options seen by the client and the rule constraints it understands when making a choice are exactly the same as the rules currently being executed by the server. This ensures that the benchmark for all subsequent state calculations is consistent, avoiding decision disagreements or state errors caused by inconsistent rule versions. For example, if the client uses an outdated rule version, it may think that a certain effect is optional, while the server has prohibited the effect according to the new rule. Version verification can detect this inconsistency before calculation. Therefore, through a lightweight but critical version identification comparison, a data consistency security guarantee can be provided for the configuration process, ensuring that subsequent mutual exclusion determinations are all based on correct and consistent rules.

[0094] Step S3530: If the verification result is that the identifiers are inconsistent, the server terminates the processing of the resource application request and sends the latest rule version identifier to the client so that the client can update the special effect configuration list accordingly.

[0095] When the server completes the verification and concludes that the rule version identifier is inconsistent, it indicates that the rule on which the client request is based is outdated and does not match the latest rule currently being executed by the server. In this case, the server will immediately terminate the subsequent business logic processing of the request to that resource. Therefore, the server will not perform the originally planned operations such as mutual exclusion relationship determination, updating effect identifier calculation, and establishing association mapping relationships, because the base rules for these calculations are no longer compatible, and continued processing may lead to data corruption or incorrect results. The server will then proceed to perform an error correction and synchronization operation. The server retrieves the latest rule version identifier currently in effect globally from its storage and generates a specific response for the client. This response does not contain business data indicating a successful request, but rather a feedback message containing explicit status indications and synchronization instructions. This response data contains at least two key parts: a specific status code or reason code indicating that the request was rejected, and the aforementioned latest rule version identifier.

[0096] The server sends this response message to the requesting client via an active network connection. Upon receiving the response, the client first parses out the rejected request status and the latest rule version identifier. It then updates its locally stored rule version identifier with this latest rule version identifier, overwriting the outdated version. Furthermore, the client will proactively trigger a re-acquisition process for the same game entity's effect configuration list based on this latest rule version identifier. This involves either including the latest version identifier or explicitly indicating a need for a refresh in the request, thus requesting a new list of currently available effect configurations calculated based on the latest rules from the server.

[0097] The embodiments described above in this application provide crucial data consistency assurance and dynamic synchronization capabilities for the entire special effects configuration system through a rule version management mechanism. By associating and storing rule version identifiers locally on the client, a clear state snapshot and benchmark reference are established for each user operation, enabling subsequent requests to the server to carry accurate version context. Upon receiving a request, the server can immediately identify whether the client is making decisions based on outdated rules by performing efficient version identifier consistency checks. This effectively intercepts all subsequent calculation errors and state chaos that may be caused by rule asynchrony at the forefront of logical processing. When a version inconsistency is detected during verification, the server terminates the process and proactively sends a response indicating the latest version. This enables immediate error correction and targeted synchronization for the client, allowing the client to quickly detect rule updates and trigger the re-acquisition of the effect configuration list. This forces the local state to synchronize with the server's authoritative rules with minimal network overhead and latency. This not only ensures that a massive number of clients interact based on a unified rule version in a distributed environment, avoiding data inconsistencies and display errors caused by rule version mismatches, but also improves the system's real-time response capability and deployment flexibility to global rule updates. Furthermore, by reducing unnecessary server-side calculations and request retries, it optimizes overall network communication efficiency and system resource utilization.

[0098] Based on any embodiment of the method in this application, applying the first special effects resource to the model part indicated by the target part identifier corresponding to the game entity, and driving the graphics rendering engine to update the visual appearance of that part in the game scene, further includes: Step S3610: Obtain the graphics rendering control unit corresponding to the game entity in the graphics rendering engine according to the target part identifier, and inject the rendering resource data contained in the first special effects resource into the graphics rendering control unit.

[0099] Based on the established target part identifier, the client locates the corresponding graphics rendering control unit (GRU) for the game entity within the graphics rendering engine. The GRU is a procedural object or component in the game engine responsible for managing the final visual representation of a specific model part; its specific form varies depending on the game engine architecture. For example, in a component-based architecture, it can be a renderer component mounted on a model part node, holding a reference to the material asset; in another architecture, it can be an independent material instance object, or a shader procedural object and its associated parameter set. The client retrieves one or more such GRUs bound to that logical part by querying the game entity's scene graph or object model, using the target part identifier as the lookup key.

[0100] After successfully locating the graphics rendering control unit, the client performs an injection operation. The rendering resource data here is the specific representation of the first effects resource in memory. It contains various parameters and asset references needed to define the visual appearance. Rendering resource data is not a single data block but typically a structured collection, which may include texture data, shader parameters, and material attribute data. Texture data refers to specific image bitmap information, such as diffuse maps, normal maps, or specular maps; shader parameters are variables passed to the shader program to control its computational behavior, such as color vectors, floating-point values, or Boolean on / off values; material attribute data are parameters that control the basic appearance of the material, such as rendering mode, opacity, and blending state.

[0101] The injection process refers to the client assigning various elements from the aforementioned rendering resource data to the corresponding interfaces or attributes exposed by the graphics rendering control unit. A common method is material replacement: the client creates a new material instance, configures all loaded textures and parameters onto this new material, and then replaces the old material reference held by the graphics rendering control unit with this new material. Another method is parameter updating: the graphics rendering control unit is associated with a dynamically modifiable material instance. The client calls the instance's application programming interface (API) to set the new texture to the specified texture sampler slot and assigns the new parameter values ​​to the corresponding named attributes. By completing this injection operation, all visual definition data for the model parts managed by the graphics rendering control unit is updated, thus directly preparing the data for the rendering engine to draw a new appearance in the next frame.

[0102] Step S3620: Call the interface of the graphics rendering engine to trigger the redraw rendering of the model part indicated by the target part identifier in the game entity, so as to update the visual appearance of the model part in the game scene based on the image frame generated after the redraw rendering.

[0103] Furthermore, the client can proactively invoke the standard program interface provided by the graphics rendering engine. The graphics rendering engine is a software system responsible for compositing 3D models, textures, lighting, and other data into a final 2D screen image. Internally, it manages a complex rendering pipeline. By calling a specific application programming interface function of the engine, the client can issue a clear instruction to the engine to redraw a specified target. The instruction includes corresponding location information, namely the model part indicated by the target part identifier. The client passes the target part identifier determined in previous steps, or an internal engine reference such as a renderer component pointer and mesh instance ID, as parameters to the rendering engine interface. The purpose of this instruction is not to recalculate the entire game scene, but to notify the engine that the underlying rendering data of that specific part has changed and needs to be re-included in the rendering calculation of the next frame.

[0104] Upon receiving the instruction, the graphics rendering engine performs targeted processing in its next rendering cycle. The rendering pipeline identifies the specific parts marked as needing updates and re-executes necessary graphics calculations, including vertex transformations, lighting calculations, and pixel shading, only on the associated geometry, materials, and shaders of that part, without processing other unchanged parts of the scene. After the redraw rendering calculations are complete, the graphics rendering engine generates a new frame of image data. This frame of image data contains the updated color information of all pixels in the game scene in memory. The visual appearance of the target part has been completely refreshed based on the newly injected rendering resource data. The graphics rendering engine then submits this frame of image to the display system, which ultimately displays it on the player's screen. Thus, the visual appearance of that specific model part in the game scene is updated instantly and accurately, allowing the player to immediately observe, for example, the reflective effect of a new paint job on a vehicle's hood or the dynamic changes of newly added patterns on a character's armor.

[0105] The embodiments described above can accurately locate the specific control unit in the graphics rendering engine based on the target part identifier, thereby achieving accurate binding of special effects resource data with the rendering pipeline of a specific part of the model. This ensures that rendering resource data such as textures and shader parameters can be injected into the correct rendering context without error, thus avoiding visual display errors caused by resource mismatch. Furthermore, by actively calling the standard interface of the graphics rendering engine to trigger targeted redraw rendering for that specific model part, the rendering pipeline can be driven to perform only the necessary graphics calculations and pixel redrawing on the parts where the data has changed, without needing to perform full rendering of the entire entity or scene. This reduces the computational load and frame rendering time of the GPU, improves the efficiency and performance of rendering updates, and ultimately ensures a short latency from data update to screen pixel refresh. This allows players to immediately and accurately observe the visual performance of custom special effects on the specified parts of the entity in the game scene, thereby achieving real-time synchronization between user operation and graphical feedback and improving the system's response speed and visual reliability.

[0106] Please see Figure 4According to one aspect of this application, an entity special effects configuration device includes a request response module 4100, an identifier selection module 4200, an association mapping module 4300, and a special effects update module 4400. The request response module 4100 is configured to, in response to a special effects configuration request for a game entity, obtain a list of currently available special effects configurations. The special effects configuration list is a set of special effects identifiers obtained by filtering a special effects configuration identifier library based on at least one special effects configuration rule associated with the game entity. The identifier selection module 4200 is configured to, in response to selecting an identifier of a first special effects identifier in the special effects configuration list... The system generates a resource application request corresponding to the first special effect identifier based on the event; the association mapping module 4300 is configured to obtain the updated special effect identifier corresponding to the resource application request according to the special effect configuration rules, and determine the association mapping relationship between the first special effect identifier and the corresponding special effect configuration part of the game entity; the special effect update module 4400 is configured to update the special effect configuration list based on the updated special effect identifier and the special effect configuration rules, obtain the corresponding first special effect resource according to the association mapping relationship, and update the image of the special effect configuration part in the game scene based on the special effect rendering image corresponding to the first special effect resource.

[0107] Based on any embodiment of the device in this application, the request response module 4100 includes: a first request unit, configured to respond to a configuration interaction operation triggered by the special effects configuration entry for the game entity in the game interface, generate the special effects configuration request based on the player identifier of the game player and the entity special effects identifier of the game entity, so that the client sends the special effects configuration request to the server; and an identifier determination unit, configured to have the server determine the applicable identifiers corresponding to the player identifier and the entity special effects identifier contained in the special effects configuration request based on the special effects configuration rules, so as to send the set of special effects identifiers composed of all the applicable identifiers to the client.

[0108] Based on any embodiment of the device in this application, the identifier selection module 4200 includes: an identifier acquisition unit, configured to, in response to an identifier selection event triggered by an operation to select the first effect identifier in the effect configuration list within the game interface, acquire configuration status data corresponding to the first effect identifier and entity effect identifier corresponding to the effect resource currently configured by the game entity; and a second request unit, configured to, on the client side, generate corresponding resource configuration data based on the first effect identifier, the player identifier, and the entity effect identifier, and generate the resource application request based on the resource configuration data and the configuration status data, so that the client can send the resource application request to the server.

[0109] Based on any embodiment of the device in this application, the association mapping module 4300 includes: a request parsing unit, configured to receive and parse the resource application request from the server, and obtain the first special effect identifier, the player identifier, and the entity special effect identifier contained in the request; an identifier filtering unit, configured to determine the mutual exclusion relationship between the first special effect identifier and the entity special effect identifier based on the special effect configuration rules, and filter out the identifiers whose status needs to be changed from the special effect configuration identifier library according to the determination result, so as to constitute the updated special effect identifier; an identifier matching unit, configured to determine at least one target part identifier that matches the special effect resource type represented by the first special effect identifier according to the predefined part configuration information of the game entity; and an association establishment unit, configured to establish the association mapping relationship between the first special effect identifier and the at least one target part identifier, so that the server synchronously sends the updated special effect identifier and the association mapping relationship to the client.

[0110] Based on any embodiment of the device in this application, the special effects update module 4400 includes: a status update unit, configured to receive the updated special effects identifier and the associated mapping relationship sent by the server on the client, and update the availability status of the corresponding special effects identifier item in the special effects configuration list maintained locally on the client according to the updated special effects identifier; and a special effects loading unit, configured to locate and load the first special effects resource bound to the first special effects identifier based on the target part identifier in the associated mapping relationship, apply the first special effects resource to the model part indicated by the target part identifier corresponding to the game entity, and drive the graphics rendering engine to update the visual appearance of the part in the game scene.

[0111] Based on any embodiment of the device in this application, it further includes: a rule identification module, configured to obtain a rule version identification corresponding to the special effect configuration rule, associate the rule version identification with the currently available special effect configuration list and store it in the client, so as to construct the configuration status data based on the rule version identification and the first special effect identification; an identification verification unit, configured to verify whether the rule version identification contained in the request is consistent with the currently effective rule version identification when the server receives the resource application request, so as to perform the mutual exclusion relationship determination based on the identification consistency verification result; and an identification update unit, configured to terminate the processing of the resource application request if the verification result is that the identifications are inconsistent, and send the latest rule version identification to the client so that the client can update the special effect configuration list accordingly.

[0112] Based on any embodiment of the device in this application, the special effects loading unit further includes: a data injection subunit, configured to obtain the graphics rendering control unit corresponding to the game entity in the graphics rendering engine according to the target part identifier, and inject the rendering resource data contained in the first special effects resource into the graphics rendering control unit; and a rendering update subunit, configured to call the interface of the graphics rendering engine to trigger the redraw rendering of the model part indicated by the target part identifier in the game entity, so as to update the visual appearance of the model part in the game scene based on the image frame generated after the redraw rendering.

[0113] Another embodiment of this application also provides a physical effects configuration device. For example... Figure 4 The diagram shows the internal structure of an entity effects configuration device. This device includes a processor, a computer-readable storage medium, a memory, and a network interface connected via a system bus. The computer-readable, non-volatile storage medium stores an operating system, a database, and computer-readable instructions. The database stores information sequences, and when executed by the processor, these computer-readable instructions enable the processor to implement an entity effects configuration method.

[0114] The processor of the physical effects configuration device provides computing and control capabilities to support the operation of the entire physical effects configuration device. The memory of the physical effects configuration device may store computer-readable instructions, which, when executed by the processor, cause the processor to perform the physical effects configuration method of this application. The network interface of the physical effects configuration device is used for communication with a terminal.

[0115] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the physical effects configuration device applied thereto. The specific physical effects configuration device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0116] In this embodiment, the processor is used to execute... Figure 3 The specific functions of each module are described, and the memory stores the program code and various data required to execute the aforementioned modules or sub-modules. A network interface is used to enable data transmission between user terminals or servers. In this embodiment, the non-volatile readable storage medium stores the program code and data required to execute all modules in the entity effect configuration device of this application. The server can call the server's program code and data to execute the functions of all modules.

[0117] This application also provides a non-volatile readable storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the entity effect configuration method of any embodiment of this application.

[0118] This application also provides a computer program product, including a computer program / instructions that, when executed by one or more processors, implement the steps of the method described in any embodiment of this application.

[0119] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a computer-readable storage medium such as a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM).

Claims

1. A method for configuring entity special effects, characterized in that, include: In response to a special effects configuration request for a game entity, a list of currently available special effects configurations is obtained, wherein the special effects configuration list is a set of special effects identifiers obtained by filtering a special effects configuration identifier library based on at least one special effects configuration rule associated with the game entity; In response to the identifier selection event of the first effect identifier in the effect configuration list, a resource application request corresponding to the first effect identifier is generated based on the event; According to the special effect configuration rules, obtain the updated special effect identifier corresponding to the resource application request, and determine the association mapping relationship between the first special effect identifier and the corresponding special effect configuration part of the game entity; The effect configuration list is updated based on the updated effect identifier and the effect configuration rules. The corresponding first effect resource is obtained according to the association mapping relationship. The image of the effect configuration part in the game scene is updated based on the effect rendering image corresponding to the first effect resource.

2. The entity special effects configuration method according to claim 1, characterized in that, In response to a special effects configuration request for a game entity, a list of currently available special effects configurations is obtained. This list is a set of special effects identifiers obtained by filtering a special effects identifier library based on at least one special effects configuration rule associated with the game entity, including: In response to the configuration interaction operation triggered by the special effects configuration entry for the game entity in the game interface, the special effects configuration request is generated based on the player identifier of the game player and the entity special effects identifier of the game entity, so that the client can send the special effects configuration request to the server. The server determines the applicable identifiers corresponding to the player identifier and the entity effect identifier contained in the effect configuration request based on the effect configuration rules, and sends the effect identifier set consisting of all the applicable identifiers to the client.

3. The entity special effects configuration method according to claim 2, characterized in that, The step of responding to an event for selecting a first effect identifier in the effect configuration list, and generating a resource application request corresponding to the first effect identifier based on the event, includes: In response to the identifier selection event triggered by the selection operation of the first effect identifier in the effect configuration list in the game interface, the configuration status data corresponding to the first effect identifier and the entity effect identifier corresponding to the effect resource currently configured by the game entity are obtained. The client generates corresponding resource configuration data based on the first effect identifier, the player identifier, and the entity effect identifier. Based on the resource configuration data and the configuration status data, the client generates the resource application request, which is then sent to the server.

4. The entity special effects configuration method according to claim 3, characterized in that, The step of obtaining the updated effect identifier corresponding to the resource application request according to the effect configuration rules, and determining the association mapping relationship between the first effect identifier and the corresponding effect configuration part of the game entity, includes: The server receives and parses the resource application request to obtain the first effect identifier, the player identifier, and the entity effect identifier contained in the request; Based on the special effect configuration rules, the mutual exclusion relationship between the first special effect identifier and the entity special effect identifier is determined. According to the determination result, the identifier whose status needs to be changed is selected from the special effect configuration identifier library to form the updated special effect identifier. Based on the predefined part configuration information of the game entity, at least one target part identifier is determined that matches the type of special effect resource represented by the first special effect identifier; Establish the association mapping relationship between the first special effect identifier and the at least one target part identifier, so that the server can synchronously send the updated special effect identifier and the association mapping relationship to the client.

5. The entity special effects configuration method according to claim 4, characterized in that, The step of updating the special effect configuration list based on the updated special effect identifier and the special effect configuration rules, obtaining the corresponding first special effect resource according to the association mapping relationship, and updating the image of the special effect configuration part in the game scene based on the special effect rendering image corresponding to the first special effect resource includes: The client receives the updated effect identifier and the associated mapping relationship sent by the server, and updates the availability status of the corresponding effect identifier item in the effect configuration list maintained locally on the client according to the updated effect identifier; Based on the target part identifier in the association mapping relationship, locate and load the first special effect resource bound to the first special effect identifier, apply the first special effect resource to the model part indicated by the target part identifier corresponding to the game entity, and drive the graphics rendering engine to update the visual appearance of the part in the game scene.

6. The entity special effects configuration method according to claim 5, characterized in that, Also includes: Obtain the rule version identifier corresponding to the special effect configuration rule, associate the rule version identifier with the currently available special effect configuration list and store it in the client, so as to construct the configuration status data based on the rule version identifier and the first special effect identifier; When the server receives the resource application request, it verifies whether the rule version identifier contained in the request is consistent with the currently effective rule version identifier, and performs the mutual exclusion relationship determination based on the verification result of the identity consistency. If the verification result indicates an inconsistency in identifiers, the server terminates the processing of the resource application request and sends the latest rule version identifier to the client so that the client can update the special effects configuration list accordingly.

7. The entity special effects configuration method according to claim 5, characterized in that, The step of applying the first special effects resource to the model part indicated by the target part identifier corresponding to the game entity, and driving the graphics rendering engine to update the visual appearance of that part in the game scene, further includes: Based on the target part identifier, obtain the graphics rendering control unit corresponding to the game entity in the graphics rendering engine, and inject the rendering resource data contained in the first special effects resource into the graphics rendering control unit; The interface of the graphics rendering engine is invoked to trigger the redrawing and rendering of the model part indicated by the target part identifier in the game entity, so as to update the visual appearance of the model part in the game scene based on the image frame generated after the redrawing and rendering.

8. A physical special effects configuration device, characterized in that, include: The request-response module is configured to respond to a special effects configuration request for a game entity and obtain a list of currently available special effects configurations. The special effects configuration list is a set of special effects identifiers obtained by filtering a special effects configuration identifier library based on at least one special effects configuration rule associated with the game entity. The identifier selection module is configured to respond to an identifier selection event for the first effect identifier in the effect configuration list, and generate a resource application request corresponding to the first effect identifier based on the event. The association mapping module is configured to obtain the updated effect identifier corresponding to the resource application request according to the effect configuration rules, and determine the association mapping relationship between the first effect identifier and the corresponding effect configuration part of the game entity. The special effects update module is configured to update the special effects configuration list based on the updated special effects identifier and the special effects configuration rules, obtain the corresponding first special effects resource according to the association mapping relationship, and update the image of the special effects configuration part in the game scene based on the special effects rendering image corresponding to the first special effects resource.

9. A physical effects configuration device, comprising a central processing unit and a memory, characterized in that, The central processing unit is used to invoke and run a computer program stored in the memory to perform the steps of the method as described in any one of claims 1 to 7.

10. A non-volatile readable storage medium, characterized in that, It stores, in the form of computer-readable instructions, a computer program implemented according to any one of claims 1 to 7, which, when invoked by a computer, executes the steps included in the corresponding method.

Images