A method and system for dynamic priority allocation in a gaming room

Abstract

This invention discloses a dynamic priority allocation method and system for game rooms, belonging to the field of internet game technology. Addressing the problems of insufficient fairness in existing game matchmaking, server load imbalance, rudimentary state control, and rigid match-starting mechanisms, this invention collects dynamic room parameters on the server side and calculates room priority values ​​using a multi-dimensional weighted approach, incorporating factors such as player level distribution and server node CPU load rate. A reinforcement learning model is used to adaptively iterate the weight coefficients. A closed-loop state machine is constructed to achieve room state control and abnormal transaction rollback. A unified server clock ensures precise countdown synchronization, and a dynamic match-starting mechanism and AI-powered player replacement mechanism are also included. This invention effectively improves matchmaking fairness and server load balancing, enhances system stability, and increases room flow efficiency. It is applicable to room scheduling and player matchmaking scenarios in various multiplayer online games.

Description

Technical Field

[0001] This invention belongs to the field of internet game technology, specifically relating to a method and system for dynamic priority allocation of game rooms, which is particularly suitable for room scheduling and player matching scenarios in multiplayer online competitive games and casual matchmaking games. Background Technology

[0002] As the user base of massively multiplayer online games (MMORPGs) continues to expand, the efficiency of game room scheduling and player matching directly impacts player experience and server load balancing. Most existing game room matching and priority allocation schemes employ fixed priority rules or single-dimensional sorting methods, relying solely on simple parameters such as the number of players in the room and waiting time for matching and allocation. These schemes suffer from numerous technical flaws in actual operation, including: Insufficient matchmaking fairness: The system does not consider differences in player levels or the balance of competitive skill, which can easily lead to rooms with vastly different player skill levels, reducing the gaming experience. Some systems do not have a safety net for level differences, which can result in a significant gap in player levels within a room in extreme cases, affecting game balance.

[0003] Server load imbalance: Priority calculation does not take into account the CPU load status of server nodes, which can easily lead to high-load nodes taking on a large number of matching requests, exacerbating server lag and latency issues. At the same time, low-load nodes have low resource utilization and unreasonable resource scheduling.

[0004] The weighting rules are rigid and inflexible: the priority weighting coefficient uses a preset fixed value, which cannot be adaptively adjusted according to historical matching success rate and server load fluctuations. After long-term operation, the matching efficiency continues to decline and it is difficult to adapt to player traffic fluctuations and server status changes.

[0005] The room status management is rudimentary: there is a lack of a sound state machine closed-loop management mechanism, and there is no transaction rollback capability for abnormal termination events; the countdown synchronization relies on the client's local clock, which is prone to timing deviations across multiple terminals, leading to chaotic start times; resource release lacks transaction control, which can easily lead to memory leaks and session remnants.

[0006] The rigid match start mechanism relies solely on the end of the countdown or when the room is full to trigger the start of the match. When there are not enough players, the room remains empty for a long time, reducing the efficiency of room turnover. The timing of the start of the match is not dynamically adjusted based on server load and player behavior, making it difficult to balance match start efficiency and player retention.

[0007] In summary, existing game room priority allocation schemes cannot simultaneously ensure matchmaking fairness, server load balancing, room transfer efficiency, and operational stability, and therefore cannot meet the efficient, stable, and fair scheduling requirements of large-scale online games. Summary of the Invention

[0008] In view of the above-mentioned defects in the existing technology, the purpose of this invention is to provide a dynamic priority allocation method and system for game rooms, which overcomes the drawbacks of traditional fixed priority and single-dimensional matching.

[0009] The technical solution adopted by this invention to solve its technical problem is as follows: In a first aspect, the present invention provides a method for dynamic priority allocation of game rooms, wherein the server performs the following steps: S1 collects dynamic status parameters of the room, including the current number of players, room capacity limit, remaining countdown time, server node load rate, and player level distribution data. S2 configures a baseline countdown duration associated with the room type, and calculates the room priority value by weighted summation based on dynamic weight coefficients and dynamic status parameters. The priority value is obtained by weighted summation of player percentage, countdown percentage, reciprocal of matching balance parameter, and reciprocal of load rate. The dynamic weight coefficient is adaptively updated based on historical matching success rate and server load fluctuation amplitude through reinforcement learning model. S3 responds to new player matchmaking requests, filters available rooms and sorts them in descending order of priority value, assigning new players to the rooms with the highest priority value; if priority values ​​are the same, they are assigned in ascending order of room creation time. S4: Construct a game room state machine that includes idle, waiting, and game states, and generate a state snapshot containing core parameters before state transition; S5, State Machine Transition: After the first player joins an empty room, a countdown begins and the room transitions to a waiting state. In the waiting state, the server maintains the countdown duration and broadcasts a synchronization data packet containing the current remaining countdown duration to the client. When the number of players reaches the limit or the countdown reaches zero, the room transitions to the match state. If an abnormal termination event is detected during the match, a transaction rollback is performed based on the state snapshot, restoring the room state to the waiting state and triggering a recalculation of the priority value.

[0010] Furthermore, the state machine also includes an end state, forming a closed-loop transition from idle, waiting, in-game, end, and idle. When the preset game end condition is met, the room transitions from the in-game state to the end state. When the duration of the end state reaches the preset data retention time, the room data is cleared and the room transitions to the idle state.

[0011] Furthermore, when a room transitions from an ended state to an idle state, player sessions are released, runtime memory is cleared, and room state variables are reset in a preset order. If any release step fails, the room is rolled back to the ended state, the exception is recorded, and the room is automatically retried. The number of retries does not exceed a preset limit.

[0012] Furthermore, the server receives synchronization correction requests reported by clients when the deviation between the local countdown and the server's synchronized data exceeds a threshold, and rebroadcasts the calibrated remaining countdown duration and corresponding timestamp to all clients in the room.

[0013] Furthermore, during the waiting period, if the current number of players is less than the minimum starting player threshold and the cumulative waiting time exceeds the dynamic waiting timeout threshold, an AI player is introduced to make up the minimum starting player number and the game is moved to the game state. If the current number of players is greater than or equal to the minimum starting player threshold and the remaining countdown time is less than the dynamic early start threshold, the game is moved directly to the game state.

[0014] Secondly, the present invention also provides a dynamic priority allocation system for game rooms, comprising: The data acquisition module is configured to collect dynamic status parameters of the room, including the current number of players, the maximum room capacity, the remaining countdown time, the server node load rate, and the player level distribution data. The priority calculation module is configured to set a baseline countdown timer associated with the room type, and calculates the room priority value by weighted summation, combining dynamic weight coefficients and dynamic status parameters. The matchmaking module is configured to respond to new player matchmaking requests, filter available rooms and sort them in descending order of priority value, and assign new players to the room with the highest priority value; The state machine management module is configured to manage the game room state machine, which includes idle, waiting, and game states, and generate a state snapshot containing core parameters before state transitions. The state transition execution module is configured to execute state machine transition logic: after the first player joins an empty room, a countdown starts and the player transitions to a waiting state; in the waiting state, the server maintains the countdown duration and broadcasts a synchronization data packet containing the current remaining countdown duration to the client; when the number of players reaches the limit or the countdown is zero, the player transitions to the match state; if an abnormal termination event is detected during the match, a transaction rollback is performed based on the state snapshot, restoring the room state to the waiting state and triggering a recalculation of the priority value.

[0015] Furthermore, the state machine management module is also configured to extend the state machine into a closed-loop transition system that includes an end state; the state transition execution module is also configured to: when the preset game end conditions are met, the room transitions from the game state to the end state; when the duration of the end state reaches the preset data retention time, the room data is cleared and the room transitions to the idle state.

[0016] Furthermore, the state transition execution module is also configured to release player sessions, clear runtime memory, and reset room state variables in a preset order when the room transitions from the closed state to the idle state; if any release step fails, it will roll back to the closed state, record the exception, and automatically retry, with the number of retries not exceeding a preset limit.

[0017] Furthermore, the state transition execution module is also configured to, during the waiting state, receive a synchronization correction request reported by the client based on the deviation between the local countdown and the server synchronization data exceeding a threshold, and rebroadcast the calibrated remaining countdown duration value and corresponding timestamp to all clients in the room.

[0018] Furthermore, the state transition execution module is also configured to, during the waiting state, if the current number of players is less than the minimum starting player threshold and the cumulative waiting time exceeds the dynamic waiting timeout threshold, introduce artificial intelligence players to make up the minimum starting player number and trigger the transition to the in-game state; if the current number of players is greater than or equal to the minimum starting player threshold and the remaining countdown time is less than the dynamic early start threshold, directly trigger the transition to the in-game state.

[0019] The beneficial effects of this invention include: Firstly, this invention ensures that the difference in player levels within a room is within a reasonable range by limiting player level distribution and a safety net threshold, thus preventing matches with a significant skill gap. Multi-dimensional weighted matching takes into account factors such as the number of players, duration, and load, resulting in a better player experience and a significant improvement in matchmaking fairness.

