Game interaction configuration method and device, equipment and medium

Abstract

The invention relates to a game interaction configuration method and device, equipment and a medium. The method comprises the steps of loading an enemy strategy data packet corresponding to an enemy role in response to an interaction request instruction for the enemy role in a graphical user interface; obtaining element selection data for player configuration elements in the graphical user interface, and generating a player strategy data packet associated with the element selection data; when interaction conditions are met, interaction calculation is carried out on the hostile strategy data packet and the player strategy data packet based on an interaction decision model, and interaction calculation data between hostile configuration elements and player configuration elements are obtained; and loading an element interaction animation corresponding to the hostile configuration element and the player configuration element in the graphical user interface based on the interaction calculation data so as to dynamically display the interaction calculation process. The game strategy interaction depth and the visual expressive force are ensured, and meanwhile the problems of high load, asynchronous states and difficult system maintenance under a traditional real-time computing architecture are solved.

Description

TECHNICAL FIELD

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

[0002] In the current increasingly diverse games, players can fight with other real players, or fight with virtual enemies set by game programs. In more specific battle modes, players can also control their units to fight through real-time input instructions, or make their units fight with enemy units that have also been configured according to a preset logic. Traditional technologies for implementing this game play usually rely on a real-time interaction and calculation architecture. When a battle is triggered, the game system needs to immediately process the complex interaction logic between the multiple units configured by the player and the multiple units of the system opponent, including but not limited to movement, attack determination, damage calculation and skill effect triggering. The entire process is often continuously and dynamically calculated by the game engine at each frame or each time point, and simultaneously drives the real-time actions and state changes of all units in the picture.

[0003] However, this traditional technology principle based on real-time calculation and rendering synchronization gradually reveals several inherent technical defects in actual application. First, since the action logic and animation performance of all units need to be calculated and presented within a very short time period, this continuously high pressure load on the computing resources and graphics rendering capabilities of the client device running the game, especially mobile terminals, easily leads to a decrease in processing speed and an increase in energy consumption, causing picture lag or response delay on devices with limited configuration, which damages the smoothness of the game process. If the smooth running of the game is to be ensured, the game picture cannot be processed very finely. Second, in order to ensure the determinacy of each detail state in the complex multi-unit interaction process, the game system needs to maintain high-frequency internal state verification and synchronization during the battle process, which not only increases the overall complexity of the system, because any adjustment to the unit attributes or interaction rules may require extensive and meticulous modification of the underlying tightly coupled logic calculation code, but also brings higher maintenance costs and error risks for game version updates and subsequent content expansion.

[0004] Therefore, the existing game interaction implementation method still has certain room for improvement in terms of balancing the player's game experience and game performance consumption. SUMMARY

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

[0006] According to an aspect of the present application, a game interaction configuration method is provided, comprising: loading an enemy strategy data packet corresponding to a preset enemy role based on an interaction request instruction for the enemy role in a graphical user interface; obtaining element selection data for a player configuration element in the graphical user interface, and generating a player strategy data packet associated with the element selection data; performing interaction calculation on the enemy strategy data packet and the player strategy data packet based on a preset interaction decision model when a preset interaction condition is met, and obtaining interaction calculation data between the corresponding enemy configuration element and the player configuration element; loading element interaction animation corresponding to the enemy configuration element and the player configuration element in the graphical user interface based on the interaction calculation data, to dynamically display the corresponding interaction calculation process.

[0007] According to another aspect of the present application, a game interaction configuration device is provided, comprising: an instruction response module configured to load an enemy strategy data packet corresponding to a preset enemy role based on an interaction request instruction for the enemy role in a graphical user interface; an element selection module configured to obtain element selection data for a player configuration element in the graphical user interface, and generate a player strategy data packet associated with the element selection data; an interaction calculation module configured to perform interaction calculation on the enemy strategy data packet and the player strategy data packet based on a preset interaction decision model when a preset interaction condition is met, and obtain interaction calculation data between the corresponding enemy configuration element and the player configuration element; an animation display module configured to load element interaction animation corresponding to the enemy configuration element and the player configuration element in the graphical user interface based on the interaction calculation data, to dynamically display the corresponding interaction calculation process.

[0008] According to another aspect of the present application, a game interaction configuration device is provided, comprising a central processing unit and a memory, wherein the central processing unit is configured to call and run a computer program stored in the memory to perform the steps of the method described in the present application.

[0009] According to another aspect of the present application, a non-volatile readable storage medium is provided, which stores a computer program implemented according to the game interaction configuration method in the form of computer readable instructions, and the computer program performs the steps included in the method when called and run by a computer.

