Game data processing method, device, and medium

Abstract

The present invention provides a game data processing method, device, and medium. In the method, game data related to the current battle scene is obtained, and the game data includes one or more of player data, environmental data, and non-player controlled character NPC data. Then, a battle module matching the game data is called to return the game data processing result of executing corresponding battle logic processing on the game data in the current battle scene through the battle module. Finally, the battle effect corresponding to the game processing result is displayed in the game interface of the game client. The above scheme facilitates the game client to implement the battle logic processing of the game data in the current battle scene through the battle module, improves the efficiency of the game battle logic processing, and reduces the difficulty of developing and maintaining the game battle logic.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a game data processing method, device, and medium. Background Art

[0002] Combat is the core experience of most games. Players experience various plots, levels, and various character skill effects through battles in the game, which brings fun to players.

[0003] In order to solve the hardware overhead problem caused by the independent implementation of combat logic by the server and the cheating problem caused by the independent implementation of combat logic by the client, a combat logic implementation method of front-end combat and back-end verification is proposed. That is, the skill settlement logic and combat effect are implemented on the front-end (such as the client), and some key combat data are verified by the back-end (such as the server) to prevent cheating.

[0004] Taking placement games as an example, in order to adapt to the hardware structure and development habits of the front and back ends, different languages ​​are usually used on the client and server sides to develop combat logic. However, due to the differences in the operating platforms on the client and server sides, it is difficult to ensure the data consistency between the two sides during the interaction process, and verification errors often occur due to inconsistent data. Moreover, different languages ​​are needed to maintain and expand the combat logic in the client and server respectively. For example, each time the combat logic is expanded, it is necessary to rewrite it on both sides and recalibrate the data consistency in the combat logic on both sides, which obviously greatly reduces the maintenance and development efficiency of the game. Therefore, it is urgent to design a game combat logic processing method that is easy to call. Summary of the invention

[0005] Multiple aspects of the present invention provide a game data processing method, device, and medium, which facilitate the game client to implement combat logic processing of game data in the current combat scene through a combat module, improve the efficiency of game combat logic processing, and reduce the difficulty of developing and maintaining game combat logic.

[0006] The embodiment of the present invention further provides a method for processing game data, the method comprising:

[0007] Obtain game data related to the current battle scene, the game data including one or more of player data, environment data, and non-player controlled character NPC data;

[0008] Calling a battle module that matches the game data to return the game data processing result of executing corresponding battle logic processing on the game data in the current battle scene through the battle module;

[0009] The combat effects corresponding to the game processing results are displayed in the game interface of the game client.

[0010] An embodiment of the present invention further provides an electronic device, including a processor and a memory, wherein the memory is used to store one or more computer instructions; the processor is used to execute the one or more computer instructions to execute any step in the game data processing method described above.

[0011] An embodiment of the present invention further provides an electronic device, including a processor and a memory, wherein the memory stores at least one instruction, at least one program, code set or instruction set, and the at least one instruction, at least one program, code set or instruction set is loaded and executed by the processor to implement the game data processing method described above.

[0012] An embodiment of the present invention provides a computer-readable medium on which at least one instruction, at least one program, code set or instruction set is stored. The at least one instruction, at least one program, code set or instruction set is loaded and executed by a processor to implement the game data processing method described above.

[0013] In this embodiment, game data related to the current battle scene is obtained, and the game data includes one or more of player data, environmental data, and non-player controlled character NPC data. Then, a battle module matching the game data is called to return the game data processing result of executing corresponding battle logic processing on the game data in the current battle scene through the battle module. Finally, the battle effect corresponding to the game processing result is displayed in the game interface of the game client. In this embodiment, by connecting to the battle module of the game client, the game client can call the battle module to execute corresponding battle logic processing on the game data, thereby displaying the battle effect corresponding to the game data processing result returned by the battle module in the game interface, so that the game client can realize the battle logic processing of the game data in the current battle scene through the battle module, improve the efficiency of the game battle logic processing, and reduce the difficulty of developing and maintaining the game battle logic. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of the present invention. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0015] Figure 1 A structural schematic diagram of a combat module construction system provided by an exemplary embodiment of the present invention;

[0016] Figure 2 A flowchart of a method for processing game data provided by an exemplary embodiment of the present invention;

[0017] Figure 3A schematic diagram of the structure of an electronic device provided by an exemplary embodiment of the present invention;

[0018] Figure 4 A schematic diagram of the structure of a game data processing device provided by an exemplary embodiment of the present invention. DETAILED DESCRIPTION

[0019] In order to make the purpose, technical solution and advantages of the present invention clearer, the technical solution of the present invention will be clearly and completely described below in conjunction with the specific embodiments of the present invention and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0020] The battle module construction scheme provided in the embodiment of the present invention can be executed by an electronic device, which can be a terminal device such as a smart phone, a tablet computer, a PC, a laptop computer, etc. In an optional embodiment, the electronic device can be installed with an application for executing the battle module construction scheme. Alternatively, in another optional embodiment, the battle module construction scheme can also be executed by the server device and the terminal device in cooperation.

[0021] In practical applications, the battle module construction scheme provided by the embodiment of the present invention is applicable to a system architecture including a terminal device and a server. Specifically, the terminal device is equipped with a game program, so the game program is also referred to as a game client in this article. Devices equipped with game clients are, for example, smart phones, tablet computers, computers, etc. The game client is used to implement various logics in the game. Taking the battle logic in an online game as an example, the game client can calculate the real-time execution result of the battle logic and render the real-time execution result into the game interface. Of course, the real-time execution result of the battle logic can also be calculated by the server and fed back to the game client, which is not limited by the embodiment of the present invention. The server can be a physical device or a virtual device. Among them, the physical device is, for example, a battle server, a game server, a cloud server, etc., and the virtual device is, for example, a virtual machine, a virtual cloud node, etc. The server can also be one or more devices in a server cluster.

[0022] The following describes the technical problems that the technical solutions provided by the embodiments of the present invention actually solve:

[0023] In view of the dual-end architecture composed of game clients and servers, in order to adapt to the hardware structures and development habits of the game clients and servers, different languages ​​are usually used on the game client and server sides to implement the development and maintenance of the same combat logic. However, due to the differences in the operating platforms between the game client and the server, such as hardware structure differences, development language differences, software system differences, etc., it is difficult to ensure the consistency of data in the interaction between the two sides, and verification errors often occur due to inconsistent data. On the other hand, it is also necessary to use different languages ​​to maintain and expand the combat logic on both sides of the game client and server. For example, each time the combat logic is expanded, it is necessary to write it on both sides separately, and recalibrate the data consistency in the combat logic on both sides, which obviously greatly reduces the maintenance and development efficiency of the game. Therefore, how to implement game combat logic processing on the game client, reduce the difficulty of game combat logic development and maintenance, and improve the efficiency of game combat logic processing has become a technical problem that needs to be solved urgently.

[0024] In view of the above technical problems, a solution is provided in some embodiments of the present invention. The technical solutions provided by the embodiments of the present invention are described in detail below with reference to the accompanying drawings.