[0020] Secondly, this invention incorporates server node load rate into priority value calculation, combines reinforcement learning adaptive weights, and performs matching requests to reasonably distribute traffic among server clusters. High-load nodes are rate-limited, and low-load nodes are fully utilized, thereby reducing latency and crash risk, improving resource utilization, and achieving efficient server load balancing.

[0021] Thirdly, this invention can quickly repair data corruption caused by abnormal termination by combining a closed-loop state machine with a state snapshot rollback mechanism; the combination of a unified server clock and a countdown calibration mechanism completely solves the problem of time synchronization issues across multiple terminals; transactional resource release eliminates memory leaks and session remnants, ensuring smooth long-term system operation and significantly enhancing system stability.

[0022] Fourthly, this invention avoids long-term room vacancy and shortens player waiting time by combining dynamic game start logic with AI player completion mechanism; refined status permission management blocks invalid matching requests, reduces redundant system operations, greatly improves room turnover speed, and significantly improves room turnover efficiency.

[0023] Fifthly, the weighting coefficients and various thresholds of this invention can be periodically and adaptively optimized, adapting to different game types and player traffic fluctuations without manual intervention; the method and system are compatible and can be directly deployed on existing server clusters, with low modification difficulty, strong compatibility, and enhanced adaptability and scalability. Attached Figure Description

[0024] Figure 1 This is a flowchart of the dynamic priority allocation method for game rooms provided in an embodiment of the present invention.

[0025] Figure 2 This is a schematic diagram of the dynamic priority allocation system for game rooms provided in an embodiment of the present invention. Detailed Implementation

[0026] Existing game room priority allocation technologies suffer from numerous drawbacks, including poor matching fairness, unbalanced server load scheduling, rigid and inflexible weighting rules, coarse room status management, countdown synchronization deviations, and inflexible game start mechanisms. This invention addresses these pain points by establishing a comprehensive technical solution that incorporates multi-dimensional dynamic weighted calculation, reinforcement learning adaptive iteration, closed-loop state machine transaction management, unified server clock synchronization, and dynamic game start adaptation. The technical solution of this invention will be fully and clearly described below with reference to the accompanying drawings and specific embodiments, enabling those skilled in the art to fully reproduce the technical solution and understand the core innovations and implementation logic of this invention.

[0027] To address the technical issues of low matchmaking efficiency, uneven load distribution, and difficulty in recovering from abnormal game room conditions, please refer to [reference needed]. Figure 1 This invention provides a method for dynamic priority allocation of game rooms, in which the server performs the following steps: S1 collects dynamic status parameters of the room, including the current number of players, the maximum room capacity, the remaining countdown time, the server node load rate, and the player level distribution data.

[0028] Specifically, in the dynamic priority allocation method for game rooms, step S1 executed by the server aims to perceive and quantify the dynamic state of the game room in real time, providing an accurate data foundation for subsequent priority calculations. Specifically, it includes the following key steps: First, the server initiates a real-time data collection mechanism to continuously monitor and acquire multiple dynamic status parameters of the target game room. These parameters collectively depict the room's immediate load status and potential matchmaking appeal. Among them, the current number of players refers to the total number of players who have entered the room but have not yet started a formal match at the current moment. The server tracks this value in real time by maintaining a list of player sessions within the room.

[0029] The maximum room capacity refers to the maximum number of players that this type of room design can accommodate. This parameter is usually determined when the room is created and is associated with the room type. The server can read it from the room configuration information.

[0030] The remaining countdown time specifically refers to the remaining matchmaking time when a room is waiting for a new player to join. When the first player joins an available room, the server will start a countdown timer, and the remaining time of that countdown timer is this parameter.

[0031] The CPU load rate of a server node reflects the real-time processing pressure of the server node carrying the current room. The server side periodically samples and calculates the CPU's busy level through the performance monitoring interface provided by the operating system. It is usually expressed as a percentage of the occupancy rate, and its value is theoretically between a value greater than zero and less than or equal to one.

[0032] Secondly, based on the collected dynamic state parameters of the room and deeper player group characteristic data, the server performs a crucial predictive calculation to estimate the dispersion of the level distribution of all players in the room after a new player joins. This calculation aims to promote a fair competitive experience among players and avoid affecting the enjoyment of the game due to excessively large or small level differences. The specific calculation process is as follows: The server retrieves the current player level distribution data for the room. This data records the level information of players who have played in the room over a period of time, reflecting the typical level composition characteristics of the player group in the room. Simultaneously, for new players initiating matchmaking requests, the server uses statistical analysis or machine learning models based on their past game behavior data, registration information, or the user group profile they belong to, to estimate a confidence interval for the new player's level. This confidence interval characterizes the range and reliability of the new player's true level.

[0033] Based on this, the server simulates the scenario of a new player joining the room with a representative level within their confidence interval. It merges the current players' level data with this newly joined simulated level to form a temporary set of all player levels. Then, statistical methods are used to calculate the standard deviation of this temporary set of levels. This standard deviation quantifies the overall difference in player levels.

[0034] Finally, to ensure a basic balance in the gaming experience, the server will perform a reasonableness check on the calculated standard deviation of the levels. The system pre-sets a minimum level difference threshold, which represents the minimum level of player level diversity that the platform operator expects to maintain. If the predicted standard deviation calculated in this step is less than this preset minimum level difference threshold, the server will automatically ignore the smaller value and use the preset minimum level difference threshold as the final result for priority evaluation in subsequent steps. Conversely, if the calculated standard deviation is greater than or equal to the threshold, the calculated value will be used directly.

[0035] Through the above series of data collection and prediction calculations, the server obtains key quantitative indicators that reflect the current dynamic status and future potential of the room, thus preparing for the priority value calculation in step S2.

[0036] It should be noted that in step S1, the algorithm for predicting the standard deviation of player levels requires the server to retrieve the current player level distribution data from the historical data storage module, reflecting the recent player level characteristics in the form of a probability distribution. For new players, based on their historical behavior data and user profiles, a level confidence interval is generated using Bayesian inference or Gaussian process regression models. The median of the interval is used as the simulated joining level, which is merged with the current player levels to form a temporary set. The dispersion is calculated using the sample standard deviation formula. If the result is lower than the preset minimum level difference threshold, the operator sets this threshold according to game balance, and this threshold becomes the final value to avoid excessive level concentration.

[0037] S2 configures a baseline countdown duration associated with the room type, and calculates the room priority value by weighted summation based on dynamic weight coefficients and dynamic status parameters. The priority value is obtained by weighted summation of player percentage, countdown percentage, reciprocal of matching balance parameter, and reciprocal of load rate. The dynamic weight coefficient is adaptively updated based on historical matching success rate and server load fluctuation amplitude through a reinforcement learning model.

[0038] Specifically, step S2, executed on the server side, aims to calculate a dynamic priority value by quantifying the room's dynamic state and matching potential, providing a basis for subsequent player allocation. This step achieves accurate evaluation of the room's attractiveness by integrating multi-dimensional parameters and an adaptive weighting mechanism. The implementation process of step S2 is as follows: (1) Configuration of Baseline Countdown Duration: The server first configures the baseline countdown duration based on the type attribute of the room to be assigned. Different types of game rooms, such as competitive, casual cooperative, and story-driven, require different baseline durations due to differences between the matching goals and player expectations. For example, competitive rooms may expect to complete matching faster to initiate high-intensity competition, so their baseline duration is relatively short; casual rooms may allow for a more relaxed waiting time to gather players with similar interests, so their baseline duration is correspondingly longer. The server obtains the corresponding baseline countdown duration value by reading the preset configuration template for the room type, which is bound to the type when the room is created, as a reference standard for subsequent calculations.

[0039] (2) Quantification and Proportion Calculation of Dynamic Status Parameters: Based on the dynamic status parameters of the room collected in step S1, including the current number of players, the upper limit of room capacity, the remaining countdown time, the standard deviation of the level, and the central processing unit load rate of the server node, the server further calculates two core proportion indicators to normalize the state differences of different dimensions. The two core proportion indicators are: a. Player proportion: Reflects the current filling degree of the room and reflects the real-time efficiency of matching. It is calculated as the ratio of the current number of players to the upper limit of room capacity, which intuitively represents the progress of the room approaching full capacity. For example, if the upper limit of room capacity is high but the current number of players is low, the player proportion is low, indicating that the room still needs to attract more players; conversely, when the proportion is close to saturation, the room's attractiveness may be more reflected in the upcoming match opportunities; b. Countdown proportion: Reflects the remaining urgency of the room's waiting state. It is calculated as the ratio of the remaining countdown time to the baseline countdown time, mapping the dynamic remaining time to a relative value relative to the baseline time. If the remaining countdown time is relatively long and the percentage is close to the upper limit, it means that the room still has enough time to accept new players; if the percentage is relatively low and close to the lower limit, it means that the waiting state is about to end and should be prioritized for scenarios that are eager to start the game.

