A method and system for processing instant combat data

Abstract

The application discloses a kind of processing method and system of instant combat data, the method is applied to the system including logic layer, middle layer and view layer, comprising the following steps: logic layer generates view execution command, and the view execution command is stored in command buffer middle layer based on logical instance identification by intermediate data manager;View layer polls the command buffer middle layer, and obtains the view execution command list associated with target logical instance identification;The view layer parses the type code of the view execution command, and the corresponding processor execution command is obtained by type mapping to drive view update;After the view execution command is executed, it is recycled by object pool and reused.The application realizes the efficient decoupling of logic and view, while ensuring the same structure anti-cheating of both ends, greatly improves the expansion of heterogeneous play and the management efficiency of complex skill life cycle.

Description

Technical Field

[0001] This invention belongs to the field of electronic game technology, and specifically relates to a method and system for processing real-time combat data. Background Technology

[0002] Real-time combat is a core gameplay element, involving complex skill effect combinations, character behavior and state control, and massive data processing. As gameplay becomes increasingly diverse and system performance demands rise, the underlying architecture and logic processing mechanisms of the real-time combat system face ever-growing challenges.

[0003] In current game development, to reduce the coupling between logic and presentation, the industry has begun to explore layered designs for combat architecture. For example, Chinese invention patent application CN119925924A discloses a game combat method and apparatus based on the synchronization of a logic layer and a rendering layer. This method creates instances of a combat logic layer and a combat rendering layer simultaneously at the start of combat. The combat logic layer is responsible for initializing and setting the attributes, skills, and combat rules of the game characters; the combat rendering layer is responsible for implementing visual and audio effects based on the data generated by the combat logic layer. Combat commands generated by user operations are transmitted from the combat logic layer to the combat rendering layer every frame.

[0004] The above solutions still have the following problems when dealing with complex real-time combat environments characterized by high concurrency, high scalability, and cross-platform synchronization: This scheme employs a frame-by-frame direct command transmission mode, lacking an independent intermediate data buffer and isolation mechanism between the logic layer and the rendering layer (presentation layer). This results in the lifecycle of the logic layer remaining tightly intertwined with that of the presentation layer. Consequently, the logic layer cannot truly operate independently and silently on the server side, detached from the client's rendering resources. If the logic is executed solely by the client, it is highly susceptible to being tampered with by cheats; if it relies on high-frequency synchronous rendering commands from the server, it will incur significant communication overhead and network latency, and it cannot support the low-cost parallel simulation of multiple battle logics in the background.

[0005] When faced with the demands of various combat types (such as PVE dungeons, PVP arenas, and various customized gameplay modes), the existing layered architecture lacks a dynamic polymorphic component registration and downward addressing replacement mechanism. This makes it difficult to reuse the logic and presentation modules of different gameplay modes at the underlying level, and the code of each gameplay mode is often intertwined and interferes with each other, severely limiting the horizontal scalability of the framework.

[0006] Traditional role control systems often require complex character AI logic and hard-coded branch decisions for the character's current state. Because they do not decouple the AI's decision intent from the character's current state, state transition control and condition checks become extremely cumbersome as the number of behavioral states increases, making expansion and maintenance extremely difficult.

[0007] In real-time combat environments, a skill typically includes multiple complex sub-effects such as damage, healing, and projectile creation. Current technologies often contain all the continuous performance logic of a single skill class, making effects unusable. This is particularly problematic when dealing with persistent, chain-triggered effects (such as missile tracking or secondary area-of-effect explosions upon hit). The forced coupling of the skill object's lifecycle with the continuous effect's lifecycle makes it difficult to define the skill object's termination boundary, resulting in extremely chaotic lifecycle management. Furthermore, designers are unable to independently and flexibly configure and expand various complex skill effect combinations using configuration tables. Summary of the Invention

[0008] This invention provides a method and system for processing real-time combat data. By constructing a three-layer asynchronous decoupled architecture consisting of a logic layer, a middleware layer, and a view layer, and combining polymorphic component extension, state machine intent separation, and skill lifecycle stripping mechanism, it aims to solve problems such as high dual-end communication load and easy cheating caused by strong coupling between logic and presentation in existing real-time combat architectures, difficulty in reusing heterogeneous gameplay code, and chaotic lifecycle management of complex skill chain effects.

