Settlement control method, apparatus, and electronic device

Abstract

The application provides a settlement control method and device and electronic equipment, when a target game battle including multiple battle rounds starts, a game main thread sends target game data required for starting the target game battle to a service process; the service process starts the target game battle based on the target game data, for each battle round, if the current battle round starts, a client instruction sent by the game main thread is received, and based on the client instruction and a settlement result of a last battle round of the current battle round, settlement processing is performed on the current battle round to obtain a settlement result of the current battle round; the settlement result of the last battle round is sent to the game main thread, so that the game main thread performs battle settlement on the target game battle. In this way, the game battle related logic is realized by adding the service process, thereby reducing the overhead and load of the game server logic main thread, and effectively avoiding the game server lag.

Description

Technical Field

[0001] This invention relates to the field of game design technology, and in particular to a settlement control method, device, and electronic device. Background Technology

[0002] The combat system is a crucial component of turn-based massively multiplayer online games (MMORPGs), and its related business logic code executes within the game's main thread. As combat mechanics and skills become increasingly complex, the overhead of the combat system grows, leading to increased overhead on the game's main thread. This can potentially cause server lag, impacting player experience and limiting the maximum number of players that can be played on a single server. Summary of the Invention

[0003] The purpose of this invention is to provide a settlement control method, device, and electronic device to reduce the overhead of the game's main thread and avoid game server lag.

[0004] In a first aspect, the present invention provides a settlement control method, which is applied to an electronic device in which a service process resides; the service process is communicatively connected to the main game thread, and the main game thread stores game data; the method includes: receiving target game data sent by the main game thread through the service process, which is required to start a target game battle; wherein, the target game battle includes at least one battle round; starting the target game battle based on the target game data; for each battle round, if the current battle round has started, receiving a client instruction sent by the main game thread, and performing settlement processing on the current battle round based on the client instruction and the settlement result of the previous battle round, to obtain the settlement result of the current battle round; and sending the settlement result of the last battle round in the at least one battle round to the main game thread, so that the main game thread performs battle settlement on the target game battle.

[0005] Secondly, the present invention provides a settlement control device, which is installed in an electronic device where a service process resides; the service process is communicatively connected to the main game thread, and the main game thread stores game data; the device includes: a data receiving module, used to receive target game data sent by the main game thread through the service process, which is required to start a target game battle; wherein, the target game battle includes at least one battle round; a battle initiation module, used to start the target game battle based on the target game data; a round settlement module, used to, for a battle round, if the current battle round has started, receive a client instruction sent by the main game thread, and perform settlement processing on the current battle round based on the client instruction and the settlement result of the previous battle round, to obtain the settlement result of the current battle round; and a battle settlement module, used to send the settlement result of the last battle round in at least one battle round to the main game thread, so that the main game thread performs battle settlement on the target game battle.

[0006] Thirdly, the present invention provides an electronic device including a processor and a memory, the memory storing machine-executable instructions that can be executed by the processor, the processor executing the machine-executable instructions to implement the above-described settlement control method.

[0007] Fourthly, the present invention provides a computer-readable storage medium storing computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the above-described settlement control method.

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

[0009] This invention provides a settlement control method, apparatus, and electronic device. When a target game battle, comprising multiple battle rounds, begins, the game's main thread sends the target game data required to initiate the battle to a service process. The service process, based on the target game data, initiates the target game battle. For each battle round, if the current battle round begins, the service process receives a client instruction from the game's main thread and, based on the client instruction and the settlement result of the previous battle round, performs settlement processing on the current battle round to obtain the settlement result. Then, the settlement result of the last battle round of the target game battle is sent to the game's main thread, enabling the main thread to perform battle settlement. This method reduces the overhead and load on the game server's main thread by adding a service process to implement the game battle-related logic, effectively preventing game server lag.

[0010] Other features and advantages of the invention will be set forth in the following description, or some features and advantages may be inferred from the description or determined without doubt, or may be learned by practicing the techniques described above.

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

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

[0013] Figure 1 A flowchart of a settlement control method provided in an embodiment of the present invention;

[0014] Figure 2 A flowchart of another settlement control method provided in an embodiment of the present invention;

