Game data processing method and device, storage medium and electronic equipment

Abstract

This application discloses a method, apparatus, storage medium, and electronic device for processing game data. The method includes: responding to a received match merge request; determining the matching degree of candidate match instances based on the difference in match progress between the requesting match instance and candidate match instances, the dynamic intensity of the match, and the predicted probability that the candidate match instance will accept the match merge request; selecting a target match instance from the set of candidate match instances based on the matching degree and a dynamic filtering radius; performing conflict detection on the merged operation data after merging the request and target match instances based on the historical operation data of the requesting match instance and the historical operation data of the target match instance to obtain global state data; and sequentially executing each operation in the merged operation data according to the round in the global state data. This application solves the technical problem of low operability in turn-based game matches.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a method and apparatus for processing game data, a storage medium, and an electronic device. Background Technology

[0002] In turn-based multiplayer games, a pre-set matchmaking mechanism randomly pairs players to form at least two teams for a match. However, this random matchmaking mechanism does not consider differences in player level or skill. This can lead to games ending prematurely when there is a significant skill gap or when players make mistakes, resulting in a poor gaming experience or premature game termination.

[0003] To address these issues, related technologies primarily involve merging two or more ongoing matches by improving matchmaking rules or candidate pool selection, thus creating larger-scale battles. However, these improvements to matchmaking rules or candidate pool selection methods are relatively simple and cannot quantify the acceptance of merge requests by candidate players, nor can they more effectively select candidates to participate in match merges. Therefore, the new matches resulting from this method of match merging fail to fundamentally improve the gameplay experience, and thus cannot achieve a rapid pace in the merged matches, leading to the technical problem of low operability in turn-based games.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a method and apparatus for processing game data, a storage medium, and an electronic device to at least solve the technical problem of low operability in turn-based game matches.

[0006] According to one aspect of the embodiments of this application, a method for processing game data is provided, comprising: responding to a received match merge request, determining the matching degree of candidate match instances based on the difference in match progress between the requesting match instance and candidate match instances, the dynamic intensity of the match, and the predicted probability that the candidate match instance accepts the match merge request; filtering target match instances from a set of candidate match instances based on the matching degree and a dynamic filtering radius, wherein the dynamic filtering radius is a filtering range determined by the state index of the turn-based game in each time window; performing conflict detection on the merge operation data after merging the request match instance and the target match instance based on the historical operation data of the request match instance and the historical operation data of the target match instance to obtain global state data; and sequentially executing each operation in the merge operation data according to the round in the global state data.

[0007] Optionally, the above-mentioned selection of target game instances from the candidate game instance set based on matching degree and dynamic filtering radius includes: when the number of requested game instances is single and the dynamic filtering radius within the first time window in which the current time is located is a first threshold, selecting a first subset of game instances with a number less than or equal to the first threshold from the candidate game instance set based on a first matching degree threshold; when none of the candidate game instances in the first subset of game instances have accepted the game merge request, selecting a second subset of game instances with a number less than or equal to the second threshold from the candidate game instance set based on the dynamic filtering radius within the second time window adjacent to the first time window and the second matching degree threshold, wherein the second subset of game instances has no intersection with the first subset of game instances, and the second threshold is greater than the first threshold; and selecting the target game instance from the second subset of game instances.

[0008] Optionally, the above method further includes: when none of the candidate game instances in the second game instance subset have accepted the game merge request, based on the dynamic filtering radius and the third matching degree threshold within the third time window adjacent to the second time window, selecting a third game instance subset from the candidate game instance set whose number is less than or equal to the third threshold, wherein the third game instance subset has no intersection with the second game instance subset and the first game instance subset, and the third threshold is greater than the second threshold; and determining the first candidate game instance in the third game instance subset that accepts the game merge request as the target game instance.

[0009] Optionally, the above method of selecting target game instances from the candidate game instance set based on matching degree and dynamic filtering radius further includes: when there are multiple request game instances, obtaining the matching degree between any two game instances among the multiple request game instances; when the matching degree is greater than a target threshold, performing game merging processing on multiple request game instances based on the number of game players predefined in turn-based games; and when the matching degree is less than or equal to the target threshold, selecting target game instances from the candidate game instance set based on matching degree and dynamic filtering radius.

[0010] Optionally, the above method further includes: when the number of candidate game instances in the candidate game instance set is less than or equal to the current threshold indicated by the current dynamic filtering radius within the current time window, sending a game merge request to each candidate game instance in the candidate game instance set; and filtering out the target game instance with the highest matching degree from the candidate game instances.

[0011] Optionally, the above method further includes: when the ratio between the virtual resources occupied by background tasks, including turn-based games, and the total virtual resources exceeds a preset limit, selecting a portion of candidate game instances with higher values ​​from the candidate game instance set based on the matching degree; and determining the target game instance from the portion of candidate game instances based on the matching success rate of each candidate game instance in the portion of candidate game instances within the historical time window.

[0012] Optionally, the determination of the matching degree of the candidate game instance based on the difference in game progress between the requesting game instance and the candidate game instance, the game dynamic intensity, and the predicted probability of the candidate game instance accepting the game merge request includes: determining the initial matching value between the requesting game instance and the candidate game instance based on the difference in game progress and the game dynamic intensity; predicting the predicted probability of the candidate game instance accepting the game merge request using the target prediction model; and obtaining the matching degree of the candidate game instance by weighted summation of the initial matching value and the predicted probability.

[0013] Optionally, the above-mentioned conflict detection of the merged operation data after merging the request game instance and the target game instance based on the historical operation data of the request game instance and the target game instance includes: merging the historical operation data of the request game instance and the historical operation data of the target game instance to obtain merged operation data; identifying two merged operations that produce mutually exclusive results on the same target object in the merged global state as conflicting operations, wherein the same target object includes the same virtual character attacked by two virtual characters in the two merged operations in succession, and the mutually exclusive result includes the attribute value of the same virtual character after the two attacks does not meet the logical requirements; and modifying the state variables of each merged operation in the conflicting operations.

[0014] Optionally, the state variables of each merge operation in the above-mentioned conflicting operations include at least one of the following: when the logical timestamps of the two conflicting merge operations are different, first execute the attack operation with the earlier logical timestamp to obtain the current attribute value of the same virtual character after the attack operation; increase the current attribute value and decrease the damage value caused by the other attack operation to the same virtual character, and the state variables include the current attribute value and the damage value; when the logical timestamps of the two conflicting merge operations are the same, determine the operation priority based on the damage value caused by each attack operation and the network latency time; execute the attack operation with the higher priority and perform compensation processing on the state variables of the other attack operation with the lower priority.

[0015] According to another aspect of the embodiments of this application, a game data processing apparatus is also provided, comprising: a first processing unit, configured to, in response to a received game merging request, determine the matching degree of a candidate game instance based on the difference in game progress between the requesting game instance and the candidate game instance, the dynamic intensity of the game, and the predicted probability that the candidate game instance accepts the game merging request; a filtering unit, configured to filter out a target game instance from a set of candidate game instances based on the matching degree and a dynamic filtering radius, wherein the dynamic filtering radius is a filtering range determined by the state index of the turn-based game in each time window; a detection unit, configured to perform conflict detection on the merged operation data after merging the requesting game instance and the target game instance based on the historical operation data of the requesting game instance and the historical operation data of the target game instance, to obtain global state data; and a second processing unit, configured to execute each operation in the merged operation data sequentially according to the round in the global state data.

[0016] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer program, which is used to execute the above-described game data processing method when the electronic device is run.

[0017] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of the above-described method.

[0018] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the game data processing method through the computer program.

