Behavior tree-based logic hot reloading and dynamic repair method and device

Abstract

The application provides a logic hot reloading and dynamic repairing method and device based on a behavior tree, behavior data of each node of the behavior tree is collected by implanting monitoring code in each node of the behavior tree. The nodes in the behavior tree are analyzed, and a dependency graph representing the dependency relationship between the nodes is constructed. In response to a hot updating operation, the affected nodes under the hot updating operation are determined based on the dependency graph, and a minimum reloading range is generated based on the affected nodes. The historical behavior data of the nodes in the minimum reloading range is obtained, the normal execution mode is obtained based on the historical behavior data, the abnormal mode is determined based on the normal execution mode and the current behavior data, and then the repairing strategy is determined. The logic hot reloading of the nodes in the minimum reloading range is performed based on the repairing strategy, so as to realize the dynamic repairing. According to the scheme, the incremental compilation and loading of the affected nodes are performed based on the dependency analysis and the influence range prediction, the resource waste of full reloading is avoided, and the efficiency and safety of the updating process are ensured.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically, to a logic hot reload and dynamic repair method and apparatus based on behavior trees. Background Technology

[0002] In the current game market, whether it is a single-player game or an online game, almost all games rely on the use of AI. The most commonly used AI technology is behavior tree. Traditional AI behavior tree systems require a shutdown and restart when the logic is modified during operation, and cannot track the execution status of nodes in real time.

[0003] It is evident that the full reloading method used in existing technologies suffers from drawbacks such as low efficiency, lack of state transition mechanisms (resulting in variable / stack data loss), and vulnerability to runtime context loss. These issues severely impact development efficiency and the continuity of online services. Summary of the Invention

[0004] The purpose of this invention is to provide a logic hot reload and dynamic repair method and apparatus based on behavior tree, so as to avoid the waste of resources in full reload and ensure the efficiency and security of the update process.

[0005] In a first aspect, the present invention provides a logic hot reload and dynamic repair method based on behavior tree, the method comprising: Monitoring code is embedded in each node of the behavior tree to collect behavioral data from each node; The nodes in the behavior tree are analyzed to construct a dependency graph representing the dependencies between nodes; In response to a hot update operation, the affected nodes under the hot update operation are determined based on the dependency graph, and a minimum overload range is generated based on the affected nodes. Obtain historical behavior data of nodes within the minimum overload range, and obtain the normal execution mode based on the historical behavior data; An abnormal mode is determined based on the normal execution mode and the current behavior data, and a repair strategy is determined based on the abnormal mode. Based on the repair strategy, logical hot reload is performed on nodes within the minimum overload range to achieve dynamic repair.

[0006] In an optional implementation, the step of analyzing the nodes in the behavior tree to construct a dependency graph representing the dependencies between nodes includes: Static analysis is performed on the read / write variables, call subtrees, and parallel branches of each node in the behavior tree, and the edge connection operation between nodes is performed based on the static analysis results to obtain the initial dependency graph; The dependencies between nodes are collected during the operation, and the initial dependency graph is updated based on the dependencies to obtain a dependency graph representing the dependencies between nodes. The dependencies include node control dependencies, data dependencies, and resource / parallel dependencies.

[0007] In an optional implementation, the step of determining the affected nodes under the hot update operation based on the dependency graph in response to the hot update operation includes: In response to a hot update operation, determine the modified node in the behavior tree to which the hot update operation points; Based on the modified node, the corresponding associated node is determined in the dependency graph; The modified node and associated node constitute the affected node.

[0008] In an optional implementation, the step of determining the corresponding associated node in the dependency graph based on the modified node includes: Starting from the modified node, search for downstream nodes with the modified node as input along the forward control or data dependency in the dependency graph, and search for upstream nodes that the modified node depends on and whose behavior changes the semantics of the modified node along the reverse dependency chain. The downstream node and the upstream node are identified as associated nodes.

[0009] In an optional implementation, the step of obtaining historical behavior data of nodes within the minimum overload range and obtaining the normal execution mode based on the historical behavior data includes: Obtain historical behavior data of nodes within the minimum overload range, and construct a historical execution sequence from the historical behavior data. The historical behavior data includes at least node ID, return status, execution time, key input and output parameters, blackboard variable values, and the context that triggered the node. The historical execution sequence is input into the constructed neural network model, and the normal execution mode of the output node is generated.

[0010] In an optional implementation, the step of determining the abnormal mode based on the normal execution mode and the current behavior data includes: The current execution sequence is obtained based on the current behavior data; The current execution sequence is compared with the normal execution sequence, and deviation information of the current execution sequence from the normal execution sequence is output. The corresponding abnormal pattern is determined based on the deviation information.

[0011] In an optional implementation, the step of determining the repair strategy based on the anomaly pattern includes: For each node within the minimum overload range, obtain the node type and context of the node; Based on the node type, context, and anomaly pattern, a corresponding candidate repair strategy is matched from a pre-set repair strategy library; The evaluation results were obtained by weighting each candidate repair strategy according to multidimensional indicators. The final repair strategy is determined from the candidate repair strategies based on the evaluation results.