[0015] Figure 3 This is a schematic diagram of the structure of a settlement control device provided in an embodiment of the present invention;

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

[0017] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0018] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0019] In related technologies, turn-based MMO (Massive Multiplayer Online) game servers all adopt a single-process, multi-threaded, single-server architecture, and the business logic in the game is executed in the main thread.

[0020] The combat system is a crucial component of turn-based MMO games, and its related business logic code executes within the game's main thread. As combat mechanics and skills become increasingly complex, the overhead of the combat system grows, leading to increased overhead on the game's main thread. This can result in increased load on the game server's main thread and server lag, negatively impacting the player experience. Furthermore, because the combat system can only execute on the main thread, it limits the scalability of the game server and the maximum number of players that can be played per server.

[0021] To address the aforementioned issues, embodiments of the present invention also provide a settlement control method, apparatus, and electronic device, which can be applied to multi-round battle scenarios in games.

[0022] To facilitate understanding of the embodiments of the present invention, a detailed description of a settlement control method, apparatus, and electronic device disclosed in the embodiments of the present invention will be provided first. This method is applied to an electronic device where a service process resides; the service process is communicatively connected to the game's main thread, and the game's main thread stores game data; such as Figure 1 As shown, the method includes the following specific steps:

[0023] Step S102: Receive target game data sent by the game's main thread through the service process, which is required to start the target game battle; wherein the target game battle includes at least one battle round.

[0024] In practical implementation, since MMO game servers in related technologies use local files to store game data, modifying data in the service process requires notifying the game's main thread (also known as the game process) via RPC (Remote Procedure Call). Furthermore, the data needed by the service process must also be obtained from the game's main thread via RPC. Therefore, this invention encapsulates an interface that facilitates data synchronization between the game's main thread and the service process. In practical applications, the game's main thread and the service process can communicate directly using TCP (Transmission Control Protocol). This is primarily because if future expansion is needed, the service process can be easily deployed to independent electronic devices, allowing multiple game main threads to share the same service process. Currently, the service process is deployed directly on the game server, rather than on independent electronic devices, because the current external server machines are multi-core, allowing for full utilization.

[0025] When a game battle is initiated in the main game thread, the game data required to start the battle needs to be sent to the service process. This game data sent by the main game thread to the service process includes at least: player data, pet data, monster data, and other data needed for the battle. Specifically, each game battle consists of at least one round.

[0026] Step S104: Based on the target game data, start the target game battle.

[0027] After the service process receives the game data required to start the target game battle, it will construct the relevant data in the service process to start the target game battle, that is, initialize the target game battle.

[0028] Step S106: For the above-mentioned battle round, if the current battle round begins, receive the client instruction sent by the game's main thread, and perform settlement processing on the current battle round based on the client instruction and the settlement result of the previous battle round to obtain the settlement result of the current battle round.

[0029] From the start to the end of the target game battle within the service process, all logic is executed within the service process. From the first to the last battle round, before each round begins, it's necessary to determine if the target game battle has ended. If not, the current battle round begins, and the service process receives client commands from the game clients participating in the current round via the game's main thread. Upon receiving the client commands, the service process performs a settlement process based on the client commands and the results of the previous battle round, obtaining the current battle's settlement result. This settlement result may include the winning and losing data, as well as the execution results corresponding to the client commands.

[0030] In practice, the settlement results also need to be sent to the game's main thread. Upon receiving the results, the main thread forwards them to the game clients, which then display the settlement results, thus updating the game screen corresponding to the target game battle. Once all game clients have updated their screens, the system waits for the current and next battle rounds to begin.

[0031] Step S108: Send the settlement result of the last battle round in at least one battle round to the game's main thread so that the game's main thread can perform battle settlement for the target game battle.

[0032] After the target game battle ends, the result of the last battle round in the target game battle can be sent to the main game thread as the battle result. After receiving the battle result, the main game thread will perform the battle settlement and reward distribution logic based on the battle result.

