Game battle processing method, device, equipment, storage medium and product

Abstract

The application discloses a game battle processing method and device, equipment, storage medium and product, relate to data processing technical field, the game battle processing method includes: in response to battle trigger instruction, obtain battle event, and load battle data through configuration layer, the battle data is obtained from the planning table, the planning table supports custom extension;Based on the battle data, execute the battle event through the logic layer, and synchronize the execution result to the performance layer, so that the battle event is played back in the performance layer. The application realizes complete separation of battle logic and performance layer, ensures cross-platform absolute certainty of battle result, allows non-technical personnel (planner) to create and combine skills in the configuration layer in a zero-code manner, and the three are not restricted, and work together.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a game battle processing method, apparatus, device, storage medium, and product. Background Technology

[0002] In related technologies, during game development, the combat logic code directly depends on the engine's component system, scene objects, and rendering pipeline. The logic code and the presentation code are intertwined, which means that the combat module can only run in the engine environment. During stress testing, the entire game client must be started, which consumes a lot of graphics resources and makes lightweight verification impossible. Summary of the Invention

[0003] The main purpose of this application is to provide a game combat processing method, device, equipment, storage medium and product, which aims to solve the technical problem of being unable to perform lightweight verification.

[0004] To achieve the above objectives, this application proposes a game combat processing method, which includes: In response to a battle trigger command, the system acquires battle events and loads battle data through a configuration layer. The battle data is obtained from a planning table, which supports custom extensions. Based on the combat data, the combat event is executed through the logic layer, and the execution result is synchronized to the presentation layer for combat replay.

[0005] In one embodiment, the combat data includes at least skill data corresponding to each combat skill, and the combat event includes at least an event type. The step of executing the combat event through the logic layer based on the combat data includes: The logic layer calls the skill data corresponding to each combat skill, and the skill data includes the triggering condition, the condition range, the effect range, and the effect result. Based on the event type, match the corresponding target triggering condition in the skill data; Determine the target combat skill associated with the target trigger condition; Execute the target combat skill.

[0006] In one embodiment, the step of executing the target combat skill includes: Determine the skill type of the target's combat skills; Based on the skill type, the target combat skill is routed to the corresponding execution path and executed.

[0007] In one embodiment, the execution path includes an immediate path and a delayed stack path. Based on the skill type, the target combat skill is routed to the corresponding execution path, and the following steps are performed: If the skill type is an attack power boosting type, then the target combat skill is routed to the instant path and executed instantly; If the skill type is not the attack power incentive type, the target combat skill is pushed into the delay stack path, and the combat skills in the delay stack path are popped out of the stack and executed in sequence. The delay stack path maintains a last-in-first-out execution queue.

[0008] In one embodiment, the combat data includes at least entity data, and the step of pushing the target combat skill into the delay stack path includes: If the number of target combat skills is greater than the number threshold, then obtain the target effect result corresponding to the target combat skill; Locate the affected entities corresponding to the target effect range; Obtain the faction attribute, column position number, and row position number of the affected entity from the entity data; Based on the priority of the target effect result, the faction attribute, the column position number, and the row position number, all the target combat skills are sorted, and the sorted target combat skills are pushed into the delay stack in sequence. The priority of the judgment is from high to low as the target effect result, the faction attribute, the column position number, and the row position number.

[0009] In one embodiment, the combat event includes at least a triggering source entity, and the step of executing the target combat skill includes: Obtain the target condition range and target effect result corresponding to the target combat skill; If the target entity corresponding to the target condition range includes the triggering source entity, then the affected entity is obtained; The execution result is the execution flow event constructed based on the triggering source entity, the target triggering condition, the affected entity, and the target effect result.

[0010] Furthermore, to achieve the above objectives, this application also proposes a game battle processing device, which includes: The loading module is used to respond to combat trigger commands, acquire combat events, and load combat data through the configuration layer. The combat data is loaded from the planning table, which supports custom extensions. The execution module is used to execute the battle event through the logic layer based on the battle data, and synchronize the execution result to the presentation layer so that the battle event can be replayed in the presentation layer.

[0011] In addition, to achieve the above objectives, this application also proposes a game battle processing device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the game battle processing method described above.

[0012] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the game battle processing method described above.

[0013] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the game battle processing method described above.