[0012] In an optional implementation, the step of performing logical hot reload on nodes within the minimum overload range based on the repair strategy to achieve dynamic repair includes: For nodes within the minimum overload range, a corresponding patch is generated based on the repair strategy, and the patch carries version metadata. During operation, a new version instance is created for the node using a copy-on-write mechanism, and the patch is loaded into the new execution body of the new version instance. Atomically switch the node pointer from the old version to the new version and perform state transition to achieve dynamic repair of the node.

[0013] In an optional implementation, the step of performing state transition includes: Freeze the execution thread where the node is located, copy the runtime state of the node under the old version, and serialize it into an old state field represented by an intermediate; The old state fields are mapped to the new version, and the mapped new state fields are injected into the new version instance; Unfreeze the execution thread of the node and resume execution of the new version from the point of interruption to achieve state migration from the old version to the new version.

[0014] Secondly, the present invention provides a logic hot reload and dynamic repair device based on behavior tree, the device comprising: The data acquisition module is used to embed monitoring code into each node of the behavior tree to collect behavioral data of each node. A construction module is used to analyze the nodes in the behavior tree to construct a dependency graph representing the dependencies between nodes; The first determining module is used to respond to the hot update operation, determine the affected nodes under the hot update operation based on the dependency graph, and generate the minimum overload range based on the affected nodes. The acquisition module is used to acquire historical behavior data of nodes within the minimum overload range, and to acquire the normal execution mode based on the historical behavior data; The second determining module is used to determine the abnormal mode based on the normal execution mode and the current behavior data, and to determine the repair strategy based on the abnormal mode. The hot reload and repair module is used to perform logical hot reload on nodes within the minimum reload range based on the repair strategy, so as to achieve dynamic repair.

[0015] This invention provides a logic hot reload and dynamic repair method and apparatus based on behavior trees. By embedding monitoring code into each node of the behavior tree, behavioral data of each node is collected. The nodes in the behavior tree are analyzed to construct a dependency graph representing the dependencies between nodes. In response to a hot update operation, the affected nodes are determined based on the dependency graph, and a minimum reload range is generated based on the affected nodes. Historical behavioral data of the nodes within the minimum reload range is obtained, and a normal execution mode is determined based on the historical behavioral data. An abnormal mode is determined based on the normal execution mode and the current behavioral data, and a repair strategy is determined based on the abnormal mode. Logical hot reload is performed on the nodes within the minimum reload range based on the repair strategy to achieve dynamic repair. This scheme, based on dependency analysis and impact range prediction, only incrementally compiles and loads the affected nodes, avoiding the resource waste of full reload and ensuring the efficiency and security of the update process. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments of the present invention will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart of a behavior tree-based logical hot repetition and dynamic repair method provided in an embodiment of the present invention; Figure 2 for Figure 1 A flowchart of the sub-steps included in S12; Figure 3 for Figure 1 A flowchart of the sub-steps included in S13; Figure 4 for Figure 1 A flowchart of the sub-steps included in S14; Figure 5 for Figure 1 A flowchart of the sub-steps included in S15; Figure 6 for Figure 1 A flowchart of the sub-steps included in S16; Figure 7This is a functional block diagram of a behavior tree-based logic hot repetition and dynamic repair device provided in an embodiment of the present invention. Detailed Implementation

[0018] The technical solutions of the present invention will now be described with reference to the accompanying drawings in the embodiments of the present invention.

[0019] Please see Figure 1 This is a flowchart illustrating the behavior tree-based logic hot reload and dynamic repair method provided in this embodiment of the invention. It should be understood that in other embodiments, the order of some steps in the behavior tree-based logic hot reload and dynamic repair method of this embodiment can be interchanged according to actual needs, or some steps can be omitted or deleted. The detailed steps of this behavior tree-based logic hot reload and dynamic repair method are described below.

[0020] S11, embed monitoring code into each node of the behavior tree to collect behavioral data of each node; S12, Analyze the nodes in the behavior tree to construct a dependency graph representing the dependencies between nodes; S13, in response to the hot update operation, determine the affected nodes under the hot update operation based on the dependency graph, and generate the minimum overload range based on the affected nodes; S14, obtain historical behavior data of nodes within the minimum overload range, and obtain normal execution mode based on the historical behavior data; S15, determine the abnormal mode based on the normal execution mode and the current behavior data, and determine the repair strategy based on the abnormal mode; S16, Based on the repair strategy, perform logical hot reload on the nodes within the minimum overload range to achieve dynamic repair.

[0021] The behavior tree-based logic hot reloading and dynamic repair method provided in this embodiment, through fine-grained state monitoring and behavior data storage technology, enables behavior tree logic to be dynamically modified at runtime and take effect immediately without downtime or service restart, significantly improving development and debugging efficiency. Based on dependency analysis and impact scope prediction, incremental compilation and loading are performed only on affected nodes, avoiding the resource waste of full reloading and ensuring the efficiency and security of the update process.