[0033] This invention adds a general service process and implements the battle process as a type of service process. To avoid asynchronous data access during battle, at the start of the battle, the game engine packages the battle-related data for both sides into a structure, and then sends the data in this structure to the battle process. Within the battle process, a new battle is constructed. After the battle ends, the relevant data is sent back to the game's main thread, where the results are calculated. The advantage of this is that all data accessed during battle is converted to accessing data within the battle structure, eliminating the need for asynchronous access to data in the game's main thread. In other words, the start and end of the battle still occur within the game's main process, while the intermediate battle command calculations are executed within the battle process itself. For battle command-related data, such as using items or summoning pets, the necessary data for calculation can be obtained from the game's main thread before the command calculation for that round. This approach keeps the data access method for battle command calculations completely unchanged; it's all synchronous operation and does not affect the original development efficiency.

[0034] This invention provides a settlement control method. When a target game battle, comprising multiple battle rounds, begins, the game's main thread sends the target game data required to initiate the battle to a service process. The service process then initiates the battle based on this data. For each battle round, if the current round begins, the service process receives a client instruction from the game's main thread and performs settlement processing on the current round based on the client instruction and the settlement result of the previous round. Finally, the settlement result of the last battle round of the target game battle is sent back to the game's main thread, enabling the main thread to perform battle settlement. This method reduces the overhead and load on the game server's main thread by adding a service process to implement the game battle-related logic, effectively preventing game server lag.

[0035] This invention also provides another settlement control method, which is applied to a server process. This method is implemented based on the above embodiments. The method focuses on describing the specific process of initiating a target game battle based on target game data (implemented through steps S204-S206 below), and the specific process of receiving client instructions sent by the game's main thread at the start of the current battle round, and performing settlement processing on the current battle round based on the client instructions and the settlement result of the previous battle round to obtain the settlement result of the current battle round (implemented through steps S208-S218 below). Figure 2 As shown, the method includes the following specific steps:

[0036] Step S202: Receive target game data sent by the game's main thread, which is required to start the target game battle; wherein the target game battle includes at least one battle round.

[0037] When the main game thread initiates a battle, it needs to send the target game data required to start the battle to the service process. After receiving the data, the service process constructs the relevant data in the battle process to begin the battle. Specifically, the data that needs to be sent to the service process includes at least player data, pet data, monster data, and other data required for the battle. Among them, player data includes various data such as player appearance, level, sect, health, magic, costumes, magic items, meridians, physical defense, magic defense, transformation cards, and weapons; pet data includes various data such as pet type, dye, health, physical attack, magic attack, and skill list; monster data includes pet-related data as well as data such as behavior tree number; other data in the battle includes various data such as battle type, captain IDs of both sides, maximum number of rounds, formation type and formation level of both sides.

[0038] Step S204: Based on the target game data, construct the various combat attributes required for the combat units in the target game battle, and obtain the construction result; wherein, the combat units include virtual objects and virtual monsters in the target game battle.

[0039] After receiving the target game data, the service process constructs the various combat attributes required by the combat units based on the received data. These attributes can include physical attack, magical attack, defense, physical critical hit rate, magical critical hit rate, and in-game appearance and costumes. Once the service process has constructed the necessary combat attributes for the combat units in the target game, the game battle can begin within the service process. These combat units include entities such as matchmakers and virtual monsters.

[0040] In practical applications, during the construction of various combat attributes required for combat units in a target game battle, if the target game data does not contain the first game data required for constructing the first combat attribute, a data retrieval request for the first game data is sent to the game's main thread, causing the main thread to return the first game data. The aforementioned first combat attribute can be any type of combat attribute. Since there are many combat attributes in a game, but not every combat unit possesses all of them, and some game battles require certain data while others do not, for example, virtual monsters have behavior tree information, but player units (also called virtual objects) do not have corresponding data. Therefore, this invention implements on-demand data transmission, sending only the required data to reduce the amount of data transmitted.

[0041] Furthermore, the data sent in this invention is configurable; subsequent data to be sent can be configured without additional processing. For example, some gameplay combat modes have their own specific data, such as the level number. In practical applications, game combat may include operations such as feeding medicine and summoning pets. The data required for these operations, such as the type and attributes of the medicine used, is only retrieved from the game's main thread when actually needed. This reduces the amount of data sent at the start of a game combat session.

