Method, apparatus and electronic device for synchronizing behavior state

Abstract

The application provides a behavior state synchronization method and device and electronic equipment. In response to a change in a behavior state of a target virtual role, a node identifier and a running state of a first branch node affecting the behavior state of the target virtual role are determined from a first behavior graph. The node identifier and the running state are sent to a second client. The behavior state of the target virtual role is synchronized by the second client according to the node identifier, the running state and a second behavior graph identical to the first behavior graph. In this way, the same behavior graph is loaded for the same virtual role in different clients. When the behavior state of the target virtual role is synchronized, only the information of the activated branch node in the first behavior graph needs to be sent to the second client. The second client synchronizes the behavior state of the target virtual role according to the information of the branch node and the second behavior graph, without the need to write scripts, thereby simplifying the development process, reducing the development workload and reducing the performance overhead of the game.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, and electronic device for synchronizing behavioral states. Background Technology

[0002] In 3D games, the behavior of game characters is typically controlled by nodes in a behavior graph. In online games, the position and behavior of a player-controlled virtual character need to be synchronized in real-time with other clients to ensure consistency in how other players perceive the target virtual character's position and behavior. In related technologies, when the behavior of the player-controlled virtual character changes, a pre-configured script is used to remotely notify other clients to update the behavior graph. This allows other clients to control the target virtual character's actions based on the updated behavior graph, thus ensuring consistency across all clients. This approach requires writing a large amount of script code, resulting in a tedious and labor-intensive development process. Furthermore, while the internal logic of the behavior graph is actually independent of the script, both the internal logic of the behavior graph and the external script logic controlling the virtual character's behavior require state synchronization via a pre-defined script, leading to significant performance overhead for the game. Summary of the Invention

[0003] In view of this, the purpose of the present invention is to provide a method, apparatus and electronic device for synchronizing behavioral states, so as to simplify the development process, reduce the development workload and reduce the performance overhead of the game.

[0004] In a first aspect, embodiments of the present invention provide a method for synchronizing behavioral states. This method is applied to a first client and includes: in response to a game start command, loading a first behavioral graph of a target virtual character; wherein the first behavioral graph includes multiple branch nodes, each branch node having a preset node identifier; the branch nodes are used to control the behavioral state of the target virtual character; the target virtual character is controlled by the first client; in response to a change in the behavioral state of the target virtual character, determining from the first behavioral graph the node identifier of the first branch node affecting the behavioral state of the target virtual character, and the running state of the first branch node; sending the node identifier and running state of the first branch node to a second client; and through the second client, controlling the behavioral state of the target virtual character based on the node identifier and running state of the first branch node, and the second behavioral graph of the target virtual character, thereby synchronizing the behavioral state of the target virtual character in the first client with the behavioral state of the target virtual character in the second client; wherein the second behavioral graph is identical to the first behavioral graph.

[0005] Secondly, embodiments of the present invention provide a method for synchronizing behavioral states. The method is applied to a second client and includes: in response to a game start command, loading a second behavioral graph of a target virtual character; wherein the target virtual character is controlled by a first client; the first client contains a first behavioral graph of the target virtual character; the first behavioral graph includes multiple branch nodes, each branch node having a preset node identifier; the branch nodes are used to control the behavioral state of the target virtual character; in response to receiving the node identifier and running state of a first branch node sent by the first client, controlling the behavioral state of the target virtual character according to the node identifier, running state, and the second behavioral graph of the target virtual character, thereby synchronizing the behavioral state of the target virtual character in the first client with the behavioral state of the target virtual character in the second client; wherein the second behavioral graph is the same as the first behavioral graph.

[0006] Thirdly, embodiments of the present invention provide a behavior state synchronization device, which is disposed in a first client. The device includes: a first loading module, used to load a first behavior graph of a target virtual character in response to a game start command; wherein the first behavior graph includes multiple branch nodes, and the branch nodes are preset with node identifiers; the branch nodes are used to control the behavior state of the target virtual character; the target virtual character is controlled through the first client; a determining module, used to determine, in response to a change in the behavior state of the target virtual character, the node identifier of the first branch node affecting the behavior state of the target virtual character, and the running state of the first branch node from the first behavior graph; and a sending module, used to send the node identifier and the running state of the first branch node to a second client, and through the second client, according to the node identifier and the running state of the first branch node, and the second behavior graph of the target virtual character, control the behavior state of the target virtual character, so that the behavior state of the target virtual character in the first client is synchronized with the behavior state of the target virtual character in the second client; wherein the second behavior graph is the same as the first behavior graph.

[0007] Fourthly, embodiments of the present invention provide a behavior state synchronization device, which is disposed in a second client. The device includes: a second loading module, used to load a second behavior graph of a target virtual character in response to a game start command; the target virtual character is controlled by a first client; the first client contains a first behavior graph of the target virtual character; wherein the first behavior graph includes multiple branch nodes, and the branch nodes are preset with node identifiers; the branch nodes are used to control the behavior state of the target virtual character; a state synchronization module, used to control the behavior state of the target virtual character in response to receiving the node identifier and running state of the first branch node sent by the first client, based on the node identifier, running state of the first branch node, and the second behavior graph of the target virtual character, so that the behavior state of the target virtual character in the first client is synchronized with the behavior state of the target virtual character in the second client; wherein the second behavior graph is the same as the first behavior graph.

[0008] Fifthly, embodiments of the present invention provide an electronic device, including a processor and a memory, wherein the memory stores computer-executable instructions that can be executed by the processor, and the processor executes the computer-executable instructions to implement the method for synchronizing the behavioral state of any of the first aspects, or to implement the method for synchronizing the behavioral state of any of the second aspects.

[0009] In a sixth aspect, embodiments of the present invention provide a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are invoked and executed by a processor, the computer-executable instructions cause the processor to implement the synchronization method of the behavioral state of any of the first aspects, or to implement the synchronization method of the behavioral state of any of the second aspects.

[0010] The embodiments of the present invention bring the following beneficial effects:

[0011] This invention provides a method, apparatus, and electronic device for synchronizing behavioral states. In response to a change in the behavioral state of a target virtual character, the method determines the node identifier and running state of a first branch node affecting the behavioral state of the target virtual character from a first behavioral graph. The node identifier and running state are then sent to a second client. The second client synchronizes the behavioral state of the target virtual character based on the node identifier, running state, and a second behavioral graph identical to the first behavioral graph. This method loads the same behavioral graph for the same virtual character on different clients. When synchronizing the behavioral state of the target virtual character, only the information of the active branch nodes in the first behavioral graph needs to be sent to the second client. The second client synchronizes the behavioral state of the target virtual character based on the branch node information and the second behavioral graph. This eliminates the need for scripting, simplifies the development process, reduces development workload, and minimizes game performance overhead.

[0012] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0013] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0014] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0015] Figure 1 A flowchart illustrating a method for synchronizing behavioral states according to an embodiment of the present invention;