[0014] One or more technical solutions proposed in this application have at least the following technical effects: In contrast to related technologies where combat logic code directly relies on the engine's component system, scene objects, and rendering pipeline during game development, with logic and presentation code intertwined, combat modules can only run within the engine environment. This necessitates launching a full game client during stress testing, consuming significant graphics resources and hindering lightweight verification. This application, in response to combat trigger commands, acquires combat events and loads combat data through a configuration layer. This combat data is obtained from a design table that supports custom extensions. Based on this combat data, the logic layer executes the combat events, and the execution results are synchronized to the presentation layer for combat replay. This application achieves complete separation of combat logic and presentation, ensures absolute cross-platform determinism of combat results, and allows non-technical personnel (designers) to freely create and combine skills in the configuration layer with zero code, while all three elements work collaboratively without mutual constraints. Attached Figure Description

[0015] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating an embodiment of the game combat processing method of this application. Figure 2 This is a flowchart illustrating Embodiment 2 of the game combat processing method of this application; Figure 3 This is a schematic diagram of the module structure of the game battle processing device according to an embodiment of this application; Figure 4 This is a schematic diagram of the device structure of the hardware operating environment involved in the game combat processing method in the embodiments of this application.

[0018] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0019] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0020] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0021] The main solution of this application embodiment is: in response to a battle trigger command, a battle event is acquired, and battle data is loaded through a configuration layer. The battle data is loaded from a planning table, which supports custom extensions. Based on the battle data, the battle event is executed through a logic layer, and the execution result is synchronized to the presentation layer for battle replay of the battle event in the presentation layer.

[0022] In related technologies, during game development, the combat logic code directly depends on the engine's component system, scene objects, and rendering pipeline. The logic code and the presentation code are intertwined, which means that the combat module can only run in the engine environment. During stress testing, the entire game client must be started, which consumes a lot of graphics resources and makes lightweight verification impossible.

[0023] This application achieves complete separation of combat logic and presentation layer, ensures absolute determinism of combat results across platforms, and allows non-technical personnel (planners) to freely create and combine skills in the configuration layer with zero code, while the three do not restrict each other and work together.

[0024] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or game combat processing device capable of performing the above functions. The following description uses a game combat processing device as an example to illustrate this embodiment and the subsequent embodiments.

[0025] Based on this, the embodiments of this application provide a game combat processing method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the game combat processing method of this application.

[0026] In this embodiment, the game combat processing method includes steps S10~S20: Step S10: In response to the battle trigger command, obtain the battle event and load the battle data through the configuration layer. The battle data is loaded from the planning table, which supports custom extensions. It should be noted that the execution entity in this embodiment is the game combat processing device. A combat trigger command refers to an input signal initiated by player operation, system event, or test script to start a new battle; it is the initial entry point for the combat process. A combat event refers to discrete events that occur during the combat process and can be identified and responded to by the system. As the basic processing unit of the event-driven mechanism, it carries the information required to trigger subsequent logic. The configuration layer is a functional layer specifically responsible for loading, storing, and providing combat-related static configuration data. Combat data refers to a static data set describing all configurable elements in a battle, including but not limited to parameterized information such as skill configuration, effect configuration, character attributes, and trigger conditions. A planning table refers to a configuration file edited and managed in electronic spreadsheet format (such as Excel), which planners can directly fill in and maintain without writing program code. The game combat processing unit responds to combat trigger commands, obtains the corresponding combat events, and then loads the combat data required for this combat through the configuration layer. The combat data is loaded from the design spreadsheet, where designers directly fill in and edit various combat configuration parameters. The game combat processing unit reads these spreadsheets upon startup and loads the data into the configuration layer. The design spreadsheet is designed to support custom expansion. When new content such as skill types, effect parameters, or trigger conditions needs to be added, designers can directly add new columns or fill in new rows in the spreadsheet without modifying any program code or recompiling the project. After loading through the configuration layer, the combat data resides in memory in a structured form, allowing the subsequent logic layer to query and call it as needed during combat execution.