[0042] Step S206: Based on the construction results, start the target game battle.

[0043] Once a game battle begins in the service process, all logic is executed within that service process until it ends. This may require data from the main game thread, such as for actions like consuming potions. All data needed by combat units is retrieved in batches from the main game thread before executing the turn's commands, rather than each unit requesting data individually. This reduces data communication overhead. Furthermore, if the service process has cached data locally, such as combat unit skills, physical and magical attack data, this data is already cached within the service process and does not need to be requested again from the battle process.

[0044] Step S208: At the start of the current battle round, determine whether the target game battle has ended; if not, proceed to step S210; otherwise, proceed to step S218.

[0045] In practice, the current battle round can be any battle round in the target game, but the battle rounds in the target game are counted sequentially from start to finish, with each round being considered the current battle round. The criteria for determining the end of the aforementioned battle in the target game can be determined according to the game rules. For example, all the opponent's virtual objects may be down and dead, or the maximum number of battle rounds may have been reached. Depending on the gameplay, there may be different ways to end the battle.

[0046] Step S210: Receive client instructions sent by the game's main thread; wherein, the client instructions are sent by the client participating in the current battle round to the game's main thread.

[0047] The aforementioned client commands contain the player's actions regarding the combat units included in the current combat round.

[0048] Step S212: Determine whether client instructions sent by each client participating in the current battle round have been received; if received, perform settlement processing on the current battle round based on the client instructions and the settlement result of the previous battle round to obtain the settlement result of the current battle round.

[0049] In the specific implementation, it is necessary to determine whether all clients have completed their actions in the current battle round or whether the current battle round has timed out. If all clients have completed their actions or the timeout has occurred, the current battle round is settled based on the client instructions and the settlement result of the previous battle round, yielding the result for the current battle round. If some clients have not completed their actions and the current battle round has not timed out, a polling check is performed, that is, all combat units are iterated one by one to see if all combat units have completed their actions (taken action), i.e., all combat units have issued instructions. If so, the current battle round is settled.

[0050] Step S214: The settlement result of the current battle round is sent to each client participating in the current battle round through the main game thread, so that the client updates the game screen of the target game battle based on the settlement result of the current battle round.

[0051] In game combat, data that needs to be synchronized to the client is forwarded through the game's main thread. This synchronized data includes information such as the appearance, color scheme, and weapon details of combat units. The reason for this is that if a dual-link approach were used, where the client directly connects to the server process, it would require client-side modifications. If the client involves modifications to the game engine, this approach is completely unacceptable because our client-side full-package update policy does not allow forced updates. Furthermore, communication between the client and the game's main thread already uses network threads, and network-related overhead in the main thread is very low. Additionally, the dual-link approach would need to consider combat timing and other issues. Therefore, we currently use the game's main thread forwarding method instead of a direct connection to the server process.

[0052] Step S216: If the game screen of each client has been updated, or the update time exceeds the preset time threshold, wait for the next battle round of the current battle round to begin. If the next battle round begins, take the next battle round as the new current battle round and execute step S208.

[0053] The aforementioned preset time threshold can be set according to development needs; for example, it can be set to 20 seconds or 1 minute. In practical implementation, if all clients participating in the current battle round have completed the game screen update, or if the update time exceeds the preset time threshold, then the game waits for the start of the next battle round or the end of the battle. If, without exceeding the preset time threshold, there are clients participating in the current battle round that have not completed the game screen update, then a polling check is performed, that is, all combat units are iterated through one by one to see if all combat units have completed the update.

[0054] Step S218: Send the settlement result of the last battle round in at least one battle round to the game's main thread so that the game's main thread can perform battle settlement for the target game battle.

[0055] In a practical implementation, step S218 above can be achieved through the following steps 10-11:

[0056] Step 10: Determine the battle result of the target game battle based on the settlement result of the last battle round in at least one battle round.

[0057] Step 11: Send the battle results to the game's main thread so that the main thread can perform settlement processing on the target game battle based on the battle results, obtain the battle settlement results, and distribute battle rewards based on the battle settlement results.