[0022] The specific implementation methods of each of the above steps will be explained in detail below.

[0023] In this embodiment, the behavior tree refers to the behavior tree related to the game execution logic. The behavior tree is a tree structure that describes the AI ​​decision control flow in the game. The nodes are related by parent-child / sibling execution scheduling relationships (selection, sequence, parallelism, etc.). The behavior tree can express the meaning of what order to execute.

[0024] Monitoring code is embedded in each node of the behavior tree to collect behavioral data of each node, including data such as execution time, return status, input and output parameters.

[0025] Building upon behavior trees, a dependency graph is constructed to represent the dependencies between nodes. The dependency graph depicts the dependencies between nodes at the data and impact levels; that is, which nodes are affected when a node is modified. Therefore, behavior trees describe how a program executes, while dependency graphs describe which nodes are affected if a node is modified.

[0026] In this embodiment, the steps of analyzing the nodes in the behavior tree to construct a dependency graph representing the dependencies between nodes are detailed below. Figure 2 This can be achieved in the following ways: S121, Static analysis is performed on the read / write variables, call subtrees, and parallel branches of each node in the behavior tree, and the edge connection operation between nodes is performed based on the static analysis results to obtain the initial dependency graph; S122, Collect the dependencies between nodes during operation, update the initial dependency graph based on the dependencies, and obtain a dependency graph representing the dependencies between nodes, wherein the dependencies include node control dependencies, data dependencies, and resource / parallel dependencies.