[0027] Understandably, during the startup phase, the game's combat processing mechanism first performs a static scan and registration of the configuration layer. It uses reflection to scan all classes with trigger attribute tags and effect type attribute tags. For each tagged class, its type and corresponding enumeration value are registered in two global dictionaries: a trigger condition dictionary and an effect result dictionary. These dictionaries are used at runtime to dynamically instantiate the corresponding processing logic objects based on the configuration data. All skill configuration data is filled in by the designers in tabular form. The design tables contain skill identifiers, trigger condition types, condition range types, effect range types, effect result types, and their numerical parameters. This tabular data is converted into binary format using a memory serialization tool and loaded into memory during the initialization of the combat logic layer, forming a set of skill configuration objects.

[0028] Step S20: Based on the combat data, execute the combat event through the logic layer and synchronize the execution result to the presentation layer so that the combat event can be replayed in the presentation layer.

[0029] Understandably, the logic layer is responsible for all calculations and state changes of the combat rules, operating independently of any specific game engine or graphical interface, running purely on computational logic. The presentation layer receives the execution results from the logic layer and transforms them into visual, auditory, or other forms of playback presentation perceptible to the user, without containing any combat logic judgments. Combat replay refers to re-executing the recorded sequence of combat events and presenting the entire combat process visually on the presentation layer for review, verification, or viewing purposes. After the game combat processing device loads the combat data in the configuration layer, it executes the combat events through the logic layer based on the combat data. The logic layer runs on an independent thread, generating corresponding execution results. The execution results are output in the form of commands, without containing any specific playback instructions or interface operations. Subsequently, the execution results are synchronized to the presentation layer. The presentation layer passively receives the execution results from the logic layer, without performing any logical judgments or modifications on the execution results, only visually presenting them on the user interface based on the information carried in the execution results. This allows the presentation layer to perform combat replay of the combat events, that is, to reproduce the complete combat process on the presentation layer by reconsuming the recorded sequence of combat events. This achieves a complete separation between combat logic and presentation, allowing the same execution result to be consumed by multiple presentation methods, while ensuring that the presentation layer does not negatively affect the correctness of the combat logic.

[0030] In one feasible implementation, the combat data includes at least skill data corresponding to each combat skill, and the combat event includes at least event type. Step S20 includes: The logic layer calls the skill data corresponding to each combat skill, and the skill data includes the triggering condition, the condition range, the effect range, and the effect result. It should be noted that combat skills are executable capabilities initiated or triggered by combat units (such as characters, monsters, and summoned creatures) during combat. They are the smallest functional units constituting combat rules, containing complete definitions of triggering conditions, scope of effect, and effect. Skill data refers to a structured set of information describing all configurable parameters of a combat skill, which is read and parsed by the logic layer when executing the skill. It contains complete definitions of four orthogonal dimensions: triggering conditions, condition scope, effect scope, and effect result. Triggering conditions refer to the timing conditions that must be met to determine whether a combat skill should be activated, determining when the skill enters a pending state, such as upon death, injury, skill release, the start of combat, summoning, or exiting combat. Condition scope refers to the filtering criteria used to determine whether the triggering conditions apply to the current combat unit, used to determine which entity triggered the skill's conditions, such as itself, friendly members, enemy members, or allied enemies. Effect scope refers to the target selection criteria when the skill effect takes effect, used to determine which combat units are affected by the skill, such as all enemies, random teammates, front-line enemies, itself, or any teammate. The effect result refers to the specific type and value of the impact on the target combat unit after the skill takes effect, describing what the skill actually changes, such as modifying attribute values, fixed damage, special damage, granting status or dispelling.

[0031] Understandably, the game's combat processing device reads the skill data corresponding to each combat skill as needed from the combat data already loaded in the configuration layer through the logic layer. The skill data includes four components: trigger conditions, condition range, effect range, and effect result.

[0032] Based on the event type, match the corresponding target triggering condition in the skill data; It should be noted that when the logic layer of the game's combat processing device receives a combat event to be processed, it first identifies the event type to which the combat event belongs. For example, the event may be a death event triggered by a unit's death, an injury event triggered by a unit taking damage, a skill release event triggered by a unit actively releasing a skill, or other types of events triggered by the start of combat, summoning units, or exiting combat. Subsequently, it iterates through the skill data corresponding to each currently available combat skill, compares the trigger conditions defined in each skill data with the current event type one by one, filters out skills whose trigger conditions match the current event type, and determines the matched trigger condition as the target trigger condition, which serves as the prerequisite for executing the skill.