[0019] By employing the embodiments provided in this application, the matching degree between the requesting match instance and the candidate match instance is quantified. Based on the calculated matching degree and dynamic filtering radius, the filtering range of candidate match instances that fit the current state is dynamically selected to determine the target match instance to participate in the merging. Finally, based on the historical operation data of the requesting match instance and the target match instance, conflict detection is performed on the merging operation data of the global match instance after merging the requesting match instance and the target match instance to ensure the rationality and fairness of the merging operation data, as well as the consistency and determinism of the global game state after merging. In this way, not only is the filtering efficiency of the candidate match instances participating in the merging improved, but the rationality of the game state after merging is also ensured. This improves the retention rate of each player after merging, increases the duration of game progress, and achieves the technical effect of improving the operability of turn-based games. Attached Figure Description

[0020] The accompanying drawings, which are provided to further illustrate this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application.

[0021] Figure 1 This is a schematic diagram illustrating an application scenario of an optional game data processing method according to an embodiment of this application;

[0022] Figure 2 This is a flowchart of an optional game data processing method according to an embodiment of this application;

[0023] Figure 3 This is an overall architecture diagram of an optional game data processing method according to an embodiment of this application;

[0024] Figure 4 This is a schematic diagram of an optional game data processing device according to an embodiment of this application;

[0025] Figure 5 This is a schematic diagram of the structure of an optional electronic device according to an embodiment of this application. Detailed Implementation

[0026] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0027] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0028] The technical solutions in this application will comply with legal regulations during implementation. When operating according to the technical solutions in the embodiments, the data used will not involve user privacy, ensuring that the operation process is compliant and legal while guaranteeing data security. In addition, when the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use, and processing of related data must comply with the relevant regulations and standards of the relevant countries or regions.

[0029] According to one aspect of the embodiments of this application, a method for processing game data is provided. As an optional implementation, the above-described game data processing method may be applied, but is not limited to, to applications such as... Figure 1 The application scenarios shown are as follows. In, for example... Figure 1 In the application scenario shown, the target terminal 102 can communicate with the server 106 via network 104, but is not limited to this. The server 106 can perform operations on the database 108, such as writing or reading data. The target terminal 102 may include, but is not limited to, a human-computer interaction screen, a processor, and a memory. The human-computer interaction screen may be used to display the game screen after the game is merged using the technical solution of this application on the target terminal 102. The processor may be used to respond to the human-computer interaction operation, execute the corresponding operation, or generate the corresponding instruction and send the generated instruction to the server 106. The memory is used to store relevant processing data, such as target acquisition strategy, acquisition logic, and acquisition parameters.

[0030] Optionally, in this embodiment, the target terminal can be a terminal configured with a target client, which may include, but is not limited to, at least one of the following: mobile phone (such as Android phone, iOS phone, etc.), laptop computer, tablet computer, PDA, MID (Mobile Internet Devices), PAD, desktop computer, smart TV, etc. The target client may be a video client, instant messaging client, browser client, educational client, etc. The network may include, but is not limited to, wired network and wireless network, wherein the wired network includes: local area network, metropolitan area network and wide area network, and the wireless network includes: Bluetooth, WIFI and other networks that enable wireless communication. The server may be a single server, a server cluster composed of multiple servers, or a cloud server.

[0031] The technical solution presented in this application can be widely applied to various turn-based online battle games, not only improving the game's operability but also enhancing the player experience. Furthermore, it can optimize game performance in resource-constrained environments, ensuring a fair, efficient, and enjoyable gaming environment.

[0032] As described in the above embodiments, in traditional turn-based game battles, the large skill gap between randomly matched teams often leads to low game operability. To solve this problem, this application proposes a game data processing method. Figure 2 This is a flowchart of a game data processing method according to an embodiment of this application, which includes the following steps S202 to S208.

[0033] It should be noted that the game data processing methods shown in steps S202 to S208 can be, but are not limited to, executed by an electronic device. The electronic device can be, but is not limited to, [the following]. Figure 1 The target terminal or server shown.

[0034] Step S202: In response to the received game merge request, determine the matching degree of the candidate game instance based on the difference in game progress between the requesting game instance and the candidate game instance, the game dynamic intensity, and the predicted probability that the candidate game instance accepts the game merge request.

[0035] Step S204: Based on the matching degree and the dynamic filtering radius, select target game instances from the candidate game instance set, wherein the dynamic filtering radius is the filtering range determined by the state index of the turn-based game in each time window;

[0036] Step S206: Based on the historical operation data of the requesting game instance and the historical operation data of the target game instance, perform conflict detection on the merged operation data after merging the requesting game instance and the target game instance to obtain global state data.

[0037] Step S208: Execute each operation in the merge operation data sequentially according to the round number in the global state data.

[0038] Before explaining the technical solutions in this embodiment, the technical terms involved in this application will be briefly introduced.

[0039] Match merge request: refers to a request initiated by a player in an ongoing turn-based multiplayer game to merge with other rooms, with the aim of creating a larger-scale game match.

[0040] Request a match example: A player in a room that initiates a merge request, where the room includes at least two teams participating in the match.

[0041] Candidate match instance: A collection of other players in other rooms that may merge with the requested match instance. The other rooms where the candidate match instance is located also include at least two teams participating in the match.

[0042] Game progress difference: The relative difference in game progress between the two rooms can be quantified by normalization.

[0043] Match dynamic strength: A dynamic measure based on the average combat power or rank of players in the room, reflecting the overall strength of the room.

[0044] Upon receiving a match merge request from at least one player in at least one room within an online turn-based game (one player per room corresponds to one match instance), the matching degree is first assessed based on the difference in match progress between the requesting match instance and the potential merge targets (candidate match instances), the match dynamic intensity (average room strength), and the predicted probability of the candidate match instances accepting the merge calculated by the online prediction model (Acceptance Predictor). For example, if room A is looking for a merge target, its average strength is 2000, and its progress is 0.4, and the model predicts that rooms B and C have a 70% and 50% probability of accepting the merge, respectively, then the matching degree between A and B / C will be calculated based on this information. It should be noted that a match instance includes at least two match teams in the turn-based game.

[0045] Based on the matching degree calculated in the first step and the current system's dynamic filtering radius (affected by factors such as resource usage and player demand), the range of candidate match instances is further narrowed down, and the target match instance with the greatest potential for merging is selected. For example, if current resources (such as server memory) are scarce and the dynamic filtering radius is set small, then only those match instances with high matching degrees and most likely to accept the merge request within the current time window will be selected as target match instances.

[0046] The dynamic filtering radius can be, but is not limited to, based on a distributed matching queue and a multi-layer time window strategy, and the diffusion degree (which can also be understood as the filtering range) can be dynamically adjusted. The process of filtering out target game instances based on the dynamic filtering radius will be described in detail below with specific examples.

[0047] After identifying the target game instance and merging the request game instance and the target game instance, the state merger will obtain the historical operation logs (op-logs) of the rooms where the two instances are located, and perform conflict detection according to the predefined conflict resolution strategy.

[0048] Conflict detection determines whether there are logical contradictions in the merged operation data. For example, in the merged operation data, player P1 in room A deals 120 damage to player P5 at game time 100, while player P3 in room B also deals 150 damage to player P5 at the same logical time. The state merger needs to detect this conflicting operation and decide how to reasonably integrate these two operations. Generally, the operation with the shorter logical time is executed first, while the longer operation is converted into an auxiliary or other form of compensation to maintain the continuity and fairness of the game state. However, compensation processing is needed for operations with later logical times.

[0049] The merged global state data contains the latest state and action sequences of all participating players. Based on the timestamps recorded in the action logs, player response latency, and affiliation preferences, the turn order and action priorities of the participants are recalculated to ensure that each action is executed correctly and flawlessly in the merged environment, forming a complete game round.