[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 abstracts and pre-defines the behavioral logic of enemy characters into independent adversarial strategy data packages, and transforms the player's configuration operations in the graphical interface into structured player strategy data packages. When conditions are met, both are centrally calculated based on a preset model. This transforms the complex logical calculations that traditional architectures require to be performed in real-time and continuously during combat into one-time or phased pre-calculations. This means that client devices no longer need to bear the heavy load of real-time logical calculations when finally displaying the combat process. They only need to drive the animation playback based on the determined interactive calculation data, thereby reducing the instantaneous requirements on client computing resources and graphics rendering capabilities. This effectively alleviates screen stuttering and response latency issues, improves the smoothness and stability of the game process, and also helps to reduce the energy consumption of mobile terminals and other devices.

[0012] Secondly, this application achieves decoupling between the core game interaction logic and the specific rendering execution by adopting an architecture of data packet encapsulation and centralized computation. Since both adversary strategies and player strategies are modularized into independently loadable and parsable data packets, and the core interaction decisions are completed by a unified preset model, when it is necessary to update or expand the game content, such as adjusting character attributes, adding new skills or interaction rules, the main work becomes configuring and updating the parameters of the corresponding data packets or decision models, without having to deeply modify the tightly coupled real-time calculation code at the bottom layer of the game engine. This reduces the overall system complexity and maintenance costs, improves the flexibility and reliability of game content iteration, and reduces the risk of errors introduced by code changes.

[0013] Furthermore, driving interactive animations in the graphical interface based on pre-generated deterministic interactive calculation data ensures that regardless of the client device's performance, as long as basic animation rendering is supported, the displayed combat process and results remain consistent and deterministic. This determinism not only guarantees the fairness and uniformity of the game experience but also allows game developers to more precisely control and design complex and detailed multi-unit combat animations without worrying excessively about the limitations of real-time computing performance on visual presentation. This improves game performance efficiency while providing a more solid technical foundation for enriching visual presentation and deepening strategic dimensions. Attached Figure Description

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

[0015] 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.

[0016] 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.

[0017] 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.

[0018] 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.

[0019] The technical solution of this application can be deployed in various software systems with strategic interaction functions, and is particularly suitable for application scenarios that require handling complex pre-configured logic and automated multi-unit interactions, such as strategy video games, simulation battle platforms, or corresponding gameplay integrated into various games. In a typical deployment architecture, the game system can be composed of a client and a server working together. The client is mainly responsible for presenting the graphical user interface, receiving user configuration operations on virtual elements, and finally playing interactive animations; the server undertakes the logic processing responsibilities, including managing strategy data resources, responding to user commands, and performing centralized interactive calculations and coordinating the synchronization of results. The two communicate through a network to jointly complete the entire process from strategy configuration to result presentation.

[0020] In one exemplary implementation, the logic and resources involved in the interaction process in this application are organized and managed in the form of structured data packets. The behavior patterns and attributes of non-player characters controlled by the system are encapsulated into independently loadable adversary strategy data packets. Similarly, the combat units and their associated rules configured by the player through the graphical interface are encapsulated into player strategy data packets. This data encapsulation method decouples the interaction logic from the specific program implementation and interface presentation, improving the modularity of the system. When the interaction is triggered, the game system parses and calculates the data packets of both sides through a preset interaction decision model, generating a set of definite interaction calculation data. This data completely defines the timing of the actions and state changes of all subsequent virtual units. Finally, based on this definite calculation data, the client schedules the corresponding animation resources and presents the entire interaction process accurately and synchronously on the interface through graphics rendering technology.

[0021] In one exemplary implementation of this application, a strategy data package, an interaction decision model, and interaction computation data are included. The strategy data package refers to an independent data unit that structurally encapsulates specific interaction rules, attribute parameters, and behavioral logic; it serves as the basic input for the system's logical calculations. The interaction decision model is a set of processing rules and algorithms pre-defined in the system, which parses, judges, and calculates the input strategy data package. The interaction computation data is the result dataset output by this model, containing complete temporal and state information, serving as the authoritative basis for driving the client's visual performance.

[0022] In one exemplary embodiment, this application can be embodied as a video game combining strategy card collection and automated monster battles. In this embodiment, the game provides a core gameplay interface set against a virtual world map. Multiple non-player characters, each with a unique backstory and a pre-configured battle strategy (i.e., their exclusive deck and behavioral logic), are distributed across the map. Players initiate challenges by selecting a specific non-player character on the map interface. Before entering a battle, players need to configure their strategy. Players possess a private deck consisting of multiple cards with different functions, obtainable through various in-game activities. Each card represents a virtual combat unit or a special effect that can be used in battle and is configured with parameters such as attribute type, resource consumption, and skill effects. Players freely select a certain number of cards from their deck to form a battle deck that conforms to specific rules, such as restrictions on card type, attribute variety, or quantity limits. Simultaneously, players must choose one of several selectable game characters, each possessing unique tactical skills that can affect card effects. A player's deck selection and character tactical configuration together constitute their strategic intent for this battle. Once the strategy is configured and the battle begins, the system enters an automated battle process, which is divided into two stages: logical calculation and visual presentation. In the logical calculation stage, the system takes the player's configured deck, character tactics, the target non-player character's preset deck, and AI logic as input. Based on a set of pre-defined interaction decision rules, the system simulates and deduces the complete behavioral sequences, interaction results, and state changes of all card units on both sides over multiple rounds, generating a deterministic data record containing all battle details—the interaction calculation data. This process can employ a logical model combining probability judgment based on random seed control and conditional behavior trees to ensure that each battle is both predictable and reproducible. In the visual presentation stage, the game system drives the dynamic display of the graphical interface based on the aforementioned interaction calculation data. The player's configured cards and the non-player character's cards are transformed into corresponding monster entity models and presented in the battle scene. These physical models will strictly follow the time points, action commands, and status results specified in the calculation data to automatically execute actions such as moving, attacking, and releasing skills, and synchronously update visual feedback such as health points until one side's health points reach zero or the round limit is reached, thus smoothly reproducing the entire calculated battle process. In this way, the system framework achieves the depth of strategy and the high efficiency and stability of battle demonstration by transforming complex strategy configurations into structured input data and separating deterministic calculations from real-time rendering.

[0023] 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.

[0024] Please seeFigure 2 The game interaction configuration method of this application, in some embodiments, includes the following steps: Step S3100: In response to an interaction request command for a preset enemy character in the graphical user interface, load the hostile strategy data packet corresponding to the enemy character based on the command.

[0025] During a player's gaming experience, such as in a large-scale open-world role-playing game, the player typically finds themselves in a vast world. The game screen displays the player's controlled character or other corresponding game entities. When the player needs to trigger certain events in the game world, such as opening the quest panel, equipment panel, or event interface, the game system loads the corresponding graphical user interface (GUI) onto the player's screen. The GUI can be a small window floating in the game screen or a full-screen page that completely occupies the game screen. It can provide different gameplay experiences depending on the interface components selected by the player.

[0026] This application can be executed in a combat gameplay interface opened by the player. When the player clicks on an activity interface component that represents a specific combat gameplay, the corresponding graphical user interface will appear on the game screen. At this time, the player can select one of the multiple preset enemy characters on the graphical user interface as their combat opponent. The corresponding operation command to select the character and confirm the battle can be regarded as an interactive request command for the enemy character.

[0027] In this embodiment, in the graphical user interface, preset enemy characters can be presented as visual icons, avatars, or models, and are fixedly or dynamically distributed within a specific activity map or list. This graphical user interface receives touch, click, or cursor selection operations from the player. When such an operation is applied to the visual marker of a preset enemy character, it is considered an interaction request command for that enemy character. This command can be triggered either by the player directly clicking the enemy character's avatar to confirm the selection, or by the game system automatically confirming the currently highlighted selected character after a preset countdown.

[0028] Upon detecting an interaction request command, the game system immediately parses the enemy character identification information carried within the command. This identification information is a unique data index corresponding to a specific enemy character, such as a specific character number or string name. Based on this identification, a retrieval and loading request can be initiated to the corresponding data storage location.

[0029] An enemy strategy data package can be a pre-generated structured data collection that encapsulates all the logic and parameters required for a specific enemy character to interact. This data package exists independently of the game's core program logic as a configurable resource. Its content includes, but is not limited to, the enemy character's basic attributes, such as health, attack power, and defense; behavioral logic definitions, such as the conditions, priorities, and target selection rules for the character to use different skills in combat; and special effects or combo rules that the character may trigger. Enemy strategy data packages can be implemented in various technical forms, such as a configuration file serialized in a specific format, a collection of records in a database, or a binary resource file that can be directly parsed by the game engine.

[0030] The process of a game system loading an adversary strategy data packet can be described as reading the packet from persistent storage into the system's runtime memory. In a client-server architecture embodiment, this process occurs on the server side. After receiving an interaction request instruction from the client, the server, based on the role identifier in the instruction, searches for and reads the corresponding data packet from the server's database or resource files, and loads it into the server's memory for use by subsequent calculation modules. In another pure client architecture embodiment, the data packet can also be directly stored in the client's resource directory and loaded directly into the client's memory by the client program according to instructions. After loading, the role logic and parameters defined in the data packet are in a ready state.

[0031] Step S3200: Obtain element selection data for player configuration elements in the graphical user interface, and generate a player strategy data package associated with the element selection data.

[0032] After selecting an enemy character and triggering the interaction request, the graphical user interface (GUI) will display a strategy preparation interface specifically for player configuration. Player configuration elements are the basic interactive units presented to the player, selectable and used to construct their battle lineup. In the game, these elements are represented by, but are not limited to, card icons representing different virtual characters, item icons with specific skills, or character models that can be dragged directly to the battle queue. These configuration elements are visually displayed on the interface, each associated with a set of predefined attribute and ability data. Players can select several player configuration elements from all available options through touch, click, drag, or selection to build their specific lineup for the upcoming battle. The game system continuously monitors these interface operations, recording each selected player configuration element in real time, and summarizing the final result of this selection operation—the identification information and configuration status of all selected elements—into a single element selection data set. This element selection data can essentially be a structured list that records at least the unique number of each selected element and any additional instructions the player may assign to it, such as setting a card as the leader or equipping a character with a specific item.

[0033] During the generation of the player strategy data package, the selected element data serves as the core input, undergoing data encapsulation and rule attachment. First, the game system reads the identifier of each element in the selected element data list and retrieves the complete underlying attribute templates corresponding to these elements from the game resource library, such as the character's base health, attack power, and skill list. Next, additional states or commands applied by the player in this configuration, such as specified character positioning order, activated additional skill effects, or triggered team synergy rules, are combined with the basic attribute templates to generate the element's real-time status data within the current lineup. Then, a new structured data container can be created—the player strategy data package. This package integrates the real-time status data of all configured elements in the current lineup, the association rules between elements, and the global attribute bonuses for the entire lineup. Its encapsulation format can be similar to the aforementioned adversary strategy data package, employing serialized configuration files, binary resources, or database records to ensure data structure uniformity and processing consistency.

[0034] In one implementation, specifically in a JSON-formatted example, the player strategy data package is a JSON object containing a lineup list, detailed attributes and skill arrays for each character, and team aura effect objects. After generating this data package, the game system associates it with the current player's account identifier and stores it in memory or temporary storage. This transforms all the player's strategic choices on the graphical interface into a single, structured data entity containing complete combat information.

[0035] Step S3300: When the preset interaction conditions are met, perform interaction calculations on the adversary strategy data packet and the player strategy data packet based on the preset interaction decision model to obtain the interaction calculation data between the corresponding adversary configuration element and the player configuration element.

[0036] Preset interaction conditions can be trigger rules set by the game system to initiate formal interaction calculations. These conditions are designed to ensure that interaction begins only when the player has a clear intention or the system logic requires it. Specific implementations can take many forms. For example, a common condition is that the player actively clicks the "Start Battle" or "Confirm Attack" button on the graphical user interface; the game system determines the condition is met upon receiving this instruction. Another approach is based on time rules, such as starting a countdown after the player completes their lineup configuration; the system automatically determines the interaction condition is met when the countdown reaches zero. A state-based implementation is also possible; for example, if both the player's strategy data packet and the enemy's strategy data packet are successfully loaded and ready, the interaction can be automatically triggered without additional instructions.

[0037] When preset interaction conditions are met, the game system can invoke a preset interaction decision model. This model can be a rule engine or computational framework pre-installed in the game system to process the strategy data of both sides and derive the interaction result. It can receive loaded enemy strategy data packets and generated player strategy data packets as input, and internally contains complete logic for parsing the data packet structure, processing logical rules, performing numerical calculations, and probabilistic determinations. The specific technical implementation of the interaction decision model can vary. It can be a deterministic logic processor based on state machines and rule tables, calculating results in a fixed order according to the attribute values ​​and skill conditions of both sides. Alternatively, it can be an artificial intelligence module containing specific algorithms to simulate a more dynamic decision-making process.

[0038] In one implementation, performing interactive calculus refers to the interactive decision model performing comprehensive simulation calculations on two data packets according to its built-in logic. This process is not a real-time response to user operations, but rather a one-time, centralized batch calculation. The interactive decision model first parses the adversary strategy data packet and the player strategy data packet, extracting all virtual entities that need to participate in the interaction—namely, adversary configuration elements and player configuration elements—along with all their attributes, skills, and association rules. Then, based on its preset decision logic, it deduce all possible behavioral sequences, state changes, and mutual influences that these elements may experience during the interaction. For example, it calculates whether an attack initiated by a player configuration element hits, calculates the damage caused by the hit, determines whether the attacked adversary configuration element will trigger a block or counter-skill, and updates the health status of both sides. All these calculations are completed at once based on the parameters in the data packets and the rules of the model, generating a deterministic set of results covering all details of the entire interaction process. This set of results is the interactive calculus data.

[0039] In one implementation, the interactive computation data is a structured dataset containing complete temporal information. It records in detail the actions performed by each adversary and player configuration element at every key point in time from the start to the end of the interaction, and how their various state values ​​change over time. For example, the data would explicitly record that at 1.2 seconds after the interaction began, player character A used skill C on adversary character B, causing a certain amount of damage and reducing adversary character B's health from 100 points to 75 points. The corresponding data is organized according to a strict timeline or event sequence to ensure it can be accurately reproduced in subsequent display stages. The interactive computation data can be stored in an in-memory data structure, such as an array of timestamps and event objects, or serialized into a temporary file. This interactive computation data can then serve as the input driving the visualization of the entire interactive process. Thus, through the centralized computation method of this implementation, the most computationally intensive logic processing stage can be separated from the graphics rendering stage, which has high real-time requirements, thereby optimizing performance allocation.

[0040] In one implementation, after the player completes the selection and confirmation of the player configuration elements, the graphical user interface can be converted into a pre-configured and locally stored transition scene animation at the same time as the player strategy data package is generated. This allows the game display animation to be provided to the player during the background data calculation process, avoiding the tedious waiting process of the progress bar and making the player's game experience smoother.

[0041] Step S3400: Based on the interactive calculation data, load the element interaction animations corresponding to the hostile configuration element and the player configuration element in the graphical user interface to dynamically display the corresponding interactive calculation process.

[0042] After acquiring complete interaction calculation data, the game system can then enter the visualization stage of the interaction process. The purpose at this stage is to transform the determined logical results recorded in the interaction calculation data into intuitive dynamic visuals in the graphical user interface. Element interaction animations can be pre-made sequences of dynamic images used to represent various behaviors and states of virtual entities, such as a character's walking animation, an animation of raising a weapon to attack, an animation of being hit when damaged, and special effects animations when releasing skills. These animation resources are stored in the game's resource management system in the form of video clips, sprite sequences, or skeletal animations.

[0043] First, the interactive calculation data can be parsed to extract the key information necessary to drive the animation playback. This information comes directly from pre-calculated records in the data, including all the behavioral commands executed by each virtual entity, i.e., each hostile configuration element and player configuration element, throughout the interaction process, as well as the resulting changes in state values. For example, the parsing process will extract information such as "At time T, character A launches an attack command against character B" and "At time T+Δt, character B's health points decrease by X points." Based on the parsed behavioral commands, the game system schedules corresponding element interaction animation materials from the animation resource library. This can be seen as a resource matching process. The game system finds and loads pre-made standard animation resources based on the type of behavioral command, such as "attack," "cast spell," and "move," and the identity of the virtual entity issuing the command. For example, when the command is "warrior character performs a normal attack," the warrior character's sword attack animation resource is loaded; when the command is "mage character casts fireball," the fireball's flight and explosion effect animation resources are loaded.

[0044] While scheduling animation resources, the game system can determine the specific performance parameters and activation timing of each animation material based on the precisely recorded state change information and time sequence in the interaction calculation data. State change information is used to dynamically adjust the visual presentation of the animation; for example, when a character's health decreases, the UI animation of their health bar needs to be updated and shortened accordingly; when an attack results in a critical hit, the damage number pop-up animation needs to use a larger font size and a special color. The time sequence strictly defines when each animation action should begin playing, ensuring the synchronization between multiple entities and animations, making the entire battle scene unfold in an orderly manner, like a pre-directed film.

[0045] Finally, the graphics rendering engine can synthesize and continuously play all the loaded animation assets in the graphical user interface according to the defined timeline and visual parameters. This process combines standard animation resources with dynamic calculation data to render a complete battle scene in real time, including character model movements, skill effects, and user interface changes. The game system renders these animations driven by interaction calculation data frame by frame, thereby dynamically and completely reproducing the entire interaction calculation process that has been calculated in the background to the player. And because all visual presentations strictly follow the pre-calculated interaction calculation data, it ensures that regardless of the device's performance, as long as rendering is possible, the displayed battle process and final result will remain absolutely consistent with the logical calculation results.

[0046] As demonstrated by the above embodiments, by encapsulating the strategic intentions of players and the system into independent strategy data packets, this application achieves decoupling of interaction logic from core programs and interface presentation, improving the modularity and maintainability of the game system. Furthermore, by performing centralized calculations on both parties' data packets through a pre-defined interaction decision model, generating definitive interaction calculation data, the high-load real-time logic calculations of traditional architectures are transformed into pre-processing, reducing the real-time computing pressure on client devices and ensuring the smoothness and consistency of results in complex interaction processes. Finally, the animation playback is driven by this definitive calculation data, achieving precise synchronization between logical results and visual presentation, avoiding audiovisual inconsistencies caused by real-time calculation fluctuations. This optimizes system performance and resource utilization efficiency while ensuring strategic depth and game experience.

[0047] Based on any embodiment of the method in this application, in response to an interaction request instruction for a preset enemy character in a graphical user interface, a hostile strategy data packet corresponding to the enemy character is loaded based on the instruction, including: Step S3110: Detect the trigger operation of a specific enemy character control in the interactive area of ​​the graphical user interface, and generate an interactive request instruction containing the corresponding enemy character identifier based on the trigger operation.

[0048] In the graphical user interface, a dedicated interactive area is set up. This area is the responsive part of the interface used to receive player actions on specific functions or objects. In this area, visual elements representing each preset enemy character are implemented as interactive controls, such as a button with a character portrait, a clickable character thumbnail, or a 3D model that directly represents the character on the map. In addition to their visual appearance, these controls can also be associated with a unique data identifier corresponding to the enemy character.

[0049] When a player selects an enemy character control within the designated area by hovering and clicking the cursor, touching it with their finger, or using another input device, the game's input system captures this event and recognizes it as a valid trigger operation. The core of this analysis is identifying the manipulated control object. By querying the internal data bound to the control during its creation, the unique identifier of the enemy character it represents can be accurately obtained. This identifier can be a numeric ID, a globally unique string name, or a specific path pointing to the character's resource.

[0050] Next, the game system assembles and generates a structured interaction request command based on the acquired character identifier. This interaction request command is essentially an information packet containing a specific purpose and necessary data. It includes the enemy character identifier that clearly indicates the specific object the player intends to interact with; additionally, it may contain contextual data such as the player's account information and a timestamp. The command format can be a JSON object with defined fields, a serialized protocol buffer message, or a custom-formatted binary data block. The generated command is then sent to a system module responsible for handling the core game logic, such as a local game logic thread or a remote server, thus formally initiating the corresponding loading and battle process.

[0051] Step S3120: Based on the role identifier in the interaction request instruction, obtain the corresponding enemy strategy data packet from the preset enemy strategy library, and load the enemy strategy data packet into the running memory.

[0052] Because the character identifier carried in the interaction request command can serve as a precise location address or query keyword, the game system can use this identifier to initiate a query to a centralized data storage system called the preset enemy strategy database. The strategy database can be viewed as a repository storing the combat files of all enemy characters, where each file is an independent enemy strategy data packet, and each data packet is indexed and managed by its corresponding character identifier. The retrieval process is an operation of searching and reading based on the identifier. If the strategy database is a database on a server, this step can be a database query, retrieving one or more records using the character identifier as the primary key. These records fully describe the character's behavioral logic and attribute parameters. If the data packet is a local resource file on the client, the game system will construct the correct file path based on the identifier and read the corresponding file content from the disk.

[0053] The next step involves loading the acquired adversary strategy data package into runtime memory. Specifically, static data stored in persistent media such as hard drives and databases is read into the computer's high-speed memory and transformed into a data structure that the program can directly access and process, such as an object containing attribute fields and behavioral function references. Once loaded, all the rules and values ​​defined in the data package are in an active state, ready to be called and calculated by subsequent interactive calculation modules. This logically activates the player's chosen opponent, ensuring that a structured and computable adversary logical entity can be prepared quickly and accurately.

[0054] Through the above implementation methods, this application establishes an efficient and accurate pathway from intuitive operation of the graphical interface to activation of backend logical entities. By solidifying interface operations into instructions carrying precise identifiers, and using these instructions as indexes to retrieve pre-made strategy data packages from the central library, it ensures that each opponent selected by the player can be quickly and accurately instantiated into a computational object with complete behavioral logic. This not only reduces processing delays and logical errors caused by ambiguous targets or incorrect resource positioning, but also facilitates dynamic updates of game content. Adding or modifying opponents only requires updating the data packages in the strategy library, without altering the core interaction process, thereby improving the responsiveness and maintainability of the game system.

[0055] Based on any embodiment of the method in this application, obtaining element selection data for player configuration elements in the graphical user interface, and generating a player strategy data package associated with the element selection data, includes: Step S3210: Based on the player's selection operation on at least one player configuration element in the graphical user interface, determine all the player configuration elements selected by the player within the preset selection rules as a configuration element set.

[0056] The strategy preparation area presented in the graphical user interface displays all currently available player configuration elements. These elements are the basic options that constitute the player's strategy, and can be visually represented as a set of selectable cards, a series of icons representing different unit types, or a row of character portraits with different skills. Each element is associated with a set of predefined attribute and ability data behind the interface.

[0057] Players can express their intention to select certain elements through intuitive interactive actions, such as clicking, dragging to a specific area, or checking checkboxes. The interface logic continuously listens for these actions, and whenever an element is successfully selected, the game system marks it and usually provides visual feedback, such as changing its border color or moving it to the "selected" area to prompt the player. However, to ensure the game's playability, the number of elements that can be selected is generally limited. It must be done within a preset selection rule framework. This rule defines the constraints for constructing an effective set of strategies. Specifically, it may include limiting the total number of selected elements, specifying the proportion of different types of elements, or prohibiting specific combinations of certain elements. For example, one rule might limit the player to select exactly twenty-two cards from all available cards, with a maximum of two cards of a specific type. The game system will perform real-time verification or final review of the current selection status based on these rules, either while the player is making selections or before final confirmation.

[0058] Once the player has completed all selections and confirmed them, the game system will perform a consolidation and confirmation process. This process integrates all the player-selected and rule-validated configuration elements from their scattered interface states into a logical whole, which can be called the configuration element set. This configuration element set can be not only a list containing unique identifiers for all selected elements, but also records the specific state or instructions assigned to each element in this configuration, such as a card being set as a core card or a character having a designated position. Thus, this structured configuration element set completely represents the lineup plan that the player has formulated for the upcoming interaction.

[0059] Step S3220: Perform compliance verification on the selected data of the elements corresponding to the configuration element set, and associate and encapsulate the configuration element set that passes the verification with the current player identifier to generate the player strategy data package.

[0060] First, the game system performs compliance checks on the selected element data corresponding to the configuration element set. This check is an automated rule review process designed to ensure that the player's choices conform to the gameplay's preset balance and logical constraints. The game system checks the current element selection data item by item according to a predefined set of rules. For example, rules might limit the total number of units in battle to no more than seven, or require that the selected units contain at least two different attribute types. The check not only verifies the quantity but also examines the compatibility between elements. For instance, it might prohibit certain conflicting skills from appearing in the same lineup. If the check fails, the player will be prompted to adjust their selection.

[0061] After successful verification, the game system performs an association and encapsulation operation. First, it binds this valid set of configuration elements to a unique identifier for the current player, such as their account ID or session ID, thus clarifying the strategy's ownership. Then, it structures and packages the bound data to generate the final player strategy data package. This encapsulation process is similar to creating a standard-format file for this lineup; the file's cover contains player information, while the content is the verified, structured lineup details. Therefore, the player strategy data package is a self-contained entity that integrates all necessary deployment information and is independent of subsequent processing, facilitating system storage, transmission, or direct calculation.

[0062] The above embodiments, by standardizing players' free selection operations into a standardized data set that passes rule verification, and binding and encapsulating this set with player identities, achieve a reliable transformation of player strategies from interface interactions to computable data entities. This ensures the compliance and balance of player lineups, prevents erroneous or invalid configurations from entering subsequent core calculations, and improves the stability and fairness of the game system. Simultaneously, the generated structured strategy data packets, as independent and complete instruction units, enable the precise and efficient transmission and processing of complex player intentions. They also facilitate unified management, storage, and reuse within the system, thereby enhancing the modularity and maintainability of the overall architecture.

[0063] Based on any embodiment of the method in this application, an interaction calculation is performed on the adversary strategy data packet and the player strategy data packet based on a preset interaction decision model to obtain interaction calculation data between the corresponding adversary configuration element and the player configuration element, including: Step S3310: Determine the configuration element set consisting of multiple configuration strategy elements contained in the adversary strategy data packet and the player strategy data packet, as well as the element interaction logic associated with the configuration element set.

[0064] Before the interactive calculation, the specific entities participating in the battle and their behavioral rules need to be parsed and extracted from the loaded strategy data packets of both sides. First, the game system will open and read the internal structure of the enemy strategy data packet and the player strategy data packet respectively. Each data packet contains a set of configuration elements. This set is not a simple list, but a group of combat units organically composed of multiple configuration strategy elements. For example, in an enemy data packet, this may mean a team composed of five monsters of different classes; while in a player data packet, this may correspond to the seven cards with different functions selected by the player. In this way, the game system can accurately identify these specific elements that make up the cornerstone of the lineup.

[0065] After extracting the specific set of elements, the game system further analyzes the element interaction logic attached to that set. The element interaction logic can be defined as a set of core rules and conditions that define how these elements act and interact with each other. It is not just a skill description of a single element, but a set of rules that govern the coordinated operation of the entire set. For example, for enemy monster groups, the interaction logic can stipulate that tank-type monsters take damage first, ranged units focus fire on the player unit with the lowest health under certain conditions, and a berserk aura effect triggered when a monster is defeated. For player card combinations, the logic can include chain reactions between cards, attribute counter rules, and global modification of the effects of character tactical skills on all cards.

[0066] Therefore, the output of this step is two structured and analytical "battle blueprints" that can be directly understood by the computational model. One blueprint clearly lists all enemy combat units and their built-in coordination commands, while the other clearly lists all player units and their combination rules. The determination of these two blueprints provides accurate and complete input data for the process of putting all units and rules into the same simulation environment for simulation, ensuring that the calculation process can fully cover every interaction that may occur in the battle.

[0067] Step S3320: Input the corresponding hostile configuration elements pre-configured in the hostile strategy data packet to participate in this interactive calculation, and the corresponding player configuration elements configured by the player in the player strategy data packet to participate in this interactive calculation into the interactive decision model to obtain the interactive calculation result containing all calculation process data.

[0068] During the specific calculation process of the interactive calculation steps, all enemy configuration elements representing the enemy and their interaction logic, as well as all player configuration elements representing the players and their interaction logic, are formally submitted to the interactive decision model, which acts as both the referee and the deduction engine. The game system transmits these two sets of complete structured data according to the interface format specified by the model. For example, the interactive decision model can request an input of a battlefield snapshot containing the initial states of all units on both sides, such as position, health, and energy, and a set of scripts defining the behavioral rules of these units. The game system will accurately extract this information from the strategy data packets of both sides and encapsulate it into a format that the model can understand. Subsequently, based on its internally preset algorithm covering all combat rules such as movement, attack, skill judgment, and status effects, the interactive decision model begins to perform fully automatic and step-by-step simulation deduction on the input data. This process is deterministic; the interactive decision model will strictly calculate each interaction according to element attributes, such as the probability parameter of critical hit rate, and conditional logic such as "releasing a healing skill when health is below 50%". It simulates every moment from the start to the end of the battle, deducing what each unit will do, whether it will succeed, and what numerical result it will produce.

[0069] Finally, after the interactive decision-making model completes the simulation of the entire timeline, it outputs the interactive calculation results. This result is an extremely detailed dataset, which not only contains a simple conclusion of victory or defeat, but also fully records all the calculation process data generated during the entire simulation, including the action records, state changes, skill triggering situations, and determination results of all random events of each unit in each round or at each key time point.

[0070] Through the synergistic effect of the above embodiments, the complex strategic composition of both sides is analyzed into clear and structured elements and logical sets, and then handed over to a unified interactive decision-making model for centralized and deterministic full-process deduction. This enables efficient transformation from strategy configuration to battle result calculation. Furthermore, by transforming the heavy-load logical calculations that require real-time processing in the traditional mode into a one-time offline batch data processing process, it not only reduces the dependence on the real-time performance of the operating environment, but also ensures that no matter how complex the battle process is, the calculation results are unique and reproducible, thereby further improving the stability and fairness of the entire interaction process.

[0071] Based on any embodiment of the method in this application, an interaction calculation is performed on the adversary strategy data packet and the player strategy data packet based on a preset interaction decision model to obtain the interaction calculation data between the corresponding adversary configuration element and the player configuration element, and the method further includes: Step S3410: Generate a corresponding random seed based on the current interactive computation request, and configure the random seed in the interactive decision model.

[0072] In game logic involving probabilistic judgments, such as skill critical hits, the triggering of special effects, or the selection of certain random actions, true randomness means that each battle will not be completely identical. Furthermore, as the types of elements and the complexity of battles in the game increase, traditional exhaustive methods, while suitable for problems with few possibilities and clear boundaries when the game is small, become extremely time-consuming and computationally expensive when the number of possibilities is enormous, and may even be impossible. Even if they can be enumerated, the sheer number of possibilities may prevent obtaining a result within a reasonable timeframe. To further establish a reproducible and stable probabilistic environment for interactive calculus, this application addresses this problem by introducing a deterministic random seed.

[0073] In this implementation, the random seed can be an initial value used to initialize the pseudo-random number generator. It can be a number or a string, and its key characteristic is that as long as the same seed is used, the random number sequence generated by the pseudo-random number generator will be exactly the same and predictable. In this step, the seed is not generated arbitrarily, but rather based on the specific context of this interactive calculation request, thus ensuring that each independent battle has its own unique and fixed random sequence. The random seed can be generated based on the unique ID of this battle, the hash value of the player's precise timestamp confirming the battle, or a specific algorithm combining player and enemy character identifiers. After generating the random seed, the game system will configure it in the interactive decision-making model. Before the interactive decision-making model officially begins its calculations, the random number generation module within the model will first receive and load this seed value. After configuration, all probability calculations within the model, such as determining whether an attack hits or what the damage fluctuation value is, will strictly follow the fixed random number sequence determined by the seed to reach a conclusion. Thus, all seemingly random steps in the interactive calculation process are actually pre-locked, ensuring that under the same strategy input, the process and result of each calculation are absolutely deterministic and reproducible, eliminating the uncertainty brought about by true randomness, and providing a solid technical foundation for battle replay, status synchronization and fault diagnosis.

[0074] Step S3420: Based on the preset behavior tree logic in the interaction decision model, analyze the element interaction logic in the adversary strategy data packet and the player strategy data packet respectively, and determine the basic behavior sequence of the corresponding configuration element in the interaction process.

[0075] In this embodiment, a pre-defined behavior tree logic exists within the interactive decision-making model. A behavior tree is a procedural structure commonly used to control virtual entity decisions. It consists of multiple nodes organized in a tree structure, defining a complete logical flow from conditional judgment to specific action execution. In this embodiment, the behavior tree logic serves as a standardized parsing framework that can be applied to both allies and adversaries simultaneously. The game system inputs the element interaction logic encapsulated in the adversary strategy data package and the player strategy data package into this behavior tree parsing framework for processing. This element interaction logic refers to the personalized action rules followed by each combat unit, such as "prioritize attacking the enemy with the lowest health" or "use healing skills when health is below 30%". The role of the behavior tree logic is to translate these textual or data-described rules into a series of strictly enforceable basic behavioral sequences with a clear order.

[0076] Because the parsing process is deterministic, for each configuration element in the data packet, such as an enemy monster or a player card, the behavior tree logic traverses the tree structure based on the interaction logic defined for that element. This traversal is based on conditions set in the logic, such as "whether an enemy is detected within range" or "whether the element has sufficient energy." Following specific branches, it ultimately determines which specific action the element should perform in the current and subsequent interaction environment, such as "moving to the target," "launching a fireball," or "activating a defensive stance," and arranges these actions in order of their trigger timing. For example, after the behavior tree parsing, the basic behavior sequence of a ranged attack unit might be determined as: first, move to a certain location; then, perform three normal attacks on the target; and finally, attempt to retreat when threatened at close range. Thus, the complex and potential strategic descriptions of all participating units on both sides are transformed into explicit and temporally ordered action command queues that can be directly used for simulation and deduction, preparing for subsequent precise calculations incorporating probabilistic factors.

[0077] Step S3430: Combine the random seed to calculate the interaction nodes involving probability determination in the basic behavior sequence, and generate the interaction calculation data containing the corresponding behavior timing instructions and state change sequences.

[0078] After each participating unit has a basic behavioral sequence determined by behavior tree logic, this sequence still contains some uncertain links requiring probability judgment. These links are called probability judgment interaction nodes. For example, an attack action plan might include a node stating "there is a 30% chance of causing double damage," the specific result of which is not yet determined. Therefore, it is necessary to further integrate logical rules with random factors and ultimately solidify the complete battle script. At this point, the pre-configured deterministic random seed can play a further role. The game system initializes a pseudo-random number generator based on this seed and generates a deterministic random value for each probability node in the basic behavioral sequence in a fixed order. This calculation process is rigorous and reproducible: the preset probability condition of the node is compared with the generated random number to obtain a unique and deterministic result for that node. In this way, all probability nodes are resolved one by one, making the originally ambiguous behavioral sequence completely determined.

[0079] Based on this, the game system performs final integration and serialization, generating interaction calculation data. This data includes behavioral timing instructions and state change sequences. The behavioral timing instructions specify the exact action each unit should perform at each precise moment on the interaction timeline, such as "2.1 seconds after the start of the battle, unit A performs a normal attack on unit B." The state change sequences precisely record the numerical results of each interaction, arranged chronologically, such as "At the same moment, unit B's health points change from 100 to 83." Thus, the entire calculation process completely binds logic, probability, and timeline, resulting in a detailed and definitive battle log of interaction calculation data.

[0080] Through the above embodiments of this application, this application can transform the inherent probabilistic factors in the interaction process into completely deterministic and reproducible calculation results by introducing deterministic random seeds and combining them with preset behavior tree logic. This ensures that under the same strategy input, each complete interaction calculation process and all its details are unique and stable, eliminating the unpredictability brought about by real randomness. The resulting interaction calculation data, as a battle script containing precise behavior timing and state changes, not only provides a reliable basis for frame-level synchronization of the game screen's visual presentation, ensuring the consistency of the experience, but also lays a solid technical foundation for game debugging, review, and fairness verification.

[0081] Based on any embodiment of the method in this application, and based on the interaction calculation data, element interaction animations corresponding to the adversary configuration element and the player configuration element are loaded into the graphical user interface to dynamically display the corresponding interaction calculation process, including: Step S3510: Obtain the corresponding interactive animation material based on the interactive calculation data, and determine the rendering attributes and playback nodes of the interactive animation material.

[0082] In order to convert the results of logical calculations into visual presentation effects, the game system first retrieves matching interactive animation materials from the resource library based on the behavior type described in the data, since the data records the behavior commands and status changes of all units during the battle. For example, if the data records "Unit A performed a 'Heavy Cleave' attack", the game system will locate and load an animation clip or effect sequence named "Heavy Cleave".

[0083] The steps to determine rendering attributes can be to assign specific visual performance parameters to the loaded animation materials. Rendering attributes are not fixed in advance, but are dynamically derived from the state change sequence in the interaction calculation data. For example, the damage value caused by an attack determines the number displayed in the blood-splatter effect; the hit position of the attack determines the generation coordinates of the hit effect on the screen; and the change in unit health directly determines the length of its health bar UI animation. By parsing the corresponding interaction calculation data, these dynamic visual parameters that each animation should have when playing can be calculated.

[0084] Determining playback nodes strictly follows the behavioral timing instructions in the interactive calculation data, scheduling a precise start time for each animation segment. The timing instructions specify the occurrence time of each logical event on the global timeline, and the game system timestamps the corresponding animation materials accordingly, such as "play unit B's 'casting' animation at 3.5 seconds after the start of the battle." In this way, all independent animation segments can be arranged into a unified and precise timeline, ensuring the synchronization and rhythm accuracy of the final composite image.

[0085] Step S3520: Based on the global timing specified in the interactive calculation data, synthesize the interactive animation material in the graphical user interface based on the rendering attributes and playback nodes, so as to display the synthesized screen to the graphical user interface.

[0086] To achieve the final visual presentation of the game, all prepared animation assets can be assembled into a continuous battle sequence according to a precise timeline and presented to the player. The global timing, derived from interactive calculation data, is an authoritative and immutable timeline that clearly defines the specific moment each action occurs within the overall battle flow. The game system strictly follows this timeline. At each playback node, the graphics rendering system activates one or more corresponding interactive animation assets to begin playing, while dynamically applying pre-calculated rendering attributes to these animation assets in real time. For example, at the 2.3-second mark specified in the global timing, the "fireball flight animation" and the "target hit animation" will be activated simultaneously. Based on the damage value and hit location recorded in the calculation data, rendering attributes such as the fireball's trajectory coordinates, the intensity of the hit effect, and the reduction in the target character's health bar are accurately applied to the corresponding animation elements.

[0087] The specific implementation of compositing involves the graphics engine overlaying, blending, and rendering these activated, dynamically-attributed animation assets with other visual elements such as scene backgrounds and user interfaces, frame by frame. This ensures that the special effects of an attack action, the target's hit feedback, the floating damage numbers, and the updated health bar interface can appear perfectly synchronized in the same frame. Finally, each frame of the composited image is sent to the graphics output pipeline and displayed on the corresponding area of ​​the graphical user interface, i.e., the player's screen. Thus, the entire data-driven, pre-calculated interactive calculation process is transformed into a smooth, precise, and expressive visual experience.

[0088] The embodiments described above in this application precisely schedule animation resources, control rendering attributes, and drive screen composition based on pre-calculated interactive computation data. This achieves a highly reliable and efficient mapping relationship between logical results and visual presentation, enabling complex multi-unit interactive animations to strictly follow a unique logical blueprint for playback. This ensures the synchronization of actions, consistency of states, and complete predictability of the final result for each frame, avoiding the problem of logic and performance asynchrony that easily occurs in traditional real-time computational rendering. Furthermore, since the visual presentation is entirely driven by deterministic data, this application reduces reliance on the client's real-time computation capabilities, improves rendering efficiency and stability, and provides a more independent and flexible optimization space for the iteration of visual effects in game content.

[0089] Based on any embodiment of the method in this application, the method further includes obtaining corresponding interactive animation materials according to the interactive calculation data, determining the rendering attributes and playback nodes of the interactive animation materials, and then: Step S3610: Based on the animation type specified in the behavior timing instruction, obtain the corresponding interactive animation material from the preset animation resource library.

[0090] In this implementation, the behavior timing instruction, as part of the interactive computation data, not only specifies when the virtual entity acts, but also clarifies the visual form in which the action should be represented through the animation type specified in its internal fields. For example, an instruction may contain type descriptions such as "execute a powerful slashing action" or "play a charged spell effect." After parsing the animation type descriptor in the instruction, the game system immediately uses it as the retrieval basis to initiate a query to the preset animation resource library. This resource library is a system that centrally manages all visual animation assets. Each animation material, such as a skeletal animation sequence, a particle effect prefab, or a sprite atlas, is cataloged and stored through its associated animation type identifier. The query process involves quickly locating and retrieving the corresponding animation resource file or resource reference by matching the type identifier in the instruction. For example, when a behavioral timing instruction requires the performance of an "Frostbolt" attack, the game system will use "Frostbolt" as a keyword to retrieve an animation clip named "Frostbolt_Launch" and the corresponding "Frostbolt_Hit" collision effect material from the resource library. The output of this step is the accurate association between the purely logical behavioral instruction and the specific visual resource, thereby ensuring that every logically occurring action has its unique and definite visual representation available for use.

[0091] Step S3620: Based on the node data corresponding to each time node in the state change sequence, obtain the visual parameters of the interactive animation material at the corresponding node, and determine the rendering attribute based on the visual parameters.

[0092] To translate the numerical results generated by logical calculations into specific instructions controlling the visual details of the animation, this can be achieved by processing a sequence of state changes. This sequence, with time as its axis, precisely records the state values ​​of each virtual entity at key points during the interaction process, such as health points, energy points, position coordinates, or the number of layers of a certain buff effect. The game system processes each time node in this sequence sequentially. For each node, it contains a set of node data, which is a snapshot of all states of the relevant virtual entity at that specific moment. For example, the node data at time point T records that "Character A has 85 health points, is located at coordinates (X,Y,Z), and has a buff effect that increases attack power by 50%".

[0093] Next, the game system extracts or calculates relevant visual parameters from the node data based on the behavior type corresponding to the currently processed interactive animation material. This can be a process of mapping game logic data to the graphics representation domain. For example, for the same "hit" animation, the severity of the hit is calculated based on the change in health points recorded in the node data, and the animation intensity parameters of "slight backward lean" or "severe stagger" are determined accordingly. At the same time, the position coordinates in the node data can determine the generation position of the hit effect in screen space. If the node data contains gain effect information, it can also determine whether to overlay a layer of visual lighting effect on the character.

[0094] Finally, the game system uses these calculated visual parameters to determine the rendering attributes. The corresponding rendering attributes can be a set of specific low-level instructions that the graphics engine uses when it executes the drawing. For example, the animation intensity visual parameter derived from the change in health points will be converted into a scaling factor for the animation playback speed or a blending weight for skeletal animation; the position parameters calculated from coordinates will be converted into world coordinates for the effect emitter; and the gain effect parameters may be converted into shader parameters or dynamic textures attached to the character model. In this way, static animation materials are given a dynamic soul, and the details of each playback are driven by deterministic calculation data, thereby ensuring that the visual performance and logical results are perfectly synchronized.

[0095] Step S3630: Determine the playback node based on the global timestamp contained in the behavior timing instruction, so as to synchronously trigger the interactive animation playback of each configuration element based on the global timestamp.

[0096] In this implementation, a playback coordination mechanism based on an absolute time standard can also be established. In addition to the action type, the behavioral timing instructions necessarily carry a crucial global timestamp. This timestamp is a precise absolute time value calculated from the start of the interactive calculation, such as "3120 milliseconds" or "3.12 seconds." It defines the exact moment when the logical behavior corresponding to the instruction occurs on the global timeline. The game system extracts this global timestamp by parsing each instruction and directly determines it as the playback node of the corresponding interactive animation material. This means that the playback of an animation material no longer depends on the end of other animations or unreliable frame counts, but is anchored to this unified, authoritative absolute time point.

[0097] During the playback execution phase, the game system maintains an internal clock that is strictly aligned with the global timeline. When this clock advances to a point where it perfectly matches the timestamp of a playback node, it immediately triggers all interactive animations associated with that node to begin playing. Since the animation triggers of all configuration elements on both sides refer to the same global timeline, regardless of which side these animation materials belong to or how numerous they are, they can be precisely synchronized and launched. For example, if the timestamps of a player character's attack animation and an enemy character's hit animation are the same, their starting frames will be rendered at the same moment, thus ensuring absolute synchronization of the impact and visual feedback. This achieves a high degree of consistency and timing accuracy in the visual presentation of the entire interactive process.

[0098] Through the synergistic effect of the above embodiments, this application decouples the three core elements of behavior instructions, state data, and global timing and accurately maps them to the acquisition of animation resources, the adaptation of visual parameters, and the synchronization of playback time. This constructs a highly reliable and efficient data-driven animation playback system, ensuring that every logical event can find a definite visual expression form. The presentation details can dynamically and accurately reflect the real-time state in the calculation results. Furthermore, the triggering of all independent animations strictly follows a unified authoritative timeline. This not only achieves frame-level precise synchronization and perfect coordination of multiple units and multiple animations in complex interactive scenarios, eliminating the problems of screen tearing and action asynchrony, but also simplifies the animation playback logic to the execution of deterministic data, reducing the scheduling complexity and performance overhead of the real-time rendering system. Thus, while improving visual expressiveness, it ensures the smoothness and stability of the playback process.

[0099] Please see Figure 3 According to one aspect of this application, a game interaction configuration device includes an instruction response module 4100, an element selection module 4200, an interaction calculation module 4300, and an animation display module 4400. The instruction response module 4100 is configured to respond to an interaction request instruction in a graphical user interface for a preset enemy character, and load an adversarial strategy data package corresponding to the enemy character based on the instruction. The element selection module 4200 is configured to obtain element selection data for player configuration elements in the graphical user interface, and generate a player strategy data package associated with the element selection data. The interaction calculation module 4300 is configured to perform interaction calculations on the adversarial strategy data package and the player strategy data package based on a preset interaction decision model when preset interaction conditions are met, and obtain interaction calculation data between the corresponding adversarial configuration element and the player configuration element. The animation display module 4400 is configured to load element interaction animations corresponding to the adversarial configuration element and the player configuration element in the graphical user interface based on the interaction calculation data, so as to dynamically display the corresponding interaction calculation process.

[0100] Based on any embodiment of the device in this application, the instruction response module 4100 includes: an instruction generation unit, configured to detect a trigger operation on a specific enemy character control in the interactive area of ​​the graphical user interface, and generate an interactive request instruction containing a corresponding enemy character identifier according to the trigger operation; and a strategy acquisition unit, configured to acquire a corresponding enemy strategy data packet from a preset enemy strategy library based on the character identifier in the interactive request instruction, so as to load the enemy strategy data packet into the running memory.

[0101] Based on any embodiment of the device in this application, the element selection module 4200 includes: a set determination unit, configured to determine all the player configuration elements selected by the player within a preset selection rule as a set of configuration elements based on the player's selection operation on at least one player configuration element in the graphical user interface; and a set encapsulation unit, configured to perform compliance verification on the element selection data corresponding to the set of configuration elements, and associate and encapsulate the verified set of configuration elements with the current player identifier to generate the player strategy data packet.

[0102] Based on any embodiment of the device in this application, the interaction calculation module 4300 includes: a data determination unit, configured to determine the configuration element set consisting of multiple configuration strategy elements contained in the adversary strategy data packet and the player strategy data packet, and the element interaction logic associated with the configuration element set; and a result acquisition unit, configured to input the corresponding adversary configuration element pre-configured in the adversary strategy data packet to participate in this interaction calculation, and the corresponding player configuration element configured by the player in the player strategy data packet to participate in this interaction calculation into the interaction decision model, so as to obtain the interaction calculation result containing all calculation process data.

[0103] Based on any embodiment of the device in this application, the interaction calculation module 4300 further includes: a seed generation unit, configured to generate a corresponding random seed based on the current interaction calculation request, and configure the random seed in the interaction decision model; a logic parsing unit, configured to parse the element interaction logic in the adversary strategy data packet and the player strategy data packet respectively based on the preset behavior tree logic in the interaction decision model, and determine the basic behavior sequence of the corresponding configuration element in the interaction process; and a data generation unit, configured to combine the random seed to calculate the interaction nodes involving probability determination in the basic behavior sequence, and generate the interaction calculation data containing the corresponding behavior timing instructions and state change sequences.

[0104] Based on any embodiment of the device in this application, the animation display module 4400 includes: a material confirmation unit, configured to obtain corresponding interactive animation materials according to the interactive calculation data, and determine the rendering attributes and playback nodes of the interactive animation materials; and a material synthesis unit, configured to synthesize the interactive animation materials in the graphical user interface based on the rendering attributes and playback nodes according to the global timing specified in the interactive calculation data, so as to display the synthesized screen to the graphical user interface.

[0105] Based on any embodiment of the device in this application, the material confirmation unit further includes: a material acquisition subunit, configured to acquire corresponding interactive animation materials from a preset animation resource library based on the animation type specified in the behavior timing instruction; an attribute acquisition unit, configured to acquire the visual parameters of the interactive animation material at the corresponding node based on the node data corresponding to each timing node in the state change sequence, so as to determine the rendering attribute based on the visual parameters; and a node determination unit, configured to determine the playback node based on the global timestamp included in the behavior timing instruction, so as to synchronously trigger the interactive animation playback of each configuration element based on the global timestamp.

[0106] Another embodiment of this application also provides a game interaction configuration device. For example... Figure 4 The diagram shows the internal structure of a game interaction 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 a game interaction configuration method.

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

[0108] 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 solution of this application and does not constitute a limitation on the game interaction configuration device to which the solution of this application is applied. The specific game interaction configuration device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

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

[0110] 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 game interaction configuration method of any embodiment of this application.

[0111] 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.

[0112] 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 game interaction, characterized in that, include: In response to an interactive request command in the graphical user interface for a preset enemy character, load the hostile strategy data packet corresponding to the enemy character based on the command; Obtain element selection data for player configuration elements in the graphical user interface, and generate a player strategy data package associated with the element selection data. When the preset interaction conditions are met, an interaction calculation is performed on the hostile strategy data packet and the player strategy data packet based on the preset interaction decision model to obtain the interaction calculation data between the corresponding hostile configuration element and the player configuration element. Based on the interactive calculation data, element interaction animations corresponding to the hostile configuration element and the player configuration element are loaded in the graphical user interface to dynamically display the corresponding interactive calculation process.

2. The game interaction configuration method according to claim 1, characterized in that, The response to the interactive request command for a preset enemy character in the graphical user interface, and the loading of the hostile strategy data packet corresponding to the enemy character based on the command, includes: The system detects trigger operations on specific enemy character controls in the interactive area of ​​the graphical user interface and generates an interactive request instruction containing the corresponding enemy character identifier based on the trigger operation. Based on the role identifier in the interactive request command, the corresponding hostile strategy data packet is obtained from the preset enemy strategy library, and the hostile strategy data packet is loaded into the running memory.

3. The game interaction configuration method according to claim 1, characterized in that, The step of obtaining element selection data for player configuration elements in the graphical user interface and generating a player strategy data package associated with the element selection data includes: Based on the player's selection operation on at least one player configuration element in the graphical user interface, all the player configuration elements selected by the player within the preset selection rules are determined as a configuration element set; The selected data of the elements corresponding to the configuration element set is subjected to compliance verification. The configuration element set that passes the verification is associated and encapsulated with the current player identifier to generate the player strategy data package.

4. The game interaction configuration method according to claim 3, characterized in that, The step of performing interaction calculations on the adversary strategy data packet and the player strategy data packet based on a preset interaction decision model to obtain interaction calculation data between the corresponding adversary configuration element and the player configuration element includes: Determine the configuration element set, which consists of multiple configuration strategy elements, contained in the hostile strategy data packet and the player strategy data packet, as well as the element interaction logic associated with the configuration element set; The corresponding hostile configuration elements pre-configured in the hostile strategy data packet to participate in this interactive calculation, and the corresponding player configuration elements configured by the player in the player strategy data packet to participate in this interactive calculation, are input into the interactive decision model to obtain the interactive calculation result containing all calculation process data.

5. The game interaction configuration method according to claim 4, characterized in that, The step of performing interaction calculations on the adversary strategy data packet and the player strategy data packet based on a preset interaction decision model to obtain interaction calculation data between the corresponding adversary configuration element and the player configuration element also includes: Generate a corresponding random seed based on the current interactive computation request, and configure the random seed in the interactive decision model; Based on the preset behavior tree logic in the interaction decision model, the element interaction logic in the adversary strategy data package and the player strategy data package is parsed to determine the basic behavior sequence of the corresponding configuration element in the interaction process. Based on the random seed, the interaction nodes involving probability determination in the basic behavior sequence are calculated to generate the interaction calculation data containing the corresponding behavior timing instructions and state change sequences.

6. The game interaction configuration method according to claim 5, characterized in that, Based on the interaction calculation data, loading element interaction animations corresponding to the hostile configuration element and the player configuration element into the graphical user interface to dynamically display the corresponding interaction calculation process includes: Based on the interactive calculation data, obtain the corresponding interactive animation materials, and determine the rendering attributes and playback nodes of the interactive animation materials; Based on the global timing specified in the interactive computation data, the interactive animation material is synthesized in the graphical user interface based on the rendering attributes and playback nodes, so as to display the synthesized screen on the graphical user interface.

7. The game interaction configuration method according to claim 6, characterized in that, The step of obtaining corresponding interactive animation materials based on the interactive calculation data and determining the rendering attributes and playback nodes of the interactive animation materials further includes: Based on the animation type specified in the behavior timing instruction, the corresponding interactive animation material is obtained from the preset animation resource library; Based on the node data corresponding to each time node in the state change sequence, the visual parameters of the interactive animation material at the corresponding node are obtained, and the rendering attributes are determined based on the visual parameters. The playback node is determined based on the global timestamp contained in the behavior timing instruction, so as to synchronously trigger the interactive animation playback of each configuration element based on the global timestamp.

8. A game interaction configuration device, characterized in that, include: The instruction response module is configured to respond to interactive request instructions for a preset enemy character in the graphical user interface, and load the hostile strategy data packet corresponding to the enemy character based on the instruction. The element selection module is configured to obtain element selection data for player configuration elements in the graphical user interface and generate a player strategy data package associated with the element selection data. The interaction calculation module is configured to perform interaction calculations on the hostile strategy data packet and the player strategy data packet based on a preset interaction decision model when preset interaction conditions are met, and obtain the interaction calculation data between the corresponding hostile configuration element and the player configuration element. The animation display module is configured to load element interaction animations corresponding to the hostile configuration element and the player configuration element in the graphical user interface based on the interaction calculation data, so as to dynamically display the corresponding interaction calculation process.

9. A game interaction 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