[0027] In this embodiment, the edge types between nodes in the dependency graph include at least three categories: control dependency (parent-child call relationship, directly taken from the behavior tree topology); data dependency (a blackboard variable written by node A is read by node B, then B's data depends on A); and resource / parallel dependency (between nodes that share the same resource, are in the same parallel branch, or are subject to the same condition gating).

[0028] Based on the static analysis structure of each node, the edge connection operation between nodes is performed, and the initial dependency graph is updated based on the edge types mentioned above.

[0029] Specifically, static construction is performed first. During the compilation / loading phase, the behavior tree source code and its scripts are parsed using an Abstract Syntax Tree (AST). Each node is traversed, and its read / write blackboard variables, called subtrees, and associated parallel branches are recorded. Edges are then connected to obtain an initial directed dependency graph. Dynamic completion is then performed. For dependencies determined at runtime (such as dynamically loaded subtrees or branches determined by variable values), the actual read / write records collected by the monitoring layer during runtime are backfilled into the graph, continuously updating it. Finally, the graph is stored in an adjacency list, and the heat update impact analyzer performs forward and reverse traversal when modifications are received.

[0030] Building upon the above, a hot update operation is initiated. This operation can be automatically triggered during program execution or manually triggered by the developer. Upon triggering a hot update operation, the affected nodes are determined based on the dependency graph. For details, please refer to [link to relevant documentation]. Figure 3 This step can be achieved in the following ways: S131, In response to the hot update operation, determine the modified node pointed to by the hot update operation in the behavior tree; S132, Based on the modified node, determine the corresponding associated node in the dependency graph; S133, the modified node and the associated node constitute the affected node.

[0031] The step of determining the corresponding associated node in the dependency graph based on the modified node can be implemented in the following way: Starting from the modified node, downstream nodes with the modified node as input are searched along the forward control or data dependency in the dependency graph, and upstream nodes that the modified node depends on and whose behavior changes the semantics of the modified node are searched along the reverse dependency chain; the downstream nodes and upstream nodes are identified as associated nodes.

[0032] In this embodiment, the affected nodes are a set, including both nodes that the developer directly modifies (i.e., modified nodes) and related nodes that must be overloaded due to dependencies, rather than referring to only one type.

[0033] Specifically, the impact analyzer starts with the modified node and traverses the dependency graph: it finds downstream nodes that take the modified node as input along the forward control / data dependencies (the output variables and return states of the modified node will be passed to them); it finds upstream nodes that the modified node depends on and whose behavior will change the semantics of the modified node along the reverse dependency chain; it merges the modified node itself and the nodes whose states in the above upstream and downstream will be invalidated due to this modification to obtain the minimum set of affected nodes, i.e., the minimum overload range.

[0034] Furthermore, nodes not included in the set remain unchanged and are not reloaded. For example, when modifying a condition node, typically only the condition node and its direct parent sequence / selection node need to be reloaded, rather than the entire tree.

[0035] Based on the above, historical behavior data within the minimum overload range is obtained. The normal execution mode is then determined based on this historical behavior data. For details, please refer to [link to relevant documentation]. Figure 4 This step can be achieved in the following ways: S141, obtain the historical behavior data of the nodes within the minimum overload range, and construct a historical execution sequence from the historical behavior data. The historical behavior data includes at least the node ID, return status, execution time, key input and output parameters, blackboard variable values, and the context that triggered the node. S142, input the historical execution sequence into the constructed neural network model, and output the normal execution mode of the node.

[0036] Based on this, abnormal modes are determined according to the normal execution mode and the current data, and repair strategies are determined based on the abnormal modes. For details, please refer to [link to relevant documentation]. Figure 5 This can be achieved in the following ways: S151, Obtain the current execution sequence based on the current behavior data; S152, compare the current execution sequence with the normal execution sequence, and output deviation information of the current execution sequence from the normal execution sequence; S153, determine the corresponding abnormal mode based on the deviation information; S154, for each node within the minimum overload range, obtain the node type and context of the node; S155, Match the corresponding candidate repair strategy from the preset repair strategy library based on the node type, context and anomaly mode; S156, The candidate repair strategies described are weighted and evaluated according to multidimensional indicators to obtain the evaluation results; S157, Based on the evaluation results, determine the final repair strategy from the candidate repair strategies.

[0037] Specifically, the historical execution sequence to be analyzed includes, for example, for affected nodes, the execution record sequence collected by the monitoring layer and sorted by time. Each record (time step) should include at least: node ID, current return status (Success / Failure / Running), execution time, key input / output parameters, relevant blackboard variable values, and the context that triggered the node (parent node, branch). In other words, the historical execution sequence is time-series data consisting of the node's status, time, return value, and context within the most recent time window.

[0038] Then, abnormal pattern detection is performed. In this embodiment, an LSTM model can be used with the above-mentioned historical execution sequence as input to learn the normal execution pattern of the node. The current execution sequence is then compared with the normal execution sequence, and the degree to which the current execution sequence deviates from the normal execution sequence is output, thereby identifying abnormal patterns such as N consecutive timeouts, a return value that is always Failure / always True for a long time, a continuous increase in execution time, and a high failure rate for pathfinding nodes.

[0039] Specifically, the identifiable anomaly types in this embodiment include at least the following: 1. Return status anomaly (nodes consistently return Failure, or conditional nodes are always true / false, such as the berserk trigger always being true in the BOSS example); 2. Execution path anomaly / freezing (such as a high failure rate of pathfinding nodes causing repeated regressions and stagnation, i.e., the case of Archer A getting stuck in a wall); 3. Decision value anomaly (imbalance in decision weights of nodes such as target selection, leading to incorrect value judgments of using ultimate skills on full-health tanks); 4. Frequency / oscillation anomaly (nodes frequently jittering between two branches); 5. Resource anomaly (blackboard variable out of bounds, null references, inconsistent skill cooldown data); 6. Performance degradation (an anomaly where execution time continuously increases over time). Different anomaly types correspond to different pre-set repair strategies.

[0040] Anomaly patterns are combined with a rule engine to determine remediation strategies. The LSTM model identifies anomalies and categorizes them into specific anomaly patterns. The rule engine (Drools) then matches the anomaly pattern with contextual features, using a pre-defined remediation strategy library: IF (anomaly pattern = X, node type = Y, and context = Z) THEN (use remediation strategy = S) rule. This maps the detection results to specific remediation actions. In other words, LSTM performs diagnostic classification, and the rule engine makes strategy decisions; the two are linked.

[0041] The repair strategy library includes at least: 1. Dynamic parameter adjustment (such as adjusting decision weights, thresholds, and random factors); 2. Logic / algorithm degradation or switching (such as pathfinding from...). 1. Algorithm switches to rule navigation); 2. Subtree / node restart or rollback to checkpoint; 3. Add failure handling branch (add "safety fallback" sub-branch for high failure rate nodes); 4. Developer-defined strategy (Python script injection).

[0042] In this embodiment, the rule engine filters out all applicable candidate repair strategies from the strategy library based on the current anomaly pattern, node type, and context. Each candidate strategy is weighted and scored according to multi-dimensional indicators, including: expected benefit (the degree to which the strategy restores the indicator under similar historical anomalies, which can be predicted by LSTM / statistical models), scope of impact (the number of nodes that need to be reloaded, the smaller the better), migration risk and rollbackability (probability of state transition failure), effectiveness delay, and whether it conflicts with version compatibility constraints.

[0043] Finally, the candidate remediation strategy with the highest overall score that passes compatibility and security checks is selected as the optimal remediation strategy and deployed for execution. If the monitoring metrics do not meet expectations after execution, the process is rolled back and the second-best strategy is selected, forming a closed loop. Developers can also configure the scoring weights or directly specify strategies to override automatic selection.

[0044] All remediation strategies are ultimately distributed and implemented through the system's differential hot update channel. That is, the remediation strategy specifies what needs to be changed / replaced on the nodes, and then the execution layer's differential compilation and hot deployment apply these changes as a hot update to the running nodes. Therefore, the remediation strategy defines what the hot update should do and how it securely applies it.

