Data processing method, device and electronic equipment for virtual character in game

Abstract

The present disclosure provides a data processing method and device for a virtual character in a game and an electronic device, and relates to the technical field of games. The method alleviates the technical problem that the operation pressure of a client is large due to a large amount of data processing of the client. The method comprises: determining, based on a control instruction of a first virtual character by a first client, game state data generated in the process of the first virtual character executing the control instruction; encapsulating the game state data as a state frame; and sending the state frame to a server, so that the server sends the state frame to a second client, to display a game picture corresponding to the game state data on the second client.

Description

Technical Field

[0001] This disclosure relates to the field of game technology, and in particular to a method, apparatus, and electronic device for processing data of virtual characters in games. Background Technology

[0002] Currently, frame synchronization is a commonly used synchronization method in games, often used in games with few virtual characters, short game durations, but high requirements for fairness and consistency, such as fighting games, first-person shooters (FPS), and multiplayer online battle arenas (MOBA). Its biggest difference from traditional state synchronization is that it places the combat logic on the client side. For example, the client needs to perform a series of calculations based on received instructions, including skills, attacks, movements, collisions, and artificial intelligence (AI).

[0003] However, the existing data processing methods for virtual characters involve various calculations on the client side, resulting in a large amount of data processing and significant operational pressure on the client. Summary of the Invention

[0004] The purpose of this disclosure is to provide a method, apparatus, and electronic device for processing data of virtual characters in games, so as to alleviate the technical problem that the large amount of data processing on the client leads to a large operating pressure on the client.

[0005] In a first aspect, embodiments of this disclosure provide a data processing method for virtual characters in a game, wherein the game scene includes a first virtual character controlled by a first client, and the method includes:

[0006] Based on the control commands from the first client to the first virtual character, determine the game state data generated by the first virtual character during the execution of the control commands;

[0007] The game state data is encapsulated into a state frame;

[0008] The status frame is sent to the server, so that the server sends the status frame to the second client, so that the game screen corresponding to the game status data is displayed on the second client.

[0009] In one possible implementation, the game state data includes any one or more of the following:

[0010] The state data of the first virtual character, the state data of other virtual characters in the game scene besides the first virtual character, and the state data of other virtual objects.

[0011] In one possible implementation, the server corresponds to multiple game scenes; it also includes:

[0012] Determine the target game scene where the first virtual character is located;

[0013] The data of the target game scene is sent to the server, so that the server sends the status frame to the second client; wherein, the second virtual character controlled by the second client is another virtual character in the target game scene besides the first virtual character.

[0014] In one possible implementation, the game scene contains multiple scene regions, each of which has a corresponding region identifier;

[0015] The step of sending the data of the target game scene to the server, so that the server sends the status frame to the second client, includes:

[0016] The data of the target game scene and the target area identifier corresponding to the target scene area are sent to the server, so that the server can determine the target game scene where the first virtual character is located based on the data of the target game scene and determine the target scene area based on the target area identifier, and send the target status frame corresponding to the target scene area to the second client.

[0017] In one possible implementation, the status frame is sent to the server in the form of a data packet; prior to the step of sending the status frame to the server, the method further includes:

[0018] Determine the data that has changed in the status frame;

[0019] The changed data in the status frame is included in the body of the data packet.

[0020] In one possible implementation, the status frames are sent to the server in the form of data packets; each data packet contains a specified number of status frames.

[0021] The game screen is displayed on the second client at a specified frame rate; wherein, the specified frame rate is the specified number of frames per second.

[0022] In one possible implementation, the game state data includes any one or more of the following:

[0023] The game's movement status data, collision status data, and position status data.

[0024] Secondly, this disclosure provides a data processing method for virtual characters in a game, applied to a server, wherein the game scene includes a first virtual character controlled by a first client; the method includes:

[0025] Obtain the status frame sent by the first client; wherein the status frame is obtained by the first client encapsulating game status data, and the game status data is the game status data generated during the process of the first virtual character executing the control command of the first client;

[0026] Identify a second virtual character who is in the same game scene as the first virtual character;

[0027] The status frame is sent to the second client corresponding to the second virtual character, so that the game screen corresponding to the game status data is displayed on the second client.

[0028] In one possible implementation, the step of determining the second virtual character in the same game scene as the first virtual character includes:

[0029] Obtain scene identifiers sent by each client; wherein, the scene identifiers are used to represent at least one game scene in which the virtual character controlled by the client is located in the game;

[0030] Based on the game scenes in which the multiple virtual characters are located, a second virtual character is determined that is in the same game scene as the first virtual character.

[0031] In one possible implementation, the server corresponds to multiple game scenes, and each virtual character corresponds to multiple game scene allocation dimensions;

[0032] The step of determining the second virtual character in the same game scene as the first virtual character includes:

[0033] By traversing all the game scenes, the game scene with the optimal allocation dimension for each of the multiple game scene allocation dimensions is determined;

[0034] Based on the priority of each game scene allocation dimension, the game scene to which the first virtual character is assigned and the second virtual character to the same game scene as the first virtual character are determined from the game scenes with the best game scene allocation dimension.

[0035] In one possible implementation, the game scene allocation dimension includes any one or more of the following:

[0036] The game habits, character level, and character activity of the virtual character.

[0037] In one possible implementation, there are multiple second virtual characters, and each second virtual character corresponds to a game character division dimension;

[0038] The step of sending the status frame to the second client corresponding to the second virtual character, so as to display the game screen corresponding to the game status data on the second client, includes:

[0039] Based on the game character classification dimension, a target second virtual character that is classified into the same category as the first virtual character is determined from multiple second virtual characters;

[0040] The status frame is sent to the target second client corresponding to the target second virtual character, so as to display the game screen corresponding to the game status data on the target second client.

[0041] In one possible implementation, the game character segmentation dimensions include any one or more of the following:

[0042] The game habits, character level, and character activity of the virtual character.

[0043] Thirdly, this disclosure provides a data processing method for virtual characters in a game, wherein the same game scene includes a first virtual character controlled by a first client and a second virtual character controlled by a second client, and a graphical user interface is provided by the second client; the method includes:

[0044] Receive a status frame sent by the server; wherein the status frame is obtained by the first client encapsulating game status data, and the game status data is game status data generated during the process of the first virtual character executing the control commands of the first client;

[0045] The game screen corresponding to the game status data is displayed in the graphical user interface.

[0046] In one possible implementation, the step of displaying the game screen corresponding to the game state data in the graphical user interface includes:

[0047] The game screen corresponding to the game status data is overlaid and displayed on the graphical user interface.

[0048] Fourthly, a data processing device for virtual characters in a game is provided, wherein the game scene includes a first virtual character controlled by a first client, and the device includes:

[0049] The determining module is used to determine, based on the control commands given by the first client to the first virtual character, the game state data generated by the first virtual character during the execution of the control commands;

[0050] An encapsulation module is used to encapsulate the game state data into state frames;

[0051] The sending module is used to send the status frame to the server, so that the server sends the status frame to the second client, so that the game screen corresponding to the game status data is displayed on the second client.

[0052] Fifthly, a data processing device for virtual characters in a game is provided, applied to a server, wherein the game scene includes a first virtual character controlled by a first client; the device includes:

[0053] The acquisition module is used to acquire the status frame sent by the first client; wherein the status frame is obtained by the first client encapsulating game status data, and the game status data is the game status data generated during the process of the first virtual character executing the control command of the first client;

[0054] The determination module is used to determine a second virtual character that is in the same game scene as the first virtual character;

[0055] The sending module is used to send the status frame to the second client corresponding to the second virtual character, so as to display the game screen corresponding to the game status data on the second client.

[0056] Sixthly, a data processing device for virtual characters in a game is provided, wherein the same game scene includes a first virtual character controlled by a first client and a second virtual character controlled by a second client, and a graphical user interface is provided through the second client; the device includes:

[0057] The receiving module is used to receive status frames sent by the server; wherein the status frame is obtained by the first client encapsulating game status data, and the game status data is game status data generated during the process of the first virtual character executing the control commands of the first client;

[0058] The display module is used to display the game screen corresponding to the game status data in the graphical user interface.

[0059] In a seventh aspect, embodiments of this disclosure also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program executable on the processor, and the processor executes the computer program to implement the steps of the methods described in the first, second, and third aspects above.

[0060] Eighthly, embodiments of this disclosure further provide a computer-readable storage medium storing computer-executable instructions that, when invoked and executed by a processor, cause the processor to perform the methods described in the first, second, and third aspects above.

[0061] The embodiments disclosed herein bring the following beneficial effects:

[0062] This disclosure provides a data processing method, apparatus, and electronic device for virtual characters in a game. First, based on control commands from a first client to a first virtual character, game state data generated during the execution of those commands is determined. This state data is then encapsulated into state frames and sent to a server. The server then forwards these state frames to a second client, displaying the game screen corresponding to the game state data on the second client. In this solution, the first client can encapsulate game state data related to its controlled virtual character into state frames and send them to the server. The server then synchronizes these state frames to the second clients. Each second client can then obtain and directly display the corresponding game screen based on the state frames from the server. State frames solve the problem of the server having no game data during frame synchronization, leaving the calculations to the client. Furthermore, since each client only processes and uploads game state data related to its own controlled virtual character, it can directly draw graphics upon receiving data from other clients. This eliminates the need for each client to perform further calculations related to the game state data of virtual characters controlled by other clients, effectively reducing the client's data processing volume and operational pressure, and alleviating the technical problem of high client operational pressure due to large data processing volumes. Attached Figure Description

[0063] To more clearly illustrate the technical solutions in the specific embodiments of this disclosure or 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 this disclosure. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0064] Figure 1 This is a schematic diagram illustrating an application scenario provided by an embodiment of this disclosure;

[0065] Figure 2 A schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure is shown;

[0066] Figure 3 This is a schematic diagram illustrating a usage scenario of a touch terminal provided in an embodiment of this disclosure;

[0067] Figure 4 A flowchart illustrating a data processing method for virtual characters in a game, provided as an embodiment of this disclosure;