[0009] To address the aforementioned technical problems, this invention proposes a method for processing real-time combat data, which is applied to a system comprising a logic layer, an intermediate layer, and a view layer. The intermediate layer includes an intermediate data manager and a command buffer intermediate layer; The logic layer generates view execution commands, and the intermediate data manager stores the view execution commands into the command buffer intermediate layer based on the logic instance identifier. The view layer polls the command buffer intermediate layer to obtain a list of view execution commands associated with the target logical instance identifier; The view layer parses the type code of the view execution command, obtains the corresponding processor through type mapping to execute the view execution command, and drives the view update; After the view execution command is completed, it is recycled and reused through the object pool; The logic layer and the view layer are decoupled through an intermediate layer. The logic layer can run independently on the server side without the view layer and produce consistent battle results.

[0010] Preferably, the method further includes: storing intermediate layer data objects corresponding to different logical instance identifiers using a type-object dictionary in the intermediate data manager; When a data retrieval request is received, based on the parent class type in the request, a polymorphic query mechanism is used to retrieve and return a matching subclass instance object from the dictionary, so as to achieve compatibility between the logic layer and the view layer for heterogeneous combat gameplay.

[0011] Preferably, the command buffer intermediate layer controls the queuing behavior of view execution commands by setting an enable flag; If the enable flag is disabled, the view execution commands generated by the logic layer are directly discarded or skipped to stop occupying view layer resources when the battle instance is switched to background execution or the battle performance is skipped.

[0012] Preferably, the processing method further includes a role control flow executed within the logic layer: The unit AI module calculates and generates action intentions for each frame, and stores the action intentions in the unit memory module; The driving unit state machine attempts to transition to a new state based on the stated action intention, and performs a condition rejection check before transitioning. Only when the condition rejection check passes and the state transition is successful, the action intent data is obtained from the unit memory module from the target state after the transition, and the corresponding view execution command is generated to drive the view layer to display the corresponding behavior of the character.

[0013] Preferably, the driving unit state machine attempts to perform a state transition according to the action intention, specifically including: If the target state to be jumped to is determined to be the same as the current state, the same state re-entry logic is triggered to refresh the internal timing and behavior of the state. If it is determined that the target state to be jumped to is different from the current state, the identifier of the target state is transmitted and recorded when exiting the current state, and the identifier of the current state is received and processed when entering the target state, so as to achieve a smooth handover of context between different state jumps.

[0014] Preferably, the processing method further includes a skill execution flow executed within the logic layer: When a character uses a skill, a running skill object is created to maintain basic release information and trigger skill sub-effects; If the skill sub-effect includes a persistent application effect, then the running skill object creates a persistent effect processing object independent of itself. The persistent application effect is taken over and maintained by the persistent effect processing object, which is also responsible for generating the view execution command corresponding to the persistent application effect. Meanwhile, the running skill object ends its lifecycle and is recycled immediately after triggering the creation action.

[0015] Preferably, when creating and triggering the skill sub-effect, the skill execution process further includes: Dynamically retrieve effect targets based on skill configuration information; the effect targets include the skill user themselves, a single primary target, or a set of targets within a specific range. An effect processor corresponding to the sub-effect is created according to the preset script configuration, and context data containing the snapshot data of the skill applicant and the effect target is passed to the effect processor; The effects processor is immediately recycled and reused after the instantaneous calculation based on context data is completed.

[0016] Preferably, the processing method further includes a functional component extension process for constructing the logic layer and view layer objects: Dynamically register components using a component manager attached to class instances; When a new component is added, if a parent component of the new component already exists in the component manager, the parent component is removed and replaced with the new component. When retrieving a component, the system prioritizes matching the specified component type. If the component does not exist, it searches downwards and returns its subclass components.

[0017] Preferably, the processing method further includes a lifecycle separation management process for combat instances: When the view of a battle instance is activated, a view layer object is created that is bound to the logic layer object of that battle instance. The view layer object handles the scene loading and object rendering process in a unified manner. When the battle instance is switched to background execution, only the corresponding view layer object and presentation resources are unloaded, while the logic layer object is maintained to be updated and calculated independently in the background. Furthermore, by setting the corresponding flag bit to stop processing buffer commands, low-cost parallel execution of multiple battle logics is achieved.

[0018] A second aspect of the invention also provides a real-time combat data processing system, said system for implementing the processing method as described in the first aspect of the invention, comprising: The middleware module includes an intermediate data manager and a command buffer middleware. The logic layer module is used to generate view execution commands and store the view execution commands into the command buffer intermediate layer based on the logic instance identifier through the intermediate data manager of the intermediate layer module. The view layer module is used to poll the command buffer intermediate layer to obtain a list of view execution commands associated with the target logical instance identifier; parse the type code of the view execution command, obtain the corresponding processor through type mapping to execute the view execution command to drive view update; and recycle and reuse the view execution command through the object pool after the view execution command is executed. The logic layer module and the view layer module are decoupled from each other through the intermediate layer module. The logic layer module can run independently on the server and produce consistent battle results without the view layer module.