[0050] In other words, this application provides a turn-based matchmaking system and method based on intelligent prediction and deterministic state merging. It mainly includes: a distributed matchmaking queue, a multi-layer time window matcher, an online acceptance prediction model, a reinforcement learning initiation strategy module, a merge coordinator, a state merger (based on op-log + vector clock / merge sorting + conflict resolution), an auditing module (chained hash audit log), and a resource-aware dynamic concurrency controller. Under the premise of meeting resource constraints, this system can predict the probability of a target room accepting a merge in real time based on characteristics such as match strength, progress, and historical behavior, and optimize the matchmaking order. During merging, it performs deterministic state merging and round reordering based on operation logs. After merging, rewards are distributed through the audit chain according to a predefined contribution calculation formula. Compared to traditional technical solutions, this application provides specific technical implementations in matchmaking decision-making, merge consistency, online learning, and system load management, and can demonstrate quantifiable improvements in system performance and user experience.

[0051] To facilitate understanding, let's first combine... Figure 3 The overall architecture diagram shown further describes the processing method for the aforementioned game data.

[0052] like Figure 3 As shown, the overall system architecture includes, but is not limited to, a receiving module, a matching module, a scheduling module, a merging coordinator, a state merging module, and an auditing module. Each module is described below.

[0053] (1) Receiving module: used to receive merge requests from ongoing games and write the requests to the distributed matching queue;

[0054] (2) Matching module: It is used to calculate the initial matching value based on the combat power value and the progress of the game, and predict the probability of the candidate target game accepting the merge request within the preset time window based on the online machine learning model trained by the historical game logs, and merge the predicted probability with the initial matching value to generate the final matching priority.

[0055] (3) Scheduling module: used to select candidate matches within multiple time windows according to the final matching priority and send them merge invitations;

[0056] (4) Merging coordinator, used to create associated records and trigger the state merger when an acceptance response that meets the predetermined acceptance rules is received;

[0057] (5) State merger, used to pull the operation log of the game to be merged and generate the merged game state according to the predetermined merge sorting rules and conflict resolution strategy, and determine the turn order of the participants after the merge.

[0058] (6) Audit module, used to record key operations and reward allocations during the merger process as a chain audit log for traceability and verification;

[0059] (7) Resource-aware concurrency control: The system monitors resource usage (such as CPU and memory) in real time. When any indicator exceeds the preset threshold, the concurrency merging limit is dynamically adjusted or the time window is expanded to protect system performance and user experience and avoid resource overload.

[0060] (8) Intelligent initiation strategy optimization: The agent makes decisions on whether to initiate a merge through reinforcement learning. The state space covers game characteristics, system load and historical responses. Actions include not initiating, initiating, relaxing thresholds or broadcasting, in order to optimize matching effect and user experience.

[0061] (9) Conflict handling: mainly used for state variable compensation.

[0062] For the conflicting operations after merging, they are sorted according to logical timestamps and damage values. The higher priority ones are executed, and the lower priority ones are adjusted in terms of damage or effect to ensure consistency of state logic. At the same time, the modifications are recorded for auditing purposes.

[0063] The matching module also includes an online Acceptance Predictor, which performs real-time reasoning during the candidate game instance selection phase and incorporates the reasoning results into the final matching priority in the form of weights. The merge coordinator adopts a distributed voting mechanism to implement the majority-subjects-minority acceptance rule when receiving the merge acceptance response. The state merger adopts an operation log-based sorting and conflict resolution algorithm to ensure the determinism and replayability of the merged state.

[0064] The entire system architecture is designed with efficiency, fairness, and transparency in mind. Through technologies such as intelligent prediction, deterministic state merging, and resource-aware control, it optimizes the merging experience in turn-based battle games, improves the matchmaking success rate and player satisfaction, and maintains the system's stable operation and auditability.

[0065] By employing the embodiments provided in this application, the matching degree between the requesting match instance and the candidate match instance is quantified. Based on the calculated matching degree and dynamic filtering radius, the filtering range of candidate match instances that fit the current state is dynamically selected to determine the target match instance to participate in the merging. Finally, based on the historical operation data of the requesting match instance and the target match instance, conflict detection is performed on the merging operation data of the global match instance after merging the requesting match instance and the target match instance to ensure the rationality and fairness of the merging operation data, as well as the consistency and determinism of the global game state after merging. In this way, not only is the filtering efficiency of the candidate match instances participating in the merging improved, but the rationality of the game state after merging is also ensured. This improves the retention rate of each player after merging, increases the duration of game progress, and achieves the technical effect of improving the operability of turn-based games.

[0066] As an optional example, the above method, based on matching degree and dynamic filtering radius, filters target game instances from the candidate game instance set, including:

[0067] When the number of requested game instances is a single instance and the dynamic filtering radius within the first time window at the current time is a first threshold, a first subset of game instances with a number less than or equal to the first threshold is selected from the candidate game instance set based on the first matching degree threshold.

[0068] If none of the candidate game instances in the first game instance subset accept the game merge request, based on the dynamic filtering radius and the second matching degree threshold in the second time window adjacent to the first time window, a second game instance subset with a number less than or equal to the second threshold is selected from the candidate game instance set. The second game instance subset has no intersection with the first game instance subset, and the second threshold is greater than the first threshold.

[0069] Select the target game instance from the second subset of game instances.

[0070] In this embodiment, a distributed matching queue and multi-layer time window filtering mechanism is proposed, which specifically includes: after a player initiates a merge request, the request is written to a distributed message queue (implemented by Kafka). The queue records fields including roomID (unique room identifier), avgPower (average combat power / rank score of the currently active players in the room), progress (match progress, represented by normalized [0,1] values), requestTimestamp (server timestamp (milliseconds) of initiating the merge request), requestingPlayersCount (number of players currently online and eligible to participate in the merge), matchingValue (initial static matching value, normalized to [0,1]), etc.).

[0071] The matcher employs multiple time windows (e.g., Layer 1 = 2s for exact matching, Layer 2 = 4s for expanded matching, Layer 3 = 10s for broadcast / approximate matching), with each layer corresponding to a different candidate filtering radius. It should be noted that one time window corresponds to one round or stage in a turn-based game. The threshold within each time window is dynamically adjusted based on the real-time system state.

[0072] The aforementioned distributed matching strategy includes: a filtering submodule that executes gradients across multiple time windows; each time window can be configured with different filtering radii and approximate query algorithms; and the matcher dynamically adjusts candidate priorities within each time window based on real-time predicted probabilities from the online Acceptance Predictor model. Furthermore, the system also includes a resource-aware control module for dynamically adjusting time window parameters and concurrent merging limits based on real-time monitoring metrics.

[0073] In other words, this embodiment tightly couples the distributed message queue (a merge request structure with signature / verification) with a multi-layer time window matcher, and employs different candidate filtering strategies at each layer (strict threshold → threshold relaxation → approximate retrieval / broadcasting) to provide an adjustable trade-off between latency, acceptance rate, and system load.

[0074] Secondly, the online Acceptance Predictor is used as the core input for decision-making within the time window (i.e., matching priority is no longer based solely on a static threshold, but rather on α·matchingValue + β·p_accept), and the latency and scalability of this prediction are guaranteed in a distributed environment (e.g., batch inference, asynchronous caching strategies). The closed loop of time window triggering and resource-aware control (automatically expanding the time window or reducing the concurrency limit of merging when resources are scarce) is a feedback control engineering design, not a simple time window logic.

[0075] For example, when a player in a room initiates a match merge request, within the first time window (i.e., the first round of filtering), a first threshold of 10 is pre-set based on the system status (such as load, server memory usage, etc.), that is, 10 candidate match instances with a matching degree greater than 90% (the first matching degree threshold) are selected from the candidate pool.