[0068] Figure 5 This is a schematic diagram illustrating a frame synchronization effect provided in an embodiment of the present disclosure;

[0069] Figure 6 This is a schematic diagram of game scene division provided in an embodiment of the present disclosure;

[0070] Figure 7 A flowchart illustrating another data processing method for virtual characters in a game provided in this embodiment of the present disclosure;

[0071] Figure 8 A schematic diagram of a microservice design provided in this disclosure embodiment;

[0072] Figure 9 A flowchart illustrating another data processing method for virtual characters in a game provided in this embodiment of the present disclosure;

[0073] Figure 10 This disclosure provides a schematic diagram of the structure of a data processing device for virtual characters in a game.

[0074] Figure 11 Structural intent of another data processing apparatus for virtual characters in a game provided in an embodiment of this disclosure;

[0075] Figure 12 This is a structural schematic of another data processing apparatus for virtual characters in a game provided in an embodiment of the present disclosure. Detailed Implementation

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

[0077] The terms “comprising” and “having”, and any variations thereof, used in the embodiments of this disclosure are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the steps or units listed, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to such processes, methods, products, or devices.

[0078] Current frame-synchronized games generally offer relatively simple social systems, with few unique designs beyond world chat, team chat, and friend chat. Window-based chat has limitations: too many players cause the window to scroll too quickly, making it difficult to find topics of interest; too few players can result in a deserted atmosphere. Imagine a social plaza where each player is a playable character who can freely move and chat. Chat messages can appear not only in the chat window but also as bubbles above each character's head, making them easily visible to others. Players can quickly find topics or people of interest and chat via these bubbles. A frame-synchronized solution can achieve a degree of this social plaza. For example, the client uploads commands at a fixed frequency of 15 frames per second (FPS), and the server broadcasts the data to all characters in the plaza at the same frequency. Upon receiving commands from themselves or others, the client calculates the results and renders them. This solution is identical to in-game combat, essentially adding social features like chat to the core gameplay. However, this method consumes a lot of computing power on the client side. It could handle the situation when the number of players was controlled between 1 and 5, but once the number of players exceeded 10, the client would experience severe lag or even crashes. Therefore, simply using frame synchronization cannot support a large number of simultaneous online users.

[0079] Frame synchronization is a technique that distributes computational load across clients, with the load increasing exponentially with the number of players. However, the maximum load a client can handle is unknown, making it impossible to quantify the maximum number of players a game scene can support. Even if quantifiable, this value is very small and insufficient for large-scale multiplayer social gaming. Because this technique caches a large amount of data locally on the client, the server cannot know the position and state of player characters, the state of non-player characters (NPCs), or the map state. Therefore, implementing a social platform using state synchronization requires both client and server-side implementations of two synchronization frameworks, doubling both development manpower and code size—unrealistic for any project. Furthermore, regardless of the technology used, high concurrent user counts inevitably lead to high bandwidth usage. While state synchronization offers mature Area of ​​Interest (AOI) solutions, implementing a specific AOI under frame synchronization presents a challenge.

[0080] Based on this, embodiments of this disclosure provide a data processing method, apparatus, and electronic device for virtual characters in games. Using the method provided by these embodiments, each client only needs to calculate its own data and can directly draw when it receives status frames from other clients; the server is only responsible for forwarding. Simultaneously, AOI technology is introduced. AOI design based on map tags can obtain the client's region of interest even without server data, thereby grouping and distributing status frames, reducing unnecessary traffic and computational consumption, and alleviating the technical problem of high client operating pressure due to large amounts of client data processing.

[0081] In one embodiment of this disclosure, the data processing method for virtual characters in a game can run on a local terminal device or a server. When the data processing method for virtual characters in a game runs on a server, the method can be implemented and executed based on a cloud interaction system, wherein the cloud interaction system includes a server and a client device.

[0082] In an optional implementation, various cloud applications, such as cloud gaming, can run under the cloud interaction system. Taking cloud gaming as an example, cloud gaming refers to a gaming method based on cloud computing. In the cloud gaming operating mode, the game program and the game screen presentation are separated. The storage and execution of data processing methods for virtual characters in the game are completed on the cloud gaming server. The client device is used for receiving and sending data and presenting the game screen. For example, the client device can be a display device with data transmission capabilities located close to the user, such as a mobile terminal, television, computer, or PDA; however, the information processing is performed by the cloud gaming server in the cloud. When playing the game, the player operates the client device to send operation commands to the cloud gaming server. The cloud gaming server runs the game according to the operation commands, encodes and compresses the game screen and other data, returns it to the client device via the network, and finally, the client device decodes and outputs the game screen.

[0083] In an optional implementation, taking a game as an example, the local terminal device stores the game program and is used to display the game screen. The local terminal device is used to interact with the player through a graphical user interface (GUI), i.e., conventionally by downloading, installing, and running the game program via an electronic device. The local terminal device can provide the GUI to the player in various ways, such as rendering it on the terminal's display screen or providing it to the player via holographic projection. For example, the local terminal device can include a display screen for displaying the GUI, which includes game screens, and a processor for running the game, generating the GUI, and controlling the display of the GUI on the display screen.

[0084] In one possible implementation, this disclosure provides a data processing method for virtual characters in a game, which provides a graphical user interface through a terminal device. The terminal device can be either the aforementioned local terminal device or a client device in the aforementioned cloud interaction system.

[0085] For example, such as Figure 1 As shown, Figure 1 This is a schematic diagram illustrating an application scenario provided by an embodiment of this disclosure. The application scenario may include an electronic terminal (e.g., mobile phone 102) and a server 101. The electronic terminal can communicate with the server 101 via a wired or wireless network. The electronic terminal is used to run a virtual desktop, through which it can interact with the server 101 to control virtual characters within the server 101.

[0086] This embodiment uses mobile phone 102 as an example to illustrate the electronic terminal. Mobile phone 102 includes components such as a radio frequency (RF) circuit 210, a memory 220, a touchscreen 230, and a processor 240. Those skilled in the art will understand that... Figure 2 The mobile phone structure shown does not constitute a limitation on the mobile phone and may include more or fewer components than shown, or combine or separate certain components, or have different component arrangements. Those skilled in the art will understand that the touchscreen 230 is a user interface (UI), and the mobile phone 102 may include a user interface with fewer components than shown.

[0087] RF circuit 210 can also communicate wirelessly with networks and other devices. The wireless communication can use any communication standard or protocol, including but not limited to Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), email, and Short Messaging Service (SMS).

[0088] The memory 220 can be used to store software programs and modules. The processor 240 executes various functional applications and data processing of the mobile phone 102 by running the software programs and modules stored in the memory 220. The memory 220 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application required for a function, etc.; the data storage area may store data created based on the use of the mobile phone 102, etc. In addition, the memory 220 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0089] The touchscreen 230 can be used to display a graphical user interface and receive user actions on the graphical user interface. Specifically, the touchscreen 230 may include a display panel and a touch panel. The display panel can be configured as a liquid crystal display (LCD), organic light-emitting diode (OLED), or similar device. The touch panel can collect touch or non-touch operations from the user on or near it (e.g., ...). Figure 3 As shown, the user operates on or near the touch panel using their finger 301, stylus, or any suitable object or accessory, generating pre-set operation commands. The touch panel can include a touch detection device and a touch controller. The touch detection device detects the user's touch position and posture, and detects the signals generated by the touch operation, transmitting the signals to the touch controller. The touch controller receives touch information from the touch detection device, converts it into information that the processor can process, and sends it to the processor 240. It can also receive and execute commands from the processor 240. Furthermore, the touch panel can be implemented using various types of technologies, such as resistive, capacitive, infrared, and surface acoustic wave, or any future-developed technology. Further, the touch panel can cover the display panel. The user can operate on or near the touch panel covered by the display panel according to the graphical user interface displayed on the display panel. After detecting the operation on or near the touch panel, the touch panel transmits it to the processor 240 to confirm the user input. Subsequently, the processor 240 responds to the user input by providing corresponding visual output on the display panel. In addition, the touch panel and the display panel can be implemented as two separate components or integrated together.

[0090] The processor 240 is the control center of the mobile phone 102. It connects various parts of the mobile phone through various interfaces and lines. By running or executing software programs and / or modules stored in the memory 220, and calling data stored in the memory 220, it performs various functions of the mobile phone 102 and processes data, thereby monitoring the mobile phone as a whole.

[0091] The embodiments of this disclosure will be further described below with reference to the accompanying drawings.