[0019] Compared with the prior art, the present invention has the following technical effects: 1. The method proposed in this invention constructs a three-layer architecture of logic layer, middle layer, and presentation layer, and uses command buffer queue to decouple asynchronous data, so that the same set of core combat logic can run independently on the server side without the client, producing consistent combat results, thereby avoiding the technical bottlenecks of pure client-side cheating and pure server-side high-frequency communication.

[0020] 2. The method proposed in this invention utilizes the polymorphic query of the intermediate data manager and the dynamic registration and replacement mechanism of functional components. Different combat gameplays can reuse basic logic modules, and on this basis, dynamically achieve backward compatibility and load customized subclass performance components, ensuring clear isolation of the code for each gameplay and improving the maintainability and scalability of the system.

[0021] 3. The method proposed in this invention separates the process of AI decision-making and intention generation from the specific execution of the unit state machine, and introduces an exclusion verification mechanism before state transition, so that the AI ​​decision module can focus on logical deduction, simplify the condition judgment link of state switching, and support the smooth handover of context parameters between states.

[0022] 4. The method proposed in this invention decomposes skill sub-effects by objectification, so that the running skill object can end its life cycle after triggering a continuous action (such as missile launch), and the subsequent business is taken over by an independent continuous effect handling object. This effectively prevents memory redundancy and object management chaos caused by long-cycle chain effects and improves the planner's independent configuration capability.

[0023] 5. The method proposed in this invention supports a single manager driving multiple logic instances. When switching to the background during battle or activating auto-play, the buffer queue is blocked by setting an enable flag and the view display resources are unloaded separately, thus completely releasing rendering resource overhead while maintaining silent operation of the underlying logic. Attached Figure Description

[0024] Figure 1 This is a flowchart illustrating the processing method described in this invention. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with specific embodiments of the present application and with reference to the accompanying drawings.

[0026] Example 1 like Figure 1As shown, this embodiment is a method for processing real-time combat data. The method is applied to a system comprising a logic layer, a middleware layer, and a view layer. This system breaks away from traditional tightly coupled designs in its underlying code architecture, constructing a bottom-up, three-layer decoupled architecture: logic layer – middleware layer – view layer. Specifically, the macroscopic physical / logical division of this system is as follows: The logic layer, acting as the system's computational brain, is responsible for performing purely black-box numerical calculations and rule processing, including but not limited to AI decision-making calculations, state machine transition management, and skill lifecycle maintenance. This logic layer completely eliminates any dependence on specific rendering engines or visual resources at the code level.

[0027] Middle Layer: Serving as the system's data hub and isolation zone, this layer primarily comprises an intermediate data manager and a command buffer middle layer. Located between the logic layer and the view layer, this middle layer allows the underlying action intentions generated by the logic layer to be buffered and retained here in the form of standardized data.

[0028] View Layer (Presentation Layer): As the system's presentation terminal, it is specifically responsible for receiving instructions and transforming them into visual effects visible to the player. It does not participate in any core numerical value determination, but is only responsible for rendering processes such as scene loading, object instantiation, particle effect playback, and UI updates.

[0029] In this architecture, the logic layer and view layer are decoupled through an intermediate layer, allowing the logic layer to run independently on the server side and produce consistent battle results. In the specific operating environment of this embodiment, because the logic layer and view layer are isolated through the intermediate layer, the logic layer object can run independently and silently on the server side, detached from the client's view display resources. In actual business application scenarios, the server can instantiate and run only the logic layer as an authoritative arbitrator, thereby preventing client-side cheating and reducing the server's communication and rendering computational load. Simultaneously, the client can synchronously instantiate the logic layer, intermediate layer, and view layer, utilizing the real-time computation of the local logic layer to ensure smooth gameplay for players. Based on this decoupled architecture, the logic layers on both ends can deduce completely identical battle results based on the same random number seed and input commands, thus ensuring both security and real-time interactive performance.

[0030] The implementation of game skill logic involves skill execution management, the execution of various skill effects, passive triggering, and chain reaction effects. In a real-time combat environment, it also requires handling skill hit detection. From a project development perspective, it is also necessary to efficiently develop and implement complex skill logic. To support highly complex skill chains and decoupled flow, the logic layer defines a hierarchical skill module system. Specifically, it includes: Initial skill objects (such as FightInitialSkill): Attached to the character unit and managed by FightUnitInitialSkillMgr on the character, responsible for statically maintaining the basic data of the character's skills and managing cooldown time (CD).