[0058] In practice, the logic related to battle settlement and reward distribution is executed in the main game thread. This is because there is a large amount of data access and modification during the settlement process. This data includes battle round data, number of divine blessings, and data on the winning side. In addition, the original gameplay had a large number of battle end callback functions, which contained a lot of logic calculations and data operations coupled together. After the battle reward settlement is performed in the main game thread, these logics do not need to be modified.

[0059] Furthermore, to ensure stability, this invention allows for the coexistence of both the old and new combat systems, and includes disaster recovery features, such as handling abnormal service process exits and restarts. New game battles can automatically switch between the two combat systems.

[0060] The aforementioned settlement control method can transfer the execution of the combat system from the main thread of the game server to other processes, reducing the overhead and load on the main thread of the game server. At the same time, the service processes in this method can be horizontally scaled, improving the scalability and system load limit of the game server system, thereby increasing the maximum number of online players on the game server.

[0061] Based on the above method embodiments, this invention also provides a settlement control device, which is installed in an electronic device where the service process resides; the service process is communicatively connected to the game's main thread, and the game's main thread stores game data; such as Figure 3 As shown, the device includes:

[0062] The data receiving module 30 is used to receive target game data sent by the game's main thread through the service process, which is required to start the target game battle; wherein the target game battle includes at least one battle round.

[0063] Battle activation module 31 is used to activate the target game battle based on the target game data.

[0064] The round settlement module 32 is used to receive client instructions sent by the game's main thread when the current battle round begins, and to perform settlement processing on the current battle round based on the client instructions and the settlement result of the previous battle round, so as to obtain the settlement result of the current battle round.

[0065] The battle settlement module 33 is used to send the settlement result of the last battle round in at least one battle round to the game's main thread so that the game's main thread can perform battle settlement on the target game battle.

[0066] The aforementioned settlement control device, when a target game battle comprising multiple battle rounds begins, sends the target game data required to initiate the battle to the service process via the game's main thread. The service process then initiates the battle based on this data. For each battle round, if the current round begins, the service process receives client instructions from the game's main thread and performs settlement processing based on these instructions and the settlement result of the previous round, obtaining the current round's settlement result. Finally, the settlement result of the last battle round of the target game battle is sent back to the game's main thread, enabling the main thread to perform the battle settlement. This method reduces the overhead and load on the game server's main thread by adding a service process to handle the game battle logic, effectively preventing game server lag.

[0067] Specifically, the aforementioned battle initiation module 31 is used to: construct various combat attributes required by combat units in the target game battle based on the target game data, and obtain the construction result; wherein, the combat units include virtual objects and virtual monsters in the target game battle; and initiate the target game battle based on the construction result.

[0068] In the specific implementation, during the process of constructing the various combat attributes required for combat units in the target game battle, if the target game data does not contain the first game data required for constructing the first combat attribute, a data retrieval request for the first game data is sent to the game main thread so that the game main thread can return the first game data.

[0069] Furthermore, the aforementioned round settlement module 32 is also used to: determine whether the target game battle has ended at the start of the current battle round; if the target game battle has not ended, receive client instructions sent by the game's main thread; wherein, the client instructions are sent by the clients participating in the current battle round to the game's main thread; determine whether client instructions sent by each client participating in the current battle round have been received; if received, perform settlement processing on the current battle round based on the client instructions and the settlement result of the previous battle round, and obtain the settlement result of the current battle round.

[0070] Furthermore, if the target game battle ends, the settlement result of the last battle round in at least one battle round will be sent to the game's main thread so that the game's main thread can perform battle settlement for the target game battle.

[0071] In its specific implementation, the aforementioned device further includes a result sending module, used to: perform settlement processing on the current battle round based on client instructions and the settlement result of the previous battle round, and after obtaining the settlement result of the current battle round, send the settlement result of the current battle round to each client participating in the current battle round through the game's main thread, so that the client updates the game screen of the target game battle based on the settlement result of the current battle round; if the game screen update of each client is completed, or the update time exceeds a preset time threshold, wait for the start of the next battle round of the current battle round; if the next battle round starts, take the next battle round as the new current battle round, and continue to execute the step of determining whether the target game battle has ended at the start of the current battle round, until the settlement of the last battle round in at least one battle round is completed.