[0092] Figure 4 This is a flowchart illustrating a data processing method for virtual characters in a game, provided as an embodiment of this disclosure. The method can be applied to a first client (e.g., Figure 2 The mobile phone 102 shown in the image contains a first virtual character controlled by a first client within the game's scene. For example... Figure 4 As shown, the method includes:

[0093] Step S410: Based on the control commands from the first client to the first virtual character, determine the game state data generated during the execution of the control commands by the first virtual character.

[0094] In practical applications, the first client can determine the game state data generated by the first virtual character during the execution of control commands based on the control commands issued by the player through the first client.

[0095] As an example, game state data can be the state data of the first virtual character. For instance, when a player controls the first virtual character to move, jump, or perform other actions in the game scene through the first client, the first client can determine the game state data as the distance of movement, position, jump height, and whether it collides with the terrain in the game scene.

[0096] As another example, game state data can be the state data of other virtual characters caused by the execution of control commands by the first virtual character. For example, if a player controls the first virtual character to attack other virtual characters through the first client, causing the other virtual characters' health to decrease, the first client can identify this data as game state data.

[0097] As another example, game state data can be the state data of other virtual objects caused by the first virtual character executing control commands. For example, the player controls the first virtual character through the first client to attack virtual buildings, cut down virtual trees, open treasure chests in the game scene, etc. The first client can identify this data as game state data.

[0098] Step S420: Encapsulate the game state data into a state frame.

[0099] For example, such as Figure 5 As shown, the first client can encapsulate the virtual character's movement distance and position, jump height, and whether it collides with the terrain in the game scene into a state frame. For example, if the virtual character moves 1 meter to the right in the first unit of time and jumps forward and to the right in the second unit of time, the first client can record these actions as game state data and encapsulate them into a state frame. This state frame differs from frame synchronization and state synchronization; the server only forwards the data without calculating it, while the client's state information is sent via frame synchronization.

[0100] Step S430: Send the status frame to the server so that the server can send the status frame to the second client so that the game screen corresponding to the game status data can be displayed on the second client.

[0101] For example, such as Figure 5As shown, the first client sends the encapsulated state frame to the server, which then forwards it to the second client. The second client then uses the content of the state frame to draw and display the first virtual character. Specifically, the second client's graphical user interface shows that the first virtual character moved 1 meter to the right in the first unit of time and jumped forward to the right in the second unit of time. Each client only calculates its own movement, jump, and collision data and encapsulates the final calculation results into a state frame before sending it to the server.

[0102] In this embodiment, the first client can encapsulate game state data related to the first virtual character it controls into a state frame, and then send the state frame to the server. The server then synchronizes the state frame to the second client. Each second client can then obtain the corresponding game screen from the server and directly display it based on the state frame. The state frame solves the problem that the server has no game data for frame synchronization, and the calculation is still handled by the client. At the same time, since each client only processes and uploads game state data related to the virtual character controlled by the server, it can directly draw the image when it receives data from other clients. This eliminates the need for each client to perform a series of calculations on game state data related to the virtual characters controlled by other clients, effectively reducing the amount of data processing and the operating pressure on the client, and alleviating the technical problem that the large amount of data processing on the client leads to a large operating pressure on the client.

[0103] The steps described above will be explained in detail below.

[0104] In some embodiments, game state data may include multiple types. By including multiple types of game state data, the first client can more flexibly encapsulate various game state data into state frames, improving the richness of uploadable content and effectively reducing the client's data processing load and operational pressure. For example, game state data includes any one or more of the following:

[0105] The state data of the first virtual character, the state data of other virtual characters in the game scene besides the first virtual character, and the state data of other virtual objects.

[0106] As an example, game state data can be the state data of the first virtual character. For instance, when a player controls the first virtual character to move, jump, or perform other actions in the game scene through the first client, the first client can determine the game state data as the distance of movement, position, jump height, and whether it collides with the terrain in the game scene.

[0107] As another example, game state data can be the state data of other virtual characters in the game scene besides the first virtual character. For example, if a player controls the first virtual character through the first client to attack other virtual characters, causing the other virtual characters' health to decrease, the first client can identify this data as game state data.

[0108] As another example, game state data can be the state data of other virtual objects. For example, a player can control a virtual character through a first client to attack virtual buildings, cut down virtual trees, open treasure chests in the game scene, etc. The first client can identify this data as game state data.

[0109] By including multiple types of game state data, the first client can more flexibly encapsulate various game state data into state frames, increasing the richness of uploadable content and effectively reducing the client's data processing volume and operating pressure.

[0110] In some embodiments, the client only displays virtual characters within a certain range of scene areas. Therefore, it only needs to obtain the status frames of these virtual characters from the server, thereby reducing the client's data processing load and alleviating the client's operational pressure in a more flexible way. For example, game scenes are generally much larger than the client screen, so the player's field of vision is very limited. Sending game data outside the player's field of vision is wasteful. Removing this part of the data can save a lot of bandwidth. This can be achieved by sending the data of the target scene area where the first virtual character is located to the corresponding second client in the same scene area through the server. This allows the second client to receive the status frames corresponding to the first virtual character in the same area, while preventing other clients in other scene areas from receiving status frames. This reduces the data transmission pressure on the server and the workload on other clients. As an example, the server corresponds to multiple game scenes; the method also includes:

[0111] Step a) Determine the target game scene where the first virtual character is located.

[0112] Step b) sends the data of the target game scene to the server so that the server sends the status frame to the second client.

[0113] For step b) above, the second virtual character controlled by the second client is another virtual character in the target game scene besides the first virtual character.

[0114] For example, such as Figure 6As shown, the game scene can contain multiple scene areas, such as the nine different scene areas divided by dotted lines. The first client can first determine the target scene area where the first virtual character 601 is located in the game scene, namely the scene area slightly to the left of center. Then, the data of the scene area slightly to the left of center is sent to the server, causing the server to send the status frame corresponding to that scene area to all clients corresponding to the target virtual character who are also located in the scene area slightly to the left of center. This can be understood as players only seeing game content within the same scene. That is, if the player controls the first virtual character to move within the scene area slightly to the left of center, the player can only see the game content within that scene area, and other players within the same scene area slightly to the left of center can also only see the game content within that scene area.

[0115] By enabling the first client to determine the target game scene where the first virtual character is located, and then sending the target game scene data to the server, which in turn sends a status frame to the second client, redundant and useless game data can be avoided. By allowing the client to only upload and render game content within the current game scene, invalid data transmission is avoided, reducing the data transmission burden on the server and the workload on the client.

[0116] Based on steps a) and b) above, the server can determine the virtual character in the scene area corresponding to each client by using area identifiers. For example, scene areas can be precisely divided by adding identifiers, thereby accurately sending status frames to the corresponding second client. This ensures that the second client can receive the status frame corresponding to the first virtual character in the same area, while other clients in other scene areas with different scene identifiers cannot receive status frames, reducing the data transmission pressure on the server and the workload on other clients. As an example, a game scene contains multiple scene areas, each with a corresponding area identifier; step b) above can specifically include the following steps:

[0117] Step c) Send the data of the target game scene and the target area identifier corresponding to the target scene area to the server so that the server can determine the target game scene where the first virtual character is located based on the data of the target game scene and determine the target scene area based on the target area identifier, and send the target status frame corresponding to the target scene area to the second client.

[0118] For example, such as Figure 6As shown, each scene area in the game corresponds to a unique area identifier. For example, the scene area slightly to the left of center is identified as 00001, the scene area in the center is identified as 00010, and the scene area slightly to the right of center is identified as 00100, and so on. If the first virtual character 601 is located in the scene area identified as 00001, the first client can send the target scene data and the target area identifier 00001 corresponding to the target scene area to the server. This allows the server to determine the target scene area where the first virtual character is located based on the target area identifier 00001 and send a status frame to the second client, which is located in the same scene area (i.e., the client corresponding to other virtual characters in the scene area corresponding to the target area identifier 00001).

[0119] In practical applications, the target area identifier can be understood as a Tag value. By maintaining Tag values, the entire map is represented. Then, based on conditions such as field of view or game scene, the entire map is divided into smaller areas, each occupying one bit of the total Tag. When uploading a status frame, the client needs to mark the area visible to the controlled virtual character on the Tag and upload it. After receiving the status frame, the server will group the virtual characters according to their Tag values; that is, characters with the same Tag bit are grouped together. If a virtual character may be in multiple groups simultaneously at the edges of certain areas, such as... Figure 6 As shown, each scene area corresponds to a digit in an integer. For example, the scene area slightly to the left of the center is identified as 00001, meaning the fifth digit identifies the scene area slightly to the left of the center; the scene area in the middle is identified as 00010, meaning the fourth digit identifies the scene area in the middle; the scene area slightly to the right of the center is identified as 00100; the scene area in the lower left is identified as 01000; and the scene area slightly to the lower center is identified as 10000. The first virtual character 601 is located in the scene area identified as 00001, so it can upload the scene identification 00001 to the server. The first virtual character can only observe other virtual characters in the scene area identified as 00001, while all virtual characters in the game scene whose fifth digit of the scene identification is 1 (XXXX1) can observe the first virtual character 601. The second virtual character 602 is simultaneously located in scene areas with scene identifiers 00010 and 10000, i.e., the fourth digit is 1 and the first digit is 1. Therefore, scene identifier 10010 can be uploaded to the server. The second virtual character 602 can see other virtual characters in both scene areas at the same time. At the same time, all virtual characters in game scenes with scene identifiers whose fourth digit and first digit are 1 (1XX1X, also including 1XXXX and XXX1X) can observe the second virtual character 602.

[0120] It should be noted that the target scene area uploaded by the first client can be the scene within the field of view of the first virtual character controlled by the first client, that is, the game scene currently displayed by the graphical user interface of the first client; the target scene area uploaded by the first client can also be a part of the scene within the field of view of the first virtual character, for example, only the game scene in the upper left corner of the graphical user interface of the first client is uploaded.

[0121] By sending the data of the target game scene and the target area identifier corresponding to the target scene area to the server, the server can determine the target game scene where the first virtual character is located based on the data of the target game scene and determine the target scene area based on the target area identifier. Then, the server sends the target status frame corresponding to the target scene area to the second client. This allows the second client to accurately receive the status frame corresponding to the first virtual character in the same area, while other clients corresponding to other scene areas with different identifiers cannot receive the status frame. This reduces the data transmission pressure on the server and the workload on other clients.

[0122] In some embodiments, the amount of data to be transmitted can be reduced in a more flexible manner, thereby effectively alleviating the data processing pressure on the client. For example, duplicate or unchanging data in the status frame can be omitted, and only the changed data in the status frame can be encapsulated to obtain the corresponding data packet, effectively reducing the amount of data to be transmitted. As an example, the status frame is sent to the server in the form of a data packet; before step S430 above, the method may also include the following steps:

[0123] Step d) Determine the data that has changed in the status frame.

[0124] Step e) involves adding the changed data from the status frame into the packet body of the data packet.

[0125] In practical applications, Protobuf is a multi-platform, multi-language, and scalable data serialization mechanism. It achieves efficient storage by serializing (serializing) structured data, providing a language-independent, platform-independent, and scalable serialized structured data format for communication protocols, data storage, and other fields, supporting custom data structures. Taking a side-scrolling 2D game as an example, since the game only has two dimensions, the X-axis and Y-axis, and the virtual character can only move left and right or up and down, besides essential parameters such as the virtual character's coordinates, character state, and map state, other states are represented by different bits of a single value. Furthermore, due to Protobuf's characteristic of not including default values ​​in the packet body, some invariant values ​​can be omitted. For example, when the virtual character only moves on the platform (X-axis direction), the Y-axis coordinates, virtual character state, and map state remain unchanged, so these are not included in the packet body. In practical applications, this compression keeps the size of a state frame within 2-19 bytes. This compression is considerable and effectively reduces bandwidth usage. In practical applications, the same method also applies to 3D games, requiring only some extensions such as adding Z-axis coordinates, game scene fields, etc., but the data flow will also increase accordingly.