[0031] The running skill object (such as FightRunningSkillBase) serves as a dynamic carrier during skill release, possessing an independent lifecycle. It is used to maintain skill targets, configurations, and caster snapshot data. Specifically, when a character releases a skill, a FightRunningSkillBase object is created. The FightRunningSkillBase object has a lifecycle, managed and driven by the FightRunningSkillMgr on the combat logic object, maintaining basic skill release information, including skill targets, skill target points, skill configurations, skill levels, and caster information.

[0032] Atomized Effect Processors: A skill typically has multiple additional effects. The system breaks down skill effects into multiple atomic sub-effects, and generates actual application effects through combination and chain triggering. Sub-effects have predefined processing logic and required parameter fields, and their implementation can be easily added, such as: damaging targets, creating projectile missiles, area damage, adding buffs, attribute changes, etc. This system decomposes complex skill performance into multiple independent atomic sub-effects (such as damage determination, additional status effects, projectile generation, etc.). Each sub-effect corresponds to an independent effect processor, which handles only a single dimension of logic, thus supporting the implementation of complex skill chain logic through combination configuration.

[0033] In addition, to support the aforementioned three-layer architecture of logic layer-middle layer-view layer and achieve efficient asynchronous decoupling and cross-playability expansion, this embodiment employs specific static data structures and interface designs for the middle layer and related core managers. Specific component designs include the middle layer data manager (FightLogicMgr) and the command buffer middle layer (CMDBufferMidder).

[0034] In the intermediate data manager, a type-object dictionary is used to store intermediate layer data objects corresponding to different logical instance identifiers. When a data acquisition request is received, based on the parent class type in the request, a polymorphic query mechanism is used to retrieve and return the matching subclass instance object in the dictionary, so as to achieve compatibility between the logic layer and the view layer for heterogeneous combat gameplay.

[0035] Specifically, the middle-layer data manager is a static global management class, primarily responsible for isolating and maintaining heterogeneous data and implementing a polymorphic retrieval mechanism when multiple battles coexist. Internally, the middle-layer data manager maintains a core storage container, employing a two-layer dictionary structure of type-component objects. The outer dictionary's keys correspond to unique logical instance identifiers (logicUid), used to isolate different battle logic instance data when multiple battles are executed simultaneously. The inner dictionary's keys correspond to the type of the middle-layer data object, and the values ​​correspond to specific data instances that implement the middle-layer abstract interface (IFightMiddler).

[0036] The intermediate layer data manager exposes a registration interface (Regiest) to the outside world. When a logical layer object is created, multiple corresponding intermediate layer data objects can be registered for it.

[0037] The intermediate data manager exposes a polymorphic retrieval interface supporting generic constraints. Internally, it utilizes a type derivation verification mechanism to retrieve and return specific derived subclass instances by passing in a parent class type. This polymorphic query mechanism allows the upper-layer scheduling module to obtain heterogeneous data without needing to be aware of specific business types, thereby achieving backward compatibility and dynamic expansion of the logic and view layers for heterogeneous combat gameplay.

[0038] The intermediate layer data manager also includes a reset interface (Reset), which is used to clean up and reset all intermediate layer data objects under a specified logical instance with one click when the instance's lifecycle ends or it is switched.

[0039] The following is an example of the core class structure of the intermediate layer data manager in this embodiment: public static class FightMiddleDataMgr { / / Structure: logicUid->(Type->IFightMiddler) static Dictionary <int,Dictionary<Type,IFightMiddler> >dicMiddlers? / / Register intermediate layer data objects public static void Regiest(int logicUid,IFightMiddler middler); / / Supports polymorphic acquisition: Retrieving a child instance using the parent class type public static T Get <t>(int logicUid) where T : class, IFightMiddler; / / Reset all intermediate layer data of the specified logical layer public static void Reset(int logicUid); }

[0040] The command buffer middle layer is a concrete data class that implements the middle layer abstract interface (IFightMiddler), and is specifically used as a pipeline buffer for the issuance of commands from the logic layer and the polling of commands from the view layer.

[0041] The command buffer intermediate layer contains a command cache queue for sequentially accumulating view execution commands written by the logic layer that have not yet been processed by the view layer. The command buffer intermediate layer also has a boolean enable flag, which is enabled by default and acts as a safety valve for data queuing.