[0016] Figure 2 A flowchart of another method for synchronizing behavioral states provided in an embodiment of the present invention;

[0017] Figure 3 A schematic diagram of the structure of a behavior state synchronization device provided in an embodiment of the present invention;

[0018] Figure 4 A schematic diagram of another synchronization device for behavioral states provided in an embodiment of the present invention;

[0019] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] In current 3D games, the behavior of game characters is typically controlled by nodes in a behavior graph. The behavior graph contains numerous state machines and branch selection nodes. These nodes determine the active branch based on specific game logic (such as player input via keyboard or mouse, or perceptual responses within the game scene). Based on the activated branch, the virtual character executes the corresponding behavior. In actual game execution, the game engine traverses the behavior graph from top to bottom for each frame to determine the active branch.

[0022] In online games, the position and behavior of a player-controlled virtual character need to be synchronized in real-time to other clients to ensure that other players perceive the same position and behavior. For example, the virtual character's position, direction, and actions need to be accurately synchronized to other clients in real-time so that the behavior displayed on other clients matches the behavior displayed on the client controlling the virtual character. However, as the combinations of virtual character actions become increasingly complex, and game logic becomes more intricate, the quality and performance requirements for synchronizing the virtual character's behavior also become increasingly demanding.

[0023] In related technologies, when the behavior of a player-controlled virtual character changes, a pre-configured script is used to remotely notify other clients to update the behavior graph. This allows other clients to control the virtual character's actions based on the updated graph, ensuring consistency across all clients. This approach requires writing a large amount of script code, resulting in a tedious and labor-intensive development process. Furthermore, while the internal logic of the behavior graph is actually independent of the script, both the internal logic of the behavior graph and the external script logic controlling the virtual character's behavior require state synchronization via a pre-defined script, leading to significant performance overhead in the game.

[0024] Based on this, embodiments of the present invention provide a method, apparatus, and electronic device for synchronizing behavioral states, which can be applied to devices such as mobile phones, computers, and laptops.

[0025] To facilitate understanding of this embodiment, a method for synchronizing behavioral states disclosed in this invention will first be described in detail, such as... Figure 1 As shown, the method includes the following steps:

[0026] Step S102: In response to the game start command, load the first behavior graph of the target virtual character; wherein, the first behavior graph includes multiple branch nodes, and the branch nodes are preset with node identifiers; the branch nodes are used to control the behavior state of the target virtual character; the target virtual character is controlled through the first client;

[0027] The first-line graph of the aforementioned target virtual character is a tree structure organized with various functional nodes, typically including five categories of nodes: animation playback nodes, procedural post-processing nodes, branch selection nodes, triggers, and mathematical operation nodes. Animation playback nodes sample animation resources and modify the character's skeleton transformation (mainly rotation and translation). They support motion blending or motion overlay. If multiple motion nodes are active within a frame, they usually have different blending ratios. Procedural post-processing nodes, based on forward kinematics (FK) or inverse kinematics (IK), procedurally modify the character's skeleton transformation, typically used to control the virtual character's hands gripping objects or its feet conforming to uneven terrain. Branch selection nodes, in the tree structure, have multiple sub-branches and activate one or a few branches as needed. State machines also belong to branch selection nodes within the tree structure. Triggers change the activated branch of a branch selection node through its internal logic. Mathematical operation nodes allow some states of the above-mentioned nodes to be calculated and input.

[0028] The node identifiers mentioned above can be numerical, alphabetical, or even string identifiers. In actual implementation, behavior graphs, whether identical or different, are typically created beforehand for different virtual characters. When the game is opened in the first client or the behavior of the target virtual character is controlled, the first behavior graph is loaded first, and during the loading process, each branch node in the first behavior graph is assigned a corresponding node identifier. Specifically, when loading the first behavior graph, a depth-first search is performed on each branch node in the first behavior graph, and a node identifier (or ID) is set for each branch node in sequence.

[0029] Step S104: In response to a change in the behavior state of the target virtual character, determine the node identifier of the first branch node that affects the behavior state of the target virtual character, as well as the running state of the first branch node, from the first behavior graph.

[0030] The operational status of the aforementioned first branch node typically includes specific actions, the duration of the actions, and the fusion ratio between multiple actions. For example, actions with a fusion ratio of 0.6 might play for 2 seconds, actions with a fusion ratio of 0.4 might play for 0.5 seconds, the lumbar spine might need to rotate 10 degrees, and the feet might need to adapt to the scene's terrain height. The aforementioned first branch node usually refers to an active branch node. The node identifier can be a numerical identifier such as "001" or "002," a letter identifier such as "a" or "b," or an encoded string identifier. Furthermore, the aforementioned first branch node can be one or more branch nodes.

[0031] Specifically, this can be achieved by traversing the first line of the graph, identifying the active branch through branch selection nodes, and then finding the active first branch node, which typically includes animation playback nodes and procedural post-processing nodes. Alternatively, the behavior of the target virtual character can be altered by the player controlling external or terminal devices, or by the target virtual character triggering a specific action within the game scene, thereby changing its behavior.

[0032] One possible implementation: In response to a change in the behavior state of the target virtual character, traverse the branch nodes in the first behavior graph and determine the active branch node as the first branch node; wherein, the first branch node includes an animation playback node and a procedural processing node; obtain the node identifier and running state of the first branch node.

[0033] Step S106: Send the node identifier and running status of the first branch node to the second client. Through the second client, based on the node identifier and running status of the first branch node, and the second behavior graph of the target virtual character, control the behavior state of the target virtual character so that the behavior state of the target virtual character in the first client is synchronized with the behavior state of the target virtual character in the second client; wherein, the second behavior graph is the same as the first behavior graph.

[0034] The aforementioned second client includes one or more. The second behavioral graph of the target virtual character is the same as the first behavioral graph; that is, the behavioral graph of the target virtual character loaded by the second client is the aforementioned first behavioral graph. During the loading process, node identifiers are simultaneously set for the branch nodes of the second behavioral graph, and the node identifiers in the second behavioral graph are the same as the node identifiers in the first behavioral graph. Specifically, the branch nodes included in the aforementioned second behavioral graph have preset node identifiers; the preset node identifiers of the branch nodes in the second behavioral graph are the same as the preset node identifiers of the branch nodes in the first behavioral graph.

[0035] Specifically, the node identifier and running status of the first branch node are first sent to the server, which then forwards them to the second client. Upon receiving the node identifier and running status of the first branch node, the second client can determine the second branch node affecting the target virtual character's behavior from the second behavior graph based on the node identifier. Then, it determines the running status of the second branch node based on the running status of the first branch node. Finally, it directly controls the target virtual character's behavior through the running status of the second branch node. For example, if the running status of the first branch node is "the lumbar spine needs to rotate 10 degrees," this running status is applied to the second branch node. Based on the running status of the second branch node, "the lumbar spine needs to rotate 10 degrees," the target virtual character is controlled to perform this action to synchronize the target virtual character's behavior, thereby synchronizing the target virtual character's behavior between the first and second clients.