[0076] Assuming that none of the 10 candidate game instances accept the merge request, the diffusion degree is adjusted, and within the second time window (i.e., the second round of screening), based on the changes in the system state, the second threshold is set to 15, that is, 15 candidate game instances with a match greater than 80% are reselected from the candidate pool (these 15 candidate game instances constitute the second game instance subset).

[0077] The game merge request is sent to the 15 candidate game instances selected in the second round, and the target game instance is selected from them.

[0078] As an optional implementation, the above method also includes:

[0079] If none of the candidate game instances in the second game instance subset accept the game merge request, based on the dynamic filtering radius and the third matching degree threshold in the third time window adjacent to the second time window, a third game instance subset with a number less than or equal to the third threshold is selected from the candidate game instance set. The third game instance subset has no intersection with the second game instance subset and the first game instance subset, and the third threshold is greater than the second threshold.

[0080] The first candidate game instance in the third game instance subset that accepts the game merge request is identified as the target game instance.

[0081] As described in the above embodiments, 15 candidate game instances are selected within the second time window. Assuming that none of these 15 candidate game instances accept the game merging request, the selection within the third time window is initiated, i.e., further diffusion. For example, if the system sets the third threshold for the third round to 20 and the third matching threshold to 60%, then 20 candidate game instances with a matching degree greater than 60% will be selected from the game instance set to form the third game instance subset.

[0082] If at least one candidate game instance in the third game instance subset accepts the game merge request, the first candidate game instance to accept the request will be designated as the target game instance. Conversely, if none of the candidate game instances in the third game instance subset accept the game merge request, the game merge process will be terminated to avoid excessive waiting time leading to a poor gaming experience.

[0083] In this embodiment, the determination of whether to accept the match merge request can also be achieved using a merge coordinator and a voting rule (majority rule): after a merge invitation is sent to the target room, the players in the target room give a vote (Accept / Reject) within an acceptance window (e.g., 10 seconds). The merge admission rule can be configured as "majority rule" (i.e., if more than 50% of the players in the target room agree, then the merge is allowed). This vote is collected and calculated on the server side using a distributed transaction method. If multiple candidates agree simultaneously, the scheduler decides the one with the higher priority or selects according to a random fair algorithm.

[0084] By combining intelligent matching algorithms with dynamic filtering strategies, the system can effectively cope with high-concurrency environments, improve the success rate of merging, reduce player waiting time, and enhance the game's appeal while ensuring fairness and fun.

[0085] As an optional example, the above method of selecting target game instances from the candidate game instance set based on matching degree and dynamic filtering radius also includes:

[0086] When there are multiple requested game instances, obtain the matching degree between any two game instances among the multiple requested game instances;

[0087] If the matching degree is greater than the target threshold, multiple request match instances are merged based on the number of players in a match predefined in turn-based games; if the matching degree is less than or equal to the target threshold, the target match instance is selected from the candidate match instance set based on the matching degree and the dynamic filtering radius.

[0088] If there are multiple players initiating match merge requests and multiple rooms, the matching value between the rooms that initiated the request is calculated first. If the matching value is greater than a set threshold (e.g., greater than 90%), the multiple rooms that initiated the request are directly merged. Otherwise, the target match instance is determined using the same diffusion matching method as in the above embodiment.

[0089] When multiple merge requests are received simultaneously from multiple rooms (e.g., rooms A, B, and C) or multiple players within those rooms, the system first calculates the matchability between each pair of rooms. This matchability is based on the average combat power of both sides, match progress, player online status, and the probability of accepting the merge predicted by an online machine learning model driven by historical data. For example, the system might calculate a matchability of 0.95 between rooms A and B, 0.72 between A and C, and 0.58 between B and C. In this case, room A and room B will be merged.

[0090] In this embodiment, the focus is always on improving the player's gaming experience. Through precise matching and acceptance probability prediction, each merge is ensured to be conducted based on a full consideration of player preferences, game status, and system resources. Furthermore, the concept of a dynamic filtering radius allows the system to flexibly adjust the merge strategy within different time windows, ensuring timely response to player needs in high-concurrency environments while avoiding unnecessary resource waste. Ultimately, whether it's directly merging game instances with high matching scores or searching for better merge targets from a broader candidate set, both methods effectively enhance the game's fun, fairness, and player retention rate.

[0091] As another alternative example, the above methods also include:

[0092] If the number of candidate game instances in the candidate game instance set is less than or equal to the current threshold indicated by the current dynamic filtering radius within the current time window, send a game merge request to each candidate game instance in the candidate game instance set.

[0093] Select the target game instance with the highest matching score from the candidate game instances.

[0094] For special time periods (such as early morning) when there are fewer players online, a match merge request is sent directly to the candidate rooms where all candidate match instances are located to speed up the merge process.

[0095] In a high-concurrency gaming environment, an ongoing match (room A) issues a merge request. Based on the system's current time window division (e.g., layer 1 = 2s exact match, layer 2 = 4s expanded match, layer 3 = 10s broadcast / approximate match) and resource monitoring, the system automatically adjusts the dynamic filtering radius and matching threshold. At a certain point, the system enters a time window (let's say layer 3, 10s broadcast / approximate match). At this time, there are exactly 5 match instances in the candidate match instance set that meet the criteria (e.g., 5 players in rooms B to F), and the number of these 5 match instances is exactly equal to or less than the current threshold indicated by the current dynamic filtering radius of layer 3 (e.g., 15). In this case, the system will no longer limit itself to a specific number of matches, but will send match merge requests to these 5 matches (B to F) to maximize the probability of finding acceptable match instances to merge.

[0096] After a merge request is issued, the system will monitor the responses from candidate match instances. Assuming that only room B and room E respond positively after a merge request is broadcast, the system will determine which room will become the target match instance based on their respective match scores (higher match scores indicate a greater skill gap, better progress matching, and a higher likelihood of accepting the merge). If room B has a match score of 0.7 and room E has a match score of 0.75, then the system will determine room E as the target match instance with the highest match score and merge it with room A, which initiated the merge request, in order to create a more balanced and engaging gaming environment.

[0097] This embodiment demonstrates the ability to efficiently and accurately drive merge requests when faced with a limited number of candidate game instances and sufficient system resources. By simplifying the screening process, it directly initiates requests and makes the best selection based on the response, thus accelerating the merge decision-making process and improving the flexibility of game merging.

[0098] In a specific example, the method for determining the target game instance described above can also be understood as an implementation process based on reinforcement learning initiation strategies. Specifically, assuming the state space S={room_features,system_load,last_k_responses}, actions A0 represent not initiating, A1 represent initiating to the Top-K candidate lists (K is a configurable parameter, such as K=3), A2 represent initiating to the candidate set after threshold relaxation, and A3 represent initiating broadcasting (only allowed when resources are sufficient and merging priority is extremely high).

[0099] The aforementioned reinforcement learning initiation strategy also includes a reward mechanism, wherein, after a successful game merge, the reward for each game instance participating in the game merge can be calculated using, but is not limited to, the following formula (1):

[0100] r_t= I_accept / T_wait_norm+ normalized_session_time_delta- I_player_drop+ normalized_engagement_delta (1)

[0101] Specifically, if the session merge request is received within a preset time window, then I_accept = 1; otherwise, it is 0. T_wait_norm is the normalized wait time (the smaller the better), used to encourage fast acceptance. normalized_session_time_delta = (session_time_after_merge - expected_...).

[0102] `session_time_if_no_merge) / max_espected` is used to reward extended session time. If the merge results in key players leaving or disconnecting (penalty), then `I_player_drop` is 1; otherwise, it is 0. `normalized_engagement_delta` measures the change in viewership / interaction (social / spectator) metrics after the merge.