[0040] (3) Determination and Adaptive Update of Dynamic Weighting Coefficients: The core of step S2 lies in the reasonable allocation of dynamic weighting coefficients, which determine the contribution ratio of four indicators to the priority value: player proportion, countdown proportion, level standard deviation (i.e., the reciprocal of the matching balance parameter), and CPU load rate. The determination of weighting coefficients is achieved through the following mechanism: Input characteristics: The server-side model inputs include the change in historical match success rate within a sliding window and the fluctuation range of server CPU load. The sliding window refers to a set of match data over a recent period, covering several recent match cycles, used to capture short-term trends. The change in historical match success rate reflects the recent improvement or decline in match performance; an increase in success rate indicates that the current weight combination is optimal and needs to be maintained or fine-tuned, while a decrease requires weight adjustment to improve matchmaking. The fluctuation range of CPU load characterizes the stability of server processing pressure; drastic load fluctuations may lead to matchmaking delays, requiring weight adjustments to guide players to lower-load rooms.

[0041] Reinforcement Learning Adaptive Model: An adaptive model based on reinforcement learning is deployed on the server side. Using the aforementioned changes and fluctuations as input features, the weight coefficients are updated periodically and iteratively. The model aims to maximize the combined benefits of long-term matching success rate and server load stability. For example, when the historical matching success rate shows an upward trend and load fluctuations are moderate, the model tends to maintain the current weights. If the success rate decreases or load fluctuations intensify, the model adjusts the weights through trial and error, such as increasing the weight of player proportion to prioritize filling rooms, or increasing the weight of the inverse of load rate to guide players away from high-load nodes, gradually approaching the optimal solution. The update cycle is set according to server performance and business needs, such as periodic execution, to avoid frequent adjustments that could cause system instability.

[0042] The four weighting coefficients correspond to different optimization objectives: the first weighting coefficient, player percentage, focuses on room filling efficiency; the second weighting coefficient, countdown percentage, focuses on the urgency of waiting; the third weighting coefficient, the reciprocal of the standard deviation of the class, which is the matching balance parameter, focuses on the quality of player matching. The smaller the standard deviation, the more concentrated the class is, and the larger the reciprocal, the higher the priority; the fourth weighting coefficient, the reciprocal of the CPU load rate, focuses on server resource utilization. The lower the load, the larger the reciprocal, and the higher the priority.

[0043] (4) Weighted summation calculation of priority values: After preparing the above parameters and weights, the server calculates the room priority value according to the weighted summation rule. The specific logic is as follows: multiply the four percentage indicators by their corresponding dynamic weight coefficients, and then add the results to form the final priority value. Among them: the multiplier of the third weight coefficient, which is the reciprocal of the grade standard deviation, is obtained by taking the reciprocal of the grade standard deviation obtained in step S1. It aims to transform the logic that the smaller the grade difference, the smaller the standard deviation, the higher the matching quality into a numerical contribution. The smaller the standard deviation, the larger the reciprocal, and the higher the priority value accordingly. The multiplier of the fourth weight coefficient, which is the reciprocal of the central processing unit load rate, is obtained by taking the reciprocal of the load rate collected in step S1. It aims to transform the logic that the lower the server load, the more abundant the resources into a numerical contribution. The lower the load rate, the larger the reciprocal, and the higher the priority value accordingly.

[0044] Through the above calculations, the priority value comprehensively reflects the room's fill status, waiting urgency, player match quality, and server load pressure, providing a quantitative basis for room selection and allocation in step S3.

[0045] It should be noted that the reinforcement learning adaptive model in step S2 aims to optimize long-term matching success rate and load balancing. Its state space includes the historical changes in matching success rate within the sliding window, the fluctuation range of server CPU load, and the current room dynamic parameters. The action space represents the adjustment range of weight coefficients. The reward function integrates positive incentives such as improved matching success rate, reduced load fluctuation, and decreased player exit rate, while penalizing latency or overload caused by adjustments. The model iteratively updates the weights at preset intervals using Q-learning or policy gradient algorithms, compares the system performance under the new and old weights, and provides feedback for optimization to ensure dynamic adaptation to real-time scenarios.

[0046] The reinforcement learning adaptive model uses the discretized Q-learning algorithm as the main training framework, and policy gradient algorithms such as PPO can also be selected. It is suitable for continuous action spaces, and its specific implementation is as follows: (1) State-space discretization design: The continuous state vector is divided into a finite set of discrete states, with specific dimensions including: ① The change in historical matching success rate ΔR∈{−0.05,−0.02,0,+0.02,+0.05} (unit: percentage points, step size 0.02, 5 levels in total); ② Server CPU load fluctuation range σ_CPU∈{0–10%,10–30%,30–60%,60–90%,>90%} (5 ranges); ③ Current room dynamic parameter combination: player percentage p=N / N_max∈{<0.4,0.4–0.7,>0.7}, level standard deviation σ_level∈{<1.5,1.5–3.0,>3.0} (unit: level points), remaining countdown normalized value t_norm=t / t_base∈{0–0.3,0.3–0.7,>0.7}; The above three types of parameters are combined to form a total number of discrete states ≤ 5×5×3×3×3=675, which constitute the state space S of a finite Markov decision process (MDP).

[0047] (2) Action space discretization: The weight coefficient adjustment range Δw_i∈{−0.05,−0.02,0,+0.02,+0.05} (i=1,2,3,4 correspond to the four factors of player proportion, countdown proportion, inverse of level dispersion, and inverse of load, respectively), for a total of 5 4=625 action combinations; In actual deployment, an action pruning strategy is adopted, which only allows single-factor weight changes (i.e., only one w_i is adjusted in each iteration), compressing the action space to 20 effective actions with 4 factors × 5 levels of variation, thus avoiding the sparse reward problem caused by high-dimensional actions.

[0048] (3) The reward function R(s,a,s′) is explicitly defined as: R=α1⋅ΔMatchRate+α2⋅(−Δσ_CPU)+α3⋅(−ΔDropRate)+α4⋅Π_Stable−β⋅Π_Overload in: ΔMatchRate is the increment of the sliding window matching success rate after this iteration relative to the previous cycle (∈[−0.03,+0.08]), where length = 100 matches; Δσ_CPU is the change in the standard deviation of CPU load, where the negative sign indicates a positive reward for reduced volatility; ΔDropRate represents the change in the abnormal player drop rate, where a negative sign indicates a positive reward for a decrease in the drop rate; ∏_Stable = 1 if and only if the server node load remains within the range of [20%, 80%] for ≥3 update cycles; otherwise, it is 0. ∏_Overload=1 when any node's CPU > 95% or memory utilization > 90% for ≥ 2 update cycles; otherwise, it is 0. The coefficient values ​​are: α1=0.4, α2=0.3, α3=0.2, α4=0.1, β=0.5, determined by fitting historical data.

[0049] (4) Exploration strategy: The ε-greedy strategy is adopted, with an initial ε0=0.3 and an exponential decay: ε_k=max(0.05,ε0×0.99^k), where k is the iteration round; at the same time, Prioritized Experience Replay (PER) is introduced, with the absolute value of the TD error as the priority weight, to improve the learning efficiency of key samples.

[0050] (5) Training data source: The model training data comes from the real-time log stream of the online service, and the following fields are aggregated every T=5 minutes: • Room ID, creation time, type, and maximum capacity; • Response latency, assignment results, and player level sequence for each match request; • Server node monitoring metrics: CPU, memory, network I / O; • Match success / failure indicators, player quitting events; After data anonymization, it is stored in a time series database, and a sample pool of (s_t, a_t, r_t, s_{t+1}) quadruples is constructed.

[0051] (6) Iterative update and convergence determination: The model performs batch updates every fixed period T_update=5 minutes, with a batch size of 1000 samples. The convergence condition is: within three consecutive update cycles, the maximum change in Q value ΔQ_max < 10⁻³, and the standard deviation of the mean fluctuation of the reward σ_R < 0.005; If convergence is not achieved, a dual-network architecture DQN with a target network is enabled, with the target network soft update coefficient τ=0.001. After each weight update, the system initiates A / B testing: the new weight strategy is applied to 10% of the traffic, and the differences in core indicators such as matching time, load variance, and player retention are compared with the old baseline weight; the new weight is only fully implemented when the p-value is less than 0.05 in a two-tailed t-test and the business indicators are significantly improved.

[0052] An example calculation: Assuming that for a certain period, ΔMatchRate=+0.05, Δσ_CPU=+0.02, ΔDropRate=−0.01, Π_Stable=1, Π_Overload=0, calculate the reward value R=0.4×0.05+0.3×(−0.02)+0.2×0.01+0.1×1−0.5×0=0.02−0.006+0.002+0.1=0.116.

[0053] The above design ensures that the reinforcement learning model is reproducible, deployable, and engineering feasible, and the adaptive weight tuning mechanism described herein can be fully implemented based on this specification.

[0054] S3 responds to new player matchmaking requests, filters available rooms and sorts them in descending order of priority value, assigning new players to the room with the highest priority value; if priority values ​​are the same, they are assigned in ascending order of room creation time.