[0036] This invention provides a method for synchronizing behavioral states. In response to a game start command, a first behavioral graph of a target virtual character is loaded. The first behavioral graph includes multiple branch nodes, each with a preset node identifier. These branch nodes control the behavioral state of the target virtual character. The target virtual character is controlled by a first client. In response to a change in the behavioral state of the target virtual character, the node identifier of the first branch node affecting the behavioral state of the target virtual character, as well as the running state of the first branch node, are determined from the first behavioral graph. A sending module sends the node identifier and running state of the first branch node to a second client. The second client, based on the node identifier and running state of the first branch node, and the second behavioral graph of the target virtual character, controls the behavioral state of the target virtual character, synchronizing the behavioral state of the target virtual character in the first client with that in the second client. The second behavioral graph is identical to the first behavioral graph. In this method, by loading the same behavior graph for the same virtual character on different clients, when synchronizing the behavior state of the target virtual character, it is only necessary to send the information of the activated branch nodes in the first behavior graph to the second client. The second client synchronizes the behavior state of the target virtual character based on the information of the branch nodes and the second behavior graph. No scripts need to be written, which simplifies the development process, reduces the workload of development, and reduces the performance overhead of the game.

[0037] The above steps, which involve controlling the behavior of the target virtual character via a second client based on the node identifier of the first branch node, the running status of the first branch node, and the second behavior graph of the target virtual character, can be implemented in one possible way:

[0038] Using the second client, the second branch node corresponding to the first branch node is determined from the second behavioral graph based on the node identifier of the first branch node; the running state of the first branch node is applied to the second branch node, and the behavioral state of the target virtual character is controlled based on the second branch node.

[0039] Specifically, since the first row of the graph is the same as the second row of the graph, and the node identifiers in the first row of the graph are the same as those in the second row of the graph, the branch node with the same identifier as the first branch node can be found in the second row of the graph, which is the active branch node, i.e., the aforementioned second branch node. Then, the running state of the first branch node is applied to the second branch node, so that the running state of the active second branch node in the second row of the graph is the same as the running state of the active first branch node in the first row of the graph. Finally, based on the running state of the second branch node, the target virtual character is controlled to perform the corresponding behavior. This allows the behavior state of the target virtual character in the first client to be synchronized with the behavior state of the target virtual character in the second client.

[0040] In this approach, the second client does not need to traverse the activated nodes from top to bottom in the second behavior graph. Instead, it directly finds the second branch node related to the behavior state based on the network synchronization results (i.e., the node identifier and running status of the first branch node mentioned above). It then controls the target virtual character to perform the corresponding action based on this second branch node. This skips a large number of functional nodes that do not directly affect the behavior state but only influence decision-making, reducing unnecessary performance overhead. Furthermore, using a more general method to implement action network synchronization at the game engine's underlying layer eliminates the need to consider whether external script logic or internal behavior graph logic drives the virtual character's action changes.

[0041] To compress the amount of data transmitted over the network and improve transmission speed, and considering that the number of nodes requiring network synchronization for each frame may vary, and that different types of nodes have different operating states and data volumes, the step of sending the node identifier and operating status of the first branch node to the second client can be implemented in the following possible way:

[0042] The running status of the first branch node is converted into an integer type; based on the converted running status of the first branch node and the node identifier of the first branch node, the target list is determined; the target list is converted into a string and sent to the server, which then forwards it to the second client.

[0043] The node identifiers mentioned above are integer values. This means that when setting node identifiers for branch nodes while loading the first row of the graph, a separate integer value, NodeID, can be assigned to each branch node. Therefore, the node identifier of the first branch node is an integer value. To further reduce data volume, the running status of the first branch node is converted to an integer (int) type. Then, the node identifier (i.e., NodeID) and running status of the first branch node are transmitted in the form of an int list (i.e., the target list mentioned above). In other words, after determining the target list, it can be directly sent to the server, which then forwards it to the second client.

[0044] Additionally, to save bandwidth, the list of integers (i.e., the target list) can be converted to a string and sent to the server, which then forwards it to the second client. Specifically, the running status of branch nodes is generally a floating-point type (float). Within an acceptable error range, float can be mapped to int (e.g., mapping a fusion ratio ranging from 0 to 1 to an integer ranging from -50 to 50) to save bandwidth. Finally, the list of integers is converted to a string before being sent. In this method, node identifiers and running statuses are converted, thereby reducing the amount of data transmitted over the network and improving transmission speed.

[0045] In related technologies, for the synchronization of a virtual character's position and orientation (generally only yaw), since position and orientation changes are frequent and the data format is relatively simple, a common approach is to upload the position and orientation to the server at fixed time intervals (e.g., 0.1 seconds) when the virtual character's position or orientation changes. Other clients will receive the position and orientation information from the server and change the virtual character's position and orientation accordingly. For the virtual character's action state, a common existing approach is to use scripts to notify the server via Remote Procedure Call (RPC) when it is necessary to change the active branch of the behavior graph or modify the running state of a node. The server then forwards the notification to other clients to update the state of the behavior graph branch or node. Because position synchronization and action synchronization are implemented in different ways, there may be a time lag between synchronized position changes and action changes. This time lag is more pronounced for actions with rapid, instantaneous position changes, such as jumping and climbing.

[0046] Therefore, to ensure that the action and position change simultaneously and avoid a time lag, another possible implementation of the above step of sending the node identifier and running status of the first branch node to the second client is as follows:

[0047] Obtain the location information of the target virtual character; send the location information, the node identifier of the first branch node, and the running status of the first branch node to the server, and then forward it to the second client through the server.

[0048] One possible approach is to encode the location information, along with the node identifier and running status string of the first branch node, into a single data packet. This packet is then sent to the server, which forwards it to the second client. This method, by simultaneously sending the changed location information, the node identifier of the first branch node, and its running status, avoids a time lag between actions and locations, thus improving the synchronization of behavioral states.

[0049] Considering that when the number of first branch nodes in network transmission is large, the data packets may be very large (or the strings may be very long), in order to save the amount of data transmitted over the network, after the step of sending the node identifier and running status of the first branch node to the second client, the method further includes:

[0050] In response to a change in the behavior state of the target virtual character, if the behavior state after the change is continuous with the behavior state before the change, a target instruction is generated; the target instruction is sent to the second client, and through the second client, the behavior state of the target virtual character is controlled according to the node identifier of the first branch node, the running status of the first branch node, and the second behavior graph of the target virtual character.

[0051] Specifically, when the behavior state of the target virtual character changes, it is first determined whether the current behavior state of the target virtual character remains continuous with the previous behavior state, such as continuously running or walking in a specified direction, or repeatedly performing jumping actions. At this time, in order to save the amount of data transmitted over the network, a target instruction can be generated. This target instruction is used to indicate that the first branch node and the second branch node activated in the current first and second line graphs remain unchanged, and their running states also remain unchanged. That is to say, the activated actions are all played at the same fusion ratio and the same playback rate, and the running state of the programmatic post-processing nodes has not been changed.