[0103] Case parameters =1.0, =0.5, =2.0 (High penalty to avoid harassment) =0.2; Time window T_wait_norm=min(1,request_wait_ms / 5000).

[0104] The specific process of the algorithm: PPO or off-policy DQN, training is carried out in a simulation environment (the simulation environment is based on historical log replay with random perturbations to simulate real player behavior). To ensure online security, "threshold masking" is used to limit the policy output to a safe set (e.g., no more than the number of times it can be initiated against the same player per hour).

[0105] As another alternative example, the above methods also include:

[0106] If the ratio between the virtual resources occupied by background tasks, including turn-based games, and the total virtual resources exceeds a preset limit, then based on the matching degree, select the candidate game instances with the highest values ​​from the candidate game instance set.

[0107] Based on the matching success rate of each candidate game instance in a subset of candidate game instances within a historical time window, the target game instance is determined from the subset of candidate game instances.

[0108] In this embodiment, a method is also provided that relies on an agent to initiate a game merging request to a specific candidate room, the purpose of which is to save computing resources and improve matching efficiency.

[0109] Specifically, a reinforcement learning-based intelligent initiation strategy is used to determine whether to initiate a merge request to a specific candidate room. The decision-making process involves an RL agent whose state includes the game's feature vector, system load information, and historical responses (such as the cumulative number of merge requests accepted within a historical period). The action is to initiate / not initiate / select a candidate set. The reward function considers a weighted combination of match success rate, platform retention, and instantaneous user experience, and employs a protection strategy to avoid excessive player disruption.

[0110] The agent receives the current game state and system context state S, and outputs action A: {Do not initiate, initiate to candidate set C1, initiate to candidate set C2...}. The goal is to maximize long-term rewards (balancing match success rate, session duration, and platform retention) and to constrain harassing behavior through security policies.

[0111] For example, if the requesting game instance that initiates the game merge request has specific candidate game instances that it wants to merge with (e.g., the four candidate rooms where players 2 to 5, who are friends with player 1 who initiated the request, are located), the intelligent agent will actively filter and focus on those game instances with high matching degree through computation, reducing unnecessary computation and communication overhead.

[0112] Furthermore, by analyzing historical data, the merge strategy is further refined, selecting match instances that demonstrated high merge success rates within past time windows as targets. This strategy not only ensures a smooth and fair competitive environment even with limited resources, but also improves the response speed and success rate of merge requests through intelligent analysis, enhancing player satisfaction and game appeal.

[0113] As an optional example, the above determination of the matching degree of candidate game instances based on the difference in game progress between the requesting game instance and the candidate game instance, the dynamic intensity of the game, and the predicted probability that the candidate game instance will accept the game merge request includes:

[0114] Based on the difference in game progress and the dynamic intensity of the game, determine the initial matching value between the request game instance and the candidate game instance;

[0115] Using a target prediction model, predict the probability that a candidate game instance will accept a game merge request;

[0116] The matching degree of candidate game instances is obtained by weighted summation of the initial matching value and the predicted probability.

[0117] In this embodiment, the matching degree between game instances or between the rooms where game instances are located is calculated by fusing matching value calculation with the Acceptance prediction model.

[0118] Specifically, the initial matching value between the request game instance and the candidate game instance is first calculated using the following formula (2):

[0119] matchingValue= ×normPowerDiff+ ×progressFactor+ ×instabilityFactor (2)

[0120] Where normPowerDiff = 1 - |avgPower_A - avgPower_B| / maxPowerRange (the higher the similarity, the closer it is to 1), A and B are different game instances or different rooms where two different game instances are located. progressFactor = 1 - |progress_A - progress_B|; instabilityFactor = f(remainingTurns, varianceOfDamage) (the closer to the end or the more unstable, the more likely to merge). All of the above are data after normalization. , , The weights are configurable. The matchingValue is only a static part of the candidate scores, which is then fused with p_accept (predicted probability) to generate the final priority.

[0121] normPowerDiff can be, but is not limited to, the power difference between two rooms; progressFactor can be, but is not limited to, a normalized indicator of the difference in game progress between two rooms; and instabilityFactor can be, but is not limited to, a normalized indicator of the degree of fluctuation in the situation within a room.

[0122] After calculating the initial matching value, the final matching degree or matching priority is calculated using the following formula (3):

[0123] Priority= ×matchingValue+ ×p_accept (3)

[0124] Among them, p_accept is a real-time prediction of the probability that a candidate room containing a candidate game instance will accept a game merge request, which is made by a pre-deployed online model (Acceptance Predictor).

[0125] The calculation of the final matching priority mentioned above supports offline training (historical logs) and online incremental updates, with an online inference latency target of less than 30ms.

[0126] It should be noted that the features used in predicting the acceptance probability using the above online model include:

[0127] (1) Room level: avgPower, progress, remainingTurns, current HP distribution, average player level, current average network latency;

[0128] (2) Player history: average player acceptance rate, the last 5 acceptance / rejection behaviors, and player activity cycle (hours);

[0129] (3) System level: time period (peak / off-peak), server load.

[0130] Model architecture: Lightweight Gradient Boosting Tree (LightGBM), offline training + online fine-tuning. The training objective is binary classification: whether to accept (1) or reject (0) within a window. The loss function is cross-entropy, and the evaluation metrics are AUC, accuracy, and F1. Online inference requires a latency of less than 30ms and supports batch inference.

[0131] Training and Deployment: The training set is built offline by sampling from historical logs, and sample reweighting is supported to solve class imbalance; the model is deployed using the model service (lightweight inference service) and the model is fine-tuned daily using a sliding window.

[0132] The above process considers both the state characteristics of the game and incorporates player behavior prediction, achieving a perfect combination of static analysis and dynamic prediction. Through this mechanism, the system can effectively improve the response rate of merge requests and player satisfaction while maintaining game balance and fun, reducing negative emotions caused by players waiting for matchmaking, and enhancing the game's appeal and user stickiness.

[0133] As an optional example, the above-mentioned conflict detection is performed on the merged operation data after merging the requesting game instance and the target game instance, based on the historical operation data of the requesting game instance and the target game instance, including:

[0134] The historical operation data of the requesting game instance and the historical operation data of the target game instance are merged to obtain merged operation data.

[0135] Two merge operations that produce mutually exclusive results on the same target in the merged global state are identified as conflicting operations. The same target includes the same virtual character that is attacked by two virtual characters in the two merge operations one after the other. The mutually exclusive result includes the attribute value of the same virtual character that does not meet the logical requirements after the two attacks.

[0136] Modify the state variables of each merge operation in a conflicting operation.

[0137] After identifying the target game instance and successfully merging it, conflict detection needs to be performed on the merged global state data, especially to check whether there are mutually exclusive results between the merged operation data. Specifically, this is achieved through the StateMerger.

[0138] Example conflict resolution strategy: When two operations are mutually exclusive (e.g., simultaneous attacks that may determine the survival of the target), priority is calculated based on the operation's timestamp plus damage weight; if a conflict still exists, a compensation event is generated (e.g., the result of the first operation is retained, and the other operation is converted to approximate damage / assist). Conflict resolution must ensure idempotency and traceability.

[0139] In this embodiment, the data structure used in the op-log driven deterministic state merging process is op-log entry:{opID,roomID,playerID,lamportClock,wallTime, actionType,params,checksum}; roomPriority is calculated by the merging coordinator for each room before merging (e.g., based on roomStartTime or room priority strategy) as a secondary key for sorting.