[0033] Because this step matches target trigger conditions in skill data based on event type, and the trigger conditions in skill data are stored independently in parameterized form rather than hard-coded conditional branch statements in program logic, when a new event type needs to be added or the response relationship of a skill to a specific event type needs to be adjusted, the planner only needs to modify the trigger condition configuration of the corresponding skill in the table, without modifying any condition judgment code.

[0034] Determine the target combat skill associated with the target trigger condition; Understandably, since each trigger condition exists as a component of a certain combat skill in the skill data of the configuration layer, after the game combat processing device matches the target trigger condition, it reverses the lookup through the skill data record to which the trigger condition belongs to find the complete skill definition containing the trigger condition, and determines the combat skill corresponding to the complete skill definition as the target combat skill.

[0035] Execute the target combat skill.

[0036] It should be noted that the game combat processing device executes the target combat skill after determining the target combat skill associated with the target triggering condition.

[0037] In one feasible implementation, the steps of executing the target combat skill include: Determine the skill type of the target's combat skills; Understandably, skill type refers to a classification identifier that categorizes combat skills based on their behavioral characteristics and trigger permissions. It is used to control the behavior pattern of skills within a skill chain, including different categories such as normal skills, condition-ignoring skills, character skills, and combo skills. Different skill types have different permissions in triggering and listening to skill events. The game combat processing device determines the skill type of the target combat skill before or during its execution.

[0038] Based on the skill type, the target combat skill is routed to the corresponding execution path and executed.

[0039] It should be noted that the game's combat processing device, based on the judgment result of the skill type, diverts the target combat skill to different execution paths for processing.

[0040] In one feasible implementation, the execution path includes an immediate path and a delayed stack path. Based on the skill type, the target combat skill is routed to the corresponding execution path, and the following steps are performed: If the skill type is an attack power boosting type, then the target combat skill is routed to the instant path and executed instantly; Understandably, "Attack Power Incentive Type" refers to a skill type specifically designed to influence the attack power attribute of combat units or change the attack power ranking benchmark. Executing this type of skill modifies the attack power value of the relevant combat unit, directly affecting the ranking benchmark of all subsequent skills. "Instant Path" refers to an execution channel that bypasses queuing, is not pushed onto a delay stack, and is executed immediately upon triggering. After the game's combat processing unit identifies that the target combat skill belongs to the Attack Power Incentive Type, it determines that the execution result of this skill will modify the attack power value of the combat unit, thereby changing the attack power ranking benchmark used by subsequent skills in multi-dimensional ranking. Therefore, instead of sending the skill to the delay stack for queuing, it directly sends it to the instant path, ensuring that the skill is executed immediately at the current moment, guaranteeing that the change in attack power value takes effect before any subsequent skills in the delay stack are ranked.

[0041] If the skill type is not the attack power incentive type, the target combat skill is pushed into the delay stack path, and the combat skills in the delay stack path are popped out of the stack and executed in sequence. The delay stack path maintains a last-in-first-out execution queue.

[0042] It should be noted that the delayed stack path is used to temporarily store the execution channels of non-real-time skills. It uses a stack data structure as the underlying storage. All skills sent to this path are first sorted and pushed onto the stack, then popped out and executed sequentially in a last-in-first-out (LIFO) order. When the game's combat processing device identifies that a target combat skill's skill type does not belong to the attack power incentive type, it determines that the skill's execution result will not affect the attack power ranking benchmark. Therefore, it sends the skill to the delayed stack path for queuing. In the delayed stack path, the target combat skill first undergoes multi-dimensional sorting, determining its push order in the stack based on dimensions such as attack power, faction, column, and row. After sorting, the skill is pushed onto the stack data structure. Subsequently, the delayed stack path's pop execution process is triggered, popping and executing all existing combat skills in the delayed stack path sequentially in a LIFO order. That is, the combat skill last pushed onto the stack is popped out and executed first, and the combat skill first pushed onto the stack is popped out and executed last. The delayed stack path maintains a LIFO execution queue throughout the entire process.