[0055] Specifically, step S3, executed on the server side, aims to respond to new players' matchmaking requests by directing them to the most attractive available rooms through quantitative evaluation and a fair allocation mechanism. This step ensures a balance between matchmaking efficiency and user experience through strict room screening, priority ranking, and conflict resolution rules. The implementation process of step S3 is as follows: (1) Receiving and parsing new player matchmaking requests: The server receives new player matchmaking requests through a pre-defined matchmaking service interface. The request contains basic data such as the player's identity information, game type preferences, and historical behavior tags. The server first verifies the validity of the request, excluding invalid requests with incorrect formatting or insufficient permissions, and only initiates the subsequent allocation process for valid requests. After the verification is passed, the system extracts the core requirements related to room matching from the request, such as the desired game mode and preferences for room status, as an auxiliary reference for filtering available rooms.

[0056] (2) Filtering logic for available rooms: The server filters rooms that meet the availability status from the global room management list as a candidate set. The availability status is strictly limited to idle or waiting status, including: a. Idle status, which refers to the initial state where the room has been created but no players have joined yet, or where all players have left but the room has not been cleared. At this time, the room has not started the match countdown and can accept new players to join directly and trigger the state transition. b. Waiting status, which refers to the room where some players have joined and the match countdown has started. It is triggered by players joining an idle room in subsequent step S5 and is waiting for more players to meet the start conditions. At this time, the room is still in the stage of accepting new players, has not reached the capacity limit, and the countdown has not ended. During the filtering process, the server traverses the real-time state records of the room state machine created in step S4 and excludes rooms that are in the game, in the end state, or have not met the conditions for allocation, such as rooms in the end state whose data retention period has not expired. At the same time, only rooms that match the game type requested by the player are retained. For example, if the player requests competitive mode, casual mode rooms are excluded to ensure the matching target is suitable.

[0057] (3) Sort by priority value in descending order: The server sorts the selected available room candidates in descending order by priority value. The priority value is calculated in step S2 and comprehensively reflects the room filling efficiency, waiting urgency, player matching quality, and server load pressure. The sorting logic follows the principle that "the higher the priority value, the stronger the room's attractiveness." The server calls the built-in sorting algorithm, such as ascending and descending order based on a comparator, placing rooms with higher priority values ​​at the front of the list. For example, if room A has a higher priority value than room B, then A will be placed before B after sorting. During the sorting process, the system reads the latest priority value of each room in real time. Because step S2 periodically updates the weights and parameters, the priority value may change dynamically, ensuring that the sorting is based on the latest state and avoiding allocation deviations caused by outdated data.

[0058] (4) Round-robin allocation rule when priority values ​​are the same: When multiple rooms have the same priority value, the server uses a round-robin rule based on the room creation time in ascending order to resolve conflicts and ensure the fairness and orderliness of the allocation. Specifically, a. Ascending order of creation time: Rooms with the same priority value are sorted from earliest to latest according to their creation time, that is, the room created earlier is placed first. The creation time is automatically recorded by the server based on the system clock when the room is instantiated, and serves as the unique time sequence identifier of the room. b. Round-robin allocation mechanism: The server maintains a round-robin pointer, pointing to the room that should be allocated first. When a group of rooms with the same priority value is encountered for the first time, after sorting them in ascending order of creation time, the pointer is pointed to the earliest created room and a new player is allocated. When a group of rooms with the same priority value is encountered again, the pointer is automatically moved to the next room in the order of creation time to avoid the same room being repeatedly allocated first. If the pointer has already pointed to the last room in the group, it loops back to the first room, forming a periodic round-robin. This mechanism avoids the uncertainty of random allocation and prevents the Matthew effect that may be caused by a fixed order, that is, some rooms are allocated first for a long time, ensuring the balance of player experience.

[0059] (5) New player allocation and status update: After sorting and conflict resolution are completed, the server will allocate the new player to the first room in the sorting results, that is, the room with the highest priority value, or the room selected by the round-robin rule when the priority values ​​are the same. The allocation operation includes: adding the player's session information to the room's player list and updating the current number of players in the room; returning a successful allocation response to the player's client, including the room identifier, server address and initial synchronization information; if the room was originally in an idle state, the state transition in step S5 will be triggered, that is, from idle to waiting, and the countdown will start; if the room was originally in a waiting state, only the player list and number will be updated, and the countdown process will continue.

[0060] After allocation, the server immediately updates the priority value of the room. Due to the change in the number of players, step S2 needs to be re-executed to ensure that subsequent matchmaking requests are based on the latest status assessment.

[0061] S4 constructs a game room state machine that includes idle, waiting, and game states, and generates a state snapshot containing core parameters before state transitions.

[0062] Specifically, step S4, executed on the server side, aims to build a state management mechanism for the game room and ensure the reliability of state transitions and recoverability in abnormal scenarios through pre-stored state snapshots. This step provides structured support for subsequent state transitions and anomaly handling by defining clear state transition rules and a snapshot solidification mechanism, ensuring the orderly management of the room's lifecycle.

[0063] The server first constructs a game room state machine to uniformly manage the entire process of room state transitions from creation to destruction. The state machine contains several core states, each corresponding to the essential characteristics of a room at different matchmaking stages. The idle state refers to the initial state where the room has been created but no players have joined, or where all players have left after the previous game and resources are pending cleanup. In this state, the room can accept new players directly without starting a countdown. The waiting state is a transitional state triggered after a player joins an idle room. At this time, the server starts a matchmaking countdown and begins accepting more players until the start conditions are met. The match-making state is the core state entered after the room meets the start conditions. Players officially begin the game, the server stops accepting new players, and maintains process synchronization. The state machine constrains the direction of state transitions through preset flow rules, allowing only transitions from the idle state to the waiting state, and from the waiting state to the match-making state. After the match-making state ends and resources are cleaned up, the room can return to the idle state, forming a unidirectional, closed-loop lifecycle management system. The server maintains a current state identifier for each room and tracks its position in the state machine in real time.

[0064] To ensure the accuracy of state transitions and traceability in abnormal scenarios, the server automatically generates a room state snapshot before each state transition. This snapshot is an instantaneous data copy containing the room's core parameters, serving as the basis for transition execution and the benchmark for exception rollback. The snapshot content covers dynamic state parameters such as the current number of players, room capacity limit, remaining countdown timer, server node CPU load rate, predicted level standard deviation, as well as priority values, room type identifiers, player level distribution feature summaries, and state transition trigger conditions. Generation is strictly controlled to occur just before the state transition command is issued, capturing the complete state before the transition. The server stores the snapshot in memory cache or distributed persistent storage, establishing a mapping using the room's unique identifier as an index to ensure the correspondence between snapshots and rooms. Its core functions are twofold: first, as a basis for transition—when the state machine executes transition logic, it verifies whether the transition conditions meet preset rules through snapshot parameters; second, as a basis for exception rollback—if an exception occurs during the transition process or an abnormal termination event occurs during subsequent state execution, the server calls the pre-stored snapshot to restore the room state to the instantaneous state before the transition and re-triggers the transition or executes compensation logic based on the snapshot.

[0065] The server-side also utilizes a state machine management module for dynamic maintenance, real-time monitoring of room status changes, and prioritizing the generation and integrity verification of snapshots when a migration trigger event is detected. Migration requests triggered by incomplete snapshots are rejected. For rooms that have already been migrated, older snapshots are marked as historical versions and archived as needed, retaining only the latest snapshot for rollback to avoid storage redundancy. Through this mechanism, the state machine and snapshot system constructed in step S4 provides a structured framework for the state transition logic in step S5, while also providing a reliable baseline for abnormal rollback, ensuring the stability and recoverability of the entire method in complex scenarios.

[0066] It should be noted that the game room state machine constructed in step S4 includes idle, waiting, and in-game states. The migration trigger conditions are, respectively, player joining for the first time, player capacity reaching zero or countdown reaching zero, game end conditions being met such as time limit, win / loss determination completed, and all players exiting. The state snapshot must include the current number of players, capacity limit, remaining countdown, CPU load rate, prediction standard deviation, priority value, room type identifier, player level distribution characteristics, and migration trigger event to fully reproduce the state before migration.

[0067] S5, State Machine Transition: After the first player joins an empty room, a countdown begins and the room transitions to a waiting state. In the waiting state, the server maintains the countdown duration and broadcasts a synchronization data packet containing the current remaining countdown duration to the client. When the number of players reaches the limit or the countdown reaches zero, the room transitions to the match state. If an abnormal termination event is detected during the match, a transaction rollback is performed based on the state snapshot, restoring the room state to the waiting state and triggering a recalculation of the priority value.

[0068] Specifically, step S5, executed on the server side, aims to drive the dynamic flow of the game room state machine. Through explicit transition rules, countdown synchronization mechanisms, and anomaly recovery strategies, it ensures that the entire process from matchmaking to the game is controllable and reliable. This step, based on the state machine built in step S4 and pre-stored snapshots, achieves orderly transitions between states and lossless recovery in abnormal scenarios. The specific implementation process is as follows: When a player joins an idle room, the server triggers the state transition logic. At this point, the server starts a matchmaking countdown for the room, transitioning its state from idle to waiting. The initial countdown value is associated with the baseline countdown duration configured for the room type, signifying that the room has entered a waiting phase to accept more players.