[0052] Then, the target instruction is forwarded by the server to the second client, enabling the second client to continue controlling the target virtual character to perform corresponding actions based on the current running state of the second branch node. In other words, when the action state remains continuous, the second client can directly reuse the previously received data, while the first client does not need to repeatedly send the same data, saving bandwidth. In this method, when the target virtual character continuously performs the same behavior, there is no need to continuously send information about the active branch node to generate the target instruction, thus saving network transmission data and improving the synchronization efficiency of the behavior state.

[0053] The above approach addresses the need for network synchronization of virtual character actions at the engine level, eliminating the need for dedicated script-level handling of synchronized behavior states via RPC or similar methods. This reduces the workload of script programmers and lowers performance overhead. Simultaneous sending and receiving of action states, position, and direction ensures temporal consistency between action and position changes, avoiding synchronization time lags. In creating behavior graphs, only the use of the target virtual character in the first client needs to be considered; there's no need to create separate behavior graphs for the target virtual character in the second client, or add special markers to the behavior graph to distinguish between the main character and third-party characters, simplifying the development process.

[0054] Secondly, embodiments of the present invention provide a method for synchronizing behavioral states, which is applied to a second client, such as... Figure 2 As shown, the method includes the following steps:

[0055] Step S202: In response to the game start command, load the second behavior graph of the target virtual character; wherein, the target virtual character is controlled by the first client; the first client loads the first behavior graph of the target virtual character; the first behavior graph includes multiple branch nodes, and the branch nodes are preset with node identifiers; the branch nodes are used to control the behavior state of the target virtual character;

[0056] Step S204: In response to receiving the node identifier and running status of the first branch node sent by the first client, the behavior status of the target virtual character is controlled according to the node identifier and running status of the first branch node, and the second behavior graph of the target virtual character, so that the behavior status of the target virtual character in the first client is synchronized with the behavior status of the target virtual character in the second client; wherein, the second behavior graph is the same as the first behavior graph.

[0057] This invention provides a method for synchronizing behavioral states. In response to a game start command, a second behavioral graph of a target virtual character is loaded. The target virtual character is controlled by a first client. The first client contains a first behavioral graph of the target virtual character. The first behavioral graph includes multiple branch nodes, each with a preset node identifier. These branch nodes control the behavioral state of the target virtual character. In response to receiving the node identifier and running status of a first branch node from the first client, the method controls the behavioral state of the target virtual character based on the node identifier, running status, and the second behavioral graph of the target virtual character, synchronizing the behavioral state of the target virtual character in the first client with that in the second client. The second behavioral graph is identical to the first behavioral graph. This method loads the same behavioral graph for the same virtual character on different clients. When synchronizing the behavioral state of the target virtual character, only the information of the activated branch nodes in the first behavioral graph needs to be sent to the second client. The second client synchronizes the behavioral state of the target virtual character based on the branch node information and the second behavioral graph. This eliminates the need for scripting, simplifying the development process, reducing workload, and minimizing game performance overhead.

[0058] The branch nodes in the second row of the diagram are pre-defined with node identifiers; the pre-defined node identifiers of the branch nodes in the second row are the same as those of the branch nodes in the first row.

[0059] The above-described steps, in response to receiving the node identifier and running status of the first branch node sent by the first client, and controlling the behavior state of the target virtual character based on the node identifier, running status of the first branch node, and the second behavior graph of the target virtual character, can be implemented in one possible way:

[0060] In response to receiving a data packet sent by the first client, the data packet is decoded to obtain the node identifier and running status of the first branch node; based on the node identifier of the first branch node, the second branch node corresponding to the first branch node is determined from the second behavioral graph; the running status of the first branch node is applied to the second branch node, and the behavioral status of the target virtual character is controlled based on the second branch node.

[0061] Specifically, the second client restores the node identifier (i.e., NodeID) of the first branch node and the running status of each first branch node by decoding the string. Then, it finds the corresponding second branch node in the second row of the graph according to the NodeID, applies the running status of the first branch node to the second branch node, and controls the action of the target virtual character according to the second branch node.

[0062] Understandably, for the second client, it only needs to run the corresponding animation playback nodes and procedural post-processing nodes, and ensure that the running states of these nodes (such as motion blending ratio, animation playback progress, etc.) are consistent with the state of the target virtual character in the first client. In this case, the behavior state of the target virtual character in the second client will be identical to that in the first client. That is, it only needs to synchronize the result of the motion playback (i.e., which nodes directly affect the motion), but not the process that affects the motion playback (i.e., the selection result of the branch selection node and some internal states). After obtaining the result, the second client does not need to traverse the node tree from top to bottom. Instead, it can start from the result, directly find these active nodes in the first line graph, apply the received running states to the corresponding second branch nodes, and make the second branch nodes work.

[0063] The above method further includes: in response to receiving a target instruction sent by a first client, controlling the behavior state of the target virtual character according to the node identifier of the first branch node, the running status of the first branch node, and the second behavior graph of the target virtual character; wherein the target instruction is used to indicate that the behavior state of the target virtual character after the change is a continuous behavior state with the behavior state of the target virtual character before the change.

[0064] Corresponding to the above method embodiments, this embodiment of the invention provides a behavior state synchronization device, which is set on a first client, such as... Figure 3 As shown, the device includes:

[0065] The first loading module 301 is used to load the first behavior graph of the target virtual character in response to the game start command; wherein, the first behavior graph includes multiple branch nodes, and the branch nodes are preset with node identifiers; the branch nodes are used to control the behavior state of the target virtual character; the target virtual character is controlled through the first client;

[0066] The determination module 302 is used to determine, in response to a change in the behavior state of the target virtual character, the node identifier of the first branch node affecting the behavior state of the target virtual character, and the running state of the first branch node from the first behavior graph.

[0067] The sending module 303 is used to send the node identifier and running status of the first branch node to the second client. Through the second client, based on the node identifier and running status of the first branch node and the second behavior graph of the target virtual character, the behavior state of the target virtual character is controlled so that the behavior state of the target virtual character in the first client is synchronized with the behavior state of the target virtual character in the second client; wherein, the second behavior graph is the same as the first behavior graph.