[0025] In an embodiment of the present invention, a game data processing scheme is provided. In this scheme, firstly, game data related to the current battle scene is obtained, and the game data includes one or more of player data, environmental data, and non-player controlled character NPC data. Then, a battle module matching the game data is called to return the game data processing result of executing corresponding battle logic processing on the game data in the current battle scene through the battle module. Finally, the battle effect corresponding to the game processing result is displayed in the game interface of the game client. In this embodiment, by connecting the battle module to the game client, the game client can call the battle module to execute corresponding battle logic processing on the game data, thereby displaying the battle effect corresponding to the game data processing result returned by the battle module in the game interface, so as to facilitate the game client to realize the battle logic processing of the game data in the current battle scene through the battle module, improve the efficiency of the game battle logic processing, and reduce the difficulty of developing and maintaining the game battle logic.

[0026] In addition, in this solution, the game client and the server can call the same battle module, that is, various battle logic processing in the game can be implemented on both the game client and the server. By calling the battle module, the game data associated with the same battle logic required by the game client and the server are provided to each other to implement the corresponding battle logic.

[0027] For example, in the front-end combat and back-end verification mode, the combat module can respond to the game client's call instructions and provide the game client with combat effect data and combat settlement data associated with the combat logic. The combat module can respond to the server's call instructions and provide the server with combat result data associated with the combat logic for verifying the game combat results.

[0028] In an optional embodiment, the combat module construction scheme provided by the embodiment of the present invention can be applied to Figure 1 The system architecture is shown in Figure 1 In the game, the game client 11 establishes a communication connection with the combat module 12, and the communication connection is used to transmit the game data associated with the combat logic to form a game data stream. The game data stream provided by the communication connection is mainly used to achieve various combat effects corresponding to the combat logic, such as combat screen, combat skill effect, combat damage, combat result, displacement effect, etc. Figure 1 In the example, the server 13 establishes another communication connection with the battle module 12, and the other communication connection can also transmit game data associated with the battle logic to form another game data stream. However, different from the game data stream provided by the communication connection between the game client 11 and the battle module 12, the game data stream provided by the other communication connection is mainly used to verify the battle effect displayed in the game client 11. It can be seen that the above two data streams are independent of each other. Through the server 13, it can be verified whether the game client 11 tampers with the game data, prevent the use of plug-ins to cheat, and ensure the fairness of the game.

[0029] exist Figure 1 In the example, the combat module 12 includes a combat skill module, an AI module, a settlement module and other modules, through which different functions can be realized respectively.

[0030] In practical applications, the combat module 12 provided in the embodiment of the present invention can be understood as an independent program module abstracted from at least one combat logic in the game, and the program module can realize the combat module construction function related to at least one combat logic in the game client and the server. The program module can be arranged in any device of the game client and the server, and can also be arranged in parallel in the game client and the server (for example, by carrying a data packet of the program module, distributing the installation file of the program module to the game client and the server, so as to respectively arrange the program module on both sides of the game client and the server), and can also be arranged in an independent third-party device. The third-party device can be configured with a communication connection with the game client and the server respectively, so that the game client and the server can call the program module respectively. The third-party device can be a physical device or a virtual device. Wherein, the physical device is, for example, a combat server, a game server, a cloud server, etc., and the virtual device is, for example, a virtual machine, a virtual cloud node, etc.

[0031] It should be noted that Figure 1 The system architecture shown is for illustration only, and the system architecture provided by the embodiment of the present invention is not limited thereto.

[0032] Based on the system architecture introduced above, an embodiment of the present invention provides a method for processing game data. Figure 2 A flowchart of a method for processing game data provided by an exemplary embodiment of the present invention is shown in FIG. Figure 2 As shown, the method comprises the following steps:

[0033] 201. Obtain game data related to the current battle scene;

[0034] 202. Calling a battle module that matches the game data to return, through the battle module, a game data processing result of executing corresponding battle logic processing on the game data in the current battle scene;

[0035] 203. Display the combat effect corresponding to the game processing result in the game interface of the game client.

[0036] In this embodiment, by connecting to the combat module of the game client, the game client can call the combat module to perform corresponding combat logic processing on the game data, thereby displaying the combat effect corresponding to the game data processing result returned by the combat module in the game interface, so that the game client can realize the combat logic processing of the game data in the current combat scene through the combat module, thereby improving the efficiency of the game combat logic processing and reducing the difficulty of developing and maintaining the game combat logic.

[0037] The specific implementation of each step in the above method is introduced below with reference to specific examples.

[0038] In 201, game data related to the current battle scene is obtained. Among them, the game data related to the current battle scene includes, but is not limited to, one or more of player data, environmental data, and non-player character (NPC) data. Player data includes, for example, the battle object, location, battle type, character type, weapons held, skills, team situation, level, profession, reward resources, etc. Environmental data includes, for example, the player's location, battle scene type, copy, scene environment information, teleportation point information, terrain, scenery and buildings in the current scene, etc. NPC data includes, for example, the NPC fighting against the player, the pet NPC held by the player, the plot NPC encountered by the player, etc.

[0039] Next, in conjunction with the acquired game data, in this embodiment, in 202, a battle module matching the game data is called to return, through the battle module, a game data processing result of executing corresponding battle logic processing on the game data in the current battle scene.

[0040] Specifically, in an optional embodiment of step 202, a target combat module matching the current combat scene is determined based on the game data; through the calling interface of the target combat module, the target combat module is called to perform target combat logic processing on the game data in the current combat scene to generate a game data processing result; and the game data processing result fed back from the target combat module is received.

[0041] In the above steps, it is first necessary to determine the target combat module that matches the current combat scene according to the game data. Specifically, the combat scene type corresponding to the current combat scene is determined according to the player data, environment data and / or NPC data in the game data; the corresponding target combat behavior tree is selected from the pre-built multiple combat behavior trees according to the combat scene type, and the target random generator is selected from the pre-built multiple random generators; the target combat module composed of the target combat behavior tree and the target random number generator is selected from the pre-built multiple combat modules.

[0042] Wherein, the battle module can be understood as an independent program module abstracted from at least one battle logic in the game, and the program module can realize the game data processing function related to at least one battle logic in the game client and the server. Similar to the program module 12 introduced above, the program module can be arranged in any device of the game client and the server, and can also be arranged in parallel in the game client and the server (for example, by carrying a data packet of the program module, the installation file of the program module is distributed to the game client and the server, so that the program module is respectively arranged on both sides of the game client and the server), and can also be arranged in an independent third-party device. The third-party device can be configured with a communication connection with the game client and the server respectively, so that the game client and the server can call the program module respectively. The third-party device can be a physical device or a virtual device. Wherein, the physical device is, for example, a battle server, a game server, a cloud server, etc., and the virtual device is, for example, a virtual machine, a virtual cloud node, etc.

[0043] In order to enable both the game client and the server to call the battle module, the battle module can be independently run in a third-party device, and corresponding calling interfaces are configured for the game client and the server respectively, so that the game client and the server can access the battle module. Alternatively, the battle module can also be run in the game client and the server respectively, and the battle module can be called through the calling interfaces encapsulated in the game client and the server.

[0044] The multiple combat behavior trees and the multiple random generators can be pre-set according to the combat scene type. Furthermore, based on the multiple combat behavior trees and the multiple random generators, multiple combat modules are combined to implement the game combat logic processing under different combat scene types.