[0072] Furthermore, the aforementioned battle settlement module 33 is used to: determine the battle result of the target game battle based on the settlement result of the last battle round in at least one battle round; send the battle result to the game main thread so that the game main thread can perform settlement processing on the target game battle based on the battle result, obtain the battle settlement result, and distribute battle rewards based on the battle settlement result.

[0073] The settlement control device provided in this embodiment of the invention has the same implementation principle and technical effect as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0074] This invention also provides an electronic device, such as... Figure 4 As shown, the electronic device includes a processor and a memory. The memory stores machine-executable instructions that can be executed by the processor, which executes the machine-executable instructions to implement the above-described settlement control method.

[0075] Specifically, the aforementioned settlement control method is applied to the electronic device where the service process resides; the service process is communicatively connected to the game's main thread, which stores game data; the settlement control method includes: receiving target game data sent by the game's main thread to initiate a target game battle through the service process; wherein the target game battle includes at least one battle round; initiating the target game battle based on the target game data; for each battle round, if the current battle round has started, receiving a client instruction sent by the game's main thread, and performing settlement processing on the current battle round based on the client instruction and the settlement result of the previous battle round to obtain the settlement result of the current battle round; and sending the settlement result of the last battle round in at least one battle round to the game's main thread so that the game's main thread performs battle settlement for the target game battle.

[0076] The aforementioned settlement control method reduces the overhead and load on the game server's main logic thread by adding a service process to implement the game's combat-related logic, thereby effectively preventing game server lag.

[0077] In an optional embodiment, the step of initiating a target game battle based on target game data includes: constructing various combat attributes required for combat units in the target game battle according to the target game data, and obtaining a construction result; wherein, combat units include virtual objects and virtual monsters in the target game battle; and initiating the target game battle according to the construction result.

[0078] In an optional embodiment, during the process of constructing various combat attributes required for combat units in the target game battle, if the target game data does not contain the first game data required for constructing the first combat attribute, a data acquisition request for the first game data is sent to the game main thread so that the game main thread returns the first game data.

[0079] In an optional embodiment, the steps described above, which involve receiving client instructions sent by the game's main thread at the start of the current battle round and performing settlement processing on the current battle round based on the client instructions and the settlement result of the previous battle round, to obtain the settlement result of the current battle round, include: determining whether the target game battle has ended at the start of the current battle round; if the target game battle has not ended, receiving client instructions sent by the game's main thread; wherein, the client instructions are sent by the clients participating in the current battle round to the game's main thread; determining whether client instructions sent by each client participating in the current battle round have been received; if received, performing settlement processing on the current battle round based on the client instructions and the settlement result of the previous battle round, to obtain the settlement result of the current battle round.

[0080] In an optional embodiment, the method further includes: if the target game battle ends, sending the settlement result of the last battle round in at least one battle round to the game main thread so that the game main thread can perform battle settlement on the target game battle.

[0081] In an optional embodiment, after the step of performing settlement processing on the current battle round based on client instructions and the settlement result of the previous battle round to obtain the settlement result of the current battle round, the method further includes: sending the settlement result of the current battle round to each client participating in the current battle round through the game's main thread, so that the client updates the game screen of the target game battle based on the settlement result of the current battle round; if the game screen update of each client is completed, or the update time exceeds a preset time threshold, waiting for the start of the next battle round of the current battle round; if the next battle round starts, taking the next battle round as the new current battle round, and continuing to execute the step of determining whether the target game battle has ended at the start of the current battle round, until the settlement of the last battle round in at least one battle round is completed.

[0082] In an optional embodiment, the step of sending the settlement result of the last battle round in at least one battle round to the game's main thread so that the game's main thread can perform battle settlement on the target game battle includes: determining the battle result of the target game battle based on the settlement result of the last battle round in at least one battle round; sending the battle result to the game's main thread so that the game's main thread can perform settlement processing on the target game battle based on the battle result, obtaining the battle settlement result, and distributing battle rewards based on the battle settlement result.

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

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

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