[0068] This invention provides a device for synchronizing behavioral states. A first loading module loads a first behavioral graph of a target virtual character in response to a game start command. The first behavioral graph includes multiple branch nodes, each with a preset node identifier. These branch nodes control the behavioral state of the target virtual character, which is controlled by a first client. A determining module determines, in response to a change in the behavioral state of the target virtual character, the node identifier of the first branch node affecting the behavioral state of the target virtual character, and the running state of the first branch node, from the first behavioral graph. A sending module sends the node identifier and running state of the first branch node to a second client. The second client, based on the node identifier and running state of the first branch node, and the second behavioral graph of the target virtual character, controls the behavioral state of the target virtual character, synchronizing the behavioral state of the target virtual character in the first client with that in the second client. The second behavioral graph is identical to the first behavioral graph. In this method, by loading the same behavior graph for the same virtual character on different clients, when synchronizing the behavior state of the target virtual character, it is only necessary to send the information of the activated branch nodes in the first behavior graph to the second client. The second client synchronizes the behavior state of the target virtual character based on the information of the branch nodes and the second behavior graph. No scripts need to be written, which simplifies the development process, reduces the workload of development, and reduces the performance overhead of the game.

[0069] The branch nodes included in the second row of the above-mentioned graph have preset node identifiers; the preset node identifiers of the branch nodes in the second row of the graph are the same as the preset node identifiers of the branch nodes in the first row of the graph; the above-mentioned sending module is also used to: determine the second branch node corresponding to the first branch node from the second row of the graph based on the node identifier of the first branch node through the second client; apply the running state of the first branch node to the second branch node, and control the behavior state of the target virtual character based on the second branch node.

[0070] The aforementioned sending module is also used to: convert the running status of the first branch node into an integer type; determine the target list based on the converted running status of the first branch node and the node identifier of the first branch node; convert the target list into a string and send it to the server, which then forwards it to the second client.

[0071] The above node identifiers are integer values.

[0072] The aforementioned sending module is also used to: obtain the location information of the target virtual character; send the location information, the node identifier of the first branch node, and the running status of the first branch node to the server, and forward them to the second client through the server.

[0073] The aforementioned device further includes a target instruction sending module, configured to: generate a target instruction in response to a change in the behavior state of the target virtual character, if the behavior state after the change is continuous with the behavior state before the change; send the target instruction to a second client, and through the second client, continue to control the behavior state of the target virtual character based on the node identifier of the first branch node, the running status of the first branch node, and the second behavior graph of the target virtual character.

[0074] The aforementioned determining module is also used to: respond to a change in the behavior state of the target virtual character, traverse the branch nodes in the first behavior graph, and determine the activated branch node as the first branch node; wherein, the first branch node includes an animation playback node and a procedural processing node; and obtain the node identifier and running state of the first branch node.

[0075] The behavior state synchronization device provided in this embodiment of the invention has the same technical features as the behavior state synchronization method provided in the above embodiments, so it can also solve the same technical problems and achieve the same technical effects.

[0076] Corresponding to the above method embodiments, this embodiment of the invention provides a behavior state synchronization device, which is set on a second client, such as... Figure 4 As shown, the device includes:

[0077] The second loading module 401 is used to load the second behavior graph of the target virtual character in response to the game start command; the target virtual character is controlled by the first client; the first client loads the first behavior graph of the target virtual character; wherein, the first behavior graph includes multiple branch nodes, and the branch nodes are preset with node identifiers; the branch nodes are used to control the behavior state of the target virtual character;

[0078] The state synchronization module 402 is used to respond to receiving the node identifier and running status of the first branch node sent by the first client, and control the behavior state of the target virtual character according to the node identifier, running status of the first branch node, and the second behavior graph of the target virtual character, so that the behavior state of the target virtual character in the first client is synchronized with the behavior state of the target virtual character in the second client; wherein, the second behavior graph is the same as the first behavior graph.

[0079] This invention provides a behavior state synchronization device, a second loading module, for loading a second behavior graph of a target virtual character in response to a game start command; the target virtual character is controlled by a first client; the first client loads a first behavior graph of the target virtual character; wherein the first behavior graph includes multiple branch nodes, each branch node having a preset node identifier; the branch nodes are used to control the behavior state of the target virtual character; a state synchronization module, for controlling the behavior state of the target virtual character based on the node identifier and running state of the first branch node sent by the first client, according to the node identifier, running state, and the second behavior graph of the target virtual character, so that the behavior state of the target virtual character in the first client is synchronized with that in the second client; wherein the second behavior graph is identical to the first behavior graph. In this method, by loading the same behavior graph for the same virtual character on different clients, when synchronizing the behavior state of the target virtual character, only the information of the activated branch nodes in the first behavior graph needs to be sent to the second client. The second client synchronizes the behavior state of the target virtual character based on the branch node information and the second behavior graph, eliminating the need for scripting, simplifying the development process, reducing development workload, and reducing game performance overhead.

[0080] The branch nodes in the second row of the above diagram are pre-defined with node identifiers; the pre-defined node identifiers of the branch nodes in the second row of the diagram are the same as the pre-defined node identifiers of the branch nodes in the first row of the diagram.

[0081] The aforementioned state synchronization module is also used to: in response to receiving a data packet sent by the first client, decode the data packet to obtain the node identifier and running status of the first branch node; determine the second branch node corresponding to the first branch node from the second behavior graph based on the node identifier of the first branch node; apply the running status of the first branch node to the second branch node, and control the behavior status of the target virtual character based on the second branch node.

[0082] The aforementioned device further includes a target instruction receiving module, configured to: in response to receiving a target instruction sent by a first client, control the behavior state of the target virtual character based on the node identifier of the first branch node, the running state of the first branch node, and the second behavior graph of the target virtual character; wherein the target instruction is used to indicate that the behavior state of the target virtual character after the change is a continuous behavior state with the behavior state of the target virtual character before the change.

[0083] The behavior state synchronization device provided in this embodiment of the invention has the same technical features as the behavior state synchronization method provided in the above embodiments, so it can also solve the same technical problems and achieve the same technical effects.

[0084] This embodiment also provides an electronic device, including a processor and a memory. The memory stores machine-executable instructions that can be executed by the processor. The processor executes the machine-executable instructions to implement the above-described method for synchronizing behavioral states. This electronic device can be a server or a terminal device.

[0085] See Figure 5 As shown, the electronic device includes a processor 100 and a memory 101. The memory 101 stores machine-executable instructions that can be executed by the processor 100. The processor 100 executes the machine-executable instructions to implement the above-described method for synchronizing behavioral states.

[0086] Furthermore, Figure 5 The electronic device shown also includes a bus 102 and a communication interface 103, with the processor 100, the communication interface 103 and the memory 101 connected via the bus 102.

[0087] The memory 101 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 103 (which can be wired or wireless), such as the Internet, wide area network, local area network, or metropolitan area network. The bus 102 may be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0088] Processor 100 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 100 or by instructions in software form. Processor 100 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 101. The processor 100 reads information from memory 101 and, in conjunction with its hardware, completes the steps of the behavior state synchronization method of the aforementioned embodiment, with the first client as the execution subject. Specifically, this includes:

[0089] In response to the game start command, the first behavior graph of the target virtual character is loaded. This first behavior graph includes multiple branch nodes, each with a pre-defined node identifier. These branch nodes control the behavior state of the target virtual character. The target virtual character is controlled through a first client. In response to a change in the target virtual character's behavior state, the node identifier of the first branch node affecting the target virtual character's behavior state, as well as the running state of the first branch node, are determined from the first behavior graph. The node identifier and running state of the first branch node are sent to a second client. The second client, based on the node identifier and running state of the first branch node, and the second behavior graph of the target virtual character, controls the behavior state of the target virtual character, synchronizing the behavior state of the target virtual character in the first client with that in the second client. The second behavior graph is identical to the first behavior graph. In this method, by loading the same behavior graph for the same virtual character on different clients, when synchronizing the behavior state of the target virtual character, it is only necessary to send the information of the activated branch nodes in the first behavior graph to the second client. The second client synchronizes the behavior state of the target virtual character based on the information of the branch nodes and the second behavior graph. No scripts need to be written, which simplifies the development process, reduces the workload of development, and reduces the performance overhead of the game.

[0090] The branch nodes in the second behavior graph mentioned above are pre-defined with node identifiers. These identifiers are the same as those in the first behavior graph. The steps for controlling the behavior state of the target virtual character via the second client, based on the node identifiers of the first branch nodes, their running status, and the second behavior graph of the target virtual character, include: determining the second branch node corresponding to the first branch node from the second behavior graph based on the node identifiers; applying the running status of the first branch node to the second branch node; and controlling the behavior state of the target virtual character based on the second branch node. Notably, the second client does not need to perform a top-down traversal of activated nodes in the second behavior graph. Instead, it directly finds the second branch node related to the behavior state based on the network synchronization results (i.e., the node identifiers and running status of the first branch node), and controls the target virtual character to perform corresponding actions based on this second branch node. This skips a large number of functional nodes that do not directly affect the behavior state but only influence decision-making, reducing unnecessary performance overhead. Furthermore, using a more general approach to implement action network synchronization at the game engine's underlying layer eliminates the need to consider whether external script logic or internal behavior graph logic drives the virtual character's action changes.

[0091] The steps described above for sending the node identifier and running status of the first branch node to the second client include: converting the running status of the first branch node into an integer type; determining a target list based on the converted running status and node identifier of the first branch node; converting the target list into a string and sending it to the server, which then forwards it to the second client. This method converts the node identifier and running status data, thereby reducing the amount of data transmitted over the network and improving transmission speed.

[0092] The above node identifiers are integer values.

[0093] The steps described above, which involve sending the node identifier and running status of the first branch node to the second client, further include: obtaining the location information of the target virtual character; sending the location information, the node identifier of the first branch node, and the running status of the first branch node to the server, which then forwards them to the second client. This method, by simultaneously sending the changed location information, the node identifier of the first branch node, and its running status, avoids a time lag between actions and locations, thus improving the synchronization effect of behavioral states.

[0094] Following the steps of sending the node identifier and running status of the first branch node to the second client, the method further includes: in response to a change in the behavior state of the target virtual character, if the changed behavior state is continuous with the previous behavior state, generating a target instruction; sending the target instruction to the second client, and through the second client, continuing to control the behavior state of the target virtual character based on the node identifier of the first branch node, the running status of the first branch node, and the second behavior graph of the target virtual character. In this approach, when the target virtual character continuously performs the same action, it is unnecessary to continuously send information about the active branch node to generate the target instruction, thus saving network transmission data and improving the synchronization efficiency of the behavior state.

[0095] The steps described above, in response to a change in the behavior state of the target virtual character, to determine the node identifier of the first branch node affecting the behavior state of the target virtual character from the first behavior graph, and the running state of the first branch node, include: in response to a change in the behavior state of the target virtual character, traversing the branch nodes in the first behavior graph, and determining the active branch node as the first branch node; wherein, the first branch node includes animation playback nodes and procedural processing nodes; and obtaining the node identifier and the running state of the first branch node.

[0096] The second client is the execution entity, specifically including:

[0097] In response to the game start command, a second behavior graph of the target virtual character is loaded. The target virtual character is controlled by a first client. The first client contains the first behavior graph of the target virtual character. The first behavior graph includes multiple branch nodes, each with a preset node identifier. These branch nodes control the behavior state of the target virtual character. In response to receiving the node identifier and running status of the first branch node from the first client, the behavior state of the target virtual character is controlled based on the node identifier, running status, and the second behavior graph of the target virtual character, synchronizing the behavior state of the target virtual character in the first client with that in the second client. The second behavior graph is identical to the first behavior graph. This method loads the same behavior graph for the same virtual character on different clients. When synchronizing the behavior state of the target virtual character, only the information of the activated branch nodes in the first behavior graph needs to be sent to the second client. The second client synchronizes the behavior state of the target virtual character based on the branch node information and the second behavior graph. This eliminates the need for scripting, simplifying the development process, reducing workload, and minimizing game performance overhead.

[0098] The branch nodes in the second row of the above diagram are pre-defined with node identifiers; the pre-defined node identifiers of the branch nodes in the second row of the diagram are the same as the pre-defined node identifiers of the branch nodes in the first row of the diagram.

[0099] The steps described above, in response to receiving the node identifier and running status of the first branch node sent by the first client, and controlling the behavior state of the target virtual character based on the node identifier, running status of the first branch node, and the second behavior graph of the target virtual character, include: in response to receiving a data packet sent by the first client, decoding the data packet to obtain the node identifier and running status of the first branch node; determining the second branch node corresponding to the first branch node from the second behavior graph based on the node identifier of the first branch node; applying the running status of the first branch node to the second branch node, and controlling the behavior state of the target virtual character based on the second branch node.

[0100] The above method further includes: in response to receiving a target instruction sent by a first client, controlling the behavior state of the target virtual character according to the node identifier of the first branch node, the running status of the first branch node, and the second behavior graph of the target virtual character; wherein the target instruction is used to indicate that the behavior state of the target virtual character after the change is a continuous behavior state with the behavior state of the target virtual character before the change.

[0101] This embodiment also provides a machine-readable storage medium storing machine-executable instructions. When these machine-executable instructions are invoked and executed by a processor, they cause the processor to implement the aforementioned synchronization method for behavioral states. With a first client as the execution subject, the method specifically includes:

[0102] In response to the game start command, the first behavior graph of the target virtual character is loaded. This first behavior graph includes multiple branch nodes, each with a pre-defined node identifier. These branch nodes control the behavior state of the target virtual character. The target virtual character is controlled through a first client. In response to a change in the target virtual character's behavior state, the node identifier of the first branch node affecting the target virtual character's behavior state, as well as the running state of the first branch node, are determined from the first behavior graph. The node identifier and running state of the first branch node are sent to a second client. The second client, based on the node identifier and running state of the first branch node, and the second behavior graph of the target virtual character, controls the behavior state of the target virtual character, synchronizing the behavior state of the target virtual character in the first client with that in the second client. The second behavior graph is identical to the first behavior graph. In this method, by loading the same behavior graph for the same virtual character on different clients, when synchronizing the behavior state of the target virtual character, it is only necessary to send the information of the activated branch nodes in the first behavior graph to the second client. The second client synchronizes the behavior state of the target virtual character based on the information of the branch nodes and the second behavior graph. No scripts need to be written, which simplifies the development process, reduces the workload of development, and reduces the performance overhead of the game.