[0045] Optionally, the battle scene type can be determined based on the game type and game battle information. For example, the current battle scene type can be determined based on one or more of the monster NPC, other player entities, whether it is a team battle, whether it is an individual battle, and the opponent's information. In turn-based or level-based game types, for the battle scene type, it is necessary to further consider the impact of physical environmental factors in the battle on the battle logic processing results. For example, on rainy days or in lakes, players with a certain attribute (such as fire attribute) may behave differently from usual, so it is also necessary to consider environmental information to determine the battle scene type. In addition, the determinants of the battle scene type in other types of games can be set in other ways, which will not be repeated here.

[0046] Furthermore, in the above steps, calling the battle module that matches the game data to return the game data processing result of executing the corresponding battle logic processing on the game data in the current battle scene through the battle module can be implemented as follows:

[0047] The game client specifies a target battle module that matches the current battle scene from among multiple pre-built battle modules through a battle scene type identifier; calls the target battle module through a calling interface of the target battle module to perform target battle logic processing on game data in the current battle scene to generate a game data processing result; and receives the game data processing result fed back from the target battle module.

[0048] Compared with the related art of rewriting the battle logic on both sides of the server and the game client, the present invention constructs a battle module connected between the game client and the server, so that the game client and the server can process the game data associated with the same battle logic through the battle module, ensuring the consistency of the game data on both sides of the game client and the server, and effectively avoiding verification errors caused by inconsistent game data. In addition, the battle module can also effectively avoid the phenomenon of repeated development and maintenance on both sides of the game client and the server for the same battle logic, improve the development and maintenance efficiency of the battle logic, and save the development and maintenance costs of various battle logics.

[0049] In view of this problem, in order to facilitate the game client to call the target battle module, optionally, the target battle module is provided with a first calling interface corresponding to the game client. Based on this, in the above steps, the target battle module is called through the calling interface of the target battle module to perform the target battle logic processing on the game data in the current battle scene to generate the game data processing result, which can be implemented as follows: through the first calling interface, the target battle module is called in a logical frame manner to perform the target battle logic processing on the current game data to obtain the game data processing result in the next logical frame.

[0050] In the game client, the call instruction for the combat module matching the current game can be triggered by the game player. For example, in some scenarios, when the game player needs to use a combat function (such as entering a multiplayer duel venue) during the game, the call instruction can be issued through the control button provided in the game interface. The call instruction can be an attack instruction, a skill release instruction, a combat mode selection instruction, a movement instruction, etc., which is not limited in this embodiment.

[0051] In other embodiments, the call instruction may be automatically triggered by the game system according to a detected event. The event that automatically triggers the call instruction may be a timing event, a counting event, or other monitoring event, which is not limited in this embodiment. If it is a timing event, the game system may issue a call instruction to the combat module according to the timed task. For example, in a game scene, during a certain period of time, the system may automatically trigger an instruction for a player in a certain area to enter a combat state, and issue a call instruction to the combat module to obtain corresponding combat data. If it is a counting event, the game system may issue a call instruction to the combat module according to a counting task. For example, in a game scene, a task is to collect fur to trigger entry into a combat copy. When the number of collected furs reaches a certain threshold, the system may automatically trigger an instruction to enter a combat copy, and issue a call instruction to the combat module to obtain the corresponding copy combat data. They will not be listed one by one.

[0052] Further optionally, in order to achieve unified combat logic processing between the front and back ends, the target combat module is provided with a first calling interface corresponding to the server. Based on this, the server calls the target combat module in a logical frame manner through the second calling interface, and performs the target combat logic processing on the current game data uploaded by the game client to obtain the game data processing result on the server side. In practical applications, the game data processing result on the server side can be used for verification of game combat logic, multi-terminal collaboration, and multi-terminal synchronization.

[0053] In the server, the call instruction to the battle module matching the current game can be triggered by the monitoring event. For example, in some scenarios, after the server detects that the game player has ended the battle state, it can issue a call instruction to the battle module to obtain the verification data for the game player. In other scenarios, after the server detects that each round of the game player has ended, it can issue a call instruction to the battle module to obtain the verification data for the game player.

[0054] In the embodiment, the game client and the server can call the game data associated with the same battle logic in the battle module. Therefore, the same battle logic can be implemented without writing program codes for the same battle logic in the game client and the server respectively, avoiding the waste of resources caused by repeated development and improving the development and maintenance efficiency of the battle logic. For example, when launching a new battle logic, it can be developed directly in the battle module, so that the game client and the server can be provided with the game data processing results required to implement the new battle logic through the battle module.

[0055] Next, after obtaining the game data processing result, in 203, an optional embodiment of displaying the combat effect corresponding to the game processing result in the game interface of the game client can be implemented as follows: receiving the game data processing result of the logical frame; rendering the combat effect corresponding to the game data processing result in the current logical frame in the game interface of the game client.

[0056] For example, the game client can receive the game data processing results in each logical frame through the first calling interface, and then render the battle effect corresponding to the game data processing result in the current logical frame in the game interface of the game client.

[0057] Of course, in actual applications, the game data processing results corresponding to multiple logical frames can also be cached. Therefore, when an abnormality occurs in the game data processing results of the current logical frame, the game data processing results of the preset logical frame can be used to render the combat effect, thereby avoiding freezes in the game interface and improving the smoothness of the game.

[0058] In actual applications, at different stages, the game data fed back by the game client (or server) after calling the combat module is also different.

[0059] For example, before a battle begins, the game client can call the battle module to verify whether the player is qualified to enter the battle, for example, whether the player's level, player's occupation and other player status conditions meet the conditions for participating in the battle. If they meet the conditions, the battle module sends a battle qualification verification pass message to the game client to notify the game client that the player can enter the battle. Optionally, the battle module can also send a notification message to the server to indicate that the player requests to enter the battle.

[0060] Furthermore, during the battle, the game client can call the battle module to calculate the battle effect data associated with each frame of the battle logic frame by frame, and transmit the battle effect data associated with each frame of the battle logic back to the game client in chronological order through the battle module, so as to render the corresponding battle effect frame by frame in the game interface of the game client. Optionally, the number of frames of the battle logic is set according to the actual battle scene and / or network conditions.

[0061] The server can also call the battle module to verify the battle effect data associated with each frame of battle logic. This verification process can be carried out in real time in the battle module. For example, the battle module will only transmit the battle effect data back to the game client after verification to ensure the accuracy of the battle effect data. Or this verification process can also be carried out within a set period of time during the battle. For example, the battle module only verifies the key frame data to improve the fluency of the battle process. This verification process can also be implemented after the battle is over, further reducing the delay caused by the verification process and improving the fluency of the battle process.

[0062] After the battle process is over, the game client can upload the game data to be verified through the battle module. The server can call the battle module to verify the reported game data, and settle the account based on the verification result sent back by the battle module, or remind the player that the battle is abnormal.

[0063] It is worth noting that the above-mentioned interaction process between the battle module and the devices on both sides is only an example, and the embodiments of the present invention do not limit the use of other methods to interact with the battle module. Regardless of the method used, the core is: through the interaction between the game client and the server and the battle module, the game client and the server process the game data associated with the same battle logic through the battle module, thereby ensuring the consistency between the game client and the server and improving the efficiency of battle logic processing.

[0064] Figure 2 In the game data processing method shown, by connecting to the battle module of the game client, the game client can call the battle module to perform corresponding battle logic processing on the game data, thereby displaying the battle effect corresponding to the game data processing result returned by the battle module in the game interface, so that the game client can realize the battle logic processing of the game data in the current battle scene through the battle module, improve the efficiency of the game battle logic processing, and reduce the difficulty of developing and maintaining the game battle logic.

