Method for handling missing game information and related products
By requesting and updating game information when the network environment recovers, the problem of lost move messages in chess applications caused by network instability is solved, and the continuity and stability of game operations are restored.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-07-15
- Publication Date
- 2026-03-17
AI Technical Summary
When the network environment is unstable, in real-time online chess applications, move messages are easily lost, leading to abnormal game situations, affecting user experience and potentially causing user churn.
A method for handling lost game information is provided, which requests the latest game information of each game player from the server when the network environment is restored, updates the local game information according to the latest information, and executes a fallback synchronization scheme to restore normal game play.
Once the network environment is restored, normal gameplay can resume, reducing the impact of the network environment on gameplay and ensuring the continuity and stability of gameplay.
Smart Images

Figure CN115238002B_ABST
Abstract
Description
Technical Field
[0001] The embodiments of the present invention relate to the field of data processing technology, and more specifically, the embodiments of the present invention relate to a method, computing device, and computer-readable storage medium for processing lost game information. Background Technology
[0002] This section is intended to provide background or context for embodiments of the invention set forth in the claims. The description herein may include concepts that may be explored, but not necessarily concepts that have been previously conceived or explored. Therefore, unless otherwise stated, what is described in this section is not prior art for the purposes of this application's specification and claims, and is not acknowledged as prior art simply by virtue of its inclusion in this section.
[0003] As a real-time online chess application, the most core and fundamental function is playing chess. However, in extremely complex network environments, it's almost impossible to guarantee that real-time game messages will be transmitted between the terminal and the server without any errors. For example, when the network environment deteriorates, the user switches network types, the user enters an elevator, or the server room experiences network jitter, real-time game messages may experience significant delays or even be lost during transmission. Once real-time game messages are lost, various abnormal situations may occur in the entire game, which severely impacts the user's gaming experience and may even lead to user churn.
[0004] Currently, many real-time online chess applications lack a robust mechanism to prevent the loss of move messages. Therefore, if move messages are lost for any reason, the entire game will become abnormal and the game cannot continue normally. Summary of the Invention
[0005] In existing technologies, reducing the impact of the network environment on game operations is a very troublesome process.
[0006] Therefore, it is desirable to provide a solution for handling the loss of game information, which can execute a fallback synchronization scheme when game information is lost due to network instability. This way, normal game can be restored as long as the network environment meets the most basic real-time game requirements, thereby reducing the impact of the network environment on game operations.
[0007] In this context, embodiments of the present invention aim to provide a method, computing device, and computer-readable storage medium for processing lost game information.
[0008] In a first aspect of the present invention, a method for handling lost game information is provided, suitable for games played by multiple players. The method includes: in response to not receiving a reply from the server based on game information sent by the current player within a first preset time period, requesting the latest game information from the server for each player, so as to re-request the latest game information from the server or update local game information accordingly; and executing a corresponding self-information loss handling strategy based on whether the latest game information is received within a second preset time period.
[0009] In one embodiment of the present invention, the corresponding self-information loss processing strategy based on whether the latest game information is received within a second preset time period includes: in response to not receiving the latest game information within the second preset time period, re-establishing the transmission link to re-request the latest game information from the server.
[0010] In another embodiment of the present invention, the game information of each game terminal synchronized by the server is stored in any game terminal, and the corresponding self-information loss processing strategy is executed according to whether the latest game information is received within a second preset time period. This includes: in response to receiving the latest game information within the second preset time period, executing the corresponding self-information loss processing strategy according to the game information of each game terminal stored in the current game terminal and the latest game information.
[0011] In another embodiment of the present invention, executing a corresponding self-information loss processing strategy based on the game information of each game player stored in the current game player and the latest game information includes: determining a first total number of games for each game player based on the latest game information; determining a second total number of games for each game player based on the game information of each game player stored in the current game player; and executing a corresponding self-information loss processing strategy based on the relationship between the first total number of games and the second total number of games.
[0012] In another embodiment of the present invention, the strategy for handling self-information loss based on the relationship between the first total number of games and the second total number of games includes: in response to the first total number of games being less than the second total number of games, performing a preset number of retransmission operations on the game information; or, in response to the first total number of games being less than the second total number of games, performing a preset number of retransmission operations on the game information, and canceling the game operation corresponding to the game information after the retransmission fails, so as to re-execute the game operation.
[0013] In one embodiment of the present invention, the corresponding self-information loss processing strategy based on the relationship between the first total number of games and the second total number of games includes: in response to the first total number of games being greater than the second total number of games, updating the local game information according to the latest game information, so as to update the local game operation according to the updated local game information.
[0014] In another embodiment of the present invention, the method further includes: obtaining information about the next player to perform a game operation from the server; determining whether the opponent's game information is lost based on the information about the next player to perform a game operation and the game information of each player stored in the current player; and executing a corresponding opponent information loss processing strategy in response to the loss of the opponent's game information.
[0015] In another embodiment of the present invention, determining whether the opponent's game information is lost based on the information of the next player to perform the game operation and the game information of each player stored in the current player includes: determining the next player to perform the game operation based on the information; determining the player that has completed the latest valid game based on the game information of each player stored in the current player; and determining whether the opponent's game information is lost based on the next player to perform the game operation and the player that has completed the latest valid game.
[0016] In another embodiment of the present invention, based on the game information of each game player stored in the current game player, the game player that meets the following conditions is determined as the game player that has completed the latest valid game: has sent the latest game information to the server; and has received a reply from the server based on the latest game information.
[0017] In one embodiment of the present invention, executing the corresponding opponent information loss handling strategy includes: requesting the latest game information of each game player from the server; in response to receiving the latest game information within a third preset time period, updating the local game information according to the latest game information, so as to update the local game operation according to the updated local game information.
[0018] In another embodiment of the present invention, the method further includes: in response to receiving a reply based on game information from the server, determining whether there is a reply with a reply processing flag locally; and executing a corresponding reply processing strategy based on the determination result.
[0019] In another embodiment of the present invention, the corresponding reply processing strategy is executed according to the judgment result, including: in response to the judgment result that there is a reply with a reply processing mark locally, the reply is added to the reply waiting queue for processing.
[0020] In another embodiment of the present invention, executing the corresponding reply processing strategy according to the judgment result includes: in response to the judgment result that there is no reply with a reply processing mark locally, adding a reply processing mark to the reply and updating the local game information based on the reply; and deleting the reply processing mark in the reply after the update is completed.
[0021] In a second aspect of the present invention, a computing device is provided, comprising: a processor configured to execute program instructions; and a memory configured to store the program instructions, which, when loaded and executed by the processor, cause the processor to perform a method for handling lost game information according to any of the embodiments of the first aspect described above.
[0022] In a third aspect of the present invention, a computer-readable storage medium is provided, wherein program instructions are stored, which, when loaded and executed by a processor, cause the processor to perform the method for handling lost game information according to any embodiment of the first aspect described above.
[0023] According to the scheme for handling lost game information according to embodiments of the present invention, when game information is lost due to network conditions, a fallback synchronization scheme can be executed (updating local game information based on the latest game information of each game player stored in the server). The execution of this fallback synchronization scheme ensures that normal game can be restored as long as the network environment meets the most basic real-time game requirements, thereby greatly reducing the impact of the network environment on game operations. Attached Figure Description
[0024] The above and other objects, features, and advantages of exemplary embodiments of the present invention will become readily apparent from the following detailed description taken in conjunction with the accompanying drawings. Several embodiments of the invention are illustrated in the drawings by way of example and not limitation, wherein:
[0025] Figure 1 A block diagram of an exemplary computing system suitable for implementing embodiments of the present invention is shown schematically;
[0026] Figure 2 A flowchart illustrating a method for handling lost game information according to an embodiment of the present invention is shown schematically.
[0027] Figure 3 A flowchart illustrating a method for handling the loss of self-play information according to an embodiment of the present invention is shown schematically.
[0028] Figure 4 This illustration schematically demonstrates a strategy for handling self-information loss upon successful reception of the latest game information, according to an embodiment of the present invention.
[0029] Figure 5 A flowchart illustrating a method for handling the loss of opponent's game information according to an embodiment of the present invention is shown schematically.
[0030] Figure 6 A detailed flowchart illustrating a method for handling the loss of opponent's game information according to an embodiment of the present invention is shown schematically.
[0031] In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts. Detailed Implementation
[0032] The principles and spirit of the invention will now be described with reference to several exemplary embodiments. It should be understood that these embodiments are given merely to enable those skilled in the art to better understand and implement the invention, and are not intended to limit the scope of the invention in any way. Rather, these embodiments are provided to make this disclosure more thorough and complete, and to fully convey the scope of this disclosure to those skilled in the art.
[0033] Figure 1 A block diagram of an exemplary computing system 100 suitable for implementing embodiments of the present invention is shown. For example... Figure 1 As shown, the computing system 100 may include: a central processing unit (CPU) 101, random access memory (RAM) 102, read-only memory (ROM) 103, a system bus 104, a hard disk controller 105, a keyboard controller 106, a serial interface controller 107, a parallel interface controller 108, a display controller 109, a hard disk 110, a keyboard 111, a serial external device 112, a parallel external device 113, and a display 114. Among these devices, the CPU 101, RAM 102, ROM 103, hard disk controller 105, keyboard controller 106, serial controller 107, parallel controller 108, and display controller 109 are coupled to the system bus 104. The hard disk 110 is coupled to the hard disk controller 105, the keyboard 111 is coupled to the keyboard controller 106, the serial external device 112 is coupled to the serial interface controller 107, the parallel external device 113 is coupled to the parallel interface controller 108, and the display 114 is coupled to the display controller 109. It should be understood that... Figure 1 The structural block diagrams described are for illustrative purposes only and are not intended to limit the scope of the invention. In some cases, certain devices may be added or removed depending on the specific circumstances.
[0034] Those skilled in the art will recognize that embodiments of the present invention can be implemented as a system, method, or computer program product. Therefore, this disclosure can be specifically implemented as entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software, generally referred to herein as a "circuit," "module," or "system." Furthermore, in some embodiments, the present invention can also be implemented as a computer program product contained in one or more computer-readable media, which includes computer-readable program code.
[0035] Any combination of one or more computer-readable media may be used. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example,, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (not exhaustive) of a computer-readable storage medium may include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device.
[0036] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.
[0037] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.
[0038] Computer program code for performing the operations of this invention can be written in one or more programming languages or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, and C++, as well as conventional procedural programming languages such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network (including a local area network (LAN) or a wide area network (WAN)), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).
[0039] Embodiments of the present invention will now be described with reference to flowchart illustrations and block diagrams of apparatus (or systems) according to embodiments of the invention. It should be understood that each block of the flowchart and / or block diagram, and combinations of blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine that, when executed by the computer or other programmable data processing apparatus, creates means for implementing the functions / operations specified in the blocks of the flowchart and / or block diagram.
[0040] These computer program instructions may also be stored in a computer-readable medium that enables a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce a product comprising an instruction apparatus that implements the functions / operations specified in the boxes of a flowchart and / or block diagram.
[0041] Computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, such that the instructions that execute on the computer or other programmable apparatus can provide a process for implementing the functions / operations specified in the boxes of a flowchart and / or block diagram.
[0042] According to embodiments of the present invention, a method, computing device, and computer-readable storage medium for processing lost game information are provided.
[0043] In this article, it is important to understand that the terminology used includes the following:
[0044] Ws(s) messages: Real-time communication technology using WebSockets, including uplink messages (sent by the terminal and received by the server) and downlink messages (sent by the server and received by the terminal).
[0045] Heartbeat Message: After a WebSocket connection is established (referred to as a "ws connection"), to ensure the connection between the server and the terminal remains open, the terminal typically sends a specific message to the server every few seconds. The server, upon receiving this message, will promptly reply. This specific message is the heartbeat message. The heartbeat message also contains information about which player's turn it is (the next player to perform a move).
[0046] Move Messages: In real-time online chess applications, after a user places a move, the application sends the user's move information to the server via a WebSocket message. The server then distributes the response to each terminal. Upon receiving the response, each terminal updates its chessboard to complete the move. All messages sent and received during the move are collectively referred to as move messages.
[0047] Fen: A text string used to represent the chessboard position. It uses specific characters to clearly describe key information such as the chessboard position, the current player's move, and historical moves. Having a complete Fen allows you to fully reconstruct a chess game.
[0048] Furthermore, the number of any elements in the accompanying drawings is for illustrative purposes only and not for limitation, and any naming is for distinction only and has no limiting meaning.
[0049] The principles and spirit of the present invention will be explained in detail below with reference to several representative embodiments. Invention Overview
[0051] The inventors have discovered that when network instability causes the loss of game information, the latest game information from each game player can be requested from the server. After the network is restored (as long as the most basic real-time game requirements are met), corresponding processing can be performed based on the latest game information (e.g., updating local game information based on the latest game information), thereby restoring normal game operation.
[0052] This operation minimizes the impact of network jitter on the loss of game information, ensuring that normal gameplay can resume under any circumstances as long as the network environment meets the most basic requirements for real-time gameplay. This greatly reduces the impact of the network environment on gameplay.
[0053] In an embodiment of the present invention, a scheme for handling the loss of game information is proposed. This scheme can execute a fallback synchronization scheme when game information is lost due to network conditions, so that normal game can be restored as long as the network environment meets the most basic real-time game requirements, thereby greatly reducing the impact of the network environment on game operations.
[0054] After introducing the basic principles of the present invention, various non-limiting embodiments of the present invention will be described in detail below.
[0055] Methods for handling the loss of game information
[0056] Figure 2 A flowchart of a method 200 for handling lost game information according to an embodiment of the present invention is shown schematically.
[0057] This method is suitable for games played by multiple players, such as two-player, three-player, four-player, or more-player games, and the type of game can be, for example, chess games, such as Chinese chess (two-player), checkers (two-player, three-player, four-player, or six-player). It is understood that, in addition to the game operations listed herein, this disclosure can also be applied to card games played by multiple players (e.g., two-player or three-player).
[0058] like Figure 2 As shown, method 200 may include, in step S201, responding to the absence of a reply from the server regarding the game information sent by the current player within a first preset time period, requesting the latest game information from the server for each player, so as to re-request the latest game information from the server or update the local game information accordingly. The executing entity of this method may be the terminal corresponding to the current player.
[0059] In one embodiment, both the game information and the reply can be ws messages. For chess games, the game operation can be a move or a card play, the game information can be a move message or a card play message, and the latest game information can be the latest game record Fen or the latest card game record. Additionally, the duration of the first preset time period can be specifically set as needed, such as 2 seconds or 3 seconds.
[0060] It is understandable that not receiving the above reply within the first preset time period indicates that the game information has been lost, which is most likely due to poor network conditions. At this time, the type of game information loss (such as information not being delivered to the server or the server's reply being lost) and the corresponding handling strategy can be determined by the latest game information of each game client stored on the server, so that normal game operation can be restored after the network environment is restored.
[0061] As described in the foregoing embodiments, during the game, each terminal participating in the game sends a game information (e.g., a move message) to the server when performing each game operation (e.g., a move operation). When the server receives the game information, it distributes the corresponding game information to each terminal participating in the game in the form of a reply (e.g., directly forwarding the game information or forwarding it after pre-processing it).
[0062] The above operations enable the synchronization of game information between various terminals and the server. Therefore, when it is determined that one's own game information is lost, the type of information loss can be determined based on the correspondence between the latest game information of each player stored on the server and the game information of each player stored locally on each terminal, allowing for targeted handling. In a specific implementation scenario, the latest game information can be requested from the server through its synchronization interface.
[0063] After requesting the latest game information from each player to the server, in step S202, method 200 can execute a corresponding self-information loss handling strategy based on whether the latest game information has been received within a second preset time period.
[0064] Understandably, if the latest game information is not received after the second preset time period (i.e., information reception timeout), it indicates that the current network environment is extremely poor and no longer meets the most basic requirements for real-time game play. In this case, a transmission link can be re-established to re-request the latest game information. Conversely, if the latest game information is received within the second preset time period (successful reception), it indicates that the current network environment can meet the most basic requirements for real-time game play. In this case, appropriate processing can be performed based on the received latest game information. The duration of the second preset time period can also be set as needed to 2 seconds, 3 seconds, or 4 seconds, etc.
[0065] To ensure that the correct and up-to-date game information has been received, and to facilitate subsequent handling of lost game information, the terminal can perform functions such as format verification on the received information. For example, if the received information format does not match the preset normal format, it is determined that the latest game information has not been received (the server returns an exception); if the received information format matches the preset normal format, it is determined that the latest game information has been received. This verification ensures effective handling of lost game information.
[0066] Therefore, this solution can implement a fallback synchronization scheme (updating local game information based on the latest game information of each game client stored on the server) when game information is lost due to network conditions. This ensures that normal game can be restored as long as the network environment meets the most basic real-time game requirements, thereby greatly reducing the impact of network conditions on game operations.
[0067] Figure 3A flowchart illustrating a method 300 for handling self-play information loss according to an embodiment of the present invention is shown, illustrating self-play information loss handling strategies under different current network environment states.
[0068] As shown in the figure, method 300 may include, in step S301, in response to not receiving a reply from the server based on the game information sent by the current game player within a first preset time period, requesting the latest game information from the server for each game player, so as to re-request the latest game information from the server or update the local game information accordingly. This step is the same as the aforementioned step S201, and the relevant description can be referred to the aforementioned embodiments, and will not be detailed here.
[0069] After requesting the latest game information from each player to the server, the operations of step S302 (in response to no latest game information being received within the second preset time period) and step S303 (in response to receiving the latest game information within the second preset time period) can be executed respectively, depending on whether the latest game information is received within the second preset time period.
[0070] Specifically, in step S302, the transmission link is re-established to re-request the latest game information from the server. As described in the foregoing embodiment, this indicates an extremely poor network environment. Therefore, one or more re-request operations can be performed to wait for the network environment to improve (as long as the most basic real-time game requirements are met), so that normal game operation can be resumed with the received latest game information.
[0071] In one implementation, when receiving the latest game information fails (no latest game information is received within a second preset time period), an error page and a retry button can be provided on the terminal. The user can click the retry button to recreate the ws connection and resume the game, depending on the network conditions. If the network is still extremely poor after the user retryes, the error page and retry button will still be displayed to repeatedly request the game again until the network environment improves.
[0072] As described in the foregoing embodiments, in order to conduct a game, each playing end stores the game information of all playing ends synchronized with the server. Therefore, under normal signal transmission conditions, the game information of each playing end stored locally on the terminal corresponding to each playing end should be synchronized with that in the server, that is, the game information should match. Based on this, after receiving the latest game information, the type of game information loss and the corresponding processing strategy can be determined according to the matching relationship between the two sets of information.
[0073] Based on this, in step S303, the corresponding self-information loss processing strategy can be executed according to the game information of each game player stored in the current game player and the latest game information mentioned above. The effective self-information loss processing strategy can be determined by matching the two pieces of information.
[0074] Since each game record represents one game operation, under normal signal transmission conditions, the total number of games recorded in the terminal and the total number of games recorded in the server should be the same. Based on this, this solution can determine the type of lost game information and the corresponding processing strategy by comparing the total number of games recorded in the terminal and the server.
[0075] Figure 4 The illustration schematically demonstrates a strategy for handling self-information loss upon successful reception of the latest game information according to an embodiment of the present invention.
[0076] As shown in the figure, method 400 may include, in step S401, determining the first total number of games played by each game player (i.e., the total number of games played recorded in the server) based on the latest game information; then, in step S402, determining the second total number of games played by each game player (i.e., the total number of games played recorded in the terminal) based on the game information of each game player stored in the current game player terminal.
[0077] After determining the first and second total number of games played, in step S403, if the first total number of games played is less than the second total number of games played (i.e., the total number of games played recorded on the server is less than the total number of games played on the terminal), it indicates that the game information sent by the terminal has not reached the server (it may have been lost during transmission to the server). In this case, the game information can be retransmitted a preset number of times (e.g., 2 or 3 times) in order to ensure successful transmission of the game information when the network environment improves.
[0078] Understandably, when the network environment remains poor, the system remains locked on the currently pending game operation (the game operation corresponding to a game message sent but not replied to), preventing the execution of new game operations. To address this issue, this solution can also cancel the game operation corresponding to the game message after a retransmission failure (i.e., abandon the invalid game operation, allowing a new game operation to be executed), enabling the game operation to continue.
[0079] During the retransmission of game information, the recovery of the network environment often allows previously sent but not yet delivered game information to reach the server. This situation can easily lead to the server receiving duplicate game information and misprocessing in the same game operation, thus affecting the progress of the game operation.
[0080] To address this issue, the server can identify whether received game information has already been processed (e.g., stored). If it has been processed, it rejects or ignores subsequent game information with the same number of moves (in a single game operation, the same terminal sends game information with the same number of moves). If it has not been processed, it receives the game information normally. This deduplication operation ensures that only one game information is received and processed in a single game operation, thus guaranteeing the effective execution of each game operation.
[0081] The above describes a solution for handling information loss when the total number of games recorded on the server is less than the total number of games recorded on the terminal. Now, let's return to... Figure 4 In the process, at step S404, in response to the total number of games played in the first round being greater than the total number of games played in the second round, it indicates that the game information sent by the terminal has been successfully delivered to the server. However, during the server's reply process, the reply was lost due to network issues. In this case, the local game information can be updated based on the latest game information, so that the local game operations can be updated according to the updated local game information.
[0082] To fully illustrate the two different processing strategies when the latest game information is successfully received, this solution will be described below with specific examples.
[0083] For example, during a chess game, the terminal UE corresponding to player A sends a move message f1 (indicating a move from position a1 to position a2) to the server, but does not receive a reply. At this point, assuming the latest game record Fen on the server shows a first total number of moves (total number of moves in the first game) of 3, while the terminal UE shows a second total number of moves (total number of moves in the second game) of 4, the terminal UE retransmits the move message f1. If this retransmission fails, the retransmission operation is repeated... until the retransmission count reaches, for example, 3 times. If the retransmission still fails at this point, the terminal UE can cancel the move from position a1 to position a2 and re-execute a new move.
[0084] In another scenario, assuming the total number of moves in the first round is 4, the total number of moves in the second round is 3, and the latest game record Fen includes a move message f2 (instructing player A to move from position a3 to position a4) that is not stored locally on the terminal UE, the terminal UE can update the move message f2 locally to execute the move operation of player A from position a3 to position a4.
[0085] The preceding text, with examples, described various handling strategies for the loss of one's own game information during a game. It is understandable that in an unstable network environment, in addition to the loss of one's own game information, the opponent's game information may also be lost, which can also prevent the game from proceeding normally. To solve this problem, this solution proposes a method for processing the opponent's game information, which will be discussed below. Figure 5 and Figure 6 Let me explain in detail.
[0086] Typically, multiple players execute their moves sequentially. Therefore, under normal signal transmission conditions, the players executing any two consecutive moves should theoretically be different. Based on this principle, we can determine whether opponent information has been lost by checking whether the players executing two consecutive moves are the same.
[0087] Figure 5 A flowchart illustrating a method 500 for handling lost opponent game information according to an embodiment of the present invention is shown schematically.
[0088] like Figure 5 As shown, method 500 may further include, at step S501, obtaining information about the next player to perform a game operation from the server. This information may come from a heartbeat message sent by the server to the terminal, which may carry an identifier (e.g., name or number) of the next player to perform a game operation.
[0089] After obtaining the information of the next player to perform the game operation, method 500 can proceed to step S502, and determine whether the opponent's game information is lost based on the information of the next player to perform the game operation and the game information of each player stored in the current player.
[0090] In a specific implementation scenario, the following method can be used to determine whether the opponent's game information is lost: Based on the above information, determine the next player to perform a game operation; based on the game information of each player stored in the current player's game information, determine the player who has completed the latest valid game; and then, based on the next player to perform a game operation and the player who has completed the latest valid game, determine whether the opponent's game information is lost.
[0091] Specifically, a player can be identified as having completed the latest valid game if it meets the following conditions: it has sent the latest game information to the server and received a reply from the server based on the latest game information.
[0092] In one implementation scenario, the terminal can locally record all game information it sends to the server and all replies it receives from the server, storing the game information and replies accordingly. Furthermore, the terminal can also record the identifier (e.g., name or number) of the player corresponding to each game piece of information, as well as the execution order of the game operations corresponding to each game piece of information. Based on this, the game information that is executed last and has a reply (a corresponding reply exists) can be found, and the corresponding player can be identified as the player who has completed the latest valid game.
[0093] The following example illustrates how to determine the player who has completed the latest valid game.
[0094] Suppose there are two players (player A and player B) playing a chess game, and the UE terminal corresponding to player A stores the local move messages of each player as follows:
[0095] 1. Player A sends a move message and receives a reply;
[0096] 2. Player B sends a move message and receives a reply;
[0097] 3. Player A sends a move message and receives a reply.
[0098] Here, 1, 2, and 3 represent the execution order of the move operation. In this case, the player who has completed the latest valid move is determined to be player A. If the corresponding information for execution order 3 is "Player A sent a move message but did not receive a reply", then the player who has completed the latest valid move is determined to be player B.
[0099] After identifying the player who completed the latest valid move, it can be determined whether the opponent's move information has been lost based on the player who will make the next move and the player who completed the latest valid move. Specifically, if the player who will make the next move is the same as the player who completed the latest valid move, it is determined that the opponent's move information has been lost; conversely, if the player who will make the next move is different from the player who completed the latest valid move, it is determined that the opponent's move information has not been lost.
[0100] Taking the chess game involving player A and player B as an example, if the player who makes the next move and the player who has made the latest valid move are both player A, then it is determined that player B's move message is lost (i.e., the opponent's play information is lost).
[0101] The above description, with examples, outlines a method for determining the loss of opponent's game information. Now, let's return to the previous section. Figure 5In response to the loss of opponent's game information, method 500 proceeds to step S503, executing the corresponding opponent information loss handling strategy. This strategy resolves the issue of game operations being unable to proceed normally due to the loss of opponent's game information, allowing normal game operations to resume once the network environment is restored (provided the most basic real-time game requirements are met).
[0102] The following disclosure will illustrate the detailed process for handling the loss of opponent's game information. Figure 6 This section explains the strategies for handling the loss of information from the opponent during the game.
[0103] Understandable, Figure 6 The method 600 shown is... Figure 5 The only difference between method 500 and the one shown is that the diagram also illustrates a specific strategy for handling the loss of opponent's game information, which is consistent with... Figure 5 Steps S501, S502, and S503 are the same. Steps S601, S602, and S603 can be referred to. Figure 5 The relevant descriptions in the document will not be repeated here.
[0104] like Figure 6 As shown, step S603 may further include requesting the latest game information of each player from the server at step S6031. This step is the same as the aforementioned step S301, and the relevant description of step S301 also applies to this step, so it will not be repeated here.
[0105] Next, in step S6032, in response to receiving the latest game information within the third preset time period, it indicates that the current network environment can meet the most basic real-time game requirements. Method 600 can update the local game information based on the latest game information, and update the local game operation based on the updated local game information. The third preset time period can be set to 2 seconds, 3 seconds, or 4 seconds, etc., as needed.
[0106] Taking the above example of two game ends, A and B, and the case where the move message of game end B is lost, if the lost move message of game end B indicates a move from position d1 to position e1, then when the terminal UE receives the latest game record Fen, it can synchronize the move message to the local machine of the terminal UE, so that the move operation of game end B from position d1 to position e1 can be executed at the terminal UE, thereby restoring the game operation to normal.
[0107] In step S6033, in response to the failure to receive the latest game information within the third preset time period, it indicates that the network environment is extremely poor. One or more requests can be resent to the server (requesting the latest game information from each game player) so that the latest game information can be obtained when the network environment improves (meeting the most basic real-time game requirements) so that normal game operation can be resumed.
[0108] It is understandable that, due to network conditions, multiple game-related messages (replies) from the server may arrive at the terminal at very close times. This could lead to unprocessed game-related messages being overwritten by later ones. Therefore, this solution adds markers to unprocessed and currently processed game-related messages. Upon receiving a later message, the markers are used to determine whether an unprocessed or currently processed reply exists locally on the terminal, thus overcoming the aforementioned problem of concurrent reply processing.
[0109] Specifically, the method may include responding to a reply based on game information received from the server, determining whether a reply with a reply processing flag exists locally, and executing the corresponding reply processing strategy based on the determination result.
[0110] If the above judgment result indicates that a reply with a reply processing mark exists locally, it means that there are unprocessed or being processed replies on the terminal. Therefore, the reply is added to the reply waiting queue to await processing. By setting up a reply waiting queue, when a new reply is received, it is possible to directly check if a reply exists in the queue, thus quickly determining whether there are any unprocessed replies locally (the presence of a reply proves the existence of unprocessed replies). Furthermore, when the terminal is processing new unprocessed replies, it can select and process them sequentially from the reply waiting queue according to the order in which they were received, thus ensuring orderly processing of replies.
[0111] In response to the above judgment result that there is no reply with a reply processing mark locally, it means that there is no unprocessed or being processed reply. Then, a reply processing mark is added to the reply just received from the server (indicating that it is unprocessed or being processed), and the local game information is updated based on the reply (i.e., the reply is processed). After the update is completed, the reply processing mark in the reply is deleted (indicating that the reply processing is completed).
[0112] After processing a reply marked as having been processed, you can check if there are any unprocessed replies in the reply waiting queue. If there are, you can process them one by one in the order mentioned above (e.g., starting from the head of the queue). If there are no unprocessed replies, the process ends and other operations continue, such as waiting for a reply from the server.
[0113] As described in the foregoing embodiments, this solution provides a robust fallback synchronization scheme for real-time game message loss under complex and unstable network conditions. It can synchronize the latest game information after network recovery, thereby enabling normal game operation to resume. This solution minimizes the impact of network jitter on game information loss, ensuring that normal game operation can resume under any circumstances, as long as the network environment meets the basic requirements for real-time game play. This significantly reduces the impact of the network environment on game operation.
[0114] Exemplary application scenarios
[0115] The method for handling lost game information according to the embodiments of the present invention can be applied to multi-player game scenarios such as chess games.
[0116] In chess-playing applications, when move messages are lost due to network instability, the latest move messages from each player can be requested from the server. Once the network is restored (as long as the most basic real-time play requirements are met), the corresponding processing (such as updating local move messages) can be performed based on these messages.
[0117] It should be noted that the above application scenarios are shown only to facilitate understanding of the spirit and principles of the present invention, and the embodiments of the present invention are not limited in any way. On the contrary, the embodiments of the present invention can be applied to any applicable scenario.
[0118] From the above exemplary description of the scheme for handling the loss of game information according to the embodiments of the present invention in conjunction with the accompanying drawings, it can be understood that the embodiments of the present invention provide a processing scheme that can greatly reduce the impact of the network environment on game operations. It can execute a fallback synchronization scheme when game information is lost due to the network environment, so that normal game can be restored as long as the network environment meets the most basic real-time game requirements, thereby greatly reducing the impact of the network environment on game operations.
[0119] It should be noted that although several modules or sub-modules of the apparatus have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of the present invention, the features and functions of two or more apparatuses described above can be embodied in one apparatus. Conversely, the features and functions of one apparatus described above can be further divided and embodied by multiple apparatuses.
[0120] Furthermore, although the operations of the method of the present invention are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all of the operations shown must be performed to achieve the desired result. Rather, the steps depicted in the flowchart may be performed in a different order. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.
[0121] The use of the verbs "including" and "contains" and their inflections in the application documents does not preclude the existence of elements or steps other than those described in the application documents. The article "a" or "one" preceding an element does not preclude the existence of multiple such elements.
[0122] While the spirit and principles of the invention have been described with reference to several specific embodiments, it should be understood that the invention is not limited to the disclosed specific embodiments, and the division of aspects does not imply that features in these aspects cannot be combined for benefit; such division is merely for ease of description. The invention is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims. The scope of the appended claims is to be interpreted in the broadest sense, thereby encompassing all such modifications and equivalent structures and functions.
Claims
1. A method for handling missing game information, suitable for a game of a plurality of game terminals, characterized in that, The method comprises: in response to not receiving the reply of the game information sent by the server based on the current game end within a first preset time period, requesting the server for the latest game information of each game end, so as to request the server for the latest game information again according to the latest game information or update the local game information according to the latest game information; and executing corresponding self-information loss processing strategies according to whether the latest game information is received within a second preset time period; wherein the game information of each game end stored in any game end is synchronized by the server, and the corresponding self-information loss processing strategies are executed according to whether the latest game information is received within a second preset time period, which comprises: in response to not receiving the latest game information within a second preset time period, re-establishing a sending link to request the server for the latest game information again; in response to receiving the latest game information within a second preset time period, executing corresponding self-information loss processing strategies according to the game information of each game end stored in the current game end and the latest game information; wherein the corresponding self-information loss processing strategies are executed according to the game information of each game end stored in the current game end and the latest game information, which comprises: determining the first total number of games of each game end according to the latest game information; determining the second total number of games of each game end according to the game information of each game end stored in the current game end; and executing corresponding self-information loss processing strategies based on the size relationship between the first total number of games and the second total number of games; wherein the corresponding self-information loss processing strategies are executed based on the size relationship between the first total number of games and the second total number of games, which comprises: in response to the first total number of games being less than the second total number of games, performing a preset number of retransmission operations on the game information; or in response to the first total number of games being less than the second total number of games, performing a preset number of retransmission operations on the game information, and after the retransmission fails, canceling the game operation corresponding to the game information so as to re-execute the game operation; wherein the corresponding self-information loss processing strategies are executed based on the size relationship between the first total number of games and the second total number of games, which comprises: in response to the first total number of games being greater than the second total number of games, updating the local game information according to the latest game information, so as to update the local game operation according to the updated local game information.
2. The method of claim 1, wherein, The method further comprises: obtaining the information of the game end that will execute the game operation next from the server; judging whether the opponent game information is lost according to the information of the game end that will execute the game operation next and the game information of each game end stored in the current game end; and in response to the opponent game information being lost, executing corresponding opponent-information loss processing strategies.
3. The method of claim 2, wherein, wherein the judgment of whether the opponent game information is lost according to the information of the game end that will execute the game operation next and the game information of each game end stored in the current game end comprises: determining the game end that will execute the game operation next according to the information. determine, according to the game information of each game terminal stored in the current game terminal, a game terminal that has performed the latest valid game as the game terminal that has performed the latest valid game; and determine, according to the game terminal that performs the next game operation and the game terminal that has performed the latest valid game, whether the opponent game information is lost.
4. The method of claim 3, wherein, wherein according to the game information of each game terminal stored in the current game terminal, a game terminal that satisfies the following conditions is determined as the game terminal that has performed the latest valid game: has sent the latest game information to the server; and has received the response from the server based on the latest game information.
5. The method according to any one of claims 2-4, characterized in that, wherein performing the corresponding opponent information loss processing strategy includes: requesting the latest game information of each game terminal from the server; in response to receiving the latest game information within a third preset time period, updating the local game information according to the latest game information, so as to update the local game operation according to the updated local game information.
6. The method of claim 1, wherein, The method further includes: in response to receiving the response from the server based on the game information, determining whether there is a response with a response processing mark in the local; and performing the corresponding response processing strategy according to the determination result.
7. The method of claim 6, wherein, wherein performing the corresponding response processing strategy according to the determination result includes: in response to the determination result being that there is a response with a response processing mark in the local, adding the response to a response waiting queue for processing.
8. The method of claim 6, wherein, wherein performing the corresponding response processing strategy according to the determination result includes: in response to the determination result being that there is no response with a response processing mark in the local, adding a response processing mark to the response and updating the local game information based on the response; and deleting the response processing mark in the response after the update is completed.
9. A computing device, comprising: includes: a processor configured to execute program instructions; and a memory configured to store the program instructions, which, when loaded and executed by the processor, cause the processor to perform the method for processing game information loss according to any one of claims 1 to 8.
10. A computer-readable storage medium, characterized in that, wherein the program instructions are stored, which, when loaded and executed by the processor, cause the processor to perform the method for processing game information loss according to any one of claims 1 to 8.
Citation Information
Patent Citations
Information generation method and device
CN110620806A