[0042] The command buffer intermediate layer controls the queuing behavior of view execution commands by setting an enable flag; if the enable flag is disabled, the view execution commands generated by the logic layer are directly discarded or skipped, so as to stop occupying view layer resources when the battle instance is switched to background execution or the battle performance is skipped.

[0043] Specifically, the command buffer intermediate layer includes a static write interface (EnqueueToBuffer). When the logic layer attempts to write a command, this interface first obtains the buffer object corresponding to the current combat instance through the intermediate layer data manager and performs a pre-verification of the enable flag. If the enable flag is enabled, the view execution command is allowed to be appended to the command cache queue; if the enable flag is disabled, the view execution command generated by the logic layer is directly discarded or skipped before being queued. Through the conditional control of this flag, when the combat instance switches to background silent data processing (such as switching to background AFK) or the player chooses to skip the combat presentation, the subsequent command stream can be intercepted directly in the intermediate layer, thereby completely stopping the view layer's occupation of rendering resources.

[0044] The command buffer intermediate layer also exposes a command retrieval interface (GetCMDBuffers) so that the view layer can export a list of commands to be executed in batches each frame update.

[0045] The following is an example of the core class structure of the command buffer intermediate layer in this embodiment: public class CMDBufferMidder : IFightMiddler { public bool enable { get; set;} = true; List <icmdbuffer>lstCMDBuffers = new(); / / Static method: Write command to the logic layer public static void EnqueueToBuffer(int logicUid, ICMDBuffer buffer) { var middler=FightMiddleDataMgr.Get <cmdbuffermidder>(logicUid); if (middler.enable) middler.lstCMDBuffers.Add(buffer); } / / Get the list of commands in the view layer public List <icmdbuffer>GetCMDBuffers(); }

[0046] To achieve efficient expansion of the logic layer and view layer, this embodiment also includes a component manager. This manager serves as a basic module attached to each class instance that requires expanded functionality. The component manager uses a type-component object data structure to store the mounted components. Its core mechanism lies in decoupling the hard-coded dependencies of the class itself on its functional components, allowing for dynamic registration or replacement of required functional modules during system runtime without modifying the original class member definitions.

[0047] To efficiently extend the logic and view layers, the system employs a component and module design. Its core is the component manager, which supports dynamic registration and retrieval of components for different types of objects, and also supports polymorphic usage of components. The component manager is attached to each class instance that needs extended functionality. When a class's functional modules need to be extended, a component can be dynamically registered through the component manager to extend the functionality without modifying the class's member definitions, thus decoupling the class's dependency on components. Simultaneously, the component retrieval interface supports polymorphic queries, allowing the retrieval of specific derived components from an object based on its base class type. For example, if component A has derived implementations Aa and Ab, and object 1 registers component Aa while object 2 registers component Ab, when a higher-level module retrieves a component of type A from an object, the component retrieval interface can obtain the specific Aa or Ab component object.

[0048] As an example, the specific operational logic of dynamic registration and polymorphic derivation in the component manager is as follows: Define subclass implementations of the component base class CompBase, such as CompSoliderMgr for soldier management; If a certain battle type, such as battle type A, requires the participation of soldiers, then add a soldier management component: var compSolider = Pool <compsolidermgr>.Get(); CompMgr.AddComp(compSolider); Retrieve the soldier management component where needed and perform the corresponding processing, such as creating soldier units: var compSolider = CompMgr.GetComp(compSolider); compSolider.CreateSoliders(); A certain battle type B also requires soldiers, but the process of creating soldier units is different. In this case, a new soldier management component CompSoliderMgrB is defined, which inherits from CompSoliderMgr and overrides the implementation of CreateSoliders: var compSoliderB = Pool <compsolidermgrb>.Get(); CompMgr.AddComp(compSoliderB); The same business logic code for retrieving and creating soldier units using the soldier retrieval component will produce different behaviors depending on which component is added.

[0049] The specific process of performing the method described in this embodiment is as follows: The logic layer generates view execution commands, and the intermediate data manager stores the view execution commands into the command buffer intermediate layer based on the logic instance identifier. The view layer polls the command buffer intermediate layer to obtain a list of view execution commands associated with the target logical instance identifier; The view layer parses the type code of the view execution command, obtains the corresponding processor through type mapping to execute the view execution command, and drives the view update; After the view execution command is completed, it is recycled and reused through the object pool.

[0050] Before combat data begins to flow, the system first initializes objects. This includes the functional component extension process of constructing the logic layer and view layer objects through the aforementioned component manager: dynamically registering components using the component manager attached to class instances; when adding a new component, if a parent component of that component already exists in the component manager, the parent component is removed and replaced with the new component; when retrieving a component, the system prioritizes matching the specified component type, and if it does not exist, it searches downwards and returns its subclass components. This ensures that when the view layer matches command processors, it can automatically adapt to the customized components of the current special gameplay through polymorphic queries without modifying the underlying scheduling logic.