[0045] Based on the above, in this embodiment, logical hot reload is performed on nodes within the minimum overload range according to the repair strategy to achieve dynamic repair. For details, please refer to [link to relevant documentation]. Figure 6 This step can be achieved in the following way: S161, For nodes within the minimum overload range, generate corresponding patches based on the repair strategy, wherein the patches carry version metadata; S162, During operation, a new version instance is created for the node through the copy-on-write mechanism, and the patch is loaded into the new execution body of the new version instance; S163, atomically switch the node pointer from the old version to the new version and perform state transition to achieve dynamic repair of the node.

[0046] The steps for performing state transitions can be implemented in the following ways: Freeze the execution thread of the node, copy the runtime state of the node under the old version, and serialize it into an old state field represented by an intermediate; map the old state field to the new version, and inject the mapped new state field into the new version instance; unfreeze the execution thread of the node, and continue the execution of the new version from the point of interruption to realize the state migration from the old version to the new version.

[0047] In this embodiment, the bytecode patch serves as the carrier for hot updating running nodes. The differential compiler recompiles only the nodes in the affected node set, generating the corresponding LLVM IR incremental bytecode (i.e., the patch). The patch includes version metadata (such as Git Hash, SemVer version number, and target node ID). At runtime, a new version instance is created for the updated node using the Copy-on-Write (COW) mechanism. The patch is loaded as the new executable for that node, and then the node pointer is atomically switched from the old version to the new version. This completes the replacement of the node's logic without restarting or affecting other nodes. The patch only covers the modified and associated nodes, so its size is in the KB range.

[0048] State transition refers to seamlessly transferring the runtime state accumulated in the old version to the new version when switching a node (or subtree) from an old version to a new version, allowing the AI ​​to continue execution from the original progress rather than being reset. The runtime state specifically includes: 1. Blackboard variables (all key-value pairs read and written by the node and its subtree); 2. Call stack / execution cursor (which node the behavior tree is currently executing at, and the child node advancement index of the sequence / selection node); 3. Subtree execution progress and internal timers / counters of Running state nodes; 4. Node-private states such as resource usage and cooldown.

[0049] Specifically, firstly, the execution thread of the target node is paused at a behavior tree tick boundary to ensure that migration does not occur in a half-execution state. A deep copy of the runtime state is then performed, serialized using Protocol Buffers into a version-independent intermediate representation, and a CRC32 checksum is calculated and written to disk as a checkpoint. Based on the state structure difference table between the old and new versions (generated by version compatibility checks), old state fields are mapped to the new version; fields with the same name and type are directly copied, renamed fields are converted according to the mapping table, newly added fields are filled with default values, and deleted fields are discarded. The mapped new state fields are injected into the new version node instance, and its execution cursor is set to the corresponding position. Finally, verification and release are performed: the restored state undergoes another CRC32 check and consistency check; if successful, the thread is unfrozen, and the new version continues from the point of interruption; if the check fails, it automatically rolls back to the checkpoint in the above steps, restoring the old version's execution to ensure no state loss or crash. The entire execution process takes less than 50ms.

[0050] For example, during a BOSS battle, when migrating, the player retains 28% of their current health, position, and skill cooldowns, which are the migration results of the aforementioned blackboard variables and node private states.

[0051] In this embodiment, the hot reload process is initiated by the developer, and the triggering source is that the developer manually modifies the behavior tree logic in the IDE; the system performs modification detection, impact analysis, differential compilation, atomic switching, and verification feedback accordingly, which solves the scenario where the developer wants to modify the logic.

[0052] The anomaly repair process is passively initiated by the system. The trigger source is the monitoring layer automatically detecting runtime anomalies (such as timeout rate exceeding the threshold). Based on this, the system performs anomaly detection, root cause analysis, strategy matching, and automatic execution (dynamically replacing faulty nodes). It solves the scenario where AI runs into problems and needs to self-heal.

[0053] The only difference between the two lies in the trigger source (active / passive) and the decision-making process (manual editing / automatic strategy matching). Once it is determined which nodes need to be modified and what modifications need to be made, the subsequent differential compilation, COW atomic switching, state transition, and rollback all reuse the same execution layer mechanism. It can be understood that anomaly repair is a special hot reload where the system automatically generates a modification plan. Therefore, the so-called hot reload and dynamic repair are essentially the same execution process.

[0054] To verify the effectiveness of the behavior tree-based logic hot reload and dynamic repair method provided in this embodiment, the following explanation is based on specific examples.

[0055] Example 1: Dynamically adjusting the behavior of game NPCs: In open-world games, players have reported that the conditions for switching to the berserk phase of a certain boss are too simple, requiring urgent adjustments to the logic.

[0056] Implementation process: Problem identification: The monitoring interface shows that the rage trigger node (Condition_Health<30%) is 100% activated in the test, but the design expectation should be 50% probability; by executing the heatmap, it was found that the node has no random factor.

[0057] Hotfix: The developer edited the conditional logic as: Condition_Health<30%&&Random()>0.5; the system automatically analyzes the scope of impact (only overloads this conditional node and its parent stage switching subtree).