[0140] The state merger sorts and applies operations sequentially according to logicalClock, roomPriority, and actionTimestamp, employing a conflict resolution strategy (e.g., attacks on the same target with mutually exclusive results are merged according to damage ratio, and a compensation event is generated). The round order is rearranged using the MergeTurnOrder algorithm (which considers the original room turnIndex, player response latency, and ownership preferences), ensuring that the merged result is deterministic and replayable.

[0141] A sorting key is set (to determine the order in which operations are applied). The primary sorting key is LamportClock (a Lamport logical clock, used to maintain causal order); the secondary sorting key is roomPriority, used to ensure a deterministic order across rooms; and the final sorting key is (wallTime, opID), used to ensure total order and idempotency. The sorting rule guarantees determinism by ensuring that, given the same op-log set and the same sorting rule, MergerOrder is unique and the merged result is deterministic.

[0142] In a specific example, the definition of conflicting operations can be, but is not limited to, two operations that cannot be simultaneously valid or mutually affect the results in the merged state. For example, "lethal attacks" targeting the same objective may be mutually exclusive in a short period of time (that is, "conflict" refers to two operations that produce mutually exclusive results on the same target in the same global state after merging, making it impossible for them to be valid at the same time and requiring priority adjudication and compensation through deterministic rules).

[0143] The detection method is as follows: for each operation (op), before applying it, check whether its target object (e.g., targetplayer) still exists in mergedState or has enough properties to satisfy the action precondition. If not, it is marked as a conflict ("conflict" refers to an operation conflict, that is, the merge operation to be executed does not meet its precondition, causing the operation to be unable to be legally applied; it is different from the state conflict caused by multiple operations modifying the same state variable at the same time, the latter only occurs in the subsequent priority decision stage).

[0144] If conflicting operations are detected in the merged data using the methods described above, a supplementary operation will be performed.

[0145] In an optional example, compensation can be performed, but is not limited to, in one of the following ways:

[0146] If two conflicting merge operations have different logical timestamps, the attack operation with the earlier logical timestamp is executed first to obtain the current attribute value of the same virtual character after the attack operation; the current attribute value is increased, and the damage value caused by the other attack operation to the same virtual character is decreased. The state variables include the current attribute value and the damage value.

[0147] When two conflicting merge operations have the same logical timestamp, the operation priority is determined based on the damage value caused by each attack operation and the network latency time; the attack operation with higher priority is executed, and the state variable of the other attack operation with lower priority is compensated.

[0148] Assuming that conflict detection and compensation operations are performed on the merged data opA and opB, the conflict resolution strategy is as follows:

[0149] If opA and opB conflict and their lamportClock (a logical clock that creates a fully ordered and causally consistent logical timestamp for each operation, ensuring that operations from different rooms are always executed in a deterministic causal order during merge replay, thus guaranteeing the uniqueness and replayability of mergedState) are different, then the one with the smaller lamportClock will be executed first; the latter will trigger a compensation event (such as converting damage into an assist, or reducing damage proportionally).

[0150] If the LamportClock is the same, compare damage or effectivenessScore = f(playerLatency, actionTimestamp, damage), with the higher one taking precedence; the lower one triggers compensation. Here, damage can be understood as the original instantaneous damage value of the operation (e.g., atk=150), and effectivenessScore can be understood as the overall utility score synthesized according to rules or the action priority weight. Essentially, it weights and normalizes "network latency + dispatch time + damage amount" to determine the order of two merged operations when Lamport clocks are the same and a secondary sorting is required.

[0151] It should be noted that all compensations are recorded as new ops (compensate_op) and written into the audit chain to ensure traceability.

[0152] The conflict detection process and results described above are replayable because each operation or each operation record (op) has a unique opID + checksum. StateMerger checks whether the op is already in the appliedSet of mergedState (idempotency) before applying it.

[0153] Since the sorting key is deterministic, given the same op-log, the same mergedState will be obtained, which can be used for replay and auditing.

[0154] For example, room A's op: (lamport=100, P1 attack P5 dmg=120@t=100), room B's op: (lamport=101, P3 attack P5 dmg=150@t=101), sorted first A then B. If room A has already killed the player-controlled virtual character P5, then B is in conflict, and B becomes the assistant; the assistant op's checksum is added to the audit chain.

[0155] In addition, the system monitors metrics such as CPU, memory, network bandwidth, and P95 latency in real time. When resources exceed the threshold, a feedback controller (such as a simplified PID or threshold backoff algorithm) is used to automatically reduce and merge room limits or expand the time window to protect service quality.

[0156] In other words, this application embodiment also introduces resource-aware concurrency control and a contribution and reward distribution mechanism. During resource-aware concurrency control, the system monitors and ensures M={CPU, Mem, NetOut, P95Latency, MatchQueueLen}, and defines a threshold set T={T_cpu, T_mem, T_net, T_lat}. The controller pulls indicators at intervals ΔT (e.g., 1 second). If any indicator exceeds the threshold, a backoff is executed; the current allowed concurrency merging limit L=max(L_min, L-ΔL). When the indicators recover to the safe range, L is gradually restored. The controller can be implemented using simple PID control or threshold rules, and adjustment logs are recorded for offline analysis.

[0157] The normalization of contribution is as follows (4):

[0158] Contribution_i = normalize( damage_i+ assist_i+ objectivePoints_i+ survivalTime_i) (4)

[0159] VictoryBonus=baseVictoryPoints (1 + mergeStageBonusFactor), the final reward distribution: Reward_i = VictoryBonus Contribution_i / All allocation actions and intermediate calculation summaries are written into the audit chain to ensure traceability and dispute resolution. That is, rewards are distributed after contribution is normalized, and reward allocation records are also written into the tamper-proof audit chain for future verification.

[0160] Additionally, assuming that after the first round following the merger, a player in either room A or room B is dissatisfied with the current state (e.g., their current health is significantly lower than their actual health), the dispute can be resolved through an audit. The player can also choose to quit the game, meaning they only participated in the first round after the merger.

[0161] Based on the analysis of the above embodiments, it can be seen that the main problems solved by this embodiment include: 1) In a massive concurrent game environment, how to improve the match acceptance rate of game merging and reduce player waiting time within a limited waiting window; 2) After merging multiple games, how to ensure the consistency of the global state after merging, deterministic replay capability and conflict resolution, instead of simply broadcasting all views and generating a large amount of communication overhead; 3) How to dynamically set the concurrency limit of merging and ensure low latency and high throughput without overloading the system; (3) How to allocate rewards after merging to ensure transparency, fairness and auditability.

[0162] To this end, a complete set of engineering technology chains for merging game gameplay, as shown in the above embodiments, is proposed, including: 1) online acceptance probability prediction based on historical behavior and fusion with static matching values ​​to optimize matching priority; 2) multi-layer time window and distributed matcher design to improve matching efficiency in concurrent environments; 3) deterministic state merging and conflict resolution algorithm based on operation log (op-log) to ensure consistency and replayability of merged states; 4) reinforcement learning agent for initiating policy optimization; 5) chain audit and contribution allocation mechanism; (6) resource-aware dynamic concurrency control.

[0163] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0164] According to another aspect of the embodiments of this application, as follows is also provided Figure 4 A game data processing apparatus is shown, the apparatus comprising:

[0165] The first processing unit 402 is configured to respond to the received game merging request by determining the matching degree of the candidate game instance based on the difference in game progress between the requesting game instance and the candidate game instance, the game dynamic intensity, and the predicted probability that the candidate game instance accepts the game merging request.

[0166] The filtering unit 404 is used to filter target game instances from the candidate game instance set based on matching degree and dynamic filtering radius, wherein the dynamic filtering radius is the filtering range determined by the state index of the turn-based game in each time window;