[0069] While the room is in a waiting state, the server acts as the sole clock source, maintaining the remaining countdown time to ensure all clients perceive time consistently. To avoid synchronization issues caused by local client clock discrepancies, the server broadcasts synchronization data packets to all clients in the room at preset intervals. These packets contain the current remaining countdown time and the server's high-precision timestamp. Upon receiving the data, clients calibrate their local countdown display based on the server's timestamp, ensuring the time information on the player's interface is completely consistent with the server's. This mechanism eliminates the common clock desynchronization problem in distributed systems, providing a unified time benchmark for determining subsequent start conditions.

[0070] The end of the waiting state is determined by two triggering conditions. First, when the number of players in the room reaches its capacity limit, it indicates that the room has met the basic requirements for starting a match at full capacity, and the state transitions from waiting to being in the match. Second, when the remaining countdown timer naturally runs out to zero, even if the number of players has not reached the limit, it is considered a timeout, and the state also transitions to being in the match. Both conditions are based on dynamic parameters collected in real time by the server to ensure the objectivity of the judgment.

[0071] The match state is the core stage of room operation, where players engage in formal game interactions. The server stops accepting new players and instead monitors the game progress. If an abnormal termination event is detected during the match, such as a sudden server node failure, network partition causing process interruption, or a mass player disconnection, the system immediately initiates the exception handling procedure. Based on the room state snapshot pre-stored in step S4, the server migrates to the instantaneous state before the match, performs a transaction rollback, and precisely restores the room state to the moment of match completion, i.e., the critical state before the waiting state ends and the room is about to enter the match. After restoration, the room does not directly enter the match; instead, step S2 is re-executed to calculate the priority value, and the room is reinstated into the available room queue for matchmaking, avoiding room idleness or resource waste caused by exceptions.

[0072] Through the above mechanism, step S5 achieves automation of state transition and recoverability of abnormal scenarios, which not only ensures the efficiency of the normal matching process, but also improves the robustness of the system through snapshot rollback and priority recalculation. It forms a closed loop with the state management in step S4 and the priority evaluation in step S2, ensuring the stable operation of the entire dynamic allocation method.

[0073] It should be noted that abnormal termination events in step S5 include server failure, network interruption, mass player disconnection, and logical deadlock. During transaction rollback, the system restores to the waiting state based on the pre-stored snapshot, notifies online players to synchronize their interfaces, releases temporary resources during the match, and re-executes step S2 to calculate priority values ​​and add them to the matching queue.

[0074] To improve the state loop and ensure room data consistency and safe resource release, the game room state machine also includes an end state, forming a closed loop transition between idle, waiting, in-game, end, and idle. When the preset game end conditions are met, the room transitions from the in-game state to the end state. When the duration of the end state reaches the preset data retention time, the room data is cleared and the room transitions to the idle state.

[0075] Specifically, based on the aforementioned dynamic priority allocation method for game rooms, the state machine management logic for game rooms is further improved. In addition to the existing idle, waiting, and in-game states, an "end" state is added, constructing a closed-loop state transition system from idle, waiting, in-game, end, to idle, achieving standardized flow management throughout the entire lifecycle of the room. When a room is in the in-game state and meets the preset game end conditions, the server automatically drives the room state to the end state. These game end conditions cover three scenarios: the game duration reaches a set standard, the match result is determined, and all players in the room have exited. Meeting any one of these conditions triggers a state switch.

[0076] Once a room enters the "End" state, the server continuously monitors its duration. When the duration reaches a preset data retention time matching the current game type, the server initiates a resource cleanup process, clearing dynamic running data and game session-related resources from the room. After cleanup, the room state is migrated to the idle state for re-entry into the matchmaking queue. Throughout this state migration process, the server continuously pushes room state update data to the associated clients at preset time intervals, while simultaneously responding to client-initiated state retrieval requests in real time, providing corresponding state data to the requesting party. If the server receives a state verification conflict flag reported by a client, it immediately uses its own pushed state data as the sole benchmark and issues a state correction command to the corresponding client, ensuring consistency between the client's and server's room states.

[0077] To avoid invalid matchmaking consuming system resources, the server implements fine-grained control over room status. When a room is in a match or in an ended state with a duration not exceeding the relevant threshold, the server marks the room as unassignable and refuses to accept new player matchmaking requests. When a room is in an ended state with a duration reaching or exceeding the aforementioned relevant threshold, the server adjusts the room's permission mode, setting it to read-only query mode while retaining access to historical data. Simultaneously, all new player matchmaking requests are continuously blocked until the room completes resource cleanup and migrates to an idle state, at which point the matchmaking block is lifted and normal scheduling permissions are restored.

[0078] It should be noted that in the final state of this embodiment, the preset data retention time is set by the configuration center according to the game type; longer for competitive games to allow for review, and shorter for casual games to facilitate data recovery. The association threshold is a part of the retention time, distinguishing between the data retention period and the read-only query period. When the association threshold is reached, the room enters read-only mode, maintaining access to historical data but blocking new matches until the retention period expires, at which point resources are cleared and migrated to idle areas.

[0079] To ensure the safe release of resources, prevent leakage, and quickly reuse rooms, when a room transitions from an ended state to an idle state, player sessions are released, runtime memory is cleared, and room state variables are reset in a preset order. If any release step fails, the system rolls back to the ended state, records the exception, and automatically retryes, with the number of retries not exceeding a preset limit.

[0080] Specifically, this embodiment details the process of a room transitioning from an ended state to an idle state. Through a transactional resource release process, a failure rollback mechanism, integrity verification, and a state synchronization strategy, it ensures the reliability of resource reclamation and the timeliness of room state restoration.

[0081] When a room is in an ended state and its duration reaches the preset data retention time, the server initiates a process to transition from the ended state to an idle state, with the core operation being the release of transactional resources. This process strictly follows a preset order to release resources, avoiding data residue caused by resource dependency conflicts. First, player session connections are released, meaning the temporary association between the room and all players who participated in the game is severed, and session tokens and permission identifiers are cleared. Second, game runtime memory data is cleared, including real-time player operation records, temporary skill states, scene interaction caches, and other dynamic data valid only within the game. Finally, the room's internal state variables are reset, restoring the capacity limit, countdown configuration, player level distribution records, etc., to their initial default values. This sequential design is based on the coupling of resource release, prioritizing the removal of external associations, then clearing internal data, and finally resetting the state, minimizing the risk of residue.

[0082] If any of the above release steps fails, such as a player session failing to disconnect properly due to network latency or memory data not being completely cleared due to process usage, the server immediately initiates an exception rollback and retry mechanism. First, the room state is rolled back to the ended state, maintaining the current data retention status; simultaneously, exception information such as the failed step, error type, and timestamp are recorded in the system log for subsequent troubleshooting. Then, the server automatically extends the preset data retention time, appropriately adding a buffer period to the original retention duration, and retrying the failed release steps within the newly extended time period. The retry process follows a limited-number principle, meaning the number of retries does not exceed a preset limit to avoid infinite retries leading to long-term resource locking. If the retry limit is reached and the process is still unsuccessful, the system marks the abnormal room as requiring manual intervention, suspends automatic migration, and notifies operations and maintenance personnel for intervention.

[0083] After all release steps are successfully executed, the server performs a resource integrity check to confirm that there are no resource remnants or leaks. The check includes verifying whether all player sessions are closed, whether memory usage has returned to baseline levels, whether state variables are consistent with the initial configuration, and whether temporary file handles have been released. The standard for passing the check is that all resource metrics meet the expected characteristics of an idle state, and there is no residual data related to the ended game.

[0084] After verification, the server officially migrates the room status to the idle state. Upon completion of the migration, a status reset and synchronization operation is immediately performed: the current number of players is reset to zero; initial calculations are performed based on the reset idle state parameters, such as the empty player list, default capacity limit, and the priority value of any unactivated countdown triggers; the updated priority value is synchronized to the matchmaking and scheduling module, allowing the room to be immediately added to the available room queue and participate in the matchmaking and allocation of new players.

[0085] Through the above transactional processes, the atomicity of resource release is achieved, that is, either a successful migration or a rollback and retry; the fault tolerance of failure handling is achieved by extending the retention time and limiting retries; the thoroughness of resource reclamation is achieved by integrity verification; and the timeliness of state recovery is achieved by resetting parameters and synchronizing priorities. In conjunction with the closed-loop state machine, the transition of a room from closure to vacancy is ensured to be efficient and reliable, avoiding a decrease in system stability due to resource leaks or abnormal states.

[0086] It should be noted that the transactional resource release in this embodiment is ordered according to dependencies: first, player session connections are released; then, memory data is cleared; and finally, state variables are reset. Integrity checks are performed on session closure, memory regression to baseline, initial configuration of state variables, and release of temporary file handles to ensure no residual leaks.

[0087] To correct countdown discrepancies and ensure consistent time synchronization across multiple devices, the server receives synchronization correction requests reported by clients when the discrepancy between their local countdown and the server's synchronization data exceeds a threshold. The server then rebroadcasts the calibrated remaining countdown duration and corresponding timestamp to all clients in the room.