[0058] State preserved: Save the BOSS's current HP (28%), player position, and skill cooldown status; after the new version loads, immediately inherit the original status and continue the battle.

[0059] Effect verification: Real-time monitoring showed that the node activation rate dropped to 52% after the modification, which was in line with expectations; the player experience was uninterrupted (no lag or data loss throughout the process).

[0060] Example 2: Dynamic Teammate Repair System for MOBA Games In a MOBA game, players can team up with four AI-controlled heroes to fight against a five-player AI team. Each AI hero's behavior is controlled by a complex behavior tree. For example, if there's an AI teammate (a ranged physical damage dealer, let's call him Marksman A), his core logic is: 1. Prioritize attacking the enemy with the lowest health (the finishing logic); 2. When an enemy approaches, use the "backflip" skill to maintain a safe distance; 3. When health drops below 30%, prioritize the "retreat" behavior to find a safe position or seek protection from teammates.

[0061] Problem identified: In one game, the monitoring system detected that Marksman A's win rate and average damage per game were significantly lower than expected. Through replay data and real-time status monitoring, the developers discovered two anomalies: Problem A (Logical Flaw): Marksman A often uses "Fatal Shot" (an ultimate ability used to finish off low-health enemies) on a full-health enemy tank during team fights, instead of saving it for low-health enemies. This is a value judgment error.

[0062] Problem B (Behavior Stuck): During the retreat, shooter A sometimes gets stuck in a corner, repeatedly attempting to "jump back" but failing to hit the wall, resulting in being stunned and killed. This is an execution path error.

[0063] Problem identification: Step 1: Real-time monitoring and data acquisition: The system continuously monitors the execution status of the behavior tree for each AI: Node Activation Record: Records the target's health percentage when the "Fatal Shot" node is activated.

[0064] Sequence execution flow: Records the frequent failures of the "pathfinding to base" node in the "retreat" sequence, which triggered the "back jump" node.

[0065] Performance metrics: Real-time statistics on K / D / A (kills / deaths / assists), damage, etc.

[0066] Step Two: Problem Diagnosis and Localization Regarding issue A, the designer observed through the monitoring interface that in the decision weighting of the "Select Target" node, the weight of "Target Type" was too high, while the weight of "Target Health Percentage" was too low. The system automatically flagged this node's decision logic as inconsistent with the expected goal of "Harvesting".

[0067] For problem B, the system detected that the "pathfinding to base" node has a high failure rate under certain terrain conditions, and after failure, the behavior tree does not have a suitable "failure handling" branch, causing the behavior tree to fall back to the parent node and incorrectly execute "back jump".

[0068] Solution: Game designers can modify behavior tree logic directly within the development tools without shutting down the game servers. Repair A (Dynamic Parameter Adjustment): The designers modified the parameters of the "Select Target" node, significantly increasing the weight of "Target Health Percentage" and decreasing its priority for tank heroes.

[0069] Clicking the "Hot Reload" button will encrypt and send the new behavior tree parameter package to all running "Shooter A" AI instances on the game server.

[0070] Effect: In the next team fight, all marksmen A's AI will begin to correctly conserve "Lethal Shot" for finishing off low-health enemies, instead of wasting it on full-health tanks.

[0071] Repair B (Dynamic Logic Replacement): The developers have added a new "Safe Retreat" sub-branch to the "Retreat" sequence. When "Pathfinding to Base" fails, it will attempt to "Move to the nearest friendly tower" or "Move towards the nearest friendly hero".

[0072] Similarly, this new behavior tree logic fragment is distributed through hot reloading.

[0073] Effect: When Shooter A retreats in complex terrain, if the pathfinding fails, it will intelligently select an alternative retreat plan and successfully escape the danger zone, thus resolving the wall-blocking problem.

[0074] In summary, the behavior tree-based logic hot reload and dynamic repair method provided in this embodiment, through differential hot update, COW atomic switching, and lossless state migration, can achieve logic modification without stopping and restarting, and without losing runtime state. Therefore, the time from modification to effect is less than 100ms and the service is uninterrupted, enabling second-level iterative debugging / zero-interruption hot update.

[0075] Furthermore, based on the dependency graph and impact analyzer, only the set of affected nodes is located and reloaded (in actual testing, changing a 200-node tree to 1 node only requires reloading 3 nodes), so the patch is KB in size and has extremely low resource consumption, enabling accurate impact range prediction / differential updates that save resources.

[0076] Furthermore, this solution utilizes mechanisms such as holographic monitoring, LSTM anomaly diagnosis rule engine strategy matching, and automatic hot update channel to enable the system to automatically detect anomalies, match and issue repair strategies, thus possessing intelligent self-healing capabilities.

[0077] Furthermore, based on lightweight node probes and zero-copy shared memory data pipelines, the monitoring latency is less than 1ms, which does not significantly affect the AI's operating performance.

[0078] Traditional solutions require downtime for compilation and deployment (5-30 minutes), while this invention supports runtime logic modification with immediate effect (<100ms), improving development and debugging efficiency by more than 10 times. Real-world testing data shows that modifying one condition node in a 200-node behavior tree only requires reloading three related nodes (traditional solutions require reloading the entire tree). Through COW state migration technology, seamless switching between old and new versions is achieved, with service availability reaching 99.99%. Only the modified parts are compiled, generating KB-level patches, while traditional full updates require MB-level files.

[0079] In summary, addressing the fundamental shortcomings of existing technologies (full-scale hot update type), namely the need for system shutdown and restart to modify behavior tree logic, and the use of full reload, which is inefficient and results in the loss of all runtime context (blackboard variables, call stack, subtree progress) upon restart, the inability to track node states in real time, and the lack of a state migration mechanism, this solution provides a fine-grained runtime profile through holographic monitoring of behavior tree execution state, replaces full reload with precise differential hot update based on dependency graph, and solves the problem of state loss upon restart with lossless cross-version runtime state migration. The combination of these three elements achieves runtime hot reload and self-healing without system shutdown, with minimal scope, and without state loss, fundamentally overcoming the shortcomings of existing technologies such as system shutdown, full reload, and state loss.

[0080] Based on the same inventive concept, please refer to Figure 7 This invention also provides a functional module diagram of a behavior tree-based logic hot reload and dynamic repair device. This embodiment can divide the behavior tree-based logic hot reload and dynamic repair device into functional modules according to the above method embodiments. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. The integrated modules can be implemented in hardware or as software functional modules. It should be noted that the module division in this invention embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0081] The behavior tree-based logic hot reload and dynamic repair device may include an acquisition module, a construction module, a first determination module, an acquisition module, a second determination module, and a hot reload and repair module. The functions of each module of the behavior tree-based logic hot reload and dynamic repair device will be described in detail below.