[0167] The detection unit 406 is used to perform conflict detection on the merged operation data after merging the request game instance and the target game instance based on the historical operation data of the request game instance and the historical operation data of the target game instance, so as to obtain global state data.

[0168] The second processing unit 408 is used to execute each operation in the merge operation data in sequence according to the round in the global state data.

[0169] Optionally, the above-mentioned filtering unit 404 includes:

[0170] The first filtering module is used to filter out a first subset of game instances with a number less than or equal to the first threshold from the candidate game instance set, based on the first matching degree threshold, when the number of requested game instances is a single instance and the dynamic filtering radius within the first time window at the current time is a first threshold.

[0171] The second filtering module is used to filter out a second subset of game instances from the candidate game instance set, based on the dynamic filtering radius and the second matching degree threshold within the second time window adjacent to the first time window, when none of the candidate game instances in the first game instance subset have accepted the game merge request. The second subset of game instances has no intersection with the first game instance subset, and the second threshold is greater than the first threshold.

[0172] The third filtering module is used to filter out target game instances from the second subset of game instances.

[0173] Optionally, the above-mentioned device further includes:

[0174] The third processing unit is used to, when none of the candidate game instances in the second game instance subset have accepted the game merge request, select a third game instance subset from the candidate game instance set whose number is less than or equal to the third threshold based on the dynamic filtering radius in the third time window adjacent to the second time window and the third matching degree threshold. The third game instance subset has no intersection with the second game instance subset and the first game instance subset, and the third threshold is greater than the second threshold.

[0175] The fourth processing unit is used to determine the first candidate game instance in the third game instance subset that accepts the game merge request as the target game instance.

[0176] Optionally, the above-mentioned filtering unit 404 further includes:

[0177] The first acquisition module is used to acquire the matching degree between any two game instances when there are multiple request game instances.

[0178] The first processing module is used to merge multiple request game instances based on the number of players in a predefined game for turn-based games when the matching degree is greater than the target threshold; and to select the target game instance from the candidate game instance set based on the matching degree and the dynamic filtering radius when the matching degree is less than or equal to the target threshold.

[0179] Optionally, the above-mentioned device further includes:

[0180] The first sending unit is configured to send a game merge request to each candidate game instance in the candidate game instance set when the number of candidate game instances in the candidate game instance set is less than or equal to the current threshold indicated by the current dynamic filtering radius within the current time window.

[0181] The fifth processing unit is used to filter out the target game instance with the highest matching degree from the candidate game instances.

[0182] Optionally, the above-mentioned device further includes:

[0183] The sixth processing unit is used to filter out the candidate game instances with the highest values ​​from the candidate game instance set based on the matching degree when the ratio between the virtual resources occupied by background tasks, including turn-based games, and the total virtual resources exceeds a preset limit.

[0184] The seventh processing unit is used to determine the target game instance from the partial candidate game instances based on the matching success rate of each candidate game instance in the partial candidate game instances within the historical time window.

[0185] Optionally, the first processing unit 402 includes:

[0186] The second processing module is used to determine the initial matching value between the request game instance and the candidate game instance based on the difference in game progress and the dynamic intensity of the game.

[0187] The first prediction module is used to predict the probability that a candidate game instance will accept a game merge request using the target prediction model.

[0188] The third processing module is used to obtain the matching degree of candidate game instances by weighted summation of the initial matching value and the predicted probability.

[0189] Optionally, the detection unit 406 includes:

[0190] The merging module is used to merge the historical operation data of the requesting game instance and the target game instance to obtain merged operation data;

[0191] The fourth processing module is used to identify two merge operations that produce mutually exclusive results on the same target in the merged global state as conflicting operations. The same target includes the same virtual character that is attacked by two virtual characters in the two merge operations one after the other, and the mutually exclusive result includes the attribute value of the same virtual character that does not meet the logical requirements after the two attacks.

[0192] The modification module is used to modify the state variables of each merge operation in a conflicting operation.

[0193] Optionally, the above-mentioned modified module includes:

[0194] The first processing submodule is used to perform at least one of the following: when the logical timestamps of two conflicting merge operations are different, first execute the attack operation with the earlier logical timestamp to obtain the current attribute value of the same virtual character after the attack operation; increase the current attribute value and decrease the damage value caused by the other attack operation to the same virtual character, and the state variables include the current attribute value and the damage value; when the logical timestamps of two conflicting merge operations are the same, determine the operation priority based on the damage value caused by each attack operation and the network latency time; execute the attack operation with the higher priority and perform compensation processing on the state variables of the other attack operation with the lower priority.

[0195] It should be noted that the embodiments of the game data processing device described here can refer to the embodiments of the game data processing method described above, and will not be repeated here.

[0196] According to another aspect of the embodiments of this application, an electronic device for implementing the above-described game data processing method is also provided. This electronic device may be... Figure 1 The target terminal or server is shown. This embodiment uses the electronic device as an example to illustrate the concept. Figure 5 As shown, the electronic device includes a memory 502 and a processor 504. The memory 502 stores a computer program, and the processor 504 is configured to execute the steps of any of the above method embodiments through the computer program.

[0197] Optionally, the aforementioned electronic device may be located in at least one of a plurality of network devices of the computer.

[0198] Optionally, the processor described above can be configured to perform the following steps via a computer program:

[0199] S1, in response to the received game merge request, determines the matching degree of the candidate game instance based on the difference in game progress between the requesting game instance and the candidate game instance, the game dynamic intensity, and the predicted probability that the candidate game instance accepts the game merge request.

[0200] S2, based on matching degree and dynamic filtering radius, selects target game instances from the candidate game instance set, where the dynamic filtering radius is the filtering range determined by the state index of the turn-based game in each time window;

[0201] S3, based on the historical operation data of the requesting game instance and the historical operation data of the target game instance, performs conflict detection on the merged operation data after merging the requesting game instance and the target game instance to obtain global state data;

[0202] S4 is used to execute each operation in the merge operation data sequentially according to the round in the global state data.

[0203] Alternatively, as those skilled in the art will understand, Figure 5 The structure shown is for illustrative purposes only. Figure 5 This does not limit the structure of the aforementioned electronic devices or electronic equipment. For example, electronic devices or electronic equipment may also include components that are more... Figure 5 The more or fewer components shown (such as network interfaces, etc.), or having the same Figure 5 The different configurations shown.

[0204] The memory 502 can be used to store software programs and modules, such as the program instructions / modules corresponding to the game data processing method and apparatus in this embodiment. The processor 504 executes various functional applications and data processing by running the software programs and modules stored in the memory 502, thereby realizing the aforementioned game data processing method. The memory 502 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 502 may further include memory remotely located relative to the processor 504, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. Specifically, the memory 502 may be used, but is not limited to, to store predicted probabilities, dynamic screening radii, and global state data. As an example, such as... Figure 5 As shown, the memory 502 may include, but is not limited to, the first processing unit 402, the filtering unit 404, the detection unit 406, and the second processing unit 408 in the game data processing device. Furthermore, it may include, but is not limited to, other module units in the game data processing device, which will not be elaborated upon in this example.

[0205] Optionally, the transmission device 506 described above is used to receive or send data via a network. Specific examples of the network described above may include wired networks and wireless networks. In one example, the transmission device 506 includes a Network Interface Controller (NIC), which can be connected to other network devices and a router via a network cable to communicate with the Internet or a local area network. In another example, the transmission device 506 is a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0206] In addition, the aforementioned electronic device also includes: a display 508 for displaying the game screen of a turn-based game; and a connection bus 510 for connecting the various module components in the aforementioned electronic device.

[0207] In other embodiments, the target terminal or server described above can be a node in a distributed system. This distributed system can be a blockchain system, formed by connecting multiple nodes through network communication. The nodes can form a point-to-point network, and any type of computing device, such as a server or target terminal, can become a node in the blockchain system by joining this point-to-point network.