[0043] In one feasible implementation, the combat data includes at least entity data, and the step of pushing the target combat skill into the delay stack path includes: If the number of target combat skills is greater than the number threshold, then obtain the target effect result corresponding to the target combat skill; Understandably, the quantity threshold can be set to 1. During the process of pushing a target combat skill onto the delay stack path or during execution path processing, the game combat processing device continuously monitors the number of currently activated or queued skills. When it detects that the number of skills exceeds the quantity threshold, it reads and obtains the target effect result corresponding to that target combat skill.

[0044] Locate the affected entities corresponding to the target effect range; Understandably, the affected entity refers to the combat unit object that, after being filtered by the effect range, is determined to be subject to the actual effect of the current skill; it is the operational target to which the effect result is ultimately applied. The game combat processing device reads the specific configuration value of the effect range dimension from the skill data of the target combat skill to which the target effect result belongs, determines the effect range definition of the skill, and then, using all surviving combat units in the current combat scene as a candidate set, selects combat units that meet the conditions as affected entities according to the filtering rules defined in the target effect range.

[0045] Obtain the faction attribute, column position number, and row position number of the affected entity from the entity data; It should be noted that entity data refers to a structured data set storing all attribute information about each combat unit, including but not limited to static and dynamic information such as the unit's faction attribute, position number, attribute value, and status effects. Faction attribute refers to the classification information identifying the faction to which a combat unit belongs, used to distinguish between friendly and enemy factions, such as allied or enemy factions. Column position number refers to the column number of a combat unit within the battle formation, used to describe the combat unit's position horizontally. Row position number refers to the row number of a combat unit within the battle formation, used to describe the combat unit's position vertically. After locating the object reference or identification information of the affected entity, the game combat processing device accesses the entity data record storing all attribute information of the combat unit. From the record, it reads the position and faction information in three dimensions. First, it reads the faction attribute of the affected entity to obtain its faction identifier, which is used to determine the enemy-ally relationship between the unit and the spellcaster. Then, it reads the column position number of the affected entity to determine the horizontal position of the combat unit in the battle formation, which is used as a sorting dimension in the sorting algorithm. Finally, it reads the row position number of the affected entity to determine the vertical position of the combat unit in the battle formation, which is also used as a sorting dimension in the sorting algorithm.

[0046] Based on the priority of the target effect result, the faction attribute, the column position number, and the row position number, all the target combat skills are sorted, and the sorted target combat skills are pushed into the delay stack in sequence. The priority of the judgment is from high to low as the target effect result, the faction attribute, the column position number, and the row position number.

[0047] Understandably, priority refers to the order in which multiple dimensions are compared during the sorting process, with higher-priority dimensions being compared first. The game combat processing device collects all target combat skills that need to be pushed onto the stack into a set to be sorted. For each target combat skill in the set, it obtains its corresponding target effect result, the faction attribute of the triggering entity, column position number, and row position number as four sorting keys for that skill. According to the preset priority, the sorting keys of each skill are compared from high to low: First, the target effect results of each skill are compared, and the order is determined based on the value of the effect result; if the target effect results are the same, the faction attribute of the triggering entity is compared; if the faction attributes are still the same, the column position number is compared; if the column position numbers are still the same, the row position number is compared. Based on this priority order, all target combat skills are sorted in ascending or descending order to obtain a sorted skill sequence. Then, according to the sorted order, each target combat skill is pushed into the delayed stack data structure in turn, with skills sorted earlier being pushed onto the stack first and skills sorted later being pushed onto the stack last, completing the stack pushing operation.

[0048] In this implementation, by using a four-level fixed priority comparison rule based on target effect result, faction attribute, column position number, and row position number, the execution order of multiple skills with the same triggering conditions and requiring execution in a specific order can be determined in a completely predictable manner, without the problem of uncertain order caused by incomplete sorting criteria.

[0049] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 The combat event includes at least a triggering source entity, the step of executing the target combat skill, and the game combat processing method further includes steps S01~S03: Step S01: Obtain the target condition range and target effect result corresponding to the target combat skill; It should be noted that after determining the target combat skill to be executed, the game combat processing device reads the specific configuration value of the condition range dimension from the skill data of the target combat skill as the target condition range. This target condition range is used to determine which combat unit is the trigger subject to determine whether the condition is met in the subsequent execution process. At the same time, it reads the specific configuration value of the effect result dimension from the skill data of the target combat skill as the target effect result. This target effect result is used to determine what specific type of influence and numerical parameters are applied to the target combat unit in the subsequent execution process.