[0051] During each frame update, the logic layer acts as a pure data processing core, independent of any screen resources, and independently executes character control logic and complex skill decoupling logic to generate commands.

[0052] In the role control logic flow, the processing method also includes a role control process executed within the logic layer: the unit AI (Artificial Intelligence) module calculates and generates action intentions every frame, and stores the action intentions in the unit memory module; the unit state machine is driven to attempt a state transition based on the action intentions, and a condition rejection check is performed before the transition; only when the condition rejection check passes and the state transition is successful, the action intention data is obtained from the unit memory module by the target state after the transition, and the corresponding view is generated to execute commands to drive the view layer to display the corresponding behavior of the role.

[0053] During this process, the driving unit state machine attempts to perform state transitions according to the action intention. Specifically, if it is determined that the target state to be transitioned to is the same as the current state, the same state re-entry logic is triggered to refresh the internal timing and performance of the state. If it is determined that the target state to be transitioned to is different from the current state, the identifier of the target state is transmitted and recorded when exiting the current state, and the identifier of the current state is received and processed when entering the target state, so as to achieve smooth context handover between different state transitions.

[0054] After the above logical verification, only when the condition rejection verification passes and the state transition is successful, the target state after the transition obtains the action intent data from the unit memory module, and drives the view layer to display the corresponding behavior of the character by generating the corresponding view execution command.

[0055] Regarding the aforementioned "generating action intent through calculation per frame by the unit AI module," this embodiment designs an AI-state machine-based role control system. Role behavior control often involves complex AI decision-making logic and role state updates. Traditional role control requires complex role AI logic and branch judgments based on the current role state. The AI-state machine-based role control system is a design that separates AI decision-making from role state, allowing AI decision-making to disregard the current role state and only focus on the AI ​​decision intent. It then drives the role to attempt to enter the corresponding role state, and after a successful state transition, it executes the corresponding role behavior.

[0056] This is mainly achieved through the following mechanisms: Unit AI: Unit AI is a decision-making module attached to a unit object. It performs logical calculations through updates every frame to generate the unit's action intentions. Different AI behaviors can be configured for different units through derivation. The AI ​​stores the decision results (such as the skill to be released, the target object of the skill, etc.) in the unit's memory module and drives the unit's state machine to execute corresponding actions to affect the unit. Unit State Machine: Units manage their states through a state machine, including movement, casting, and stun states. State transitions are conditionally determined by different states; for example, a stun state cannot transition to a casting or movement state. Only after successfully entering a state will the specific state trigger the character to perform the corresponding action. For instance, entering a skill state will retrieve skill release data from the unit's memory and execute the skill.

[0057] Condition exclusion check: Each state internally implements the method CheckEnableChangeTo(EFSM other) to determine whether it can jump to other types, such as the dizziness state cannot jump to the movement state or the casting state. This check is performed once when setting the state interface.

[0058] Handling logic after successful / failed transition: If the state transition is successful, the OnEnter interface of the target state is triggered; otherwise, no processing is performed.

[0059] In the complex skill decoupling logic flow, when a character's behavior triggers skill release, the processing method also includes a skill execution process executed within the logic layer: when the character releases a skill, a running skill object is created to maintain basic release information and trigger skill sub-effects; at this instant, when the skill sub-effect is created and triggered, the skill execution process also includes: dynamically retrieving the effect target based on the skill configuration information, the effect target including the skill caster itself, a single main target, or a set of targets within a specific range; creating an effect processor corresponding to the sub-effect based on a preset script configuration, and passing context data containing the skill caster snapshot data and the effect target to the effect processor; the effect processor is immediately recycled and reused after instantaneous settlement based on the context data.

[0060] If the skill does not take effect instantly, and if the skill's sub-effect includes a persistent application effect, then the running skill object creates a persistent effect handling object independent of itself. The persistent application effect is taken over and maintained by the persistent effect handling object, which is also responsible for generating the view execution commands corresponding to the persistent application effect. Simultaneously, the running skill object immediately ends its lifecycle and is recycled after triggering the creation action. This design completely separates skill triggering from subsequent performance, effectively preventing the chaos in object lifecycle management caused by long-cycle skills.