[0065] In the above or following embodiments, a verification mechanism is also provided. Optionally, the game client sends a verification message of the game data processing result to the server, so that the server calls the target combat module to verify whether the game data processing result conforms to the preset rules; and receives the verification result returned by the server to execute the game processing logic corresponding to the verification result.

[0066] In the above verification mechanism, the game client sends a verification message of the game data processing result to the server, which can be implemented as follows: the game client selects a corresponding verification time from multiple pre-set verification times according to the combat mode of the current combat scene, and sends a verification message of the game data processing result to the server at the corresponding verification time.

[0067] The multiple verification opportunities include any one or more of a preset time interval, a random time interval, a set time period after a skill is released, and a set time period after a battle. For example, if the battle mode of the current battle scene is a turn-based or level-based battle mode, the verification opportunity selected by the game client may be after each round or level. In some real-time battle games, since each round has a fixed duration, the game client may select a preset time interval or a random time interval (e.g., an integer multiple of the fixed duration of the battle) as the verification opportunity.

[0068] Then, the game client receives the verification result returned by the server to execute the game processing logic corresponding to the verification result. If the verification result returned by the game client is passed, the subsequent processing based on the original game data processing result is maintained. If the verification result returned by the game client is not passed, the game data processing result is forced to roll back, for example, the game data processing result is rolled back to the state before the game data processing result is obtained. Optionally, if the verification result returned by the game client is not passed, the game account can also be blocked, frozen, etc., or a prompt message can be sent to the game account to indicate that the user has abnormal combat operations or is suspected of plug-in. For example, within 2 hours, the player fails to pass the inspection multiple times. In this case, the player account is considered to be abnormal and the player account is blocked. Thereby, the delay caused by manual reporting is avoided, problems with the game client are discovered and solved in a timely manner, and the player experience is improved.

[0069] In an optional embodiment, in order to increase the reliability of the verification result, a collaborative verification mechanism can be introduced. Specifically, the verification result returned by the server can be implemented as: the verification result obtained by the server collaboratively verifying the game data processing result and the collaborative game data processing result.

[0070] Among them, the game data processing result and the collaborative game data processing result correspond to at least two combat subjects in the current battle scene respectively. In this embodiment, the combat subject includes but is not limited to the player subject and / or the NPC subject. For example, the collaborative game data processing result can be the game data from another player (i.e., the player subject) who is fighting against the current player. That is, the server can obtain the game data processing result of another player by calling the battle module, so that the players on both sides participating in the battle can perform collaborative verification to improve the reliability of the game verification. Of course, the server can also use a similar method to perform collaborative verification on the player subject and the NPC subject participating in the battle, which will not be repeated here.

[0071] In the above or following embodiments, a method for constructing a combat module is also provided. Specifically, for each combat module, determine the game client and server to which the combat module is to be connected; determine the target version of Lua language that is compatible with the respective runtime libraries of the game client and server; generate a combat behavior tree and a random number generator in the target combat module using the target version of Lua language based on game data; generate combat logic in the combat module using the target version of Lua language based on the combat behavior tree and the random number generator; and construct the combat module based on the combat behavior tree, the random number generator, and the combat logic.

[0072] Among them, the combat behavior tree is used to provide the same combat strategy to the game client and server, and the random number generator is used to generate the same pseudo-random queue in the game client and server to obtain random data in the same combat logic.

[0073] Optionally, the processing precision of the game data in the respective runtime libraries of the game client and the server is also modified so that the number of bits of the processing results of the same game data in the game client and the server is the same.

[0074] Optionally, the combat behavior tree and random number generator in the target combat module are generated using the target version of Lua language based on the game data, which can be implemented as follows:

[0075] Determine the combat modes corresponding to the multiple combat scenes; and generate combat behavior trees and random number generators matching the multiple combat modules using the target version of Lua language according to the combat modes corresponding to the multiple combat scenes.

[0076] Optionally, a battle cache queue is also set in the battle module; the game data processing results calculated by the battle module are cached frame by frame in the battle cache queue, and synchronized to the game client through the battle cache queue.

[0077] The following describes how to construct a battle module connected to both the game client and the server in an embodiment of the present invention with reference to a specific example:

[0078] First, for the combat module to be built, determine the game client and server to which the combat module is to be connected. Determine the target version of Lua language that is compatible with the runtime libraries of the game client and server.

[0079] In an embodiment of the present invention, the combat module can be implemented by Lua language. Lua language is a scripting language, which is mainly used for flexible embedding in application programs to provide extension and customization functions for application programs. Lua language is written in standard C, so it can run on most operating systems and platforms. Therefore, in an embodiment of the present invention, Lua language can be selected as a development language for building a combat module with cross-platform common functions. In practical applications, the combat module built based on Lua language can be used as an extension script of the game program, and can also be used as a configuration file of the game program to facilitate later development and maintenance.

[0080] The runtime library is the library file required by the combat module when it is running. The runtime library is an encapsulated program module that provides an interface to the outside world. The corresponding program module in the runtime library can be used through the interface parameters of the runtime library. Using the runtime library can reduce the duplication of code development work in the combat module and improve the efficiency of development and maintenance.

[0081] Specifically, determine the game client and server to be connected, and obtain the runtime library versions supported by the game client and server respectively.

[0082] For example, assume that a game client is installed on the game client, such as UE4. Assume that the server's operating system is implemented based on the Java language. Assume that the combat module is a combat module built based on the Lua language. Based on the above assumptions, the game client is provided with an unLua runtime library based on the Lua language environment to support the combat module built in the Lua language. The server is provided with a LuaJ runtime library based on the Lua language environment to support the combat module built in the Lua language.

[0083] Then, after obtaining the runtime versions supported by the game client and server, if there are multiple runtime versions of different versions, the lower version runtime is used as the runtime supporting the combat module, and the Lua language version supported by the lower version runtime is used as the target version Lua language to ensure the operation of the runtime in the game client and server. In actual applications, different versions of runtime can be selected according to the game type, game performance and other requirements to meet various game performance requirements.

[0084] In actual applications, in order to enhance the flexibility of the combat module, multiple Lua language versions supported by both the game client and the server can be configured into a dynamic list. Then, based on the operation of the combat module, the Lua language version that best matches the current operation is dynamically selected from the list as the target version of the Lua language.

[0085] Specifically, the game client and the server are respectively provided with a runtime library supporting the Lua language. Based on this, in an optional embodiment, the processing accuracy of the game data in the respective runtime libraries of the game client and the server is modified so that the number of digits of the same game data processing results in the game client and the server is the same. In simple terms, the calculation accuracy of each type of game data related to the combat logic is modified in the respective runtime libraries of the game client and the server so that the number of digits of the same type of game data processing results in the game client and the server is the same. For example, the processing accuracy of each type of game data is set to three decimal places in the respective runtime libraries of the game client and the server, so that the number of digits of the same type of game data processing results in the game client and the server can be consistent, further ensuring the consistency of the game data on both sides.

[0086] A tolerance range can also be set for the calculation accuracy of the above-mentioned game data processing results, for example, a deviation of 0.005 is allowed in the game data processing results. Optionally, the tolerance range can be set based on the data type, algorithm, and application scenario. Furthermore, if it is determined that the game data processing result is within the tolerance range, the subsequent steps will continue to be executed; otherwise, the combat module will be actively triggered to reprocess the game data associated with the combat logic. Thus, by setting the tolerance range, the jamming caused by frequent restarts of the processing flow can be avoided, further ensuring the smoothness of the game.