[0082] The data acquisition module is used to embed monitoring code into each node of the behavior tree to collect behavioral data of each node. A construction module is used to analyze the nodes in the behavior tree to construct a dependency graph representing the dependencies between nodes; The first determining module is used to respond to the hot update operation, determine the affected nodes under the hot update operation based on the dependency graph, and generate the minimum overload range based on the affected nodes. The acquisition module is used to acquire historical behavior data of nodes within the minimum overload range, and to acquire the normal execution mode based on the historical behavior data; The second determining module is used to determine the abnormal mode based on the normal execution mode and the current behavior data, and to determine the repair strategy based on the abnormal mode. The hot reload and repair module is used to perform logical hot reload on nodes within the minimum reload range based on the repair strategy, so as to achieve dynamic repair.

[0083] The behavior tree-based logic hot reload and dynamic repair device provided in this embodiment can be used to execute the behavior tree-based logic hot reload and dynamic repair method under any of the above embodiments. For details not covered in this embodiment, please refer to the corresponding descriptions in the above embodiments. This embodiment will not elaborate further here.

[0084] The structural block diagram of the electronic device provided in this embodiment of the invention can be, for example, a computer device or a server. The electronic device includes a memory, a processor, and a communication module. The memory, processor, and communication module are electrically connected directly or indirectly to each other to achieve data transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses or signal lines.

[0085] The memory is used to store computer programs or data. Memory can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc.

[0086] The processor is used to read / write data or programs stored in the memory and execute the behavior tree-based logic hot reload and dynamic repair method provided in any embodiment of the present invention.

[0087] The communication module is used to establish communication connections between electronic devices and other communication terminals via a network, and to send and receive data via the network.

[0088] Furthermore, embodiments of the present invention also provide a computer-readable storage medium storing machine-executable instructions, which, when executed, implement the behavior tree-based logic hot reload and dynamic repair method provided in the above embodiments.

[0089] Specifically, the computer-readable storage medium can be a general-purpose storage medium, such as a removable disk or hard disk. When the computer program on the computer-readable storage medium is executed, it can perform the aforementioned behavior tree-based logical hot reload and dynamic repair method. The processes involved in the execution of the executable instructions on the computer-readable storage medium can be referred to the relevant descriptions in the above method embodiments, and will not be detailed here.

[0090] In the embodiments provided by this invention, it should be understood that the disclosed apparatus and method can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0091] Furthermore, the units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0092] Furthermore, the functional modules in the various embodiments of the present invention can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0093] It should be noted that if the functionality is implemented as a software module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0094] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0095] The above description is merely an embodiment of the present invention and is not intended to limit the scope of protection of the present invention. For those skilled in the art, the present invention can have various modifications and variations. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A logic hot reload and dynamic repair method based on behavior tree, characterized in that, The method includes: Monitoring code is embedded in each node of the behavior tree to collect behavioral data from each node; The nodes in the behavior tree are analyzed to construct a dependency graph representing the dependencies between nodes; In response to a hot update operation, the affected nodes under the hot update operation are determined based on the dependency graph, and a minimum overload range is generated based on the affected nodes. Obtain historical behavior data of nodes within the minimum overload range, and obtain the normal execution mode based on the historical behavior data; An abnormal mode is determined based on the normal execution mode and the current behavior data, and a repair strategy is determined based on the abnormal mode. Based on the repair strategy, logical hot reload is performed on nodes within the minimum overload range to achieve dynamic repair.