[0050] Step S02: If the target entity corresponding to the target condition range includes the trigger source entity, then obtain the affected entity; It is understood that the triggering source entity refers to the original combat unit that initiated the currently being processed combat event. The game combat processing device filters each combat unit in the current combat scene based on the configured value of the target condition range, generating a set of target entities that satisfy the definition of the condition range. If the target entity set contains the triggering source entity, it is determined that the initiator of the current combat event meets the condition range requirements of the skill, and then the affected entity is further acquired. When the triggering source entity does not meet the target condition range, the subsequent acquisition of the effect range and application of the effect result are skipped, avoiding unnecessary calculations that consume system resources.

[0051] Step S03: The execution flow event constructed based on the triggering source entity, the target triggering condition, the affected entity, and the target effect result is taken as the execution result.

[0052] It should be noted that the game combat processing device uses the trigger source entity as the identifier of the skill's trigger initiator, the target trigger condition as the basis for the skill's activation timing, the affected entities as the final set of objects affected by the skill's effect, and the target effect result as the specific impact content actually applied by the skill. These four elements are combined into a complete execution flow event according to a predefined event structure. This event records the entire chain information of this skill execution, from the trigger source to condition matching, target selection, and effect application. After construction, the execution flow event is output as the execution result of the logic layer for subsequent processes to consume.

[0053] In one feasible implementation, the combat event can be triggered by the combat entity itself or passively triggered by the skill released by other entities. For example, a group damage skill triggered when A dies may cause B to passively trigger a defensive skill. After the target effect result is determined, the Boolean value of the cascaded effect switch corresponding to each target effect result is read in sequence. For effect results where the Boolean value of the cascaded effect switch is true, a corresponding combat event is generated and sent to the event bus after the effect result is executed; for effect results where the Boolean value of the cascaded effect switch is false, no corresponding combat event is generated after the effect result is executed.

[0054] Specifically, the cascading effect switch refers to a Boolean control field configured independently for each effect result dimension of skill data. It controls whether a given effect result triggers subsequent skill events after execution; a true value triggers the event, while a false value does not. For example, if a skill contains both health deduction and attack buff effects, the system can ensure that the health deduction effect triggers a subsequent skill after execution, while the attack buff effect does not trigger any skill. Because this control granularity is refined to the level of individual effect results rather than being limited to the overall skill level, designers can allow certain side effects of a skill (such as additional damage) to continue propagating through the skill chain, while other side effects (such as attribute buffs) serve as the final node of the skill and do not generate any cascading propagation.

[0055] Furthermore, the process of executing the target combat skill includes: The skill attributes of the target combat skill are read. If the skill attribute is a normal skill, then during the execution of all effects of the target combat skill, no skill trigger events generated by the execution of the target combat skill are sent to the logic layer. Simultaneously, during the listening and matching process of combat events, the target combat skill is excluded from the listening target set of all trigger conditions, ensuring that the target combat skill will not trigger other skills upon completion of its own execution. If the skill attribute is an ignore-condition skill, then during the execution of the effect of the target combat skill, the skill trigger events generated by the execution of the target combat skill are allowed to be sent to the event bus. During the listening and matching process of the event bus, the target combat skill is excluded from the listening target set of all trigger conditions, ensuring that the target combat skill will not trigger other skills upon completion of its own execution. The target combat skill is excluded from the set of listening targets for all triggering conditions, so that the target combat skill can trigger other skills but will not be triggered by other skills itself, forming a chain behavior of one-way output without receiving input. If the skill type is a character skill, when the effect result of the target combat skill is executed, the skill triggering event generated by the execution of the target combat skill is allowed to be sent to the event bus. At the same time, during the listening and matching process of the event bus, the target combat skill is included in the set of listening targets for all triggering conditions, so that the target combat skill can trigger other skills by its own execution and can also be triggered by the execution of other skills, with a complete two-way skill chain participation capability.