[0126] For example, the first client can refresh in real time or at a preset frame rate. For instance, it can draw an image at a preset frame rate of 15 FPS. During the image drawing process, some invariant values ​​are omitted by using the characteristics of Protobuf. Although the number of status frames in the body of each data packet remains the same, the storage space occupied by each data packet is reduced, which alleviates the data processing pressure on the client and server.

[0127] By having the first client identify the changed data in the status frame before including it in the packet body, and by encapsulating only the changed data in the status frame, the amount of data to be transmitted is effectively reduced, alleviating the data processing burden on the client.

[0128] In some embodiments, the amount of data to be transmitted can be reduced in a more flexible way, thereby effectively alleviating the data processing pressure on the client. For example, while ensuring stable and continuous visuals, the amount of data can be reduced by limiting the number of status frames in each data packet. This effectively reduces the data processing pressure on the client without affecting the player's gaming experience. As an example, status frames are sent to the server in the form of data packets; each data packet contains a specified number of status frames; the game screen is displayed on the second client at a specified frame rate; where the specified frame rate is a specified number of frames per second.

[0129] For example, the client still renders images at a frame rate of 15 FPS, but the uploaded data is compressed from 15 frames per packet to 7 frames per packet. That is, it collects its own 7 frames of data, packages them into a single data packet, and sends it to the server. This reduces the number of packets uploaded per second by all clients, reduces the number of serialization and deserialization operations on the server, and effectively alleviates the server's load. Therefore, at the same time, such as Figure 5 As shown, the actual movement of the first virtual character (solid line figure) will appear 0.5 seconds later to other players (dotted line figures). This is acceptable in a game scenario that is primarily social, and players are generally unaware of this phenomenon, meaning they are unaware that someone else has jumped 0.5 seconds earlier.

[0130] It's important to note that the frame rate within each data packet can be replaced, but this significantly impacts the player experience. If 15 frames are reduced by half, other virtual characters' movements may appear noticeably choppy to the player. If 7 frames are reduced by half, the first virtual character will appear one second behind to other players.

[0131] By sending status frames to the server in the form of data packets, with each data packet containing a specified number of status frames, and displaying the game screen on the second client at a specified frame rate, this approach effectively reduces the amount of data that needs to be transmitted, thereby alleviating the data processing pressure on the client without affecting the player's gaming experience.

[0132] In some embodiments, the data type of game state data may include multiple types. By including multiple types of game state data, the data contained in the data packet can fully record the behavior state and other related content of the first virtual character, thereby enabling other clients to accurately represent the behavior state and other related content of the first virtual character and improve the player's gaming experience. As an example, game state data includes any one or more of the following:

[0133] The game's movement status data, collision status data, and position status data.

[0134] For example, the state data may include the movement state of the first virtual character, such as which direction the first virtual character moves, whether it jumps, etc.; the state data may also include the collision state of the first virtual character, such as whether it collides with other virtual characters, whether it collides with prop models in the game scene area, etc.; the state data may also include the position state of the first virtual character, such as which game scene area the first virtual character is currently in, corresponding to which identifier.

[0135] By including multiple types of game status data, the data packets can fully record the behavior and status of the first virtual character and other related content. This allows other clients to accurately represent the behavior and status of the first virtual character and other related content, thereby improving the player's gaming experience.

[0136] Figure 7 This is a flowchart illustrating a data processing method for virtual characters in a game, provided as an embodiment of this disclosure. The method can be applied to a server-side environment, where the game scene includes a first virtual character controlled by a first client. Figure 7 As shown, the method includes:

[0137] Step S710: Obtain the status frame sent by the first client.

[0138] Among them, the status frame is obtained by the first client encapsulating the game status data, and the game status data is the game status data generated during the process of the first virtual character executing the control commands of the first client.

[0139] For example, the server can obtain a status frame sent by the first client. The status frame is obtained by the first client encapsulating status data, which is game status data generated based on the control commands of the first client to the first virtual character. For example, if a player controls the first virtual character to move, jump, or perform other actions in the game scene through the first client, the first client can determine the game status data, such as the distance and position of the movement, the jump height, and whether there is a collision with the terrain in the game scene, and then encapsulate it to obtain a status frame.

[0140] Step S720: Determine the second virtual character that is in the same game scene as the first virtual character.

[0141] For example, the server can determine the second virtual character in the same room (game scene) as the first virtual character based on the data of the target game scene sent by the first client and the target area identifier corresponding to the target scene area. This enables the server's forwarding to have a filtering function, thereby filtering out the second virtual character in the same room (game scene) as the first virtual character.

[0142] Step S730: Send the status frame to the second client corresponding to the second virtual character so that the game screen corresponding to the game status data can be displayed on the second client.

[0143] For example, the server sends the encapsulated state frame to the second client, so that the second client does not need to recalculate, but can directly draw based on the content of the state frame, and then display the first virtual character, that is, display the first virtual character moving, jumping and other actions in the game scene in the graphical user interface of the second client.

[0144] In this embodiment, when a player controls a first virtual character through a first client, the system can obtain the state data of the first virtual character, encapsulate the state data into a state frame, and then synchronize the state frame to a second client via the server. The second client then displays the first virtual character on the graphical user interface based on the state frame. The state frame solves the problem of the server having no game data during frame synchronization, still leaving the calculations to the client. Furthermore, since each client only processes and uploads its own data, it can directly draw graphics upon receiving data from other clients, effectively reducing client load and alleviating the technical problem of high client operating pressure due to large data processing volumes.

[0145] The steps described above will be explained in detail below.

[0146] In some embodiments, the amount of data processing on the client can be reduced by allowing the client to display only the content in the corresponding scene area, thereby alleviating the client's workload in a more flexible way. For example, through server-side filtering, the second client can only receive and display game screens within the same area, effectively reducing the workload of the second client. As an example, step S720 above may specifically include the following steps:

[0147] Step f) Obtain the scene identifier sent by each client.

[0148] Step g) Determine the second virtual character that is in the same game scene as the first virtual character based on the game scenes in which the multiple virtual characters are located.

[0149] For step f) above, the scene identifier is used to represent at least one game scene in which the virtual character controlled by the client is located in the game.

[0150] For example, such as Figure 6As shown, the scene identifier can be understood as a Tag value. By maintaining Tag values, the entire map is represented. Then, based on conditions such as field of view or game scene, the entire map is divided into small areas, each area occupying one bit of the total Tag. When the client uploads a status frame, it needs to mark the area visible to the controlled virtual character on the Tag and upload it. After receiving the scene identifiers sent by each client, the server will group the virtual characters according to the Tag values, i.e., those with the same Tag bit are grouped together. The first client system sends the scene identifier 00001 of the scene area where the first virtual character 601 is located to the server. After the server obtains the scene identifiers from multiple clients, it can determine which virtual characters are simultaneously in the same scene area as the first virtual character 601. Then, for the same scene area, the status frame corresponding to each virtual character is broadcast to all virtual characters in the same scene area, so that other players can observe the status of other virtual characters. For example, if the second virtual character 602 is simultaneously in scene area 00010 and scene area 10000, the server can obtain the scene identifiers of the two scene areas. Then, for the same scene area 00010 and scene area 10000, the server broadcasts the status frame corresponding to each virtual character to all virtual characters in the same scene area. That is, other virtual characters in scene area 00010 and scene area 10000 can observe the second virtual character 602.

[0151] By enabling the server to obtain scene identifiers sent by each client, and then determining the virtual characters in the same scene area based on the scene areas where multiple virtual characters are located, the server broadcasts the status frame corresponding to each virtual character to all virtual characters in the same scene area. This allows the client to only display game content within the same game scene, ensuring that players can see the game content they need within their field of vision, while omitting unnecessary content that does not require data transmission, thus reducing the workload of both the server and the client.

[0152] In some embodiments, the server corresponds to multiple game scenes. By traversing all game scenes, the server can obtain the game scene with the highest priority corresponding to the virtual character based on the traversal results and assign it to the virtual character. This allows the virtual character to be in the same game scene as other virtual characters with high similarity, improving the player's gaming experience. As an example, the server corresponds to multiple game scenes, and each virtual character corresponds to multiple game scene allocation dimensions; the above step S720 may specifically include the following steps:

[0153] Step h) involves traversing all game scenes to determine the optimal game scene for each of the multiple game scene allocation dimensions.

[0154] Step i) Based on the priority of each game scene allocation dimension, determine the game scene to which the first virtual character is assigned and the second virtual character to the same game scene as the first virtual character from the game scene with the best game scene allocation dimension.

[0155] For example, such as Figure 8 As shown, this embodiment can be applied to the social square in a game. The social square is a distributed microservice architecture, relatively independent of other service clusters. Both the cluster and its internal components support horizontal scaling and scaling down. Inter-cluster access is achieved through clients randomly accessing different gateways to ensure relative equality in the number of users across different clusters. Each cluster has multiple load balancing servers that calculate the current load in real time based on the previous load value plus a predicted value for each square process, and select the optimal process to assign to a virtual character. The square's clusters and processes are allocated based on the principle of equality, with virtual characters having an equal probability of entering each square server. Each process contains hundreds of game scenes, and the allocation of these game scenes is based on attribute priorities defined by the game designers. Virtual characters with similar or attractive attributes are more likely to be assigned together. For example, it might be desirable to prioritize matching the first virtual character with other virtual characters with similar gaming habits; if none are found, then those with similar levels are matched; if still none are found, the condition is abandoned, and a relatively active game scene is matched. Therefore, all game scenes can be inserted into four queues, defined according to their activity levels: full load, high load, active, and idle. Game habits are set as the first priority, and character level as the second priority. Each virtual character's entry and exit updates the game scene attributes. This transforms the process from finding a suitable virtual character to finding a suitable game scene. However, since each priority level requires iterating through all game scenes based on activity level, which is very performance-intensive, an additional iteration checklist needs to be maintained. After one iteration, all game scenes meeting various conditions can be obtained, and if a game scene meets the highest priority, the iteration can immediately exit.