[0087] In practical applications, double-precision floating point numbers are used as the processing precision of game data in the runtime libraries of game clients and servers, for example, IEEE754 standard floating point numbers. Optionally, two decimal places are retained in the game data processing results to remove errors generated when different types of game clients or servers are running.

[0088] Furthermore, after determining the target version of Lua language, the target version of Lua language is used to generate a combat behavior tree and a random number generator in a target combat module based on the game data.

[0089] In the embodiment of the present invention, the combat behavior tree is used to provide the same combat strategy to the game client and server. In this step, the combat module is set according to the combat strategy in the current game. Optionally, the combat strategy is implemented as a behavior tree structure. For example, the displacement strategy, attack strategy, damage settlement strategy, and skill use strategy of the game object.

[0090] Specifically, the target version of Lua language is used to convert the combat strategy in the current game into a tree structure to obtain the combat behavior tree in the combat module. In actual applications, the combat strategy is stored in the third-generation behavior tree structure (behavior3) database built based on the Lua language, so the type of the combat behavior tree is behavior 3. To further ensure the data consistency between the game client and the server, the behavior3 database should be set to be called by the combat module that can be shared by the game client and the server.

[0091] In order to enable the game client and the server to obtain consistent random data, it is necessary to ensure that the game client and the server use the same random number seed. Therefore, in the embodiment of the present invention, a random number generator is also provided in the combat module. The random number generator is used to generate the same pseudo-random queue in the game client and the server to obtain random data in the same combat logic.

[0092] In simple terms, the random number generator is used to generate random number seeds distributed to the game client and server, and the random number seeds are used to generate the same pseudo-random queues in the game client and server, respectively, so as to obtain random combat values ​​corresponding to various combat skills. For example, random combat values ​​include but are not limited to: random damage values ​​when causing damage, random damage values ​​when causing critical hits, and random values ​​when generating buffs.

[0093] In this way, through the random number generator set in the combat module, it is possible to effectively avoid the problem of obtaining different random number queues based on the same random number seed when the front-end and back-end combat modules are developed in different languages, thereby further ensuring the data consistency between the game client and the server and improving the accuracy of the verification results.

[0094] In practical applications, the random number generator is implemented as a random number generator based on the Lua language, which is constructed using a linear congruential algorithm. Specifically, the random number generator in the combat module generated based on the target version of the Lua language can be implemented as follows: using the target version of the Lua language, a random number generator for generating random number seeds is constructed based on a linear congruential algorithm.

[0095] In fact, other random algorithms may be used to generate the random number seeds required by the combat module, and the present invention is not limited thereto, such as the Mersenne Twister method.

[0096] Furthermore, based on the combat behavior tree and the random number generator set above, the combat logic in the combat module is generated using the target version of Lua language according to the combat behavior tree and the random number generator.

[0097] Among them, the combat logic can be the logic related to any combat function in the game. For example, in the game, the logic related to the combat function of the player character, such as the logic of the use of the player's attack skills, the logic of the damage settlement based on the player's attack, the logic of the player's displacement, the logic of the combat settlement, etc. For another example, it can also be the logic related to the NPC combat function in the game, such as the monster AI logic, the logic of the damage settlement based on the monster's attack, the logic of the monster's movement, etc. The combat logic can also be the logic of player-to-player combat, the logic of combat settlement, etc. For example, the combat logic in the combat module includes but is not limited to: the combat logic with the monster NPC, the combat logic with other single players, and the team combat logic.

[0098] In practical applications, combat behavior trees and random number generators can be used to implement logic related to various combat functions.

[0099] It should be understood that the battle logic varies according to the game types and game settings, and therefore, it is necessary to maintain the battle module for processing the game data associated with the battle logic. For example, the battle module is periodically maintained, or the developer manually updates and maintains the battle module to ensure the accuracy of the game data processing results.

[0100] Finally, a combat module was built based on the combat behavior tree, random number generator, and combat logic.

[0101] Compared with the related art, in the above steps, a battle module connected between the game client and the server is constructed, so that the game client and the server can process the game data associated with the same battle logic through the battle module, thereby ensuring the consistency of the game data on both sides of the game client and the server. It can also effectively avoid the phenomenon of repeated development and maintenance on both sides of the game client and the server for the same battle logic, thereby improving the development and maintenance efficiency of the battle logic.

[0102] Based on the combat module described above, the following describes the interaction process between the game client, server, and combat module with specific examples:

[0103] In actual applications, optionally, the game client and server can be respectively configured with a calling interface to the combat module.

[0104] The calling interface is, for example, a logic frame calling interface and a verification interface. By configuring the corresponding calling interfaces for the game client and the server respectively, the data flows between the two devices and the combat module are made independent of each other. Thus, the server can verify whether the game client tampers with the game data, prevent cheating by using plug-ins, and ensure the fairness of the game.

[0105] Based on the above calling interface, in an embodiment of the present invention, an optional implementation method of providing game data associated with the same battle logic in the game to the game client and the server is as follows:

[0106] In response to a combat service call request to the combat module, the combat module processes game data associated with at least one frame of combat logic in the game client or server; and feeds back the processing result of the game data to the game client or server that issued the combat service call request through a calling interface, so that the game client or server executes at least one frame of combat logic.

[0107] Optionally, a battle cache queue is set in the battle module, so that the game data processing results calculated by the battle module are cached frame by frame in the battle cache queue, and synchronized to the game client and server through the battle cache queue. In this way, the game data on both sides can be cached in advance, reducing the delay caused by game data transmission, and further improving the fluency of the game.

[0108] The following describes the specific implementation methods of the above steps from both the game client and server sides.

[0109] In the game client, optionally, a calling interface is established between the game client and the battle module, and the calling interface is referred to as the first calling interface in the above embodiment. For example, a logic frame calling interface (i.e., the first calling interface) is set in the battle module for the game client to obtain battle logic-related data, and the logic frame calling method of the logic frame calling interface is sent to the game client, so that the game client sends a logic frame calling instruction to the battle module according to the issued logic frame calling method, so as to trigger the battle module to process the game data associated with the battle logic related to the game client side through the logic frame calling instruction.

[0110] Among them, the battle logic related to the game client side is, for example, battle skill release logic, character displacement logic and other battle behavior logic, based on which, the game data is, for example, battle effect data, such as battle skill effect data, displacement data. Alternatively, it can also be damage settlement logic, battle skill random effect logic and other battle result calculation logic, based on which, the game data is, for example, battle result data, such as battle damage data, player duel results, operation execution time point (such as the time point when the skill is triggered), random skill effect data.

[0111] Based on the first calling interface, in an optional embodiment, in the above steps, in response to the battle service calling request to the battle module, the battle module processes the game data associated with at least one frame of battle logic in the game client or server, which can be implemented as follows:

[0112] The combat module receives a combat logic frame acquisition request from the game client through a first calling interface established with the game client; the combat module determines a combat logic event to be implemented according to the logic frame calling instruction; and generates combat effect data corresponding to the combat logic event.

[0113] The battle logic frame acquisition request is used to instruct the battle module to obtain the processing result of the game data according to the battle function in the current game.