[0061] Simultaneously, the running skill object immediately ends its lifecycle and is recycled after triggering the creation action. For example, when executing a skill that launches a homing missile, the running skill object ends and is recycled immediately after triggering the missile creation sub-effect; the subsequent continuous tracking of the missile, hit determination, and corresponding view behavior (such as continuously generating view execution commands for missile movement) are all independently managed and maintained by the newly created missile launcher (i.e., the continuous effect handling object). This design completely separates skill triggering from subsequent continuous behavior, effectively preventing chaotic skill object lifecycle management and memory redundancy caused by excessively long chain effect times.

[0062] After the character control and skill logic calculations described above, the logic layer generates a large number of view execution commands (such as playing attack animations, creating missile effects, etc.). Subsequently, the logic layer stores these view execution commands in the command buffer intermediate layer based on the logic instance identifier (logicUid) through the intermediate data manager. At this point, the single-frame task of the logic layer is complete, without any waiting operations, achieving asynchronous decoupling from the view layer.

[0063] The client's main rendering thread is responsible for handling subsequent operations. Each frame update polls the command buffer intermediate layer to obtain a list of view execution commands associated with the current target logic instance identifier. Then, the view layer parses the type code of the view execution commands, and through the type mapping system built in the aforementioned functional component extension process, obtains the corresponding subclass processor to execute the view execution commands, thereby driving the actual game view update on the screen.

[0064] To handle the massive amounts of command data generated per second in real-time combat gameplay, the system introduces an object pool mechanism for memory management of intermediate layer resources. Specifically, after the processor executes a view execution command, the system calls the unloading and cleanup interface (e.g., Despawn) of the command object to clear its internal temporary data (e.g., target ID, effect coordinates). Then, the cleaned-up empty view execution command object is pushed into the object pool for recycling (e.g., PutToPool). When the logic layer needs to generate new view execution commands, it will preferentially wake up and reuse existing objects from the object pool, rather than re-instantiating them in memory.

[0065] Through the object pool recycling and reuse mechanism described above, this system avoids frequent memory allocation and destruction caused by the high-frequency command flow in real-time combat, reduces the garbage collection (GC) overhead and screen frame drops during system operation, and ensures the smoothness of the client view.

[0066] To address common scenarios involving background switching or multiple instances during game operation, this embodiment provides a contingency mechanism. The processing method also includes a separate lifecycle management process for battle instances: when the view presentation of a battle instance is activated, a view layer object bound to the logic layer object of that battle instance is created, and the view layer object handles the scene loading and object presentation processes uniformly; when the battle instance switches to background execution, only the corresponding view layer object and presentation resources are unloaded, while the logic layer object maintains independent updates and calculations in the background, and buffered commands are stopped by setting corresponding flags, thus achieving low-cost parallel execution of multiple battle logics. Combined with the aforementioned mechanism, the invention ultimately achieves the objective of enabling the logic layer to run independently on both ends (server-side / client-side background) and produce consistent results, detached from the view layer.

[0067] Example 2 This embodiment is a real-time combat data processing system. The system is used to implement the processing method described in Embodiment 1, including: The middleware module includes an intermediate data manager and a command buffer middleware. The logic layer module is used to generate view execution commands and store the view execution commands into the command buffer intermediate layer based on the logic instance identifier through the intermediate data manager of the intermediate layer module. The view layer module is used to poll the command buffer intermediate layer to obtain a list of view execution commands associated with the target logical instance identifier; parse the type code of the view execution command, obtain the corresponding processor through type mapping to execute the view execution command to drive view update; and recycle and reuse the view execution command through the object pool after the view execution command is executed. The logic layer module and the view layer module are decoupled from each other through the intermediate layer module. The logic layer module can run independently on the server and produce consistent battle results without the view layer module.

[0068] The above description is only a preferred embodiment of the present invention. It should be noted that those skilled in the art can make several modifications and improvements without departing from the inventive concept of the present invention, and these all fall within the protection scope of the present invention.< / compsolidermgrb> < / compsolidermgr> < / icmdbuffer> < / cmdbuffermidder> < / icmdbuffer> < / t>

Claims

1. A method for processing real-time combat data, characterized in that, The method is applied to systems that include a logic layer, a middle layer, and a view layer; The intermediate layer includes an intermediate data manager and a command buffer intermediate layer; The logic layer generates view execution commands, and the intermediate data manager stores the view execution commands into the command buffer intermediate layer based on the logic instance identifier. The view layer polls the command buffer intermediate layer to obtain a list of view execution commands associated with the target logical instance identifier; The view layer parses the type code of the view execution command, obtains the corresponding processor through type mapping to execute the view execution command, and drives the view update; After the view execution command is completed, it is recycled and reused through the object pool; The logic layer and the view layer are decoupled through an intermediate layer. The logic layer can run independently on the server side without the view layer and produce consistent battle results.