[0156] In practical applications, the server initially has an empty list as shown in Table 1. After traversing it once, the optimal game scene for each dimension is filled into it, and finally the result is obtained from this list.

[0157] Table 1

[0158] Priority / Activity active idle Similar habits Game Scene 1 none Similar levels none Game Scene 2

[0159] Because priorities and the number of game scenes can grow according to the planner's needs. If there are N game scenes and M priorities, then before optimization, each iteration would require N*M iterations, and after optimization, the iteration count would be N+M. This is because the design is based on priorities; if game habits are similar, matching skill levels are no longer considered. Alternatively, a weighted design could be considered, where each game scene has a habit percentage and a skill level percentage, with the final sum used as the filtering criterion.

[0160] By having the server traverse all game scenes and determine the optimal target game scene for each of the multiple game scene allocation dimensions, and then determining the final game scene to which the virtual character is assigned from the target game scene based on the priority of each game scene allocation dimension, the virtual character can be placed in the same game scene as other virtual characters with high similarity, allowing players to find other players with similar interests and improving the player's gaming experience.

[0161] Based on steps h) and i) above, the game scene allocation dimensions can include multiple types. By allowing multiple game scene allocation dimensions, the determination of the final game scene can be implemented more flexibly and in detail, enabling virtual characters to be assigned to the game scene with the highest matching degree, thereby improving the player's gaming experience. As an example, the game scene allocation dimensions include any one or more of the following:

[0162] The virtual character's gaming habits, character level, and character activity level.

[0163] For example, game scene allocation dimensions can include multiple factors, such as the virtual character's gaming habits, character level, and character activity. Different dimensions can be assigned different priorities to appropriately allocate game scenes to virtual characters. As mentioned above, the virtual character's gaming habits can be set as the first priority, and the player's character level as the second priority. Each player's entry and exit will update the game scene attributes. This transforms the process from finding suitable players to finding suitable game scenes. Furthermore, a single iteration of the checklist will retrieve all game scenes that meet various conditions; if a game scene meets the highest priority, the iteration can immediately exit.

[0164] By including multiple dimensions in the game scene allocation, the final game scene can be determined in a more flexible and detailed manner. This allows virtual characters to be assigned to the game scene with the highest matching degree, and virtual characters can be placed in the same game scene with other virtual characters with high similarity. This enables players to find other players with similar interests and improves the player's gaming experience.

[0165] In some embodiments, the server can further classify multiple second virtual characters according to the classification dimension corresponding to the second virtual character, determine the target second virtual character that belongs to the same category as the first virtual character, and send a status frame to the target second client corresponding to the target second virtual character through filtering. This achieves the effect that players with similar interests can see each other, further improving the player's gaming experience. As an example, there are multiple second virtual characters, and each second virtual character corresponds to a game character classification dimension; the above step S730 may specifically include the following steps:

[0166] Step j) Identify the target second virtual character that is classified in the same category as the first virtual character from multiple second virtual characters by using the game character classification dimension.

[0167] Step k) sends the status frame to the target second client corresponding to the target second virtual character, so as to display the game screen corresponding to the game status data on the target second client.

[0168] For example, similar to the allocation of game scenarios, virtual character game habits can be set as the first priority, virtual character level as the second priority, and virtual character activity level as the third priority. Based on these game character classification dimensions, multiple second virtual characters can be further subdivided and filtered to identify a group of players most similar to the first virtual character. The server then sends the status frame of the first client to the corresponding target second client, enabling the second client to display the game screen corresponding to the game status data.

[0169] By first identifying target second virtual characters that belong to the same category as the first virtual character from multiple second virtual characters based on game character classification dimensions, and then sending status frames to the target second client corresponding to the target second virtual character, the game screen corresponding to the game status data is displayed on the target second client. This achieves further classification of multiple second virtual characters on the server side, filtering out target second virtual characters that belong to the same category as the first virtual character. By sending status frames to the target second client corresponding to the target second virtual character through this filtering, the effect of only like-minded players being able to see each other is achieved, further reducing the client's operational pressure and improving the player's gaming experience.

[0170] Based on steps j) and k) above, the game character classification dimensions can include multiple types. By allowing multiple dimensions, the determination of virtual characters of the same type can be implemented more flexibly and in detail, enabling the first virtual character to be assigned to the second virtual character with the highest matching degree, thus improving the player's gaming experience. As an example, the game character classification dimensions include any one or more of the following:

[0171] The virtual character's gaming habits, character level, and character activity level.

[0172] For example, game character classification dimensions can include multiple factors, such as the virtual character's gaming habits, character level, and character activity level. Different dimensions can be assigned different priorities to appropriately allocate virtual characters. As mentioned above, the virtual character's gaming habits can be set as the first priority, and the virtual character's level as the second priority. Each virtual character's entry and exit will update the game scene attributes. This can also be achieved by iterating through a checklist similar to Table 1 above; after one iteration, all second virtual characters belonging to the same category can be obtained.

[0173] By allowing game character classification dimensions to include multiple factors, it is possible to flexibly and comprehensively determine the same type of virtual character, enabling the first virtual character to be assigned to the second virtual character with the highest matching degree, thereby improving the player's gaming experience.

[0174] Figure 9 This is a flowchart illustrating a data processing method for virtual characters in a game, provided as an embodiment of this disclosure. The method can be applied to a second client (e.g., Figure 2 The mobile phone 102 shown in the image contains a first virtual character controlled by a first client and a second virtual character controlled by a second client within the same game scene, with the second client providing the graphical user interface. For example... Figure 9 As shown, the method includes:

[0175] Step S910: Receive the status frame sent by the server.

[0176] Among them, the status frame is obtained by the first client encapsulating the game status data, and the game status data is the game status data generated during the process of the first virtual character executing the control commands of the first client.

[0177] For example, based on the server-side filtering and allocation, some target second clients corresponding to the first client will receive status frames sent by the server.

[0178] Step S920: Display the game screen corresponding to the game status data in the graphical user interface.

[0179] For example, after receiving the status frame sent by the server, the second client can draw based on the content of the status frame and then display the game screen corresponding to the game status data in the graphical user interface.

[0180] In this embodiment, the first client can encapsulate game state data related to the first virtual character it controls into a state frame, and then send the state frame to the server. The server then synchronizes the state frame to the second client. Each second client can then obtain the corresponding game screen from the server and directly display it based on the state frame. The state frame solves the problem that the server has no game data for frame synchronization, and the calculation is still handled by the client. At the same time, since each client only processes and uploads game state data related to the virtual character controlled by the server, it can directly draw the image when it receives data from other clients. This eliminates the need for each client to perform a series of calculations on game state data related to the virtual characters controlled by other clients, effectively reducing the amount of data processing and the operating pressure on the client, and alleviating the technical problem that the large amount of data processing on the client leads to a large operating pressure on the client.

[0181] In some embodiments, the second client can display the game screen corresponding to the game state data in the graphical user interface in a more flexible manner. For example, the existing game screen can be overlaid with the game screen corresponding to the game state data in the state frame, thereby displaying the game screen to the player in real time. As an example, the above step S920 may specifically include the following steps:

[0182] Step 1) Overlay the game screen corresponding to the game status data onto the graphical user interface.

[0183] For example, after receiving the status frame sent by the server, the second client can draw based on the game status data in the status frame to obtain the corresponding game screen. Then, it can overwrite the displayed content in the current graphical user interface to achieve real-time updates of the game content.

[0184] By overlaying the game screen corresponding to the game status data onto the graphical user interface, the game display content can be updated relatively quickly, and the game screen can be displayed to the player in real time, thereby improving the player's gaming experience.

[0185] Figure 10 This is a schematic diagram of a data processing device for virtual characters in a game, provided as an embodiment of this disclosure. The device can be applied to a first client, and the game scene includes a first virtual character controlled by the first client. Figure 10 As shown, the data processing device 1000 for virtual characters in the game includes:

[0186] The determination module 1001 is used to determine the game state data generated during the execution of control commands by the first virtual character based on the control commands of the first client to the first virtual character.

[0187] Encapsulation module 1002 is used to encapsulate game state data into state frames.

[0188] The sending module 1003 is used to send the status frame to the server so that the server can send the status frame to the second client so that the game screen corresponding to the game status data can be displayed on the second client.

[0189] In some embodiments, game state data includes any one or more of the following:

[0190] The state data of the first virtual character, the state data of other virtual characters in the game scene besides the first virtual character, and the state data of other virtual objects.

[0191] In some embodiments, the server corresponds to multiple game scenes; the device may further include:

[0192] The second determining module is used to determine the target game scene where the first virtual character is located;

[0193] The target game scene data is sent to the server so that the server sends a status frame to the second client. The second virtual character controlled by the second client is another virtual character in the target game scene besides the first virtual character.

[0194] In some embodiments, the game scene includes multiple scene areas, each scene area corresponding to an area identifier; the sending module 1003 is specifically used for:

[0195] The target game scene data and the target area identifier corresponding to the target scene area are sent to the server so that the server can determine the target game scene where the first virtual character is located based on the target game scene data and determine the target scene area based on the target area identifier, and send the target status frame corresponding to the target scene area to the second client.

[0196] In some embodiments, the status frame is sent to the server in the form of a data packet; the apparatus may further include:

[0197] The third determination module is used to determine the data that has changed in the status frame before sending the status frame to the server.

[0198] Add the changed data from the status frame to the packet body of the data packet.

[0199] In some embodiments, status frames are sent to the server in the form of data packets; each data packet contains a specified number of status frames.

[0200] The game screen is displayed on the second client at a specified frame rate; where the specified frame rate is the number of frames per second.

[0201] In some embodiments, game state data includes any one or more of the following:

[0202] The game's movement status data, collision status data, and position status data.

[0203] Figure 11 This is a schematic diagram of a data processing device for virtual characters in a game, provided as an embodiment of this disclosure. The device can be applied to a server, and the game scene includes a first virtual character controlled by a first client. Figure 11 As shown, the data processing device 1100 for virtual characters in the game includes:

[0204] The acquisition module 1101 is used to acquire the status frame sent by the first client; wherein the status frame is obtained by the first client encapsulating the game status data, and the game status data is the game status data generated during the process of the first virtual character executing the control command of the first client.

[0205] The determination module 1102 is used to determine the second virtual character who is in the same game scene as the first virtual character.

[0206] The sending module 1103 is used to send the status frame to the second client corresponding to the second virtual character, so as to display the game screen corresponding to the game status data on the second client.

[0207] In some embodiments, the determining module 1102 is specifically used for:

[0208] Obtain scene identifiers sent by each client; where the scene identifier is used to represent at least one game scene in which the virtual character controlled by the client is located.

[0209] Based on the game scenes where multiple virtual characters are located, a second virtual character is identified that is in the same game scene as the first virtual character.

[0210] In some embodiments, the server corresponds to multiple game scenes, and each virtual character corresponds to multiple game scene allocation dimensions; the determining module 1102 is specifically used for:

[0211] By traversing all game scenes, the game scene with the optimal allocation dimension for each of the multiple game scene allocation dimensions is determined.

[0212] Based on the priority of each game scene allocation dimension, the game scene to which the first virtual character is assigned and the second virtual character to the same game scene as the first virtual character are determined from the game scenes with the best game scene allocation dimension.

[0213] In some embodiments, the game scene assignment dimension includes any one or more of the following:

[0214] The virtual character's gaming habits, character level, and character activity level.

[0215] In some embodiments, the number of second virtual characters is multiple, and each second virtual character corresponds to a game character classification dimension; the sending module 1103 is specifically used for:

[0216] By using the game character classification dimension, a target second virtual character that is classified into the same category as the first virtual character is identified from multiple second virtual characters;

[0217] The status frame is sent to the target second client corresponding to the target second virtual character, so that the game screen corresponding to the game status data is displayed on the target second client.

[0218] In some embodiments, the dimensions for classifying game characters include any one or more of the following:

[0219] The virtual character's gaming habits, character level, and character activity level.

[0220] Figure 12 This is a schematic diagram of a data processing device for virtual characters in a game, provided as an embodiment of this disclosure. The device can be applied to a second client. The same game scene includes a first virtual character controlled by a first client and a second virtual character controlled by a second client, with a graphical user interface provided by the second client. Figure 12 As shown, the data processing device 1200 for virtual characters in the game includes:

[0221] The receiving module 1201 is used to receive status frames sent by the server; wherein, the status frame is obtained by the first client encapsulating game status data, and the game status data is the game status data generated during the process of the first virtual character executing the control commands of the first client.

[0222] Display module 1202 is used to display the game screen corresponding to the game status data in the graphical user interface.

[0223] In some embodiments, the display module 1202 is specifically used for:

[0224] The game screen corresponding to the game status data is overlaid and displayed on the graphical user interface.

[0225] The data processing apparatus for virtual characters in a game provided in this embodiment has the same technical features as the data processing method for virtual characters in a game provided in the above embodiment, and therefore can also solve the same technical problems and achieve the same technical effects. A first client can encapsulate game state data related to a first virtual character it controls into a state frame, and then send the state frame to the server. The server then synchronizes the state frame to a second client. Each second client can then obtain and directly display the corresponding game screen based on the state frame from the server. The state frame solves the problem that the server has no game data for frame synchronization, still leaving the calculations to the client. Furthermore, since each client only processes and uploads game state data related to the virtual character it controls, it can directly draw graphics when receiving data from other clients. This eliminates the need for each client to perform a series of calculations related to the game state data of virtual characters controlled by other clients, effectively reducing the client's data processing volume and operating pressure, and alleviating the technical problem of high operating pressure caused by a large amount of client data processing.

[0226] This application also provides an electronic device, including: a processor, a storage medium, and a bus. The storage medium stores machine-readable instructions executable by the processor. When the electronic device runs a data processing method for a virtual character in a game as described in the embodiments, the processor communicates with the storage medium via the bus. The processor executes the machine-readable instructions, and the preamble of the processor method item performs the following steps:

[0227] Based on the control commands from the first client to the first virtual character, determine the game state data generated by the first virtual character during the execution of the control commands;

[0228] The game state data is encapsulated into a state frame;

[0229] The status frame is sent to the server, so that the server sends the status frame to the second client, so that the game screen corresponding to the game status data is displayed on the second client.

[0230] In one feasible implementation, the game state data includes any one or more of the following:

[0231] The state data of the first virtual character, the state data of other virtual characters in the game scene besides the first virtual character, and the state data of other virtual objects.

[0232] In one feasible implementation, the server corresponds to multiple game scenes; and further includes:

[0233] Determine the target game scene where the first virtual character is located;

[0234] The data of the target game scene is sent to the server so that the server sends the status frame to the second client. The second virtual character controlled by the second client is another virtual character in the target game scene besides the first virtual character.

[0235] In one feasible implementation, the game scene includes multiple scene areas, and each scene area corresponds to a region identifier;

[0236] The step of sending the data of the target game scene to the server, so that the server sends the status frame to the second client, includes:

[0237] The data of the target game scene and the target area identifier corresponding to the target scene area are sent to the server, so that the server can determine the target game scene where the first virtual character is located based on the data of the target game scene and determine the target scene area based on the target area identifier, and send the target status frame corresponding to the target scene area to the second client.

[0238] In one feasible implementation, the status frame is sent to the server in the form of a data packet; prior to the step of sending the status frame to the server, the method further includes:

[0239] Determine the data that has changed in the status frame;

[0240] The changed data in the status frame is included in the body of the data packet.

[0241] In one feasible implementation, the status frames are sent to the server in the form of data packets; each data packet contains a specified number of status frames.

[0242] The game screen is displayed on the second client at a specified frame rate; wherein, the specified frame rate is the specified number of frames per second.

[0243] In one feasible implementation, the game state data includes any one or more of the following:

[0244] The game's movement status data, collision status data, and position status data.

[0245] When the aforementioned electronic device operates a data processing method for virtual characters in a game as described in the embodiment, the processor communicates with the storage medium via a bus, the processor executes the machine-readable instructions, and the preamble of the processor method item performs the following steps:

[0246] Obtain the status frame sent by the first client; wherein the status frame is obtained by the first client encapsulating game status data, and the game status data is the game status data generated during the process of the first virtual character executing the control command of the first client;

[0247] Identify a second virtual character who is in the same game scene as the first virtual character;

[0248] The status frame is sent to the second client corresponding to the second virtual character, so that the game screen corresponding to the game status data is displayed on the second client.

[0249] In one feasible implementation, the step of determining the second virtual character in the same game scene as the first virtual character includes:

[0250] Obtain scene identifiers sent by each client; wherein, the scene identifiers are used to represent at least one game scene in which the virtual character controlled by the client is located in the game;

[0251] Based on the game scenes in which the multiple virtual characters are located, a second virtual character is determined that is in the same game scene as the first virtual character.

[0252] In one feasible implementation, the server corresponds to multiple game scenes, and each virtual character corresponds to multiple game scene allocation dimensions;

[0253] The step of determining the second virtual character in the same game scene as the first virtual character includes:

[0254] By traversing all the game scenes, the game scene with the optimal allocation dimension for each of the multiple game scene allocation dimensions is determined;

[0255] Based on the priority of each game scene allocation dimension, the game scene to which the first virtual character is assigned and the second virtual character to the same game scene as the first virtual character are determined from the game scenes with the best game scene allocation dimension.

[0256] In one feasible implementation, the game scene allocation dimension includes any one or more of the following:

[0257] The game habits, character level, and character activity of the virtual character.

[0258] In one feasible implementation, the number of the second virtual characters is multiple, and each second virtual character corresponds to a game character classification dimension;

[0259] The step of sending the status frame to the second client corresponding to the second virtual character, so as to display the game screen corresponding to the game status data on the second client, includes:

[0260] Based on the game character classification dimension, a target second virtual character that is classified into the same category as the first virtual character is determined from multiple second virtual characters;

[0261] The status frame is sent to the target second client corresponding to the target second virtual character, so as to display the game screen corresponding to the game status data on the target second client.

[0262] In one feasible implementation, the game character classification dimensions include any one or more of the following:

[0263] The game habits, character level, and character activity of the virtual character.

[0264] When the aforementioned electronic device operates a data processing method for virtual characters in a game as described in the embodiment, the processor communicates with the storage medium via a bus, the processor executes the machine-readable instructions, and the preamble of the processor method item performs the following steps:

[0265] Receive a status frame sent by the server; wherein the status frame is obtained by the first client encapsulating game status data, and the game status data is game status data generated during the process of the first virtual character executing the control commands of the first client;

[0266] The game screen corresponding to the game status data is displayed in the graphical user interface.

[0267] In one feasible implementation, the step of displaying the game screen corresponding to the game state data in the graphical user interface includes:

[0268] The game screen corresponding to the game status data is overlaid and displayed on the graphical user interface.

[0269] The specific embodiments and working processes of the steps performed by the above-mentioned electronic device can be referred to the corresponding processes in the above-mentioned method embodiments, and will not be repeated here.

[0270] In this way, the first client can encapsulate the game state data related to the first virtual character it controls into a state frame, and then send the state frame to the server. The server then synchronizes the state frame to the second client. Each second client can then obtain the corresponding game screen from the server and directly display it based on the state frame. The state frame solves the problem that the server has no game data for frame synchronization, leaving the calculation to the client. At the same time, since each client only processes and uploads the game state data related to the virtual character it controls, it can directly draw the image when it receives data from other clients. This eliminates the need for each client to perform a series of calculations on the game state data related to the virtual characters controlled by other clients, effectively reducing the client's data processing volume and operating pressure, and alleviating the technical problem of high operating pressure caused by large client data processing volume.