[0088] Specifically, to address the issue of client-server countdown synchronization during the waiting state, a synchronization correction mechanism based on client-initiated detection was designed. This mechanism ensures consistency of time perception in a distributed environment through quantified deviation-triggered calibration, authoritative server broadcasting, and audit tracing.

[0089] While the room is in a waiting state, the server acts as the sole clock source, maintaining the remaining countdown timer and broadcasting synchronization data packets to all clients in the room at preset intervals. These packets contain the current remaining countdown timer value and the server's high-precision timestamp. Upon receiving the data, each client starts its local countdown display based on its local system clock, while continuously comparing its local countdown value with the remaining time on the server in the synchronization data packet.

[0090] When a client detects that the deviation between its local countdown and the server's remaining time exceeds a preset tolerance range—a range configured by the server based on factors such as network latency and client performance—representing the upper limit of acceptable normal deviation, correction is not immediately triggered. Instead, a continuous deviation verification mechanism is initiated. Specifically, the client only considers the local countdown to have significantly deviated from the server's authoritative time and generates a synchronization correction request if it detects deviations exceeding the limit multiple times consecutively, such as at least twice to ensure that misjudgments are not due to occasional network jitter. The request includes the client identifier, the current local countdown value, the time of the most recent synchronization data packet reception, and a count of the number of deviations exceeding the limit, serving as the server's basis for determining the necessity of correction.

[0091] After receiving the synchronization correction request from the client through the matching service's request interface, the server immediately performs authoritative calibration and global broadcast. First, based on the server's high-precision timestamp and the actual value of the current remaining countdown timer, it calculates the calibrated remaining countdown timer. Then, it rebroadcasts a synchronization data packet containing the calibration value and the corresponding server timestamp to all clients in the room, forcing each client to reset its local countdown based on this broadcast. During this process, the server ignores differences in the client's local state, using only its own clock source as the sole standard to ensure global time synchronization.

[0092] After the synchronization event is processed, the server records the correction action in the system audit log. The log content includes the correction trigger time, the list of clients that initiated the request, the remaining duration before and after calibration, the server timestamp, and a summary of the cause of the deviation, such as the cumulative error of the client's local clock. The audit log is used for subsequent system operation and maintenance traceability, and can help identify clients or network areas with frequent synchronization anomalies, providing data support for optimizing the synchronization cycle and adjusting the tolerance range.

[0093] Through the above mechanism, a closed-loop correction process of client-initiated detection, server-authoritative calibration, global synchronization, and audit traceability is realized, which solves the problem of inconsistent countdown display caused by client local clock drift and network latency accumulation. In conjunction with the server clock source maintenance mechanism in step S5, it ensures that all players have a unified perception of the remaining time in the waiting state, and provides a reliable time benchmark for judging the start conditions.

[0094] It should be noted that in the synchronous calibration of this solution, the number of consecutive checks is set according to network stability; fewer checks are performed when there are large fluctuations, and more checks are performed when the network is stable. The tolerance range is dynamically adjusted based on the average client latency, and calibration is triggered only when there is a significant deviation. The server broadcasts the calibration value and timestamp upon response and records it in the audit log.

[0095] To dynamically adapt to the start conditions and improve matching efficiency and experience, during the waiting period, if the current number of players is less than the minimum start threshold and the cumulative waiting time exceeds the dynamic waiting timeout threshold, AI players will be introduced to make up the minimum start number and trigger the transition to the game state. If the current number of players is greater than or equal to the minimum start threshold and the remaining countdown time is less than the dynamic early start threshold, the transition to the game state will be triggered directly.

[0096] Specifically, for the start conditions in the waiting state of step S5, a dynamic start adaptation logic was designed. By flexibly adjusting the start time and supplementing virtual players, the player waiting experience and matching efficiency are balanced. At the same time, the start strategy is optimized by combining adaptive configuration.

[0097] While the room is in the waiting state defined in step S5, the server continuously monitors the remaining countdown timer and the current number of players. If the remaining countdown timer is greater than zero (meaning the wait has not timed out) and the current number of players is less than the room's capacity limit (meaning the room is not full), then the dynamic match start adaptation logic is triggered, and two scenarios are handled based on the real-time status.

[0098] The first scenario focuses on situations where there are insufficient players but the waiting time is too long. The server first determines whether the current number of players is less than the preset minimum starting player threshold. This threshold is set by the configuration center according to the room type and represents the minimum number of real players required to start the match. If it is confirmed that there are insufficient players, the server further checks the cumulative waiting time since entering the waiting state. If this time exceeds the dynamic waiting timeout threshold, which is generated by the configuration center based on room type characteristics and historical matching data (e.g., competitive rooms have shorter timeout thresholds to prioritize starting matches, while casual rooms have longer timeout thresholds to gather players with similar interests), then it is determined that additional players are needed to start the match. At this time, the server calls the AI ​​player scheduling service to introduce AI players whose number is the difference between the minimum starting player threshold and the current number of players. The introduced AI players are not randomly generated. Their behavioral strategy parameters, such as operating style, reaction speed, and skill release tendency, are adaptively configured by the server based on the level distribution data of real players in the room. By analyzing the average level and distribution range of real players (e.g., concentrated in high-ranking positions or dispersed across multiple ranks), the server ensures that the AI ​​players' competitive ability parameters, such as damage output, defensive strength, and tactical selection weights, match the overall level characteristics of the real player group, avoiding significant skill disparities that could negatively impact the experience. Once the total number of active players in the room reaches the minimum threshold for starting a match, the server triggers a state transition, switching the room from a waiting state to a match state.