[0086] This invention also provides a computer-readable storage medium storing computer-executable instructions. When these computer-executable instructions are invoked and executed by a processor, they cause the processor to implement the aforementioned settlement control method.

[0087] Specifically, the aforementioned settlement control method is applied to the electronic device where the service process resides; the service process is communicatively connected to the game's main thread, which stores game data; the settlement control method includes: receiving target game data sent by the game's main thread to initiate a target game battle through the service process; wherein the target game battle includes at least one battle round; initiating the target game battle based on the target game data; for each battle round, if the current battle round has started, receiving a client instruction sent by the game's main thread, and performing settlement processing on the current battle round based on the client instruction and the settlement result of the previous battle round to obtain the settlement result of the current battle round; and sending the settlement result of the last battle round in at least one battle round to the game's main thread so that the game's main thread performs battle settlement for the target game battle.

[0088] The aforementioned settlement control method reduces the overhead and load on the game server's main logic thread by adding a service process to implement the game's combat-related logic, thereby effectively preventing game server lag.

[0089] In an optional embodiment, the step of initiating a target game battle based on target game data includes: constructing various combat attributes required for combat units in the target game battle according to the target game data, and obtaining a construction result; wherein, combat units include virtual objects and virtual monsters in the target game battle; and initiating the target game battle according to the construction result.

[0090] In an optional embodiment, during the process of constructing various combat attributes required for combat units in the target game battle, if the target game data does not contain the first game data required for constructing the first combat attribute, a data acquisition request for the first game data is sent to the game main thread so that the game main thread returns the first game data.

[0091] In an optional embodiment, the steps described above, which involve receiving client instructions sent by the game's main thread at the start of the current battle round and performing settlement processing on the current battle round based on the client instructions and the settlement result of the previous battle round, to obtain the settlement result of the current battle round, include: determining whether the target game battle has ended at the start of the current battle round; if the target game battle has not ended, receiving client instructions sent by the game's main thread; wherein, the client instructions are sent by the clients participating in the current battle round to the game's main thread; determining whether client instructions sent by each client participating in the current battle round have been received; if received, performing settlement processing on the current battle round based on the client instructions and the settlement result of the previous battle round, to obtain the settlement result of the current battle round.

[0092] In an optional embodiment, the method further includes: if the target game battle ends, sending the settlement result of the last battle round in at least one battle round to the game main thread so that the game main thread can perform battle settlement on the target game battle.

[0093] In an optional embodiment, after the step of performing settlement processing on the current battle round based on client instructions and the settlement result of the previous battle round to obtain the settlement result of the current battle round, the method further includes: sending the settlement result of the current battle round to each client participating in the current battle round through the game's main thread, so that the client updates the game screen of the target game battle based on the settlement result of the current battle round; if the game screen update of each client is completed, or the update time exceeds a preset time threshold, waiting for the start of the next battle round of the current battle round; if the next battle round starts, taking the next battle round as the new current battle round, and continuing to execute the step of determining whether the target game battle has ended at the start of the current battle round, until the settlement of the last battle round in at least one battle round is completed.

[0094] In an optional embodiment, the step of sending the settlement result of the last battle round in at least one battle round to the game's main thread so that the game's main thread can perform battle settlement on the target game battle includes: determining the battle result of the target game battle based on the settlement result of the last battle round in at least one battle round; sending the battle result to the game's main thread so that the game's main thread can perform settlement processing on the target game battle based on the battle result, obtaining the battle settlement result, and distributing battle rewards based on the battle settlement result.

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

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

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

Claims