[0271] Corresponding to the data processing method for virtual characters in the above-mentioned game, this disclosure also provides 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 perform the following steps:

[0272] Based on the control commands from the first client to the first virtual character, determine the game state data generated by the first virtual character during the execution of the control commands;

[0273] The game state data is encapsulated into a state frame;

[0274] The status frame is sent to the server, so that the server sends the status frame to the second client, so that the game screen corresponding to the game status data is displayed on the second client.

[0275] In one feasible implementation, the game state data includes any one or more of the following:

[0276] The state data of the first virtual character, the state data of other virtual characters in the game scene besides the first virtual character, and the state data of other virtual objects.

[0277] In one feasible implementation, the server corresponds to multiple game scenes; and further includes:

[0278] Determine the target game scene where the first virtual character is located;

[0279] The data of the target game scene is sent to the server so that the server sends the status frame to the second client. The second virtual character controlled by the second client is another virtual character in the target game scene besides the first virtual character.

[0280] In one feasible implementation, the game scene includes multiple scene areas, and each scene area corresponds to a region identifier;

[0281] The step of sending the data of the target game scene to the server, so that the server sends the status frame to the second client, includes:

[0282] The data of the target game scene and the target area identifier corresponding to the target scene area are sent to the server, so that the server can determine the target game scene where the first virtual character is located based on the data of the target game scene and determine the target scene area based on the target area identifier, and send the target status frame corresponding to the target scene area to the second client.

[0283] In one feasible implementation, the status frame is sent to the server in the form of a data packet; prior to the step of sending the status frame to the server, the method further includes:

[0284] Determine the data that has changed in the status frame;

[0285] The changed data in the status frame is included in the body of the data packet.

[0286] In one feasible implementation, the status frames are sent to the server in the form of data packets; each data packet contains a specified number of status frames.

[0287] The game screen is displayed on the second client at a specified frame rate; wherein, the specified frame rate is the specified number of frames per second.

[0288] In one feasible implementation, the game state data includes any one or more of the following:

[0289] The game's movement status data, collision status data, and position status data.

[0290] The aforementioned computer-readable storage medium stores computer-executable instructions, which, when invoked and executed by a processor, can also cause the processor to perform the following steps:

[0291] Obtain the status frame sent by the first client; wherein the status frame is obtained by the first client encapsulating game status data, and the game status data is the game status data generated during the process of the first virtual character executing the control command of the first client;

[0292] Identify a second virtual character who is in the same game scene as the first virtual character;

[0293] The status frame is sent to the second client corresponding to the second virtual character, so that the game screen corresponding to the game status data is displayed on the second client.

[0294] In one feasible implementation, the step of determining the second virtual character in the same game scene as the first virtual character includes:

[0295] Obtain scene identifiers sent by each client; wherein, the scene identifiers are used to represent at least one game scene in which the virtual character controlled by the client is located in the game;

[0296] Based on the game scenes in which the multiple virtual characters are located, a second virtual character is determined that is in the same game scene as the first virtual character.

[0297] In one feasible implementation, the server corresponds to multiple game scenes, and each virtual character corresponds to multiple game scene allocation dimensions;

[0298] The step of determining the second virtual character in the same game scene as the first virtual character includes:

[0299] By traversing all the game scenes, the game scene with the optimal allocation dimension for each of the multiple game scene allocation dimensions is determined;

[0300] Based on the priority of each game scene allocation dimension, the game scene to which the first virtual character is assigned and the second virtual character to the same game scene as the first virtual character are determined from the game scenes with the best game scene allocation dimension.

[0301] In one feasible implementation, the game scene allocation dimension includes any one or more of the following:

[0302] The game habits, character level, and character activity of the virtual character.

[0303] In one feasible implementation, the number of the second virtual characters is multiple, and each second virtual character corresponds to a game character classification dimension;

[0304] The step of sending the status frame to the second client corresponding to the second virtual character, so as to display the game screen corresponding to the game status data on the second client, includes:

[0305] Based on the game character classification dimension, a target second virtual character that is classified into the same category as the first virtual character is determined from multiple second virtual characters;

[0306] The status frame is sent to the target second client corresponding to the target second virtual character, so as to display the game screen corresponding to the game status data on the target second client.

[0307] In one feasible implementation, the game character classification dimensions include any one or more of the following:

[0308] The game habits, character level, and character activity of the virtual character.

[0309] The aforementioned computer-readable storage medium stores computer-executable instructions, which, when invoked and executed by a processor, can also cause the processor to perform the following steps:

[0310] Receive a status frame sent by the server; wherein the status frame is obtained by the first client encapsulating game status data, and the game status data is game status data generated during the process of the first virtual character executing the control commands of the first client;

[0311] The game screen corresponding to the game status data is displayed in the graphical user interface.

[0312] In one feasible implementation, the step of displaying the game screen corresponding to the game state data in the graphical user interface includes:

[0313] The game screen corresponding to the game status data is overlaid and displayed on the graphical user interface.

[0314] When the computer-executable instructions stored in the aforementioned computer-readable storage medium are called and run by the processor, the specific embodiments and working processes of the steps executed by the processor can be referred to the corresponding processes in the above method embodiments, and will not be repeated here.

[0315] In this way, the first client can encapsulate the game state data related to the first virtual character it controls into a state frame, and then send the state frame to the server. The server then synchronizes the state frame to the second client. Each second client can then obtain the corresponding game screen from the server and directly display it based on the state frame. The state frame solves the problem that the server has no game data for frame synchronization, leaving the calculation to the client. At the same time, since each client only processes and uploads the game state data related to the virtual character it controls, it can directly draw the image when it receives data from other clients. This eliminates the need for each client to perform a series of calculations on the game state data related to the virtual characters controlled by other clients, effectively reducing the client's data processing volume and operating pressure, and alleviating the technical problem of high operating pressure caused by large client data processing volume.

[0316] The data processing device for virtual characters in games provided in this disclosure can be specific hardware on a device or software or firmware installed on the device. The implementation principle and technical effects of the device provided in this disclosure are the same as those in the foregoing method embodiments. For the sake of brevity, any parts not mentioned in the device embodiments can be referred to the corresponding content in the foregoing method embodiments. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can all be referred to the corresponding processes in the above method embodiments, and will not be repeated here.

[0317] In the embodiments provided in this disclosure, it should be understood that the disclosed apparatus and methods 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 or 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.

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

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

[0320] In addition, the functional units in the embodiments provided in this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0321] 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 disclosure, in essence, 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 data processing method for virtual characters in the game described in the various embodiments of this disclosure. 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.

[0322] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0323] Finally, it should be noted that the above-described embodiments are merely specific implementations of this disclosure, used to illustrate the technical solutions of this disclosure, and not to limit it. The protection scope of this disclosure is not limited thereto. Although this disclosure 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, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this disclosure; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this disclosure. All should be covered within the protection scope of this disclosure. Therefore, the protection scope of this disclosure should be determined by the protection scope of the claims.

Claims

1. A method for processing data of virtual characters in a game, characterized in that, The game scene includes a first virtual character controlled by a first client. The server corresponds to multiple game scenes, each game scene containing multiple scene areas, and each scene area has a corresponding area identifier; including: Based on the control commands from the first client to the first virtual character, determine the game state data generated by the first virtual character during the execution of the control commands; The game state data is encapsulated into a state frame; Determine the target game scene where the first virtual character is located; The status frame, the data of the target game scene, and the target area identifier corresponding to the target scene area are sent to the server, so that the server determines the target game scene where the first virtual character is located based on the data of the target game scene and determines the target scene area based on the target area identifier. The server then sends the status frame and the target status frame corresponding to the target scene area to the second client, so that the game screen corresponding to the game status data is displayed on the second client. The target scene area is the scene area where the first virtual character is located in the target game scene, and the second virtual character controlled by the second client is another virtual character located in the target scene area besides the first virtual character. The method for determining the second virtual character includes: based on... The virtual character's field of view and the game scene divide the entire game map into multiple scene areas, each scene area corresponding to a scene identifier; the scene identifiers sent by each client are obtained, and the scene identifiers sent by the client are used to indicate the field of view area that the virtual character controlled by the client can see in the game, corresponding to at least one scene area; the virtual characters are grouped according to the multiple scene identifiers sent by the multiple clients, and virtual characters with at least some of the same scene identifiers are grouped together, and the same group indicates that they correspond to the same scene area. For the same scene area, the status frame corresponding to each virtual character is broadcast to all virtual characters in the same scene area; based on the scene areas corresponding to the multiple virtual characters, a second virtual character that corresponds to the same scene area as the first virtual character is determined.

2. The data processing method for virtual characters in a game according to claim 1, characterized in that, The game status data includes any one or more of the following: The state data of the first virtual character, the state data of other virtual characters in the game scene besides the first virtual character, and the state data of other virtual objects.

3. The data processing method for virtual characters in a game according to claim 1, characterized in that, The status frame is sent to the server in the form of a data packet; before sending the status frame to the server, the process further includes: Determine the data that has changed in the status frame; The changed data in the status frame is included in the body of the data packet.

4. The data processing method for virtual characters in a game according to claim 1, characterized in that, The status frames are sent to the server in the form of data packets; each data packet contains a specified number of status frames. The game screen is displayed on the second client at a specified frame rate; wherein, the specified frame rate is the specified number of frames per second.

5. The data processing method for virtual characters in a game according to claim 1, characterized in that, The game status data includes any one or more of the following: The game's movement status data, collision status data, and position status data.