[0056] Furthermore, during the process of sequentially pushing the sorted target combat skills onto the delay stack, each combat skill pushed onto the delay stack is assigned a push sequence number bound to the combat skill itself. The push sequence number is a monotonically increasing integer number. When the combat skills in the delay stack path are reordered due to external events, for combat skills whose order changes after sorting, the push sequence numbers already assigned to each combat skill remain unchanged. At the same time, the push sequence number and pop sequence number of each popped combat skill are output in the pop record of the delay stack path, so as to verify whether the relative order of the same combat skill before and after reordering meets the deterministic requirement during playback.

[0057] In this implementation, before an event is consumed by the presentation layer or written into the event sequence recording, the validity of the target effect's numerical value, the state premise of the affected entity, and the logical consistency with the triggering source entity are actively verified, rather than passively trusting all intermediate data generated in the previous stage of the skill execution pipeline. Therefore, in cases of abnormalities such as errors in filling in configuration layer data or extreme nesting of skill chains leading to numerical overflow, the abnormalities can be actively identified and intercepted or corrected before the event escapes from the logic layer, fundamentally preventing erroneous data from polluting the event sequence recording or causing abnormal playback in the presentation layer.

[0058] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the game combat processing method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0059] This application also provides a game combat processing device, please refer to... Figure 3 The game combat processing device includes: Loading module 10 is used to respond to combat trigger commands, acquire combat events, and load combat data through a configuration layer. The combat data is loaded from a planning table, which supports custom extensions. The execution module 20 is used to execute the battle event through the logic layer based on the battle data, and synchronize the execution result to the presentation layer so that the battle event can be replayed in the presentation layer.

[0060] Optionally, the execution module includes: The matching submodule is used to call the skill data corresponding to each combat skill through the logic layer. The skill data includes trigger conditions, condition range, effect range, and effect result. Based on the event type, it matches the corresponding target trigger condition in the skill data; determines the target combat skill associated with the target trigger condition; and executes the target combat skill.

[0061] Optionally, the matching submodule includes: The first judgment unit is used to determine the skill type of the target combat skill; based on the skill type, the target combat skill is routed to the corresponding execution path and executed.

[0062] The second judgment unit is used to obtain the target condition range and target effect result corresponding to the target combat skill; if the target entity corresponding to the target condition range includes the trigger source entity, then the affected entity is obtained; and the execution flow event constructed based on the trigger source entity, the target trigger condition, the affected entity and the target effect result is used as the execution result.

[0063] Optionally, the first determination unit includes: The routing subunit is used to route the target combat skill to the instant path and execute it instantly if the skill type is an attack power incentive type; if the skill type is not an attack power incentive type, the target combat skill is pushed onto the delay stack path, and the combat skills in the delay stack path are popped off the stack path in sequence for execution, and the delay stack path maintains a last-in-first-out execution queue.

[0064] Optionally, the routing subunit includes: A sorting component is used to: if the number of target combat skills is greater than a threshold, obtain the target effect result corresponding to the target combat skill; locate the affected entity corresponding to the target effect range; obtain the faction attribute, column position number, and row position number of the affected entity from the entity data; sort all the target combat skills based on the judgment priority of the target effect result, the faction attribute, the column position number, and the row position number, and push the sorted target combat skills into the delay stack in sequence, wherein the judgment priority from high to low is the target effect result, the faction attribute, the column position number, and the row position number.

[0065] The game battle processing apparatus provided in this application, employing the game battle processing method described in the above embodiments, can solve the technical problems of game battle processing. Compared with the prior art, the beneficial effects of the game battle processing apparatus provided in this application are the same as those of the game battle processing method provided in the above embodiments, and other technical features in the game battle processing apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0066] This application provides a game battle processing device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the game battle processing method in the above embodiment 1.

[0067] The following is for reference. Figure 4 The diagram illustrates a structural schematic of a game battle processing device suitable for implementing embodiments of this application. The game battle processing device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, tablets, digital broadcast receivers, PDAs (Personal Digital Assistants), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 4 The game combat processing device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0068] like Figure 4 As shown, the game battle processing device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the game battle processing device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. The communication device 1009 allows the game battle processing device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a game battle processing device with various systems, it should be understood that implementing or having all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0069] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0070] The game combat processing device provided in this application, employing the game combat processing method described in the above embodiments, can solve the technical problems of game combat processing. Compared with the prior art, the beneficial effects of the game combat processing device provided in this application are the same as those of the game combat processing method provided in the above embodiments, and other technical features of the game combat processing device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0071] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0072] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0073] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the game battle processing method described in the above embodiments.