2. The logic hot reload and dynamic repair method based on behavior tree according to claim 1, characterized in that, The step of analyzing the nodes in the behavior tree to construct a dependency graph representing the dependencies between nodes includes: Static analysis is performed on the read / write variables, call subtrees, and parallel branches of each node in the behavior tree, and the edge connection operation between nodes is performed based on the static analysis results to obtain the initial dependency graph; The dependencies between nodes are collected during the operation, and the initial dependency graph is updated based on the dependencies to obtain a dependency graph representing the dependencies between nodes. The dependencies include node control dependencies, data dependencies, and resource / parallel dependencies.

3. The logic hot reload and dynamic repair method based on behavior tree according to claim 1, characterized in that, The step of determining the affected nodes under the hot update operation based on the dependency graph in response to the hot update operation includes: In response to a hot update operation, determine the modified node in the behavior tree to which the hot update operation points; Based on the modified node, the corresponding associated node is determined in the dependency graph; The modified node and associated node constitute the affected node.

4. The logic hot reload and dynamic repair method based on behavior tree according to claim 3, characterized in that, The step of determining the corresponding associated node in the dependency graph based on the modified node includes: Starting from the modified node, search for downstream nodes with the modified node as input along the forward control or data dependency in the dependency graph, and search for upstream nodes that the modified node depends on and whose behavior changes the semantics of the modified node along the reverse dependency chain. The downstream node and the upstream node are identified as associated nodes.

5. The logic hot reload and dynamic repair method based on behavior tree according to claim 1, characterized in that, The step of obtaining historical behavior data of nodes within the minimum overload range and obtaining the normal execution mode based on the historical behavior data includes: Obtain historical behavior data of nodes within the minimum overload range, and construct a historical execution sequence from the historical behavior data. The historical behavior data includes at least node ID, return status, execution time, key input and output parameters, blackboard variable values, and the context that triggered the node. The historical execution sequence is input into the constructed neural network model, and the normal execution mode of the output node is generated.

6. The logic hot reload and dynamic repair method based on behavior tree according to claim 5, characterized in that, The step of determining the abnormal mode based on the normal execution mode and the current behavior data includes: The current execution sequence is obtained based on the current behavior data; The current execution sequence is compared with the normal execution sequence, and deviation information of the current execution sequence from the normal execution sequence is output. The corresponding abnormal pattern is determined based on the deviation information.

7. The logic hot reload and dynamic repair method based on behavior tree according to claim 1, characterized in that, The step of determining the repair strategy based on the anomaly pattern includes: For each node within the minimum overload range, obtain the node type and context of the node; Based on the node type, context, and anomaly pattern, a corresponding candidate repair strategy is matched from a pre-set repair strategy library; The evaluation results were obtained by weighting each candidate repair strategy according to multidimensional indicators. The final repair strategy is determined from the candidate repair strategies based on the evaluation results.

8. The logic hot reload and dynamic repair method based on behavior tree according to claim 1, characterized in that, The step of performing logical hot reload on nodes within the minimum overload range based on the repair strategy to achieve dynamic repair includes: For nodes within the minimum overload range, a corresponding patch is generated based on the repair strategy, and the patch carries version metadata. During operation, a new version instance is created for the node using a copy-on-write mechanism, and the patch is loaded into the new execution body of the new version instance. Atomically switch the node pointer from the old version to the new version and perform state transition to achieve dynamic repair of the node.

9. The logic hot reload and dynamic repair method based on behavior tree according to claim 8, characterized in that, The execution state transition steps include: Freeze the execution thread where the node is located, copy the runtime state of the node under the old version, and serialize it into an old state field represented by an intermediate; The old state fields are mapped to the new version, and the mapped new state fields are injected into the new version instance; Unfreeze the execution thread of the node and resume execution of the new version from the point of interruption to achieve state migration from the old version to the new version.

10. A logic hot reload and dynamic repair device based on behavior tree, characterized in that, The device includes: The data acquisition module is used to embed monitoring code into each node of the behavior tree to collect behavioral data of each node. A construction module is used to analyze the nodes in the behavior tree to construct a dependency graph representing the dependencies between nodes; The first determining module is used to respond to the hot update operation, determine the affected nodes under the hot update operation based on the dependency graph, and generate the minimum overload range based on the affected nodes. The acquisition module is used to acquire historical behavior data of nodes within the minimum overload range, and to acquire the normal execution mode based on the historical behavior data; The second determining module is used to determine the abnormal mode based on the normal execution mode and the current behavior data, and to determine the repair strategy based on the abnormal mode. The hot reload and repair module is used to perform logical hot reload on nodes within the minimum reload range based on the repair strategy, so as to achieve dynamic repair.

Images