1. A settlement control method, characterized in that, The method is applied to an electronic device where a service process resides; the service process is communicatively connected to the game's main thread, and the game's main thread stores game data; the method includes: The service process receives target game data required to initiate a target game battle from the game's main thread; wherein, the target game battle includes at least one battle round; Based on the target game data, initiate the target game battle; For the aforementioned battle round, if the current battle round begins, a client instruction sent by the game's main thread is received, and based on the client instruction and the settlement result of the previous battle round, a settlement process is performed on the current battle round to obtain the settlement result of the current battle round; wherein, the client instruction includes operations on the combat units included in the current battle; The settlement result of the last battle round in the at least one battle round is sent to the game's main thread so that the game's main thread can perform battle settlement for the target game battle; The step of receiving a client instruction sent by the game's main thread at the start of the current battle round, and performing a settlement process on the current battle round based on the client instruction and the settlement result of the previous battle round to obtain the settlement result of the current battle round includes: At the start of the current battle round, determine whether the target game battle has ended; If the target game battle has not ended, receive a client instruction sent by the game's main thread; wherein, the client instruction is sent by the client participating in the current battle round to the game's main thread; Determine whether a client instruction sent by each of the clients participating in the current battle round has been received; if so, perform settlement processing on the current battle round based on the client instruction and the settlement result of the previous battle round to obtain the settlement result of the current battle round.

2. The method according to claim 1, characterized in that, The step of initiating the target game battle based on the target game data includes: Based on the target game data, various combat attributes required for combat units in the target game battle are constructed to obtain the construction result; wherein, the combat units include virtual objects and virtual monsters in the target game battle; Based on the constructed result, initiate the target game battle.

3. The method according to claim 2, characterized in that, In the process of constructing the various combat attributes required for combat units in the target game battle, if the target game data does not contain the first game data required for constructing the first combat attribute, a data acquisition request for the first game data is sent to the game main thread so that the game main thread returns the first game data.

4. The method according to claim 1, characterized in that, The method further includes: If the target game battle ends, the settlement result of the last battle round in the at least one battle round is sent to the game's main thread so that the game's main thread can perform battle settlement for the target game battle.

5. The method according to claim 1, characterized in that, After the step of performing settlement processing on the current battle round based on the client command and the settlement result of the previous battle round to obtain the settlement result of the current battle round, the method further includes: The game's main thread sends the settlement result of the current battle round to each client participating in the current battle round, so that the client updates the game screen of the target game battle based on the settlement result of the current battle round. If the game screen of each client is updated, or the update time exceeds a preset time threshold, wait for the next battle round of the current battle round to begin. If the next battle round begins, take the next battle round as the new current battle round and continue to execute the step of determining whether the target game battle has ended at the beginning of the current battle round, until the last battle round of the at least one battle round is settled.

6. The method according to claim 1, characterized in that, The step of sending the settlement result of the last battle round in the at least one battle round to the game's main thread, so that the game's main thread can perform battle settlement for the target game battle, includes: The battle result of the target game battle is determined based on the settlement result of the last battle round in the at least one battle round. The battle results are sent to the game's main thread, so that the game's main thread can perform settlement processing on the target game battle based on the battle results, obtain the battle settlement results, and distribute battle rewards based on the battle settlement results.

7. A settlement control device, characterized in that, The device is installed on the electronic device where the service process resides; the service process is communicatively connected to the main game thread, and the main game thread stores game data; the device includes: The data receiving module is used to receive target game data sent by the game's main thread, which is required to start a target game battle, through the service process; wherein the target game battle includes at least one battle round; The battle initiation module is used to initiate a battle in the target game based on the target game data. The round settlement module is used to, for the current battle round, receive client instructions sent by the game's main thread when the current battle round begins, and perform settlement processing on the current battle round based on the client instructions and the settlement result of the previous battle round, to obtain the settlement result of the current battle round; wherein, the client instructions include operations on the combat units included in the current battle; The battle settlement module is used to send the settlement result of the last battle round in the at least one battle round to the game main thread, so that the game main thread can perform battle settlement on the target game battle; The round settlement module is further configured to: determine whether the target game battle has ended at the start of the current battle round; if the target game battle has not ended, receive a client instruction sent by the game's main thread; wherein the client instruction is sent by the client participating in the current battle round to the game's main thread; determine whether a client instruction sent by each client participating in the current battle round has been received; if received, perform settlement processing on the current battle round based on the client instruction and the settlement result of the previous battle round, and obtain the settlement result of the current battle round.

8. An electronic device, characterized in that, The electronic device includes a processor and a memory, the memory storing machine-executable instructions that can be executed by the processor, the processor executing the machine-executable instructions to implement the settlement control method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the settlement control method according to any one of claims 1 to 6.

Images