[0074] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0075] The aforementioned computer-readable storage medium may be included in the game battle processing device; or it may exist independently and not be assembled into the game battle processing device.

[0076] The aforementioned computer-readable storage medium carries one or more programs. When the one or more programs are executed by the game combat processing device, the game combat processing device: responds to a combat trigger command, acquires a combat event, and loads combat data through a configuration layer. The combat data is obtained from a planning table, which supports custom extensions. Based on the combat data, the device executes the combat event through a logic layer and synchronizes the execution result to a presentation layer for combat replay at the presentation layer.

[0077] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0078] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0079] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0080] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described game battle processing method, thereby solving the technical problems of game battle processing. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the game battle processing method provided in the above embodiments, and will not be repeated here.

[0081] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the game battle processing method described above.

[0082] The computer program product provided in this application can solve the technical problems of game battle processing. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the game battle processing method provided in the above embodiments, and will not be repeated here.

[0083] The above description is only a part of the embodiments of this application and does not limit the scope of protection of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included in the scope of protection of this application.

Claims

1. A method for handling game combat, characterized in that, The game combat handling method includes: In response to a battle trigger command, the system acquires battle events and loads battle data through a configuration layer. The battle data is obtained from a planning table, which supports custom extensions. Based on the combat data, the combat event is executed through the logic layer, and the execution result is synchronized to the presentation layer for combat replay.

2. The game combat processing method as described in claim 1, characterized in that, The combat data includes at least skill data corresponding to each combat skill, and the combat event includes at least an event type. The step of executing the combat event through the logic layer based on the combat data includes: The logic layer calls the skill data corresponding to each combat skill, and the skill data includes the triggering condition, the condition range, the effect range, and the effect result. Based on the event type, match the corresponding target triggering condition in the skill data; Determine the target combat skill associated with the target trigger condition; Execute the target combat skill.

3. The game combat processing method as described in claim 2, characterized in that, The steps for executing the target combat skill include: Determine the skill type of the target's combat skills; Based on the skill type, the target combat skill is routed to the corresponding execution path and executed.

4. The game combat processing method as described in claim 3, characterized in that, The execution path includes an immediate path and a delayed stack path. Based on the skill type, the target combat skill is routed to the corresponding execution path, and the following steps are performed: If the skill type is an attack power boosting type, then the target combat skill is routed to the instant path and executed instantly; If the skill type is not the attack power incentive type, the target combat skill is pushed into the delay stack path, and the combat skills in the delay stack path are popped out of the stack and executed in sequence. The delay stack path maintains a last-in-first-out execution queue.

5. The game combat processing method as described in claim 4, characterized in that, The combat data includes at least entity data, and the step of pushing the target combat skill into the delay stack path includes: If the number of target combat skills is greater than the number threshold, then obtain the target effect result corresponding to the target combat skill; Locate the affected entities corresponding to the target effect range; Obtain the faction attribute, column position number, and row position number of the affected entity from the entity data; Based on the priority of the target effect result, the faction attribute, the column position number, and the row position number, all the target combat skills are sorted, and the sorted target combat skills are pushed into the delay stack in sequence. The priority of the judgment is from high to low as the target effect result, the faction attribute, the column position number, and the row position number.

6. The game combat processing method as described in claim 5, characterized in that, The combat event includes at least a triggering source entity, and the step of executing the target combat skill includes: Obtain the target condition range and target effect result corresponding to the target combat skill; If the target entity corresponding to the target condition range includes the triggering source entity, then the affected entity is obtained; The execution flow event constructed based on the triggering source entity, the target triggering condition, the affected entity, and the target effect result is used as the execution result.

7. A game combat processing device, characterized in that, The device includes: The loading module is used to respond to combat trigger commands, acquire combat events, and load combat data through the configuration layer. The combat data is loaded from the planning table, which supports custom extensions. The execution module is used to execute the battle event through the logic layer based on the battle data, and synchronize the execution result to the presentation layer so that the battle event can be replayed in the presentation layer.

8. A game combat processing device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the game battle processing method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the game battle processing method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the game battle processing method as described in any one of claims 1 to 6.

Images