[0099] The second scenario focuses on situations where the player count meets the minimum threshold but the wait is urgent. If the current player count is greater than or equal to the minimum starting player threshold (meeting the basic start conditions) but still less than the room capacity limit (meaning there are still available spots), the server further determines whether the remaining countdown timer is less than the dynamic early start threshold. This threshold is dynamically generated by the configuration center based on real-time server load (such as the current node's processing pressure) and player retention rate (such as the proportion of players who recently quit due to long wait times). A higher threshold can be set when the load is low and the retention rate is high, allowing for longer waits; conversely, a lower threshold is set to prioritize early start. If the remaining countdown timer is less than this threshold, it indicates that continued waiting may lead to player churn or resource idleness. In this case, the server will skip the remaining countdown and directly trigger the state transition to the match state, starting the match using the currently gathered players.

[0100] The core parameters of the aforementioned dynamic match start logic—minimum number of players required to start, dynamic waiting timeout threshold, and dynamic early start threshold—are all periodically optimized and updated by the configuration center. The configuration center uses historical matching data within a sliding window as a sample, covering recent matching results for various room types. Combined with current server load fluctuation trends and player behavior characteristics such as average waiting patience and quitting preferences, the center adjusts the threshold values ​​through a data analysis model to ensure the match start strategy always adapts to the actual operating environment. For example, if historical data shows that a certain type of room experiences an increase in player quitting rates due to waiting timeouts, the configuration center will shorten the dynamic waiting timeout threshold for that type of room; if the server load remains consistently high, the dynamic early start threshold will be lowered to reduce waiting resource consumption.

[0101] By introducing AI players to fill rooms with low player counts and starting matches earlier to avoid high load waiting times, the dynamic adaptation logic in this embodiment effectively solves the problems of wasted time or forced number filling caused by traditional fixed countdown start times. The adaptive configuration of AI players ensures the compatibility of the supplementary player experience. Together with the priority calculation of player proportion and level standard deviation in step S2 and the rollback of state snapshots in case of anomalies in step S4, a dynamic optimization is formed throughout the entire process from matching and waiting to the start of the match, improving the system's flexibility and player satisfaction.

[0102] It should be noted that in this scheme's dynamic match start, the waiting timeout threshold is combined with room type and historical matching data, while the early start threshold is calculated by weighting real-time load and player retention rate; the threshold decreases when the load is high and the retention rate is low. The number of artificial intelligence (AI) players is supplemented to the minimum number of players required for the match, and their behavioral strategies are matched according to the mean and variance of the real player level distribution, achieving balance when concentrated and complementarity when dispersed, with competitive abilities matched according to the percentile of the distribution.

[0103] To address the technical challenges of low matchmaking efficiency, uneven load distribution, and difficulty in recovering from game room anomalies through a modular distributed architecture, and to achieve efficient maintenance and expansion, please refer to [reference needed]. Figure 2 This invention provides a dynamic priority allocation system for game rooms, comprising the following modules deployed on a server cluster: The data acquisition module is configured to collect dynamic status parameters of the room, including the current number of players, the maximum room capacity, the remaining countdown time, the server node load rate, and the player level distribution data.

[0104] The priority calculation module is configured with a baseline countdown timer associated with the room type. It combines dynamic weighting coefficients and dynamic status parameters to calculate the room priority value through weighted summation.

[0105] The matchmaking module is configured to respond to new player matchmaking requests, filter available rooms and sort them in descending order of priority value, and assign new players to the room with the highest priority value.

[0106] The state machine management module is configured to manage the game room state machine, which includes idle, waiting, and game states. Before a state transition, a state snapshot containing core parameters is generated.

[0107] The state transition execution module is configured to execute state machine transition logic: after the first player joins an empty room, a countdown starts and the player transitions to a waiting state; in the waiting state, the server maintains the countdown duration and broadcasts a synchronization data packet containing the current remaining countdown duration to the client; when the number of players reaches the limit or the countdown is zero, the player transitions to the match state; if an abnormal termination event is detected during the match, a transaction rollback is performed based on the state snapshot, restoring the room state to the waiting state and triggering a recalculation of the priority value.

[0108] Specifically, in the game room dynamic priority allocation system, the modules deployed on the server cluster achieve full-process management of room dynamic priority through structured division of labor and data flow collaboration.

[0109] The data acquisition module, as a component of the system's perception layer, is configured to collect dynamic room status parameters in real time and preprocess core indicators. It continuously acquires parameters such as the current number of players, room capacity limit, remaining countdown time, and server node CPU load rate through the monitoring interfaces of each node in the server cluster. The load rate value ranges from greater than zero to less than or equal to one. Simultaneously, it incorporates a level distribution prediction algorithm. Based on the current player level distribution data and the confidence interval for new player levels, it calculates the standard deviation of the predicted level of all players after a new player joins. If the calculated standard deviation is lower than a preset minimum level difference threshold, the module automatically uses this threshold as the subsequent calculation value to ensure a reasonable level difference benchmark. The collected and calculated parameters are output to the priority calculation module as raw data for priority evaluation.

[0110] The priority calculation module, as the core of the system decision-making, is configured to generate room priority values ​​by integrating multi-dimensional parameters. It stores the baseline countdown timer associated with each room type (e.g., shorter for competitive rooms and longer for casual rooms). After receiving dynamic parameters from the data acquisition module, it calculates the priority value using a weighted summation rule: first, it calculates the player percentage (the ratio of current player count to maximum capacity) and the countdown percentage (the ratio of remaining countdown to baseline time). Then, it multiplies the player percentage by the first weight coefficient, the countdown percentage by the second weight coefficient, the inverse of the class standard deviation by the third weight coefficient, and the inverse of the CPU load rate by the fourth weight coefficient, summing these to obtain the priority value. The weight coefficients are periodically updated through a reinforcement learning adaptive model. The model uses the historical match success rate change within a sliding window and the CPU load fluctuation as input features, aiming to optimize the overall benefit of match success rate and load balancing. The updated weight coefficients and calculation results are output to the match allocation module.

[0111] The matchmaking module, serving as the system's scheduling entry point, is configured to respond to new player requests and allocate the optimal room. Upon receiving a new player's matchmaking request, it filters available rooms from the global room list that are either idle or waiting, excluding rooms currently in competition or whose reservation period has not yet expired. It then sorts the rooms in descending order based on the priority values ​​output by the priority calculation module. For rooms with the same priority value, it polls for allocation in ascending order of creation time, maintaining a polling pointer that continuously points to the earliest created room. After a successful allocation, it returns a room identifier to the player and simultaneously feeds back the player's addition information to the data acquisition module to update the current player count.

[0112] The state machine management module, acting as the system's state hub, is configured to build and maintain the room state machine and snapshot mechanism. Its definition includes the transition rules between idle, waiting, and in-game states: Idle → Waiting → In-game → End → Idle (closed loop). It maintains a current state identifier for each room. Before each state transition, a state snapshot containing core room parameters, dynamic states, priority values, player distribution characteristics, etc., is generated and stored in a distributed cache, indexed by the room identifier. The snapshot serves as the basis for state transitions and anomaly rollback, and is synchronously shared with the state transition execution module.

[0113] Furthermore, the system also incorporates a built-in countdown synchronization module as a system clock synchronization component, configured to maintain a countdown for the waiting state and broadcast it to clients. Using the server's system clock as the sole reference source, it dynamically adjusts the broadcast synchronization data packets according to a preset period based on network latency during the room's waiting state, including the remaining countdown duration and a high-precision timestamp. Upon receiving the delay compensation parameters calculated by the client based on the server's timestamp and the local received time difference, the client dynamically optimizes the broadcast strategy to ensure consistent global time perception.

[0114] The state transition execution module, acting as a system process driver, is configured to perform state transitions and exception handling. Based on the rules of the state machine management module, it starts a countdown when a player joins an available room, and transitions to the match when the waiting state reaches full capacity or the countdown reaches zero. During the match, if an abnormal termination event is detected, such as a node failure or a mass player disconnection, it calls the snapshot pre-stored by the state machine management module to perform a transaction rollback, restoring the room to the match completion time and triggering the priority calculation module to recalculate the room's priority value, re-entering it into the match queue.

[0115] During system operation, modules interact with each other through a distributed communication bus, such as a message queue, within the server cluster: the data acquisition module pushes parameters in real time, the priority calculation module dynamically updates weights and results, the matching and allocation module schedules according to priority, the state machine management module and the state transition execution module work together to ensure reliable state transitions, and the countdown synchronization module ensures consistent client time. This architecture solidifies the methodological logic steps into independently deployable, parallel-running modules, improving processing efficiency and system robustness in high-concurrency scenarios through distributed utilization of hardware resources and functional decoupling.

[0116] To build a closed-loop state system and ensure resource security and data consistency, the state machine management module is also configured to extend the state machine into a closed-loop migration system that includes an end state; the state migration execution module is also configured to: when the preset game end conditions are met, the room transitions from the game state to the end state; when the duration of the end state reaches the preset data retention time, the room data is cleared and the room transitions to the idle state.

[0117] Specifically, based on the aforementioned dynamic priority allocation system for game rooms, the architecture is expanded. Through the coordinated upgrade of various functional modules, more comprehensive full lifecycle management of rooms is achieved, and closed-loop scheduling is completed by relying on the cooperation of modular hardware and software. The state machine management module in the system further expands the scope of state management, adding an end state to the original state system, and building a closed-loop state transition system of idle, waiting, in-game, end, and idle, so as to realize the full-process manageable and controllable state of game rooms from creation to reuse.

[0118] The state transition execution module synchronously extends the execution logic, monitors the room's running status in real time, and drives the room's state to switch to the end state when the room is in a game and meets the preset game end conditions. After the duration of the room being in the end state reaches the preset data retention time for the corresponding game type, it automatically performs a cleanup action, clearing the room's dynamic running data and game session resources, and then switches the state to the idle state. The game end conditions here cover a variety of situations, including the game duration reaching the target, the completion of the win / loss determination, and all players leaving.

[0119] The countdown synchronization module expands interactive functions by pushing room status update data to associated clients at preset time intervals, providing a status query interface, responding to status retrieval requests initiated by clients in real time and providing corresponding data. Once a status verification conflict flag is received from a client, a status correction instruction is immediately issued to the client based on the data it pushes, ensuring that the client and server statuses are consistent.

[0120] The matchmaking module has simultaneously optimized the scheduling and control rules. Rooms that are in a match or that have ended but whose duration has not reached the association threshold are uniformly marked as unassignable and new matchmaking requests are rejected. For rooms that have ended but whose duration has reached or exceeded the association threshold, the permission mode is adjusted to read-only query mode, while retaining access to historical data and continuously blocking new player matchmaking requests until the room completes its state transition and switches to an idle state, at which point normal scheduling permissions are restored.

[0121] To ensure the safe release of resources, prevent leakage, and quickly reuse rooms, the state transition execution module is also configured to release player sessions, clear runtime memory, and reset room state variables in a preset order when a room transitions from an ended state to an idle state. If any release step fails, it will roll back to the ended state, record the exception, and automatically retry, with the number of retries not exceeding a preset limit.

[0122] Specifically, based on the system architecture, the upgraded state transition execution module enables transactional resource management. This differs from a single, process-oriented execution logic, using modular hardware and software to collaboratively complete closed-loop resource reclamation, further ensuring system stability. The state transition execution module is specifically configured with transactional resource release logic. During the transition from an ended state to an idle state, resource disposal actions are executed step-by-step according to a preset sequence: releasing player sessions, clearing runtime memory data, and resetting internal room state variables, thus achieving orderly resource reclamation.

[0123] During transaction execution, if any resource release step encounters an execution exception, the state transition execution module immediately rolls back the room state to the completed state, synchronously records the exception information, extends the corresponding preset data retention time, and automatically initiates a retry operation. The number of retries is strictly controlled within a preset limit to avoid unnecessary occupation of system resources. After all resource release steps have been completed, the state transition execution module initiates a resource integrity check. After verifying that there are no resource residues or leaks, it officially transitions the room state to the idle state and simultaneously resets the current number of players in the room.

[0124] At the same time, the state transition execution module triggers the priority calculation module, which initializes the priority value based on the reset idle state parameters, and then synchronizes the updated priority data to the matching and scheduling module, so that the room can be quickly included in the available scheduling queue, realizing efficient reuse and cyclic scheduling of system resources.

[0125] To dynamically compensate for delays and force corrections, ensuring multi-terminal countdown synchronization, the state transition execution module is also configured to, during the waiting state, receive synchronization correction requests reported by clients based on the deviation between local countdown and server synchronization data exceeding a threshold, and rebroadcast the calibrated remaining countdown duration and corresponding timestamp to all clients in the room.

[0126] Specifically, by expanding the functionality of the countdown synchronization module, more precise timing synchronization control is achieved. Unlike purely procedural execution logic, it relies on the hardware and software collaboration of system modules to complete dynamic delay adaptation and global timing calibration, ensuring consistency across multiple devices. The countdown synchronization module adds delay adaptation and correction functions, receiving network latency compensation parameters uploaded by the client in real time. These parameters are calculated by the client based on the difference between the server's timestamp and the local received time. The module dynamically optimizes the countdown synchronization strategy based on these parameters, adapting to transmission differences in complex network environments.

[0127] When a client repeatedly detects that the local countdown and the server-side countdown duration deviate from the limit and initiates a synchronization correction request, the countdown synchronization module immediately responds to the request and broadcasts the calibrated remaining countdown duration value and the corresponding server timestamp to all clients in the room. This achieves forced global time synchronization, completely eliminates scheduling anomalies caused by multi-terminal time deviations, and ensures accurate and stable countdown control in the game room.

[0128] To dynamically adapt to the start conditions, AI is introduced to fill in gaps and improve matching efficiency. The state transition execution module is also configured to, during the waiting state, if the current number of players is less than the minimum start number threshold and the cumulative waiting time exceeds the dynamic waiting timeout threshold, introduce AI players to fill in the minimum start number and trigger the transition to the in-game state; if the current number of players is greater than or equal to the minimum start number threshold and the remaining countdown time is less than the dynamic early start threshold, directly trigger the transition to the in-game state.

[0129] Specifically, by leveraging the functional expansion of the state transition execution module, a systematic and dynamic match start scheduling and control is achieved. Through inter-module collaboration, intelligent match start adaptation is completed, improving room flow efficiency and game balance. When a room is in a waiting state, the state transition execution module specifically executes dynamic match start adaptation logic, monitoring the room's remaining countdown and player count in real time.

[0130] When the room countdown has not ended and the current number of players has not reached the room's capacity limit, the state transition execution module makes an intelligent judgment based on preset thresholds. If the current number of players does not meet the minimum number of players required to start the game, and the cumulative waiting time exceeds the corresponding dynamic waiting timeout threshold, the module automatically dispatches AI players to fill the gap in the number of players, and then triggers the room state to transition to the game. If the current number of players has reached the minimum number but is not full, and the remaining countdown is less than the early start threshold, the module directly skips the countdown process and immediately drives the state to switch to the game.

[0131] The system's built-in configuration center links various functional modules, periodically optimizing and updating dynamic match start thresholds based on historical match data, server load, and player behavior characteristics to ensure the real-time rationality of the adaptation logic. Simultaneously, the state transition execution module adaptively configures the number of AI players and their behavioral strategy parameters according to the distribution of real player levels within the room, ensuring that the AI ​​players' competitive ability matches the overall skill level of real players and maintaining fairness in the game.

[0132] It should be noted that the system modules are deployed on a server cluster, communicating asynchronously via message queues. Data collection pushes parameters to priority calculation, and results are pushed to matching and allocation. The state machine and migration module share a distributed cache for synchronized snapshots. Modules are functionally partitioned, with data collection and synchronization closer to the game server to reduce latency. The calculation module uses high-performance nodes, and the allocation module is load-balanced to ensure high concurrency and high efficiency.

[0133] For those skilled in the art, various other corresponding changes and modifications can be made based on the technical solutions and concepts described above, and all such changes and modifications should fall within the protection scope of the claims of this invention.

[0134] It should be noted that the embodiments described above are only some embodiments of the present invention, and not all embodiments. The singular forms "a," "described," and "itself" used in the embodiments and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise.

Claims

1. A method for dynamic priority allocation in game rooms, characterized in that, The server performs the following steps: S1 collects dynamic status parameters of the room, including the current number of players, room capacity limit, remaining countdown time, server node load rate, and player level distribution data. S2 configures a baseline countdown duration associated with the room type, and calculates the room priority value by weighted summation based on dynamic weight coefficients and dynamic status parameters. The priority value is obtained by weighted summation of player percentage, countdown percentage, reciprocal of matching balance parameter, and reciprocal of load rate. The dynamic weight coefficient is adaptively updated based on historical matching success rate and server load fluctuation amplitude through reinforcement learning model. S3 responds to new player matchmaking requests, filters available rooms and sorts them in descending order of priority value, assigning new players to the rooms with the highest priority value; if priority values ​​are the same, they are assigned in ascending order of room creation time. S4: Construct a game room state machine that includes idle, waiting, and game states, and generate a state snapshot containing core parameters before state transition; S5, State Machine Transition: After the first player joins an empty room, a countdown begins and the room transitions to a waiting state. In the waiting state, the server maintains the countdown duration and broadcasts a synchronization data packet containing the current remaining countdown duration to the client. When the number of players reaches the limit or the countdown reaches zero, the room transitions to the match state. If an abnormal termination event is detected during the match, a transaction rollback is performed based on the state snapshot, restoring the room state to the waiting state and triggering a recalculation of the priority value.

2. The method according to claim 1, characterized in that, The state machine also includes an end state, forming a closed-loop transition between idle, waiting, in-game, end, and idle; when the preset game end condition is met, the room transitions from the in-game state to the end state; when the duration of the end state reaches the preset data retention time, the room data is cleared and the room transitions to the idle state.

3. The method according to claim 2, characterized in that, When a room transitions from an ended state to an idle state, player sessions are released, runtime memory is cleared, and room state variables are reset in a preset order. If any release step fails, the room is rolled back to the ended state, the exception is recorded, and the room is automatically retried. The number of retries does not exceed a preset limit.

4. The method according to claim 1, characterized in that, The server receives a synchronization correction request reported by the client when the deviation between the local countdown and the server's synchronized data exceeds a threshold, and then rebroadcasts the calibrated remaining countdown duration and corresponding timestamp to all clients in the room.

5. The method according to claim 1, characterized in that, During the waiting period, if the current number of players is less than the minimum starting player threshold and the cumulative waiting time exceeds the dynamic waiting timeout threshold, AI players will be introduced to make up the minimum starting player number and the game will be moved to the game state. If the current number of players is greater than or equal to the minimum starting player threshold and the remaining countdown time is less than the dynamic early start threshold, the game will be moved to the game state directly.

6. A dynamic priority allocation system for game rooms, characterized in that, include: The data acquisition module is configured to collect dynamic status parameters of the room, including the current number of players, the maximum room capacity, the remaining countdown time, the server node load rate, and the player level distribution data. The priority calculation module is configured to set a baseline countdown timer associated with the room type, and calculates the room priority value by weighted summation, combining dynamic weight coefficients and dynamic status parameters. The matchmaking module is configured to respond to new player matchmaking requests, filter available rooms and sort them in descending order of priority value, and assign new players to the room with the highest priority value; The state machine management module is configured to manage the game room state machine, which includes idle, waiting, and game states, and generate a state snapshot containing core parameters before state transitions. The state transition execution module is configured to execute state machine transition logic: after the first player joins an empty room, a countdown starts and the player transitions to a waiting state; in the waiting state, the server maintains the countdown duration and broadcasts a synchronization data packet containing the current remaining countdown duration to the client; when the number of players reaches the limit or the countdown is zero, the player transitions to the match state; if an abnormal termination event is detected during the match, a transaction rollback is performed based on the state snapshot, restoring the room state to the waiting state and triggering a recalculation of the priority value.

7. The system according to claim 6, characterized in that, The state machine management module is further configured to extend the state machine into a closed-loop migration system that includes an end state; the state migration execution module is further configured to: when the preset game end condition is met, the room transitions from the game state to the end state; when the duration of the end state reaches the preset data retention time, the room data is cleared and the room transitions to the idle state.

8. The system according to claim 7, characterized in that, The state transition execution module is also configured to release player sessions, clear runtime memory, and reset room state variables in a preset order when the room transitions from the ended state to the idle state; if any release step fails, it will roll back to the ended state, record the exception, and automatically retry, with the number of retries not exceeding a preset limit.

9. The system according to claim 6, characterized in that, The state transition execution module is also configured to, during the waiting state, receive a synchronization correction request reported by the client based on the deviation between the local countdown and the server synchronization data exceeding a threshold, and rebroadcast the calibrated remaining countdown duration value and corresponding timestamp to all clients in the room.

10. The system according to claim 6, characterized in that, The state transition execution module is also configured to, during the waiting state, if the current number of players is less than the minimum starting player threshold and the cumulative waiting time exceeds the dynamic waiting timeout threshold, introduce AI players to make up the minimum starting player number and trigger the transition to the game state; if the current number of players is greater than or equal to the minimum starting player threshold and the remaining countdown time is less than the dynamic early start threshold, directly trigger the transition to the game state.

Images