[0208] According to another aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the game data processing method provided in various optional implementations of the above-described server verification processing, wherein the computer program is configured to execute the steps in any of the above-described method embodiments at runtime.

[0209] Optionally, in this embodiment, the computer-readable storage medium described above may be configured to store a computer program for performing the following steps:

[0210] S1, in response to the received game merge request, determines the matching degree of the candidate game instance based on the difference in game progress between the requesting game instance and the candidate game instance, the game dynamic intensity, and the predicted probability that the candidate game instance accepts the game merge request.

[0211] S2, based on matching degree and dynamic filtering radius, selects target game instances from the candidate game instance set, where the dynamic filtering radius is the filtering range determined by the state index of the turn-based game in each time window;

[0212] S3, based on the historical operation data of the requesting game instance and the historical operation data of the target game instance, performs conflict detection on the merged operation data after merging the requesting game instance and the target game instance to obtain global state data;

[0213] S4 is used to execute each operation in the merge operation data sequentially according to the round in the global state data.

[0214] Optionally, in embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0215] Optionally, in this embodiment, those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the target terminal. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0216] The sequence numbers of the embodiments in this application are merely for description and do not represent the superiority or inferiority of the embodiments. If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part 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 one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods in the various embodiments of this application.

[0217] In the above embodiments of this application, the descriptions of each embodiment have their own emphasis. Parts not described in detail in a certain embodiment can be referred to in the relevant descriptions of other embodiments. It should be understood that the disclosed client can be implemented in other ways in the several embodiments provided in this application. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling or direct coupling or communication connection may be through some interfaces; the indirect coupling or communication connection of units or modules may be electrical or other forms.

[0218] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units described above can be implemented in hardware or as software functional units.

[0219] The above are merely preferred embodiments of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for processing game data, characterized in that, include: In response to a received game merge request, the matching degree of the candidate game instance is determined based on the difference in game progress between the requesting game instance and the candidate game instance, the game dynamic intensity, and the predicted probability that the candidate game instance accepts the game merge request. Based on the matching degree and the dynamic filtering radius, target game instances are filtered from the candidate game instance set, wherein the dynamic filtering radius is the filtering range determined by the state index of the turn-based game in each time window; Based on the historical operation data of the request game instance and the historical operation data of the target game instance, conflict detection is performed on the merged operation data after merging the request game instance and the target game instance to obtain global state data. According to the rounds in the global state data, each operation in the merge operation data is executed sequentially.

2. The method according to claim 1, characterized in that, The step of selecting target game instances from the candidate game instance set based on the matching degree and dynamic filtering radius includes: When the number of requested game instances is single and the dynamic filtering radius within the first time window of the current time is a first threshold, a first subset of game instances with a number less than or equal to the first threshold is filtered out from the candidate game instance set based on a first matching degree threshold. If none of the candidate game instances in the first game instance subset accept the game merging request, based on the dynamic filtering radius and the second matching degree threshold in the second time window adjacent to the first time window, a second game instance subset with a number less than or equal to the second threshold is selected from the candidate game instance set, wherein the second game instance subset has no intersection with the first game instance subset, and the second threshold is greater than the first threshold. The target game instance is selected from the second subset of game instances.

3. The method according to claim 2, characterized in that, The method further includes: If none of the candidate game instances in the second game instance subset accept the game merging request, based on the dynamic filtering radius and the third matching degree threshold in the third time window adjacent to the second time window, a third game instance subset with a number less than or equal to the third threshold is selected from the candidate game instance set. The third game instance subset has no intersection with the second game instance subset and the first game instance subset, and the third threshold is greater than the second threshold. The first candidate game instance in the third subset of game instances that accepts the game merging request is determined as the target game instance.

4. The method according to claim 1, characterized in that, The step of selecting target game instances from the candidate game instance set based on the matching degree and dynamic filtering radius further includes: When there are multiple request game instances, the matching degree between any two game instances among the multiple request game instances is obtained; If the matching degree is greater than the target threshold, the multiple request match instances are merged based on the number of players in the predefined match in the turn-based game; if the matching degree is less than or equal to the target threshold, the target match instance is selected from the candidate match instance set based on the matching degree and the dynamic filtering radius.

5. The method according to claim 1, characterized in that, The method further includes: If the number of candidate game instances in the candidate game instance set is less than or equal to the current threshold indicated by the current dynamic filtering radius within the current time window, the game merge request is sent to each candidate game instance in the candidate game instance set. The target game instance with the highest matching degree is selected from the candidate game instances.

6. The method according to claim 1, characterized in that, The method further includes: If the ratio between the virtual resources occupied by background tasks, including the turn-based game, and the total virtual resources exceeds a preset limit, then based on the matching degree, select the candidate game instances with the highest values ​​from the candidate game instance set. The target game instance is determined from the candidate game instances based on the matching success rate of each candidate game instance in the partial candidate game instances within the historical time window.

7. The method according to claim 1, characterized in that, The determination of the matching degree of the candidate game instance based on the difference in game progress between the requesting game instance and the candidate game instance, the dynamic intensity of the game, and the predicted probability that the candidate game instance accepts the game merging request includes: Based on the difference in game progress and the dynamic intensity of the game, an initial matching value is determined between the requested game instance and the candidate game instance; Using a target prediction model, predict the probability that the candidate game instance will accept the game merge request; The matching degree of the candidate game instance is obtained by weighted summation of the initial matching value and the predicted probability.

8. The method according to claim 1, characterized in that, The step of performing conflict detection on the merged operation data of the requesting game instance and the target game instance based on the historical operation data of the requesting game instance and the target game instance includes: The historical operation data of the requesting game instance and the historical operation data of the target game instance are merged to obtain the merged operation data. Two merge operations that produce mutually exclusive results on the same target in the merged global state are identified as conflicting operations. The same target includes the same virtual character that is attacked by two virtual characters in the two merge operations in succession. The mutually exclusive result includes the attribute value of the same virtual character that does not meet the logical requirements after the two attacks. Modify the state variables of each merge operation in the conflicting operations.

9. The method according to claim 8, characterized in that, The modification of the state variables of each merge operation in the conflicting operations includes at least one of the following: If the two merging operations that conflict have different logical timestamps, the attack operation with the earlier logical timestamp is executed first to obtain the current attribute value of the same virtual character after the attack operation; the current attribute value is increased, and the damage value caused to the same virtual character by the other attack operation is decreased. The state variable includes the current attribute value and the damage value. In the case where the logical timestamps of the two conflicting merge operations are the same, the operation priority is determined based on the damage value caused by each attack operation and the network latency time. Execute the attack operation with higher priority, and compensate the state variables of the other attack operation with lower priority.

10. A device for processing game data, characterized in that, include: The first processing unit is configured to, in response to a received game merging request, determine the matching degree of the candidate game instance based on the difference in game progress between the requesting game instance and the candidate game instance, the game dynamic intensity, and the predicted probability that the candidate game instance accepts the game merging request. A filtering unit is used to filter target game instances from a set of candidate game instances based on the matching degree and the dynamic filtering radius, wherein the dynamic filtering radius is a filtering range determined by the state index of the turn-based game within each time window. The detection unit is used to perform conflict detection on the merged operation data of the request game instance and the target game instance based on the historical operation data of the request game instance and the historical operation data of the target game instance, so as to obtain global state data. The second processing unit is used to execute each operation in the merge operation data sequentially according to the round in the global state data.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein the program can be executed by a terminal device or computer at runtime as described in any one of claims 1 to 9.

12. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to perform the method as described in any one of claims 1 to 9 via the computer program.

Images