[0103] The branch nodes in the second behavior graph mentioned above are pre-defined with node identifiers. These identifiers are the same as those in the first behavior graph. The steps for controlling the behavior state of the target virtual character via the second client, based on the node identifiers of the first branch nodes, their running status, and the second behavior graph of the target virtual character, include: determining the second branch node corresponding to the first branch node from the second behavior graph based on the node identifiers; applying the running status of the first branch node to the second branch node; and controlling the behavior state of the target virtual character based on the second branch node. Notably, the second client does not need to perform a top-down traversal of activated nodes in the second behavior graph. Instead, it directly finds the second branch node related to the behavior state based on the network synchronization results (i.e., the node identifiers and running status of the first branch node), and controls the target virtual character to perform corresponding actions based on this second branch node. This skips a large number of functional nodes that do not directly affect the behavior state but only influence decision-making, reducing unnecessary performance overhead. Furthermore, using a more general approach to implement action network synchronization at the game engine's underlying layer eliminates the need to consider whether external script logic or internal behavior graph logic drives the virtual character's action changes.

[0104] The steps described above for sending the node identifier and running status of the first branch node to the second client include: converting the running status of the first branch node into an integer type; determining a target list based on the converted running status and node identifier of the first branch node; converting the target list into a string and sending it to the server, which then forwards it to the second client. This method converts the node identifier and running status data, thereby reducing the amount of data transmitted over the network and improving transmission speed.

[0105] The above node identifiers are integer values.

[0106] The steps described above, which involve sending the node identifier and running status of the first branch node to the second client, further include: obtaining the location information of the target virtual character; sending the location information, the node identifier of the first branch node, and the running status of the first branch node to the server, which then forwards them to the second client. This method, by simultaneously sending the changed location information, the node identifier of the first branch node, and its running status, avoids a time lag between actions and locations, thus improving the synchronization effect of behavioral states.

[0107] Following the steps of sending the node identifier and running status of the first branch node to the second client, the method further includes: in response to a change in the behavior state of the target virtual character, if the changed behavior state is continuous with the previous behavior state, generating a target instruction; sending the target instruction to the second client, and through the second client, continuing to control the behavior state of the target virtual character based on the node identifier of the first branch node, the running status of the first branch node, and the second behavior graph of the target virtual character. In this approach, when the target virtual character continuously performs the same action, it is unnecessary to continuously send information about the active branch node to generate the target instruction, thus saving network transmission data and improving the synchronization efficiency of the behavior state.

[0108] The steps described above, in response to a change in the behavior state of the target virtual character, to determine the node identifier of the first branch node affecting the behavior state of the target virtual character from the first behavior graph, and the running state of the first branch node, include: in response to a change in the behavior state of the target virtual character, traversing the branch nodes in the first behavior graph, and determining the active branch node as the first branch node; wherein, the first branch node includes animation playback nodes and procedural processing nodes; and obtaining the node identifier and the running state of the first branch node.

[0109] The second client is the execution entity, specifically including:

[0110] In response to the game start command, a second behavior graph of the target virtual character is loaded. The target virtual character is controlled by a first client. The first client contains the first behavior graph of the target virtual character. The first behavior graph includes multiple branch nodes, each with a preset node identifier. These branch nodes control the behavior state of the target virtual character. In response to receiving the node identifier and running status of the first branch node from the first client, the behavior state of the target virtual character is controlled based on the node identifier, running status, and the second behavior graph of the target virtual character, synchronizing the behavior state of the target virtual character in the first client with that in the second client. The second behavior graph is identical to the first behavior graph. This method loads the same behavior graph for the same virtual character on different clients. When synchronizing the behavior state of the target virtual character, only the information of the activated branch nodes in the first behavior graph needs to be sent to the second client. The second client synchronizes the behavior state of the target virtual character based on the branch node information and the second behavior graph. This eliminates the need for scripting, simplifying the development process, reducing workload, and minimizing game performance overhead.

[0111] The branch nodes in the second row of the above diagram are pre-defined with node identifiers; the pre-defined node identifiers of the branch nodes in the second row of the diagram are the same as the pre-defined node identifiers of the branch nodes in the first row of the diagram.

[0112] The steps described above, in response to receiving the node identifier and running status of the first branch node sent by the first client, and controlling the behavior state of the target virtual character based on the node identifier, running status of the first branch node, and the second behavior graph of the target virtual character, include: in response to receiving a data packet sent by the first client, decoding the data packet to obtain the node identifier and running status of the first branch node; determining the second branch node corresponding to the first branch node from the second behavior graph based on the node identifier of the first branch node; applying the running status of the first branch node to the second branch node, and controlling the behavior state of the target virtual character based on the second branch node.

[0113] The above method further includes: in response to receiving a target instruction sent by a first client, controlling the behavior state of the target virtual character according to the node identifier of the first branch node, the running status of the first branch node, and the second behavior graph of the target virtual character; wherein the target instruction is used to indicate that the behavior state of the target virtual character after the change is a continuous behavior state with the behavior state of the target virtual character before the change.

[0114] The computer program products of the behavior state synchronization method, apparatus and electronic device provided in the embodiments of the present invention include a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation, please refer to the method embodiments, which will not be repeated here.

[0115] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0116] Furthermore, in the description of the embodiments of the present invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in the present invention based on the specific circumstances.

[0117] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion 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.

[0118] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0119] Finally, it should be noted that the above embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for synchronizing behavioral states, characterized in that, The method is applied to a first client, and the method includes: In response to the game start command, a first behavior graph of the target virtual character is loaded; wherein, the first behavior graph includes multiple branch nodes, and the branch nodes are preset with node identifiers; the branch nodes are used to control the behavior state of the target virtual character; the target virtual character is controlled through the first client; In response to a change in the behavior state of the target virtual character, the node identifier of the first branch node affecting the behavior state of the target virtual character and the running state of the first branch node are determined from the first behavior graph. The node identifier and running status of the first branch node are sent to the second client. The second client, based on the node identifier and running status of the first branch node, and the second behavior graph of the target virtual character, controls the behavior state of the target virtual character, so that the behavior state of the target virtual character in the first client is synchronized with the behavior state of the target virtual character in the second client; wherein, the second behavior graph is the same as the first behavior graph. The branch nodes included in the second row diagram have preset node identifiers; the preset node identifiers of the branch nodes in the second row diagram are the same as the preset node identifiers of the branch nodes in the first row diagram. The steps of controlling the behavior state of the target virtual character through the second client, based on the node identifier of the first branch node, the running status of the first branch node, and the second behavior graph of the target virtual character, include: Using the second client, a second branch node corresponding to the first branch node is determined from the second line graph based on the node identifier of the first branch node; The running state of the first branch node is applied to the second branch node, and the behavior state of the target virtual character is controlled based on the second branch node.