[0114] Optionally, before the above steps, the game client also responds to the combat service request triggered by the player and collects game data associated with at least one frame of combat logic in the game client, such as one or a combination of the following data: player data in the game scene, interactive object data, combat skill data, environmental attribute data, and a random number seed for generating random skill effect data.

[0115] Optionally, if the device that issues the combat service call request is a game client, the processing result of the game data includes combat effect data associated with at least one frame of combat logic, wherein the combat effect data is used to render at least one frame of combat effect in the game interface of the game client.

[0116] Optionally, after receiving the battle logic frame acquisition request from the game client, the battle module obtains game data processing results according to the battle function in the current game, for example including: battle effect data of the target control object in the current game executing the battle strategy.

[0117] Here, the combat effect data associated with at least one frame of combat logic provided to the game client includes one or a combination of the following: combat result data, skill effect data, combat damage data, displacement data, operation execution time point, and random skill effect data.

[0118] Further optionally, in the above steps, the processing results of the game data are fed back to the game client or server that issued the combat service call request through a calling interface, which can be implemented as follows: the combat effect data is packaged in a logical frame of a preset data format, and the logical frame of the preset data format is fed back to the game client through the first calling interface.

[0119] In this way, after the game client receives the combat effect data, it can render the corresponding combat effect in the game interface of the game client according to the time sequence of the logical frames.

[0120] Through the above steps, after the combat module receives the logic frame call instruction (such as a combat logic frame acquisition request) from the game client, it responds to the logic frame call instruction to generate a logic frame to be fed back, thereby sending the logic frame to the game client, so that the game client can render the corresponding combat effect in the game interface of the game client according to the logic frame.

[0121] In the server, optionally, a calling interface is established between the server and the battle module, and the calling interface is referred to as the second calling interface in the above embodiment. For example, a verification interface (i.e., the second calling interface) is set in the battle module for the server to obtain battle logic-related data, and the calling method of the verification interface is sent to the server, so that the server sends a verification interface calling instruction to the battle module according to the calling method of the verification interface, so as to trigger the battle module to process the game data associated with the battle logic related to the server side through the verification interface calling instruction. The verification interface calling instruction is, for example, a verification request.

[0122] Among them, the game data associated with the combat logic related to the server side (ie, at least one frame of combat logic) includes but is not limited to: key frame data, combat messages, and the first combat result reported by the game client.

[0123] In order to reduce the amount of data transmission and further improve the efficiency of data verification, in the embodiment of the present invention, the game client or the combat module can optionally select key frames from multiple logical frames and obtain key frame data. The key frame data includes but is not limited to: player data in the key frame, interactive object data, combat skill data, environmental attribute data, and random number seeds for generating random skill effect data.

[0124] In fact, the key frame can be set according to the combat behavior during the combat, such as the logic frame of issuing combat skills, the logic frame of causing damage, and the logic frame of causing critical strikes. Alternatively, it can be selected according to a preset period, such as selecting a key frame every 5ms.

[0125] Among them, the battle logic related to the server side is, for example, battle settlement logic, such as damage settlement logic, battle result calculation logic, etc. Based on this, the game data processing results fed back to the server are, for example, battle result data, such as battle damage data, player duel results.

[0126] Of course, in some embodiments, the combat module can also feed back other key data associated with the combat logic to the server side, such as the combat behavior type, the game characters participating in the combat, and the skill types released in the combat. This helps to adapt to various types of games and further improve the accuracy of the verification results.

[0127] Based on the above second calling interface, in an optional embodiment, if the device that issues the battle service calling request is a server, then in the above steps, processing the game data associated with at least one frame of battle logic in the game client or server through the battle module can be implemented as follows:

[0128] The battle module verifies whether the key frame data complies with the preset battle rules; the key frame data that complies with the preset battle rules is inserted into the battle message to calculate the second battle result; if the second battle result is consistent with the first battle result reported by the game client, an indication information is generated to indicate that the first battle result has passed the verification.

[0129] Among them, the second battle result generated by the server call here and the first battle result introduced above for feedback to the game client are both generated by the battle module based on the same battle logic. Therefore, the two data can be directly verified without cross-platform data conversion, which effectively avoids verification errors caused by data inconsistency (such as inconsistent data formats) and further ensures the accuracy of the verification results.

[0130] Through this step, the server verifies the first battle result reported by the game client through the called battle module. Specifically, first verify whether the key frame data meets the preset battle rules, and preliminarily verify the game data reported by the game client, for example, verify whether the skill use in the key frame data is reasonable (such as whether the preset thawing time has not been reached, or whether the player has the authority to issue the skill, etc.), and whether the damage data exceeds the preset fault tolerance range. Then, the key frame data that passes the initial verification (that is, the key frame data that meets the preset battle rules) is inserted into the battle message to calculate the second battle result. By judging whether the second battle result is consistent with the first battle result reported by the game client, the game data reported by the game client is verified twice. If the second battle result is consistent with the first battle result reported by the game client, it means that the secondary verification is passed. In this case, an indication information for indicating that the first battle result has passed the verification can be generated.

[0131] Furthermore, in the above steps, the processing result of the game data is fed back to the game client or server that issued the combat service call request by calling the interface, which can be implemented as follows:

[0132] Through the second calling interface between the combat module and the server, the instruction information is sent to the combat settlement module of the server.

[0133] In this way, the battle settlement module of the server can calculate the corresponding game rewards and send them to the game client.

[0134] In this embodiment, by constructing a battle module connected between the game client and the server, the game client and the server can process the game data associated with the same battle logic through the battle module, thereby ensuring the consistency of the game data on both sides of the game client and the server, and effectively avoiding verification errors caused by inconsistent game data. In addition, the battle module can also effectively avoid the phenomenon of repeated development and maintenance on both sides of the game client and the server for the same battle logic, thereby improving the development and maintenance efficiency of the battle logic and saving the development and maintenance costs of various battle logics.

[0135] In addition to the game data processing methods provided in the aforementioned embodiments, the present invention also provides an electronic device, which will be exemplarily described below.

[0136] Figure 3 1 is a schematic diagram of the structure of an electronic device provided by an exemplary embodiment of the present invention, and the electronic device can be used to execute the game data processing method described in the above embodiments. The electronic device can be implemented as a third-party device connected to the combat module, or any device in the game client and server connected to the combat module.

[0137] like Figure 3 As shown, the electronic device includes: a memory 301 , a processor 302 and a communication component 303 .

[0138] The memory 301 is used to store computer programs and can be configured to store various other data to support operations on the electronic device. Examples of such data include instructions for any application or method used to operate on the electronic device, such as game data, various game control instructions, etc.

[0139] The processor 302 is coupled to the memory 301 and is used to execute the computer program in the memory 301, so as to: obtain game data related to the current battle scene, wherein the game data includes one or more of player data, environmental data, and non-player controlled character NPC data; call a battle module matching the game data to return a game data processing result of executing corresponding battle logic processing on the game data in the current battle scene through the battle module; and display the battle effect corresponding to the game processing result in the game interface of the game client.

[0140] Further optionally, when the processor 302 calls the combat module that matches the game data to return the game data processing result of executing corresponding combat logic processing on the game data in the current combat scene through the combat module, it is specifically used to: determine the target combat module that matches the current combat scene according to the game data; call the target combat module through the calling interface of the target combat module to execute target combat logic processing on the game data in the current combat scene to generate the game data processing result; and receive the game data processing result fed back from the target combat module.