2. The method according to claim 1, characterized in that, The method further includes: in the intermediate data manager, using a type-object dictionary to store intermediate layer data objects corresponding to different logical instance identifiers; When a data retrieval request is received, based on the parent class type in the request, a polymorphic query mechanism is used to retrieve and return a matching subclass instance object from the dictionary, so as to achieve compatibility between the logic layer and the view layer for heterogeneous combat gameplay.

3. The method according to claim 1, characterized in that, The command buffer intermediate layer controls the queuing behavior of view execution commands by setting an enable flag; If the enable flag is disabled, the view execution commands generated by the logic layer are directly discarded or skipped to stop occupying view layer resources when the battle instance is switched to background execution or the battle performance is skipped.

4. The method according to claim 1, characterized in that, The processing method also includes a role control flow executed within the logic layer: The unit AI module calculates and generates action intentions for each frame, and stores the action intentions in the unit memory module; The driving unit state machine attempts to transition to a new state based on the stated action intention, and performs a condition rejection check before transitioning. Only when the condition rejection check passes and the state transition is successful, the action intent data is obtained from the unit memory module from the target state after the transition, and the corresponding view execution command is generated to drive the view layer to display the corresponding behavior of the character.

5. The method according to claim 4, characterized in that, The driving unit state machine attempts to perform state transitions based on the action intention, specifically including: If the target state to be jumped to is determined to be the same as the current state, the same state re-entry logic is triggered to refresh the internal timing and behavior of the state. If it is determined that the target state to be jumped to is different from the current state, the identifier of the target state is transmitted and recorded when exiting the current state, and the identifier of the current state is received and processed when entering the target state, so as to achieve a smooth handover of context between different state jumps.

6. The method according to claim 1, characterized in that, The processing method also includes a skill execution flow executed within the logic layer: When a character uses a skill, a running skill object is created to maintain basic release information and trigger skill sub-effects; If the skill sub-effect includes a persistent application effect, then the running skill object creates a persistent effect processing object independent of itself. The persistent application effect is taken over and maintained by the persistent effect processing object, which is also responsible for generating the view execution command corresponding to the persistent application effect. Meanwhile, the running skill object ends its lifecycle and is recycled immediately after triggering the creation action.

7. The method according to claim 6, characterized in that, When creating and triggering the skill sub-effect, the skill execution process also includes: Dynamically retrieve effect targets based on skill configuration information; the effect targets include the skill user themselves, a single primary target, or a set of targets within a specific range. An effect processor corresponding to the sub-effect is created according to the preset script configuration, and context data containing the snapshot data of the skill applicant and the effect target is passed to the effect processor; The effects processor is immediately recycled and reused after the instantaneous calculation based on context data is completed.

8. The method according to claim 1, characterized in that, The processing method also includes a functional component extension process for constructing the logic layer and view layer objects: Dynamically register components using a component manager attached to class instances; When a new component is added, if a parent component of the new component already exists in the component manager, the parent component is removed and replaced with the new component. When retrieving a component, the system prioritizes matching the specified component type. If the component does not exist, it searches downwards and returns its subclass components.

9. The method according to claim 1, characterized in that, The processing method also includes a lifecycle separation management process for combat instances: When the view of a battle instance is activated, a view layer object is created that is bound to the logic layer object of that battle instance. The view layer object handles the scene loading and object rendering process in a unified manner. When the battle instance is switched to background execution, only the corresponding view layer object and presentation resources are unloaded, while the logic layer object is maintained to be updated and calculated independently in the background. Furthermore, by setting the corresponding flag bit to stop processing buffer commands, low-cost parallel execution of multiple battle logics is achieved.

10. A real-time combat data processing system, characterized in that, The system is used to implement the processing method as described in any one of claims 1-9, including: The middleware module includes an intermediate data manager and a command buffer middleware. The logic layer module is used to generate view execution commands and store the view execution commands into the command buffer intermediate layer based on the logic instance identifier through the intermediate data manager of the intermediate layer module. The view layer module is used to poll the command buffer intermediate layer to obtain a list of view execution commands associated with the target logical instance identifier; parse the type code of the view execution command, obtain the corresponding processor through type mapping to execute the view execution command to drive view update; and recycle and reuse the view execution command through the object pool after the view execution command is executed. The logic layer module and the view layer module are decoupled from each other through the intermediate layer module. The logic layer module can run independently on the server and produce consistent battle results without the view layer module.

Images