2. The method according to claim 1, characterized in that, The step of sending the node identifier of the first branch node and the running status of the first branch node to the second client includes: Convert the running state of the first branch node into an integer type; Based on the transformed running status of the first branch node and the node identifier of the first branch node, determine the target list; The target list is converted into a string and sent to the server, which then forwards it to the second client.

3. The method according to claim 1, characterized in that, The node identifier is an integer value.

4. The method according to claim 1, characterized in that, The step of sending the node identifier of the first branch node and the running status of the first branch node to the second client further includes: Obtain the location information of the target virtual character; The location information, the node identifier of the first branch node, and the running status of the first branch node are sent to the server, and then forwarded to the second client by the server.

5. The method according to claim 1, characterized in that, After the step of sending the node identifier of the first branch node and the running status of the first branch node to the second client, the method further includes: In response to a change in the behavior state of the target virtual character, if the behavior state after the change is a continuous behavior state with the behavior state before the change, a target instruction is generated. The target instruction is sent to the second client. Through the second client, the behavior state of the target virtual character is controlled according to the node identifier of the first branch node, the running status of the first branch node, and the second behavior graph of the target virtual character.

6. The method according to claim 1, characterized in that, In response to a change in the behavioral state of the target virtual character, the steps of determining, from the first behavioral graph, the node identifier of the first branch node affecting the behavioral state of the target virtual character, and the running state of the first branch node, include: In response to a change in the behavioral state of the target virtual character, the branch nodes in the first behavior graph are traversed, and the activated branch node is determined as the first branch node; wherein, the first branch node includes an animation playback node and a procedural processing node. Obtain the node identifier and running status of the first branch node.

7. A method for synchronizing behavioral states, characterized in that, The method is applied to a second client, and the method includes: In response to a game start command, a second behavior graph of the target virtual character is loaded; wherein, the target virtual character is controlled through a first client; the first client loads a first behavior graph of the target virtual character; the first behavior graph includes multiple branch nodes, each branch node having a preset node identifier; the branch nodes are used to control the behavior state of the target virtual character; In response to receiving the node identifier of the first branch node and the running status of the first branch node sent by the first client, the behavior state of the target virtual character is controlled according to the node identifier of the first branch node, the running status of the first branch node, and the second behavior graph of the target virtual character, so that the behavior state of the target virtual character in the first client is synchronized with the behavior state of the target virtual character in the second client; wherein, the second behavior graph is the same as the first behavior graph; The branch nodes included in the second row diagram have preset node identifiers; the preset node identifiers of the branch nodes in the second row diagram are the same as the preset node identifiers of the branch nodes in the first row diagram. In response to receiving the node identifier and running status of the first branch node sent by the first client, the step of controlling the behavior state of the target virtual character based on the node identifier, the running status of the first branch node, and the second behavior graph of the target virtual character includes: In response to receiving a data packet sent by the first client, the data packet is decoded to obtain the node identifier of the first branch node and the running status of the first branch node; Based on the node identifier of the first branch node, determine the second branch node corresponding to the first branch node from the second row graph; The running state of the first branch node is applied to the second branch node, and the behavior state of the target virtual character is controlled based on the second branch node.

8. The method according to claim 7, characterized in that, The method further includes: In response to receiving a target instruction sent by the first client, the behavior state of the target virtual character is controlled according to the node identifier of the first branch node, the running status of the first branch node, and the second behavior graph of the target virtual character; wherein, the target instruction is used to indicate that the behavior state of the target virtual character after the change is a continuous behavior state with the behavior state of the target virtual character before the change.

9. A device for synchronizing behavioral states, characterized in that, The device is located at the first client, and the device includes: The first loading module is used to load a first behavior graph of the target virtual character in response to a game start command; wherein, the first behavior graph includes multiple branch nodes, and the branch nodes are preset with node identifiers; the branch nodes are used to control the behavior state of the target virtual character; the target virtual character is controlled through the first client; The determination module is used to, in response to a change in the behavior state of the target virtual character, determine from the first behavior graph the node identifier of the first branch node that affects the behavior state of the target virtual character, and the running state of the first branch node. The sending module is used to send the node identifier and running status of the first branch node to the second client. Through the second client, based on the node identifier and running status of the first branch node, and the second behavior graph of the target virtual character, the behavior state of the target virtual character is controlled to synchronize the behavior state of the target virtual character in the first client with the behavior state of the target virtual character in the second client; wherein, the second behavior graph is the same as the first behavior graph. The branch nodes included in the second row diagram have preset node identifiers; the preset node identifiers of the branch nodes in the second row diagram are the same as the preset node identifiers of the branch nodes in the first row diagram. The sending module is further configured to: determine, through the second client, a second branch node corresponding to the first branch node from the second behavior graph based on the node identifier of the first branch node; apply the running state of the first branch node to the second branch node; and control the behavior state of the target virtual character based on the second branch node.

10. A device for synchronizing behavioral states, characterized in that, The device is located at the second client, and the device includes: The second loading module is used to load a second behavior graph of the target virtual character in response to a game start command; the target virtual character is controlled by a first client; the first client loads a first behavior graph of the target virtual character; wherein, the first behavior graph includes multiple branch nodes, and the branch nodes are preset with node identifiers; the branch nodes are used to control the behavior state of the target virtual character; The state synchronization module is used to respond to receiving the node identifier of the first branch node and the running status of the first branch node sent by the first client, and according to the node identifier of the first branch node, the running status of the first branch node, and the second behavior graph of the target virtual character, control the behavior state of the target virtual character so that the behavior state of the target virtual character in the first client is synchronized with the behavior state of the target virtual character in the second client; wherein, the second behavior graph is the same as the first behavior graph; The branch nodes included in the second row diagram have preset node identifiers; the preset node identifiers of the branch nodes in the second row diagram are the same as the preset node identifiers of the branch nodes in the first row diagram. The state synchronization module is further configured to: in response to receiving a data packet sent by the first client, decode the data packet to obtain the node identifier of the first branch node and the running state of the first branch node; determine the second branch node corresponding to the first branch node from the second behavior graph based on the node identifier of the first branch node; apply the running state of the first branch node to the second branch node, and control the behavior state of the target virtual character based on the second branch node.

11. An electronic device, characterized in that, It includes a processor and a memory, the memory storing computer-executable instructions that can be executed by the processor, the processor executing the computer-executable instructions to implement the method for synchronizing behavioral states as described in any one of claims 1-6, or to implement the method for synchronizing behavioral states as described in any one of claims 7-8.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the synchronization method of behavioral states as described in any one of claims 1-6, or to implement the synchronization method of behavioral states as described in any one of claims 7-8.

Images