[0141] Further optionally, when the processor 302 determines the target combat module that matches the current combat scene according to the game data, it is specifically used to: determine the combat scene type corresponding to the current combat scene according to the player data, environment data and / or NPC data in the game data; select a corresponding target combat behavior tree from a plurality of pre-built combat behavior trees according to the combat scene type, and select a target random generator from a plurality of pre-built random generators; select the target combat module composed of the target combat behavior tree and the target random number generator from a plurality of pre-built combat modules.

[0142] Further optionally, when the processor 302 calls the battle module that matches the game data to return the game data processing result of executing corresponding battle logic processing on the game data in the current battle scene through the battle module, it is specifically used to: the game client specifies the target battle module that matches the current battle scene from multiple pre-built battle modules through the battle scene type identifier; calls the target battle module through the calling interface of the target battle module to execute target battle logic processing on the game data in the current battle scene to generate the game data processing result; and receives the game data processing result fed back from the target battle module.

[0143] Further optionally, the target combat module is provided with a first calling interface corresponding to the game client. When the processor 302 calls the target combat module through the calling interface of the target combat module to perform the target combat logic processing on the game data in the current combat scene and generate the game data processing result, it is specifically used to: call the target combat module through the first calling interface in a logical frame manner to perform the target combat logic on the current game data to obtain the game data processing result in the next logical frame.

[0144] Further optionally, the processor 302 is also used to: send a verification message of the game data processing result to the server, so that the server calls the target combat module to verify whether the game data processing result complies with preset rules; receive the verification result returned by the server to execute the game processing logic corresponding to the verification result.

[0145] Further optionally, the processor 302 sends a verification message of the game data processing result to the server, specifically for: selecting a corresponding verification time from a plurality of pre-set verification times according to the combat mode of the current combat scene, and sending the verification message of the game data processing result to the server at the corresponding verification time; wherein the plurality of verification times include any one or more of a preset time interval, a random time interval, a set time period after a skill is released, and a set time period after a combat ends.

[0146] Further optionally, when the processor 302 constructs the combat module in the following manner, it is specifically used to: determine the game client and server to which the combat module is to be connected; determine the target version of Lua language that is compatible with the respective runtime libraries of the game client and the server; based on the game data, use the target version of Lua language to generate a combat behavior tree and a random number generator in the target combat module; wherein the combat behavior tree is used to provide the same combat strategy to the game client and the server, and the random number generator is used to generate the same pseudo-random queue in the game client and the server to obtain random data in the same combat logic; according to the combat behavior tree and the random number generator, use the target version of Lua language to generate the combat logic in the combat module; and construct the combat module based on the combat behavior tree, the random number generator, and the combat logic.

[0147] Further optionally, the processor 302 is also used to: modify the processing precision of the game data in the respective runtime libraries of the game client and the server, so that the number of bits of the processing results of the same game data in the game client and the server is the same.

[0148] Further optionally, when the processor 302 generates the combat behavior tree and the random number generator in the target combat module based on the game data using the target version of Lua language, it is specifically used to: determine the combat modes corresponding to each of the multiple combat scenes; and generate combat behavior trees and random number generators matching each of the multiple combat modules using the target version of Lua language according to the combat modes corresponding to each of the multiple combat scenes.

[0149] Further optionally, the processor 302 is also used to: set a battle cache queue in the battle module; cache the game data processing results calculated by the battle module into the battle cache queue frame by frame, and synchronize them to the game client through the battle cache queue.

[0150] Further optionally, when the processor 302 displays the combat effect corresponding to the game processing result in the game interface of the game client, it is specifically used to: receive the game data processing result of the current logical frame; and render the combat effect corresponding to the game data processing result in the current logical frame in the game interface of the game client.

[0151] like Figure 3 As shown, the electronic device also includes: a display component 304, a power component 305, an audio component 306 and other components. Figure 3 Only some components are shown schematically, which does not mean that the electronic device only includes Figure 3 Components shown.

[0152] Among them, the memory 301 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0153] Among them, the communication component 303 is configured to facilitate wired or wireless communication between the device where the communication component is located and other devices. The device where the communication component is located can access a wireless network based on a communication standard, such as WiFi, 2G, 3G, 4G or 5G, or a combination thereof. In an exemplary embodiment, the communication component receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component can be implemented based on near field communication (NFC) technology, radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0154] The display component 304 includes a screen, which may include a liquid crystal display component (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundaries of a touch or slide action, but also detect the duration and pressure associated with the touch or slide operation.

[0155] The power supply component 305 provides power to various components of the device where the power supply component is located. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device where the power supply component is located.

[0156] Correspondingly, an embodiment of the present invention further provides a computer-readable storage medium storing a computer program, and when the computer program is executed, each step that can be executed by an electronic device in the above method embodiment can be implemented.

[0157] This embodiment also provides a game data processing device, such as Figure 4 As shown, the device includes: an acquisition module 401, a calling module 402 and a display module 403.

[0158] Among them, the acquisition module 401 is used to obtain game data related to the current battle scene, and the game data includes one or more of player data, environmental data, and non-player controlled character NPC data; the calling module 402 is used to call the battle module matching the game data, so as to return the game data processing results of executing corresponding battle logic processing on the game data in the current battle scene through the battle module; the display module 403 is used to display the battle effect corresponding to the game processing result in the game interface of the game client.

[0159] Further optionally, when calling the combat module that matches the game data to return the game data processing result of executing corresponding combat logic processing on the game data in the current combat scene through the combat module, the calling module 402 is specifically used to: determine the target combat module that matches the current combat scene according to the game data; call the target combat module through the calling interface of the target combat module to execute target combat logic processing on the game data in the current combat scene to generate the game data processing result; and receive the game data processing result fed back from the target combat module.

[0160] Further optionally, when the calling module 402 determines the target combat module that matches the current combat scene according to the game data, it is specifically used to: determine the combat scene type corresponding to the current combat scene according to the player data, environment data and / or NPC data in the game data; select a corresponding target combat behavior tree from a plurality of pre-built combat behavior trees according to the combat scene type, and select a target random generator from a plurality of pre-built random generators; select the target combat module composed of the target combat behavior tree and the target random number generator from a plurality of pre-built combat modules.

[0161] Further optionally, when calling the battle module that matches the game data to return the game data processing result of executing corresponding battle logic processing on the game data in the current battle scene through the battle module, the calling module 402 is specifically used to: the game client specifies the target battle module that matches the current battle scene from multiple pre-built battle modules through the battle scene type identifier; calls the target battle module through the calling interface of the target battle module to execute target battle logic processing on the game data in the current battle scene to generate the game data processing result; and receives the game data processing result fed back from the target battle module.

[0162] Further optionally, the target combat module is provided with a first calling interface corresponding to the game client. When the calling module 402 calls the target combat module through the calling interface of the target combat module to perform the target combat logic processing on the game data in the current combat scene and generate the game data processing result, it is specifically used to: through the first calling interface, call the target combat module in a logical frame manner to perform the target combat logic on the current game data to obtain the game data processing result in the next logical frame.

[0163] Further optionally, the display module 403 is also used to: send a verification message of the game data processing result to the server, so that the server calls the target combat module to verify whether the game data processing result complies with the preset rules; receive the verification result returned by the server to execute the game processing logic corresponding to the verification result.

[0164] Further optionally, when the display module 403 sends a verification message of the game data processing result to the server, it is specifically used to: select a corresponding verification time from a plurality of pre-set verification times according to the combat mode of the current combat scene, and send the verification message of the game data processing result to the server at the corresponding verification time; wherein the plurality of verification times include any one or more of a preset time interval, a random time interval, a set time period after the skill is released, and a set time period after the battle ends.

[0165] Further optionally, when the calling module 402 constructs the combat module in the following manner, it is specifically used to: determine the game client and server to which the combat module is to be connected; determine the target version of Lua language that is compatible with the respective runtime libraries of the game client and the server; based on the game data, use the target version of Lua language to generate a combat behavior tree and a random number generator in the target combat module; wherein the combat behavior tree is used to provide the same combat strategy to the game client and the server, and the random number generator is used to generate the same pseudo-random queue in the game client and the server to obtain random data in the same combat logic; according to the combat behavior tree and the random number generator, use the target version of Lua language to generate the combat logic in the combat module; and construct the combat module based on the combat behavior tree, the random number generator, and the combat logic.

[0166] Further optionally, the calling module 402 is also used to modify the processing precision of the game data in the respective runtime libraries of the game client and the server so that the number of bits of the same game data processing results in the game client and the server is the same.

[0167] Further optionally, when the calling module 402 generates the combat behavior tree and the random number generator in the target combat module using the target version of Lua language based on the game data, it is specifically used to: determine the combat modes corresponding to each of the multiple combat scenes; and generate combat behavior trees and random number generators matching each of the multiple combat modules using the target version of Lua language according to the combat modes corresponding to each of the multiple combat scenes.

[0168] Further optionally, the calling module 402 is also used to: set a battle cache queue in the battle module; cache the game data processing results calculated by the battle module into the battle cache queue frame by frame, and synchronize them to the game client through the battle cache queue.

[0169] Further optionally, when the display module 403 displays the combat effect corresponding to the game processing result in the game interface of the game client, it is specifically used to: receive the game data processing result of the current logical frame; and render the combat effect corresponding to the game data processing result in the current logical frame in the game interface of the game client.

[0170] Correspondingly, an embodiment of the present invention further provides a computer-readable storage medium storing a computer program, and when the computer program is executed, each step that can be executed by an electronic device in the above method embodiment can be implemented.

[0171] The device embodiments described above are merely illustrative, wherein the modules described as separate components may or may not be physically separated. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present embodiment. Those of ordinary skill in the art may understand and implement the present invention without creative effort.

[0172] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by adding a necessary general hardware platform, and of course can also be implemented by combining hardware and software. Based on such an understanding, the above technical solution is essentially or the part that contributes to the present invention can be embodied in the form of a computer product, and the present invention can be in the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0173] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for processing game data, characterized in that: Applicable to a game client, the method includes: Obtaining game data related to the current battle scene, wherein the game data includes one or more of player data, environment data, and non-player controlled character NPC data; Calling a battle module matching the game data to return a game data processing result of executing corresponding battle logic processing on the game data in the current battle scene through the battle module, wherein the battle module is set in an independent third-party device, and the battle module adopts a target version of Lua language compatible with the respective runtime libraries of the game client and the server, and the server is used to verify the game data processing result; The combat effect corresponding to the game processing result is displayed in the game interface of the game client.