6. A method for processing data of virtual characters in a game, characterized in that, Applied to the server side, the game scene of the game includes a first virtual character controlled by a first client; The server corresponds to multiple game scenes, and each game scene contains multiple scene regions, each scene region corresponding to a region identifier; including: The system acquires a status frame sent by the first client, data of the target game scene, and a target area identifier corresponding to the target scene area; wherein, the status frame is obtained by the first client encapsulating game status data, the game status data is game status data generated during the execution of control commands by the first virtual character by the first client, the target game scene is the game scene in which the first virtual character is located in the game, and the target scene area is the scene area in which the first virtual character is located in the target game scene. Based on the game scene where the multiple virtual characters are located, a second virtual character is determined that is in the same game scene as the first virtual character; The target game scene where the first virtual character is located is determined based on the data of the target game scene, and the target scene area is determined based on the target area identifier; The status frame and the target status frame corresponding to the target scene area are sent to the second client corresponding to the second virtual character, so as to display the game screen corresponding to the game status data on the second client; The step of determining the second virtual character that is in the same game scene as the first virtual character includes: dividing the entire game map into multiple scene areas based on the virtual character's field of view and the game scene, with each scene area corresponding to a scene identifier; obtaining scene identifiers sent by each client, wherein the scene identifiers sent by the client are used to indicate at least one scene area in the game corresponding to the field of view area that the virtual character controlled by the client can see; grouping the virtual characters according to the multiple scene identifiers sent by the multiple clients, grouping virtual characters with at least some of the same scene identifiers into one group, the same group indicating that they correspond to the same scene area, broadcasting the status frame corresponding to each virtual character to all virtual characters in the same scene area for the same scene area; and determining the second virtual character that corresponds to the same scene area as the first virtual character based on the scene areas corresponding to the multiple virtual characters.

7. The data processing method for virtual characters in a game according to claim 6, characterized in that, The server corresponds to multiple game scenes, and each virtual character corresponds to multiple game scene allocation dimensions; The step of determining a second virtual character that is in the same game scene as the first virtual character includes: By traversing all the game scenes, the game scene with the optimal allocation dimension for each of the multiple game scene allocation dimensions is determined; Based on the priority of each game scene allocation dimension, the game scene to which the first virtual character is assigned and the second virtual character to the same game scene as the first virtual character are determined from the game scenes with the best game scene allocation dimension.

8. The data processing method for virtual characters in a game according to claim 7, characterized in that, The game scene allocation dimensions include any one or more of the following: The game habits, character level, and character activity of the virtual character.

9. The data processing method for virtual characters in a game according to claim 6, characterized in that, There are multiple second virtual characters, and each second virtual character corresponds to a game character classification dimension; Sending the status frame to the second client corresponding to the second virtual character, so as to display the game screen corresponding to the game status data on the second client, includes: Based on the game character classification dimension, a target second virtual character that is classified into the same category as the first virtual character is determined from multiple second virtual characters; The status frame is sent to the target second client corresponding to the target second virtual character, so as to display the game screen corresponding to the game status data on the target second client.

10. The data processing method for virtual characters in a game according to claim 9, characterized in that, The game character classification dimensions include any one or more of the following: The game habits, character level, and character activity of the virtual character.

11. A method for processing data of virtual characters in a game, characterized in that, The same game scene of the game includes a first virtual character controlled by a first client and a second virtual character controlled by a second client, with the second client providing a graphical user interface; The server corresponds to multiple game scenes, each game scene containing multiple scene regions, and each scene region corresponding to a region identifier; the method includes: The server receives a status frame, target game scene data, and a target area identifier corresponding to the target scene area sent by the server. The status frame is obtained by the first client encapsulating game state data, and the game state data is generated during the execution of control commands from the first virtual character by the first client. The target game scene is the game scene in which the first virtual character is located, and the target scene area is the scene area in which the first virtual character is located within the target game scene. The server determines the target game scene in which the first virtual character is located based on the target game scene data and determines the target scene area based on the target area identifier. It also determines a second virtual character in the same game scene as the first virtual character based on the game scenes in which multiple virtual characters are located. The game screen corresponding to the game status data is displayed in the graphical user interface; The step of determining the second virtual character that is in the same game scene as the first virtual character includes: dividing the entire game map into multiple scene areas based on the virtual character's field of view and the game scene, with each scene area corresponding to a scene identifier; obtaining scene identifiers sent by each client, wherein the scene identifiers sent by the client are used to indicate at least one scene area in the game corresponding to the field of view area that the virtual character controlled by the client can see; grouping the virtual characters according to the multiple scene identifiers sent by the multiple clients, grouping virtual characters with at least some of the same scene identifiers into one group, the same group indicating that they correspond to the same scene area, broadcasting the status frame corresponding to each virtual character to all virtual characters in the same scene area for the same scene area; and determining the second virtual character that corresponds to the same scene area as the first virtual character based on the scene areas corresponding to the multiple virtual characters.

12. The data processing method for virtual characters in a game according to claim 11, characterized in that, The step of displaying the game screen corresponding to the game status data in the graphical user interface includes: The game screen corresponding to the game status data is overlaid and displayed on the graphical user interface.

13. A data processing device for virtual characters in a game, characterized in that, The game scene includes a first virtual character controlled by a first client, and the server corresponds to multiple game scenes. Each game scene contains multiple scene areas, and each scene area corresponds to a region identifier. The device includes: The determining module is used to determine, based on the control commands given by the first client to the first virtual character, the game state data generated by the first virtual character during the execution of the control commands; An encapsulation module is used to encapsulate the game state data into state frames; The sending module is used to send the status frame to the server, so that the server sends the status frame to the second client, so that the game screen corresponding to the game status data is displayed on the second client; The sending module is specifically used to: determine the target game scene where the first virtual character is located, and send the status frame, the data of the target game scene, and the target area identifier corresponding to the target scene area to the server, so that the server determines the target game scene where the first virtual character is located based on the data of the target game scene and determines the target scene area based on the target area identifier, and sends the status frame and the target status frame corresponding to the target scene area to the second client, so as to display the game screen corresponding to the game status data on the second client; wherein, the target scene area is the scene area where the first virtual character is located in the target game scene, and the second virtual character controlled by the second client is another virtual character other than the first virtual character located in the target scene area; the first The method for determining the second virtual character includes: dividing the entire game map into multiple scene areas based on the virtual character's field of view and the game scene, with each scene area corresponding to a scene identifier; obtaining scene identifiers sent by each client, wherein the scene identifiers sent by the client are used to indicate at least one scene area in the game corresponding to the field of view area that the virtual character controlled by the client can see; grouping the virtual characters according to the multiple scene identifiers sent by the multiple clients, grouping virtual characters with at least some of the same scene identifiers into one group, the same group indicating that they correspond to the same scene area, broadcasting the status frame corresponding to each virtual character to all virtual characters in the same scene area for the same scene area; and determining the second virtual character that corresponds to the same scene area as the first virtual character based on the scene areas corresponding to the multiple virtual characters.

14. A data processing device for virtual characters in a game, characterized in that, Applied to the server side, the game scene of the game includes a first virtual character controlled by a first client; The server corresponds to multiple game scenes, each game scene contains multiple scene regions, and each scene region corresponds to a region identifier; the device includes: The acquisition module is used to acquire the status frame sent by the first client, the data of the target game scene, and the target area identifier corresponding to the target scene area; wherein, the status frame is obtained by the first client encapsulating the game status data, and the game status data is the game status data generated during the execution of the control commands of the first virtual character by the first client; the target game scene is the game scene in which the first virtual character is located in the game, and the target scene area is the scene area in which the first virtual character is located in the target game scene. The determining module is used to determine a second virtual character that is in the same game scene as the first virtual character, and to determine the target game scene in which the first virtual character is located based on the data of the target game scene, and to determine the target scene area based on the target area identifier; The sending module is used to send the status frame and the target status frame corresponding to the target scene area to the second client corresponding to the second virtual character, so as to display the game screen corresponding to the game status data on the second client; The determination module is specifically used for: dividing the entire game map into multiple scene areas based on the virtual character's field of view and the game scene, with each scene area corresponding to a scene identifier; acquiring scene identifiers sent by each client, wherein the scene identifiers sent by the client represent at least one scene area in the game corresponding to the field of view area that the virtual character controlled by the client can see; grouping virtual characters according to the multiple scene identifiers sent by multiple clients, grouping virtual characters with at least some of the same scene identifiers into one group, the same group indicating that they correspond to the same scene area, broadcasting the status frame corresponding to each virtual character to all virtual characters in the same scene area for the same scene area; and determining a second virtual character that corresponds to the same scene area as the first virtual character based on the scene areas corresponding to the multiple virtual characters.

15. A data processing device for virtual characters in a game, characterized in that, The same game scene of the game includes a first virtual character controlled by a first client and a second virtual character controlled by a second client, with the second client providing a graphical user interface; The server corresponds to multiple game scenes, each game scene containing multiple scene regions, and each scene region corresponding to a region identifier; the device includes: A receiving module is used to receive a status frame, target game scene data, and a target area identifier corresponding to the target scene area sent by the server. The status frame is obtained by the first client encapsulating game state data, and the game state data is generated during the execution of control commands from the first virtual character by the first client. The target game scene is the game scene in which the first virtual character is located, and the target scene area is the scene area in which the first virtual character is located within the target game scene. The server is used to determine the target game scene in which the first virtual character is located based on the target game scene data and to determine the target scene area based on the target area identifier. Furthermore, based on the game scenes in which multiple virtual characters are located, the server determines the game scene in which the first virtual character is located. The server is further configured to: divide the entire game map into multiple scene areas based on the virtual character's field of view and the game scene, with each scene area corresponding to a scene identifier; acquire scene identifiers sent by each client, wherein the scene identifiers sent by the client represent at least one scene area in the game corresponding to the field of view area that the virtual character controlled by the client can see; group the virtual characters according to the multiple scene identifiers sent by the multiple clients, grouping virtual characters with at least some of the same scene identifiers into one group, the same group indicating that they correspond to the same scene area; broadcast the status frame corresponding to each virtual character to all virtual characters in the same scene area for the same scene area; and determine a second virtual character that corresponds to the same scene area as the first virtual character based on the scene areas corresponding to the multiple virtual characters. The display module is used to display the game screen corresponding to the game status data in the graphical user interface.

16. An electronic device comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the data processing method for virtual characters in a game as described in any one of claims 1 to 12.

17. 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 perform the data processing method for virtual characters in a game as described in any one of claims 1 to 12.

Images