2. The method according to claim 1, characterized in that The calling of the battle module matching the game data to return the game data processing result of executing the corresponding battle logic processing on the game data in the current battle scene through the battle module includes: Determine a target combat module matching the current combat scene according to the game data; Calling the target combat module through the calling interface of the target combat module to perform target combat logic processing on the game data in the current combat scene to generate the game data processing result; Receive the game data processing result fed back from the target combat module.

3. The method according to claim 2, characterized in that The step of determining a target combat module matching the current combat scene according to the game data includes: Determining a battle scene type corresponding to the current battle scene according to player data, environment data and / or NPC data in the game data; Select a corresponding target combat behavior tree from a plurality of pre-built combat behavior trees according to the combat scene type, and select a target random generator from a plurality of pre-built random generators; The target combat module consisting of the target combat behavior tree and the target random number generator is selected from a plurality of pre-constructed combat modules.

4. The method according to claim 1, characterized in that The calling of the battle module matching the game data to return the game data processing result of executing the corresponding battle logic processing on the game data in the current battle scene through the battle module includes: The game client specifies a target combat module matching the current combat scene from among a plurality of pre-built combat modules through a combat scene type identifier; Calling the target combat module through the calling interface of the target combat module to perform target combat logic processing on the game data in the current combat scene to generate the game data processing result; Receive the game data processing result fed back from the target combat module.

5. The method according to claim 2 or 4, characterized in that: The target combat module is provided with a first calling interface corresponding to the game client; The calling interface of the target combat module is used to call the target combat module to perform target combat logic processing on the game data in the current combat scene to generate the game data processing result, including: Through the first calling interface, the target combat module is called in a logical frame manner to perform the target combat logic processing on the current game data to obtain the game data processing result in the next logical frame.

6. The method according to claim 1, characterized in that Also includes: Sending a verification message of the game data processing result to the server, so that the server calls the combat module to verify whether the game data processing result complies with the preset rules; Receive the verification result returned by the server to execute the game processing logic corresponding to the verification result.

7. The method according to claim 6, characterized in that The sending a verification message of the game data processing result to the server specifically includes: According to the battle mode of the current battle scene, a corresponding verification time is selected from a plurality of pre-set verification times, and the verification message of the game data processing result is sent to the server at the corresponding verification time; The multiple verification opportunities include any one or more of a preset time interval, a random time interval, a set time period after a skill is released, and a set time period after a battle ends.

8. The method according to claim 6, characterized in that The verification result returned by the server includes: a verification result obtained by the server through collaborative verification of the game data processing result and the collaborative game data processing result; The game data processing result and the collaborative game data processing result respectively correspond to at least two combat entities in the current combat scene, and the combat entities include a player entity and / or an NPC entity.

9. The method according to claim 1, characterized in that: Combat modules are constructed by: Determine the game client and server to which the combat module is to be connected; Determine the target version of Lua language that is compatible with the game client and server runtime libraries; Based on the game data, a combat behavior tree and a random number generator in the target combat module are generated using the target version of Lua language; wherein the combat behavior tree is used to provide the same combat strategy to the game client and the server, and the random number generator is used to generate the same pseudo-random queue in the game client and the server to obtain random data in the same combat logic; Generate the combat logic in the combat module using the target version of Lua language according to the combat behavior tree and the random number generator; The combat module is constructed based on the combat behavior tree, the random number generator, and the combat logic.

10. The method according to claim 9, characterized in that Also includes: Modify the processing precision of game data in the game client and server's respective runtime libraries so that the number of bits in the processing results of the same game data in the game client and server is the same.

11. The method according to claim 9, characterized in that The step of generating a combat behavior tree and a random number generator in the target combat module based on the game data using the target version of Lua language includes: Determine the combat modes corresponding to each of the multiple combat scenarios; According to the combat modes corresponding to the multiple combat scenes, the target version of Lua language is used to generate combat behavior trees and random number generators that match the multiple combat modules.

12. An electronic device, characterized in that: include: Memory and processor; The memory is used to store one or more computer instructions; The processor is configured to execute the one or more computer instructions to: perform the steps in the method according to any one of claims 1-11.

13. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed, the steps in the method according to any one of claims 1 to 11 can be implemented.

Images