Game-based team matching method, device, medium and product

Abstract

Embodiments of the present application relate to the technical field of computer, and disclose a team matching method and device based on game, medium and product. The method comprises: determining a team score of a matching team according to a teaming request of a player; the matching team is used to represent a basic battle unit generated based on the teaming request; dynamically calculating a segment width according to a current number of online players; determining a dynamic segment set according to the team score and the segment width; wherein the segment set is an elastic matching interval set based on dynamic adjustment of a segment boundary and the segment width according to real-time matching load; and determining a multi-team matching result according to the dynamic segment set. At least the technical problem of rigid rules in related technologies can be solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, and particularly relates to a team matching method based on a game, equipment, medium and product. BACKGROUND

[0002] Team matching in a game is a mechanism in which a game system combines players into teams or finds opponents for teams according to rules and algorithms such as player strength, team composition and game mode. After a player sends a matching request, the server filters objects meeting the conditions in a queue, and starts a game when the matching is successful and the player is ready. This mechanism can help players quickly find suitable battle combinations, guarantee the fairness and competitiveness of the game, improve the player experience, and enhance the interest and sociality of the game.

[0003] However, the inventors have found that the team matching method in the related art at least has the technical problem of rigid rules. SUMMARY

[0004] An object of the present application is to provide a team matching method based on a game, equipment, medium and product, at least to solve the technical problem of rigid rules in the related art.

[0005] To achieve the above object, some embodiments of the present application provide the following aspects:

[0006] In a first aspect, some embodiments of the present application further provide a method, comprising: determining a team score of a matching team according to a teaming request of a player; the matching team is used to represent a basic battle unit generated based on the teaming request; dynamically calculating a segment width according to a number of current online players; determining a dynamic segment set according to the team score and the segment width; wherein the segment set is a set of elastic matching intervals based on dynamic adjustment of a segment boundary and the segment width according to real-time matching load; and determining a multi-team matching result according to the dynamic segment set.

[0007] In a second aspect, some embodiments of the present application further provide an electronic device, comprising: one or more processors; and a memory storing computer program instructions which, when executed, cause the processor to perform the steps of the method described above.

[0008] In a third aspect, some embodiments of the present application further provide a computer-readable medium having stored thereon computer program instructions executable by a processor to implement the method described above.

[0009] In a fourth aspect, some embodiments of the present application further provide a computer program product comprising computer programs / instructions which, when executed by a processor, implement the steps of the method described above.

[0010] Compared with the related art, in the scheme provided by the embodiments of the present application, the team score is determined according to the team formation request of the player, and the team score is a quantifiable numerical value; the segmented width is dynamically calculated according to the number of current online players, which changes the previous fixed segmented range mode, and can flexibly adapt to the matching demand under different online number scales; further, the dynamic segmented set is determined based on the real-time matching load in combination with the team score and the segmented width, which breaks the limitation of the static segmented boundary, can realize the elastic adjustment of the matching interval, ensures the reasonable team distribution in each segment, and therefore, when the multi-team matching result is determined according to the dynamic segmented set, the system can dynamically adjust the matching strategy according to the real-time data, avoid the matching rigidity caused by the fluctuation of the number of players and the uneven distribution of team strength, and make each team quickly and fairly find the opponent with similar strength, thereby fundamentally solving the technical problem that the related art cannot adapt to the complex and changeable game environment due to the rigid rules. BRIEF DESCRIPTION OF DRAWINGS

[0011] One or more embodiments are illustrated by way of example in the drawings in which like reference numerals indicate like elements, and in which:

[0012] Figure 1 An exemplary schematic diagram of a game-based team matching system method provided by some embodiments of the present application;

[0013] Figure 2 An exemplary flowchart of a game-based team matching method provided by some embodiments of the present application;

[0014] Figure 3 An exemplary structural diagram of an electronic device provided by some embodiments of the present application. DETAILED DESCRIPTION

[0015] In order to make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are some but not all of the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the protection scope of the present application.

[0016] First Embodiment

[0017] The first embodiment of the present application relates to a game-based team matching method. The method can be applied to the game-based team matching system.

[0018] In some examples, as shown in Figure 1 The game team matching system adopts a three-layer modular design, including a matching rule layer, a matching partition layer, and a team data layer. The matching rule layer, as the top layer architecture of the system, is responsible for defining global matching parameters, including the upper limit of the number of single teams, the matching unit value calculation standard, and the number of matching partition sets; the matching partition layer, as the intermediate execution layer, splits the global player pool into multiple independent matching partitions (such as the 20 matching partitions in the example), and each partition processes matching requests in parallel; the team data layer, as the basic data unit, stores specific team information, including player membership composition, team ID identification, and team score based on matching unit value calculation.

[0019] The three layers work collaboratively through strict hierarchical constraints and data flow. The matching rule layer passes down core parameters, directly constraining the number of partitions, the upper limit of team size, and the matching score standard of the matching partition layer; the matching partition layer creates parallel processing units based on the rule layer parameters and allocates team data that meets the conditions to each partition; the team data layer, as the execution carrier, participates in matching operations following the partition rules, and its team score and member composition information serve as the core basis for matching decisions. This hierarchical architecture decouples rule definition, parallel execution, and data storage, ensuring system scalability and operational efficiency.

[0020] This modular design achieves exponential improvement in matching performance through three-layer linkage. The parameterized configuration of the matching rule layer enables the system to support rapid deployment of various battle modes (such as 4-team mixed battles and 100-person survival games); the parallel processing mechanism of the matching partition layer optimizes the algorithm complexity from the traditional O(n 16 ) to O(kn 2 )(k is the number of partitions), significantly reducing computational delay; the precise data modeling of the team data layer combined with the recursive pruning algorithm reduces invalid matching combinations by 82%, further improving the success rate of matching. The three-layer collaboration not only ensures matching speed (reducing actual time consumption by 45.6%) but also ensures battle fairness through a dynamic difference control model (reducing the rate of difference exceeding the standard by 78.7%), ultimately achieving dual optimization of system resource utilization and user experience.

[0021] Further, the method can include the following steps, as shown in Figure 2

[0022] Step S101, determining a team score of a matching team according to a team formation request of a player; the matching team is used to represent a basic battle unit generated based on the team formation request; ​

[0023] Step S102: Dynamically calculate the segment width based on the current number of online players;

[0024] Step S103: Determine a dynamic segment set based on the team score and the segment width; wherein the segment set is a set of elastic matching intervals that dynamically adjust the segment boundaries and the segment width based on real-time matching load.

[0025] Step S104: Determine the multi-team matching results based on the dynamic segmentation set.

[0026] The following sections will provide a detailed explanation of each of the above steps.

[0027] For example, in step S101, when a player initiates a team creation or joining operation, the system can initialize player data, which may include the player's basic attributes, such as level, equipment, skills, etc.

[0028] Furthermore, the system can detect team-up request status in real time. If a team-up request is detected, a multi-player matchmaking team can be created for the player, triggering a multi-player team scoring mechanism. This mechanism may use algorithms such as weighted averaging or attribute aggregation to comprehensively evaluate the basic attributes of team members and generate a team score that represents the overall strength of the team. If no team-up request is detected, a solo matchmaking team can be created for the player, triggering a solo team scoring mechanism. This mechanism may directly use the player's individual base score as the team score for the solo matchmaking team. A solo matchmaking team is a virtual team unit created by the system for players who are not in a team. Thus, the team score of a matchmaking team in this embodiment can be either the team score of a multi-player matchmaking team or the team score of a solo matchmaking team.

[0029] The above design enables unified management of solo and team players, placing all players in the same matchmaking pool. This allows the system to allocate matches based on standardized team scores, eliminating matchmaking discrepancies caused by differences in player team status and ensuring a fair and competitive gaming environment.

[0030] For step S102, for example, the segment width (represented by W in some embodiments) can be dynamically calculated in real time based on the number of active online players in the current game server. The segment width is the basis for dividing the matching pool and also the score range value that defines the player's skill level.

[0031] Specifically, the system can divide the matchmaking pool, comprised of all online players, into multiple sub-ranges based on segment width. For example, when W=100, the matchmaking pool can be divided into ranges such as 0-99 points, 100-199 points, and 200-299 points. Players within each range are considered to have similar skill levels, forming an independent sub-matchmaking pool. In this case, the segment width determines both the range of each sub-matchmaking pool and the score span of the corresponding skill range.

[0032] It is worth noting that the segment width in this embodiment is not fixed. The system can flexibly adjust it according to the number of online players. For example, if there are many online players, the segment width can be appropriately increased to improve matching efficiency and expand the scope of each sub-matching pool; if there are few online players, the segment width can be reduced to ensure matching quality, making the skill levels of players within the same sub-matching pool more similar. Through this dynamic adjustment mechanism, the system can ensure both matching efficiency and maintain fairness in the battles.

[0033] For step S103, for example, the matched teams can be assigned to target segments in a dynamic segment set. The segment set consists of multiple flexible matching intervals, each corresponding to a specific range of team scores. The boundary values ​​(i.e., start and end scores) and segment widths of each segment in the segment set are not fixed but can be dynamically adjusted based on real-time matching load conditions. For example, when matching queue backlogs or uneven team score distribution occur, the segment boundaries and segment widths can be automatically optimized to ensure a balanced number and similar strength of teams within each segment, thereby improving the system's flexibility and response efficiency.

[0034] For step S104, for example, the system can, within the flexible matching interval constructed by the segment set, select balanced match combinations for multiple teams to be matched based on the principle of similar team scores. Specifically, the system can divide matching teams with similar team scores into the same candidate pool according to the boundaries and width of the dynamic segments; then, it selects suitable match partners from the candidate pool to ensure that the strength difference between the two teams is within a reasonable range, and outputs the matching results to determine the match combinations of each team, completing a full matching cycle. This process, by dynamically adjusting the matching interval, optimizes matching efficiency while ensuring fairness, which is beneficial to improving the player's battle experience.

[0035] Regarding steps S101-S104, assuming there are currently 1000 online players queuing for matchmaking, the system can first calculate the team score for each team based on their team information. Then, based on the player density in the current matchmaking pool, it automatically adjusts the matchmaking range—widening the range if there are fewer players and narrowing it if there are more. Then, based on the dynamically calculated range width, all teams are divided into different skill ranges, the boundaries of which can be adjusted in real-time as new teams join. Furthermore, the system can prioritize selecting the four teams with the closest team scores within the same dynamic range (e.g., teams between scores of 85-90) to form a 4v4v4v4 match, ensuring a balance of strength among all sides. This entire process significantly reduces player waiting time while ensuring matchmaking fairness.

[0036] Optionally, in some embodiments, the method can be applied to game scenarios such as four-player team matching and 100-player battle royale.

[0037] Specifically, in some game modes, such as four-player team battles (4v4v4v4) or 100-player battle royale, this method can flexibly adapt to the needs of asymmetrical battles by adjusting matching parameters. The system can dynamically set the number of teams, team balance conditions, and matching range based on the rules of different gameplay modes, ensuring a relatively balanced distribution of strength among multiple teams. For example, in a four-player free-for-all mode, the matching scores of four teams can be evaluated simultaneously, placing them within similar dynamic score ranges to prevent one side from affecting fairness due to a significant skill disparity. In battle royale games, the matching pool capacity can be expanded to support large-scale simultaneous matching of players, while still optimizing the distribution of competitive skill levels among players in the same match through dynamic segmentation, thereby improving matching efficiency and fairness in complex battle scenarios.

[0038] It should be noted that this method is applicable to various game genres, including but not limited to MOBA (Multiplayer Online Battle Arena), FPS (First-Person Shooter), and survival games. One advantage of this embodiment lies in the versatility of the dynamic ranking mechanism—regardless of changes in game rules, the system can adapt to different gameplay requirements by adjusting the team score calculation method and matchmaking parameters. For example, in MOBAs, team scores can focus on player rank and hero synergy; in FPSs, gun skill ratings and tactical coordination can be emphasized; and in survival games, survival time and kill statistics may be more important. This ensures that various games can maintain their unique characteristics while using the same dynamic matchmaking framework to achieve fair competition, effectively addressing the common needs of different game genres in matchmaking system design.

[0039] Understandably, in related technologies, the traditional fixed-segment matching mechanism, such as dividing segments into tiers of 200 points, leads to the following problems when player online volume fluctuates: either high-score players experience long queues due to overly narrow segments (e.g., in the early morning), or low-score players are forced to play against high-score players due to overly wide segments (e.g., during evening peak hours). This rigid segmentation cannot dynamically adjust matching accuracy based on real-time matching load—maintaining narrow segments when online players are scarce results in low matching efficiency, while large segment spans during player surges affect fairness.

[0040] It is not difficult to see that, compared with related technologies, the solution provided in this application determines the team score of the matched team based on the player's team-up request, and the team score is a quantifiable value; by dynamically calculating the segment width based on the current number of online players, it changes the previous fixed segment range mode, which can flexibly adapt to the matching needs under different online player scales; furthermore, by combining the team score and segment width, a dynamic segment set is determined based on the real-time matching load, breaking the limitation of static segment boundaries, which can realize the elastic adjustment of the matching interval and ensure that the team distribution within each segment is reasonable. Therefore, when determining the matching results of multiple teams based on the dynamic segment set, the system can dynamically adjust the matching strategy based on real-time data, avoiding the rigidity of matching caused by problems such as fluctuations in the number of players and uneven distribution of team strength, so that each team can quickly and fairly find opponents of similar strength, fundamentally solving the technical problem of rigid rules in related technologies that cannot adapt to complex and ever-changing game environments.

[0041] Second Embodiment

[0042] The second embodiment of this application relates to a game-based team matching method. The second embodiment is an improvement upon the first embodiment, specifically in that it provides a concrete implementation method for determining the team score of the matched team after responding to a player's team-up request.

[0043] Specifically, determining the team score of the matched team based on the player's team request, i.e., step S101, may include the following steps:

[0044] Step S1011: Based on the player's team-up request, obtain the original scores of the players in the matched team;

[0045] Step S1012: Based on the original scores, determine the average score, highest score, and lowest score of the matched teams; wherein the highest score is the maximum value among the original scores, and the lowest score is the minimum value among the original scores.

[0046] Step S1013: Determine the team score of the matched team based on the average score, the highest team score, and the lowest team score.

[0047] For step S1011, for example, the raw individual score of each player in the matched team can be extracted based on the player's team request. The raw score can be calculated based on data such as the player's historical performance, competitive rank, or character attributes, and is used to characterize each player's individual skill level. The calculation method for the raw score can be implemented using related technologies and is not the focus of this embodiment.

[0048] For step S1012, for example, based on the original scores, the team average score (the arithmetic mean of the original scores of all members), the team's highest score, and the team's lowest score are further calculated. The average score, the team's highest score, and the team's lowest score respectively characterize the team's comprehensive strength distribution from three dimensions: overall level, upper limit strength, and lower limit strength.

[0049] For step S1013, for example, the final team score of the matching team can be generated by combining the average score, the highest team score and the lowest team score through a weighted OR algorithm.

[0050] Optionally, in some embodiments, the determination of the team score of the matching team based on the average score, the highest team score, and the lowest team score is specifically achieved by the following formula: Team score = Average score - Penalty coefficient × (Highest team score - Lowest team score).

[0051] For example, the value of the penalty coefficient can be flexibly set according to multiple factors such as game type, matching mechanism design objectives, and player experience. This embodiment does not make specific limitations in this regard.

[0052] For example, suppose a four-player team has initial scores of 80, 85, 90, and 95. The system can first calculate the team's average score as (80+85+90+95) / 4 = 87.5, the highest score as 95, and the lowest score as 80. If a penalty coefficient of 0.1 is set, the final team score = 87.5 - 0.1 × (95 - 80) = 87.5 - 1.5 = 86. This calculation method introduces a score difference penalty mechanism, so the greater the skill gap between team members (a range of 15 points in this example), the greater the decrease in the final team score compared to the average score (from 87.5 to 86).

[0053] As can be seen, in this embodiment, by using the above calculation method, the penalty coefficient is used to quantify the score difference between members, thereby weakening the effective matching score of high variance teams (i.e., teams with large differences in member strength). As a result, when matching, it is more inclined to match teams with similar strength, which to a certain extent avoids the matching imbalance problem caused by high-scoring players carrying low-scoring teammates.

[0054] It is not difficult to see that in this embodiment of the application, by obtaining the original scores of the players in the matched team according to the player's team-up request, the strength data of each member can be completely collected; then, based on the original scores, the team average score, the team highest score, and the team lowest score are calculated, which can comprehensively show the average strength and strength distribution range of the team members; then, based on the average score, the team highest score, and the team lowest score, the team score of the matched team is determined, providing a specific implementation method for determining the team score of the matched team after responding to the player's team-up request.

[0055] Third Embodiment

[0056] The third embodiment of this application relates to a game-based team matching method. The third embodiment is an improvement upon the first embodiment, specifically in that it provides a method for dynamically calculating the segment width based on the current number of online players.

[0057] Specifically, the step of dynamically calculating the segment width based on the current number of online players, i.e., step S102, can further include the following steps:

[0058] Step S1021: Obtain the current number of online players;

[0059] Step S1022: When the number of currently online players is greater than a preset threshold, the segment width is determined to a preset fixed value;

[0060] Step S1023: When the number of currently online players is less than or equal to the preset threshold, calculate the segment width based on the number of currently online players, the highest score of the currently online players, and the lowest score of the currently online players.

[0061] For step S1021, for example, the system can monitor the number of currently online players in real time, or it can monitor the number of currently online players at preset intervals. This embodiment does not specifically limit this.

[0062] For step S1022, for example, the system can compare the acquired number of currently online players with a preset threshold. If the number of currently online players is greater than the preset threshold, it means that the matching pool is large and the number of players is sufficient. In order to improve matching efficiency and maintain relatively stable matching quality, the system can directly determine the segment width as a preset fixed value. The preset fixed value can balance matching speed and fairness when there are enough players, ensuring that most players can be matched with opponents quickly and reasonably.

[0063] It should be noted that the preset threshold can serve as the boundary between high load and low load conditions. The preset threshold and the preset fixed value can be determined based on actual circumstances, and this embodiment does not impose specific limitations on them.

[0064] For example, suppose in a multiplayer online competitive game, the system detects 1200 players currently online, exceeding the preset threshold of 1000. Based on this, the system can directly set the segment width to a fixed preset value of 100. With this setting, the system can quickly divide players into different ranges based on their team scores, such as 100-199 points, 200-299 points, etc., avoiding excessively fine segmentation that could lead to long matchmaking wait times. When there are enough players, this effectively improves matchmaking efficiency, allowing players to enter matches faster.

[0065] Regarding step S1023, for example, when the system determines that the number of currently online players is less than or equal to the preset threshold, it indicates that the matching pool is small and the number of players is limited. In this case, continuing to use a fixed segment width may lead to matching difficulties or an imbalance in the matching process. Therefore, the system can dynamically calculate the segment width by combining the current number of online players, the highest score of online players, and the lowest score of online players.

[0066] Optionally, in some embodiments, the step of calculating the segment width based on the number of currently online players and the highest and lowest scores of the currently online players, i.e., step S1023, can be specifically implemented by the following formula:

[0067] W=ceil((MaxScore-MinScore) / 10^(log 10 (N)-1))

[0068] Wherein, MaxScore represents the highest score of the currently online player, MinScore represents the lowest score of the currently online player, ceil represents the round-up function, W represents the segment width, and N represents the number of currently online players.

[0069] For example, suppose in the same multiplayer online competitive game, the system detects that the current number of online players N is 800, which does not exceed the preset threshold of 1000. Simultaneously, the system obtains the highest score (MaxScore) of the current online players as 1200 points and the lowest score (MinScore) as 200 points. At this time, the system executes step S1023, substituting the data into the formula to calculate the segment width W:

[0070] W=ceil((MaxScore-MinScore) / 10^(log 10 (N)-1))

[0071] =ceil(1200-200) / 10^(log 10 (800)-1))≈13

[0072] Thus, with a segment width of 13, the system can divide player teams into intervals such as 200-212 points and 213-225 points. This allows for flexible adjustment of the segment width based on the actual number and strength distribution of players, while also expanding the matching range when the number of players is small. This avoids matchmaking imbalances caused by excessively wide segments or excessively long matchmaking waiting times caused by excessively narrow segments, achieving a balance between matchmaking efficiency and fairness.

[0073] It should be noted that this embodiment can also be an improvement based on the second embodiment.

[0074] It is easy to see that in this embodiment, obtaining the current number of online players provides basic data for the dynamic adjustment of segment width. When the number of online players is greater than a preset threshold, the segment width is determined to a preset fixed value. This allows for the rapid division of matching intervals with stable segmentation rules when there are enough players, reducing computational complexity and improving matching efficiency. When the number of online players is less than or equal to the preset threshold, the segment width is calculated based on the current number of online players, the highest score, and the lowest score. This allows the system to flexibly adjust the segment granularity based on insufficient player numbers and relatively dispersed skill distribution, avoiding matching difficulties caused by overly fine segments and preventing imbalances in battles caused by overly wide segments. Therefore, through this mechanism of dynamically calculating segment width based on different situations, the system can ensure matching speed during peak player periods and balance matching fairness during off-peak periods, effectively solving the problem of balancing matching efficiency and fairness under different online player scenarios and optimizing the overall matching experience for players.

[0075] Third Embodiment

[0076] The third embodiment of this application relates to a game-based team matching method. The third embodiment is an improvement upon the first embodiment, specifically in that it provides a concrete implementation method for determining a dynamic set of segments based on the team score and the segment width.

[0077] Specifically, determining the dynamic set of segments based on the team composition and the segment width, i.e., step S103, may further include the following steps:

[0078] Step S1031: Based on the team score, the score interval is divided into multiple continuous elastic segments according to the segment width; wherein, the segment boundaries are dynamically adjusted according to the real-time score distribution.

[0079] Step S1032: Determine a dynamic set of segments based on the multiple consecutive elastic segments.

[0080] For step S1031, for example, the current team score can be used as the center point, and combined with the dynamically calculated segment width, a continuous elastic score interval can be divided in the matching pool. The elastic score interval can be adjusted in real time according to the score distribution density of all teams to be matched.

[0081] Optionally, in some embodiments, the boundary adjustment of the elastic segment can follow the following rules: when the number of players in a certain score range exceeds a set threshold, the width of the segment is automatically expanded; when the difference in the number of players in adjacent segments exceeds a balance threshold, the segment boundaries are adjusted to make the distribution more balanced. For example, if teams are clustered in a certain score range, the segment is automatically refined; if teams are sparse in a certain score range, adjacent segments are merged, thereby forming an adaptive range that matches the real-time player distribution.

[0082] For step S1032, for example, the system maps all teams to be matched to the corresponding dynamic intervals to form a global segment set.

[0083] Optionally, in some embodiments, the optimization method for the dynamic segment set may include: dynamically merging low-activity segments or splitting high-density segments based on real-time matching load to improve matching efficiency. For example, when the addition of a new team causes a surge in the number of teams in a segment, the system can trigger segment fission (e.g., splitting the original 100-200 segment into 100-150 and 150-200); conversely, when players leave, resulting in too few teams in a segment, adjacent segments are automatically merged (e.g., merging 80-100 and 100-120 into 80-120), always maintaining the number of teams within each segment within a reasonable threshold range.

[0084] For example, assuming there are several teams in the current matching pool, with their scores ranging from 50 to 150, the system can first divide the pool into multiple overlapping flexible intervals (such as 50-90, 70-110, 90-130, and 110-150 points) centered on each team score, based on dynamically calculated segment widths (e.g., ±20 points). The boundaries of these intervals will slide and adjust in real time as new teams are added. Subsequently, the system can integrate these flexible intervals into a dynamic segment set. When there are too many teams in a certain interval (e.g., 70-110 points), it can be automatically subdivided into two sub-intervals: 70-90 and 90-110. If there are too few teams in adjacent intervals (e.g., 50-90 and 90-130 points), they can be merged into 50-130 points, thereby always maintaining a balanced team density within each segment and achieving dynamic optimization of matching efficiency and fairness.

[0085] It should be noted that this embodiment can also be an improvement based on the second embodiment.

[0086] It is easy to see that in this embodiment, by using team scores as a benchmark and dividing the score interval into multiple continuous flexible segments according to the segment width, and with the segment boundaries dynamically adjusted according to the real-time score distribution, the system can flexibly determine the start and end scores of each segment based on the actual strength distribution of players. This avoids the problem of some intervals being too concentrated or too sparsely populated due to fixed segments. Furthermore, these flexible segments are integrated into a dynamic set of segments, allowing the entire matching interval to adaptively adjust as player team scores change in real time. Therefore, the dynamic segmentation mechanism provided in this embodiment can accurately reflect the strength distribution characteristics of the player group. When the number of players fluctuates or the strength distribution changes, it automatically optimizes the segmentation strategy, ensuring both matching fairness (placing teams of similar strength in the same interval) and improving matching efficiency (avoiding excessively long matching wait times due to unreasonable segmentation). This achieves stability and adaptability of the matching system in different environments, effectively improving the player's matching experience.

[0087] Fourth embodiment

[0088] The fourth embodiment of this application relates to a game-based team matching method. The fourth embodiment is an improvement upon the third embodiment, specifically in that it provides a concrete implementation method for determining the multi-team matching results based on the dynamic segment set.

[0089] Specifically, determining the multi-team matching results based on the dynamic segment set, i.e., step S104, may further include the following steps:

[0090] Step S1041: Monitor the waiting time of teams in each segment and / or the segment load;

[0091] Step S1042: Determine whether to trigger the cross-segment diffusion mechanism based on the waiting time and / or segmented load; the cross-segment diffusion mechanism is used to balance matching speed and fairness by dynamically expanding the matching segment range.

[0092] Step S1043: Determine the multi-team matching results according to the cross-segment diffusion mechanism.

[0093] For step S1041, for example, the system can monitor the waiting time of teams within each segment in real time, record the waiting time of each team from the time it enters the matching queue to the current time, and simultaneously count the number of teams waiting for matching within each segment in real time, thereby assessing the segment load. In some examples, the waiting time may specifically be the average waiting time.

[0094] For step S1042, for example, when it is detected that the waiting time of a team within a certain segment exceeds a preset threshold, and / or the number of waiting teams within that segment is too large, causing excessive load, the system can trigger a cross-segment diffusion mechanism. This cross-segment diffusion mechanism is used to seek a balance between matching fairness and speed, dynamically expanding the range of matching segments to provide more matching opportunities for teams with excessively long waiting times, avoiding long waiting times caused by strictly limiting them to a single segment.

[0095] It's worth noting that if the cross-segment diffusion mechanism is not triggered, it indicates that the team waiting time and segment load within each segment are within reasonable thresholds. In this case, the system can perform matchmaking locally within each segment. Simultaneously, the system can initiate a periodic detection mechanism to monitor the team waiting time within each segment at fixed time intervals (e.g., every 10 seconds). If, during a detection, a team's waiting time exceeds a preset timeout threshold (e.g., 120 seconds), the system can reassess whether to trigger the cross-segment diffusion mechanism. If all teams' waiting times are within acceptable limits, matchmaking can continue within the local segment, ensuring that the matchmaking process maintains fairness within the segment while completing match assignments within a reasonable timeframe.

[0096] Regarding step S1043, for example, after the cross-segment diffusion mechanism is triggered, the system can dynamically expand the matching range of waiting teams from their original segment to adjacent or nearby segments. Within the expanded range, the system can re-evaluate the matching degree of candidate teams, comprehensively considering factors such as team score difference and waiting time, and finally determine the multi-team matching result. In this way, the mechanism can ensure that teams can enter the battle within a reasonable time, and by controlling the expansion range, it can maintain the balance of strength between the two sides as much as possible, achieving a dual optimization of matching efficiency and fairness.

[0097] For example, suppose in a game, the system monitors in real time that there are 50 teams waiting for matchmaking in the Diamond rank (1800-1900 points), with an average wait time of 90 seconds (exceeding the preset threshold of 60 seconds), while the adjacent Star rank (1900-2000 points) has only 20 teams waiting, with a lower load. In this case, the system can trigger a cross-rank diffusion mechanism, expanding the matchmaking range from the Diamond rank to the Star rank. Then, within the expanded range, the system can filter out 10 Star rank teams of similar strength (e.g., a point difference ≤ 50) that have had longer wait times, thus quickly completing the matchmaking. This reduces the wait time for Diamond teams (from 90 seconds to 30 seconds) and ensures fairness for both sides by controlling the rank expansion range and skill differences.

[0098] Optionally, in some embodiments, the step of determining whether to trigger the cross-segment diffusion mechanism based on the waiting time and / or segmented load, i.e., step S1042, may further include:

[0099] Step S10421: Obtain the current segment load and the system average load;

[0100] Step S10422: Determine the diffusion trigger probability based on the waiting time, the current segment load, and the system average load;

[0101] Step S10423: Determine whether to trigger the diffusion mechanism based on the diffusion trigger probability.

[0102] For example, in S10421, the system can initiate a data acquisition program to obtain data such as the number of teams waiting for matching and resource utilization in the current segment in real time, thereby calculating the load of the current segment and reflecting the matching pressure of that segment. Simultaneously, the system can aggregate the load of all segments and calculate the average load of the entire system as a benchmark for measuring global matching pressure.

[0103] For example, regarding S10422, the system can use a preset probability calculation model to weight each factor according to different weights. For instance, the waiting time accounts for 40%, the current segment load accounts for 35%, and the system average load accounts for 25%. A value between 0 and 1 is obtained through function calculation to represent the probability of diffusion triggering. This value comprehensively reflects the degree of imbalance in the current segment matching; the higher the value, the stronger the necessity of triggering the cross-segment diffusion mechanism.

[0104] For example, in S10423, the system generates a diffusion trigger probability, which can be compared with a pre-set trigger threshold (e.g., 0.6) to determine whether to trigger a cross-segment diffusion mechanism. If the probability value is greater than or equal to the threshold, the system can immediately activate the cross-segment diffusion mechanism to expand the matching segment range; if the probability value is less than the threshold, the current matching strategy can be maintained, and the matching operation can continue within the current segment.

[0105] For example, in a certain game, the system detects that the current segment load is 80% (40 waiting teams, far exceeding the system average load of 30%), and the average waiting time of the teams has reached 80 seconds (the preset timeout threshold is 60 seconds). After obtaining this data through step S10421, step S10422 calculates the diffusion trigger probability using a preset model: assuming a waiting time weight of 40%, a current segment load weight of 35%, and a system average load weight of 25%, then the probability of waiting time contributing is (80 / 60)×40%≈53.3%, the probability of current segment load contributing is (80%-30%) / 70%×35%≈25% (assuming the full load difference is 70%), and the probability of system average load contributing is (1-30% / 30%)×25%=0 (because the system average load has not exceeded the limit). The overall trigger probability is approximately 53.3%+25%=78.3%. In step S10423, since the probability (78.3%) exceeds the preset threshold of 60%, the system immediately triggers the cross-segment diffusion mechanism.

[0106] Optionally, in some embodiments, determining the diffusion trigger probability based on the waiting time, the current segment load, and the system average load, i.e., step S10422, can be specifically implemented using the following formula:

[0107] P = α1 × ln(t+1) + β1 × (current segment load / system average load);

[0108] Wherein, P represents the diffusion trigger probability, t represents the waiting time, α1 represents the first time factor weighting coefficient, and β1 represents the first load factor weighting coefficient.

[0109] For example, suppose in a certain game, the system detects that the current segment load is 60% (30 waiting teams), the system average load is 30%, and the average team waiting time t = 70 seconds. After obtaining this data in step S10421, the diffusion trigger probability P can be calculated using the above formula:

[0110] Assuming the first time factor weighting coefficient α1 = 0.1, substituting into ln(70+1) = ln71 ≈ 4.26, the corresponding term is 0.1 × 4.26 = 0.426; assuming the first load factor weighting coefficient β1 = 0.05, the ratio of the current segment load to the system average load is 60% / 30% = 2, the corresponding term is 0.05 × 2 = 0.1; the diffusion trigger probability P can be calculated as 0.426 + 0.1 = 0.526 (i.e., 52.6%). If the preset trigger threshold is 50%, then 52.6% exceeds the threshold, and the system triggers the cross-segment diffusion mechanism.

[0111] It should be noted that this embodiment may also be an improvement based on the first embodiment and / or the second embodiment.

[0112] Understandably, in related technologies, matchmaking mechanisms are typically designed to only allow teams from adjacent skill levels to match. For example, a Diamond player can only match with teams from the adjacent Master or Platinum skill levels, and the threshold for cross-skill matching, i.e., the range of skill difference between skill levels, remains fixed. Under this rule, regardless of changes in wait times, load conditions, or player skill distribution within a given skill level, the range of cross-skill matching is always limited to fixed adjacent skill levels and cannot be dynamically adjusted based on real-time data. For instance, if a skill level in a skill level drops drastically, resulting in excessively long wait times, the system can still only search for matches within fixed adjacent skill levels. If the skill difference between adjacent skill levels is too large or there are similarly few matches available, this will lead to low matchmaking efficiency or an imbalance in fairness, making it unsuitable for complex real-time matchmaking scenarios.

[0113] It is easy to see that in this embodiment, by monitoring the waiting time and segment load of teams within each segment, the system can accurately capture the real-time status of the matching queue; then, based on the waiting time and / or segment load, it determines whether to trigger the cross-segment diffusion mechanism, allowing the system to dynamically expand the matching segment range when the waiting time is too long and / or the segment load is too high; thus, the matching result of multiple teams can be determined according to the cross-segment diffusion mechanism. In this way, the system can avoid long waiting times caused by strictly limiting segments, and can also ensure the relative balance of strength between the two sides by controlling the expansion range, achieving a dual optimization of matching speed and fairness.

[0114] Fifth embodiment

[0115] The fifth embodiment of this application relates to a game-based team matching method. The fifth embodiment is an improvement upon the fourth embodiment, specifically in that it provides a concrete implementation method for determining multi-team matching results based on the cross-segment diffusion mechanism.

[0116] Specifically, determining the multi-team matching results based on the cross-segment diffusion mechanism, i.e., step S1043, may further include the following steps:

[0117] Step S10431: When the diffusion trigger probability exceeds the preset probability threshold, the matching range is expanded from the current segment width to the target segment width, centered on the team segment of the current matching team.

[0118] Step S10432: Filter low-load partitions. The low-load partitions meet the following conditions: the current load rate is lower than a preset ratio of the system average load rate, and the teams in the partition are located within the range determined by the target partition width.

[0119] Step S10433: Generate a cross-partition candidate set based on the candidate matching teams within the low-load partition;

[0120] Step S10434: Determine the multi-team matching results based on the cross-partition candidate set.

[0121] Regarding step S10431, for example, when the diffusion trigger probability exceeds a preset probability threshold (e.g., 60%), it indicates that the matching pressure of the current segment has exceeded a reasonable range. At this time, the system can use the team segment of the team waiting for matching as the reference center point and expand the originally fixed matching segment width (e.g., 100 points) to the target segment width (e.g., 150 points). That is, the matching range can be expanded from the segment width W to the target segment width W', where W' = k × W (k > 1), and the expansion coefficient k is negatively correlated with the system's cross-segment matching success rate. In this way, by expanding the score range, the limitations of the original segment boundary are broken, providing a wider matching candidate pool for the waiting teams, thereby increasing the possibility of finding a suitable opponent.

[0122] For step S10432, for example, after expanding the matching range, the system can perform load rate screening on all segments covered by the target segment width, filtering out "low-load partitions" that meet two conditions: first, the current load rate of the segment (such as the percentage of waiting teams) is lower than a preset proportion of the system's average load rate (e.g., 70%), indicating that its matching pressure is relatively low; second, the scores of the teams within the segment fall within the range determined by the target segment width, ensuring that the strength gap between the candidate teams and the currently matched teams is within an acceptable range. Through this filtering mechanism, the system can prioritize finding matching targets from segments with lower pressure, avoiding further transmission of pressure from high-load segments.

[0123] For step S10433, for example, based on the selected low-load partitions, the system can extract all candidate matching teams that meet the conditions within these partitions and integrate them into a cross-partition candidate set. The teams in this candidate set not only meet the score range requirements, but also have the characteristic of low load in their respective segments, which can ensure the fairness of matching (similar strength) and lay the foundation for fast matching (fewer waiting teams in each segment).

[0124] Regarding step S10434, for example, the system can determine the multi-team matching result based on the cross-segment candidate set and a preset matching strategy (such as prioritizing matching the team with the closest team score or prioritizing matching the team with the longest waiting time). For example, for a waiting team with a team score of 1800, after the target score segment width is expanded to 150 points, the system selects teams with team scores of 1780-1820 and longer waiting times from the low-load 1700-1950 score range to complete the matching. This shortens the waiting time through cross-segment diffusion and maintains the balance of strength between the two sides through precise screening, thus optimizing matching efficiency and fairness.

[0125] For steps S10431-S10434, for example, suppose in a certain game, a team with 1600 points is waiting for a team whose current width W = 100 (corresponding to the 1500-1600 point range). The system calculates the diffusion trigger probability to be 75% (exceeding the probability threshold of 60%). Step S10431 expands the matching range to the target segment width of 150 points, that is, determining the matching range of 1450-1750 points centered on 1600 points. In step S10432, the system filters out low-load partitions with a load rate lower than 70% of the system average load rate, such as 1450-1550 points (load rate 20%) and 1650-1750 points (load rate 15%), and the team scores in these partitions are all within the target range. Step S10433 integrates the candidate teams from these two partitions into a cross-partition candidate set. In this set, there are candidate teams with a score of 1530 in the 1450-1550 score range, and candidate teams with a score of 1720 in the 1650-1750 score range. Step S10434 applies the score difference constraint formula max(score difference between adjacent section teams) ≤ 1.5W = 150 points, calculating the score difference between the current team and the candidate teams: 1600-1530 = 70 points ≤ 150 points, 1720-1600 = 120 points ≤ 150 points, both meeting the condition. Finally, the system can select the team with the smaller score difference (1530 points) from the candidate set for matching. This solves the waiting problem caused by high load in the original segment through cross-segment expansion, and controls the strength gap through a score difference constraint of 1.5 times the segment width, achieving a balance between matching efficiency and fairness.

[0126] Optionally, in some embodiments, the method for determining the probability threshold may include:

[0127] P_cross=α2×ln(t+1)+β2×(N_pending / γ);

[0128] Wherein, P_cross represents the probability threshold, N_pending is the total number of players currently waiting to be matched, α2 represents the second time factor weight coefficient, β2 represents the second load factor weight coefficient, and γ represents the load normalization base.

[0129] In some other embodiments, the probability threshold can be a fixed value; however, in this embodiment, the probability threshold is a dynamic value.

[0130] For example, suppose in a game, the average wait time for teams in a certain rank is t = 80 seconds, the total number of players waiting to be matched is Npending = 300, and the load normalization base is γ = 200. According to the formula P_cross = α² × ln(t+1) + β² × (Npending / γ), and given that the weighting coefficient of the second time factor α² = 0.2 and the weighting coefficient of the second load factor β² = 0.1, then ln(80+1) = ln81 ≈ 4.39. Therefore, α² × ln(t+1) = 0.2 × 4.39 = 0.878; Npending / γ = 300 ÷ 200 = 1.5, β² × (Npending / γ) = 0.1 × 1.5 = 0.15. Adding the two results together, we get the dynamic threshold P_cross = 0.878 + 0.15 = 1.028. This means that when the probability of diffusion triggering exceeds 1.028, the system will trigger the cross-segment diffusion mechanism. Based on this dynamic threshold, the system can flexibly adjust the triggering conditions of cross-segment diffusion by combining the actual waiting time and the number of players waiting to be matched, so as to dynamically adapt to the real-time needs of player matching in the game while ensuring matching efficiency and fairness.

[0131] Optionally, in some embodiments, the step of generating a cross-partition candidate set based on the candidate matching teams within the low-load partition, i.e., step S10433, may further include:

[0132] Step S10433A: Calculate the absolute difference between the team scores of the candidate matching team and the current matching team;

[0133] Step S10433B: Sort the candidate matching teams in ascending order according to the absolute difference to generate a cross-partition candidate set.

[0134] For example, in step S10433A, after filtering out candidate matching teams in the low-load partition, the system can calculate the absolute difference in team score between each candidate matching team and the current matching team. This operation can quantitatively reflect the strength gap between the candidate teams and the current team, providing a clear numerical basis for subsequent matching and filtering. For example, if the current matching team has a team score of 1500, and the candidate matching teams have team scores of 1450 and 1530 respectively, then the system will calculate the absolute differences between the two teams and the current team's score as 50 and 30 points respectively.

[0135] For example, in step S10433B, after obtaining the absolute difference in team scores between each candidate team and the currently matched team, the system can sort these absolute differences in ascending order. The candidate team with the smallest absolute difference is placed at the top, and teams with larger differences are arranged sequentially downwards, thus generating an ordered cross-regional candidate set. In this way, the teams at the top of the candidate set are closest in strength to the currently matched team. When determining the matching results for multiple teams, the system prioritizes selecting teams from the top, ensuring fairness in the matching process and a more balanced strength between the two sides, providing players with a better gaming experience.

[0136] For steps S10433A-S10433B, for example, suppose in a certain game, the current matched team has a team score of 1800. Three candidate matched teams are selected from the low-load partition, with team scores of 1750, 1830, and 1900 respectively. In step S10433A, the system calculates the absolute difference between the team scores of these three candidate teams and the current team, i.e., |1750-1800|=50, |1830-1800|=30, and |1900-1800|=100. Next, in step S10433B, the system sorts the teams in ascending order according to their absolute difference, prioritizing the team with a difference of 30 points (1830 points), followed by the team with a difference of 50 points (1750 points), and finally the team with a difference of 100 points (1900 points). This generates a cross-regional candidate set containing these three teams and sorted by their strength difference, which facilitates the system to prioritize the matching of teams with the most similar strength, balancing matching efficiency and fairness.

[0137] It should be noted that this embodiment may also be an improvement based on any one or more embodiments of the first to third embodiments.

[0138] It is not difficult to see that in the embodiments of this application, since step S10431 expands the matching range when the diffusion trigger probability exceeds the threshold, step S10432 filters low-load partitions, step S10433 generates a cross-partition candidate set, and step S10434 determines the matching result by combining the candidate set, and can relax the score difference constraint through cross-segment collaborative matching to initially screen the set of potential matchable teams, the system can both expand the size of the matching pool to solve the problem of "insufficient matching range" and ensure the matching quality by filtering low-load partitions and controlling the score difference constraint, thereby achieving a dual optimization of matching efficiency and fairness, which is conducive to improving the player's matching experience.

[0139] Sixth Embodiment

[0140] The sixth embodiment of this application relates to a game-based team matching method. The sixth embodiment is an improvement upon the fifth embodiment, specifically in that it provides a concrete implementation method for determining multi-team matching results based on the cross-partition candidate set.

[0141] Specifically, step S10434, which determines the multi-team matching results based on the cross-partition candidate set, may further include:

[0142] Step S10434A: Sort the candidate matching teams in the cross-partition candidate set in descending order according to the number of members;

[0143] Step S10434B: Select the team with the most unmatched members as the basic matching unit.

[0144] Step S10434C: Dynamically incorporate other candidate teams that meet the preset matching conditions into the basic matching unit;

[0145] Step S10434D: When the number of teams in the basic matching unit reaches the battle requirement, the multi-team matching result is determined.

[0146] For step S10434A, for example, the cross-partition candidate set contains potentially matchable teams that meet the basic matching conditions. In this step, the system can sort the candidate matching teams in the candidate set in descending order of the number of members in each team. For example, if there is a 5-person team, a 3-person team, and a 2-person team in the candidate set, the system can rank the 5-person team first, the 3-person team second, and the 2-person team last. This is done to prioritize the processing of large-scale teams later, avoiding matching small-scale teams first, which would make it difficult for large-scale teams to find enough opponents, thereby improving the overall matching success rate and reducing invalid calculations caused by differences in team size, thus reducing system computational overhead.

[0147] Regarding step S10434B, for example, after sorting by the number of members in descending order, the system can select the team with the most members that has not yet entered the matching process from the candidate set as the basic matching unit. This is because prioritizing large teams maximizes the use of matching resources and reduces the probability of large teams timeouts while waiting for suitable opponents. For instance, if a 4-person team has the most members and is not yet matched in the descending candidate set, the system can select this 4-person team as the basic matching unit, and then continue to search for suitable match partners around this team to gradually build a complete battle combination.

[0148] For step S10434C, for example, after selecting a basic matching unit, the system can iterate and filter other unmatched teams in the cross-segment candidate set, dynamically incorporating teams that simultaneously meet the following conditions into the basic matching unit: First, the absolute value of the average score difference between teams is ≤1.5W (W is the current segment width), ensuring that the strength gap between the two sides is within a controllable range; second, the number of team members is compatible with the basic matching unit, and the required number of players can be achieved through reasonable combination; third, the network latency is ≤ a preset threshold, ensuring that the network conditions between matched teams meet the requirements for smooth gameplay. For example, if the basic matching unit is a 4-person team, the system can prioritize finding a 2-person team (if one exists). When the average score difference between the 2-person team and the basic unit score is ≤1.5W and the network latency meets the standard, it is incorporated to form a 6-person combination. If the required number of players is still not met (e.g., 8 players are required), the remaining candidate teams (e.g., 1-person or 2-person teams) are recursively filtered until the required number of players is met or resources are exhausted. This mechanism, through multi-dimensional constraints, can ensure both matching efficiency (rapid team formation) and matching quality (balanced strength and network stability), achieving complete link optimization from coarse screening to fine matching.

[0149] For step S10434D, for example, the system can continuously monitor the number of teams within the basic matching unit. When the number of teams reaches the system's preset matching success threshold UnitNum, and meets the quality indicators (i.e., 95% of the game score difference is less than 1.2 times the segment width W, and the team matching success rate is greater than 96%), the current basic matching unit can be determined as the final multi-team matching result, and the matching can be completed directly. If UnitNum is not reached or the quality requirements are not met, the system can enter the next matching cycle, continue to filter and adjust candidate teams, and reconstruct the basic matching unit until the matching success conditions are met. This mechanism, through strict dual control of quantity and quality, improves matching efficiency while ensuring the fairness and rationality of the matching results, avoiding a decrease in the quality of the game due to rushing to complete the matching.

[0150] For steps S10434A-S10434D, let's take an example. Suppose in a game, the current cross-server candidate set contains five teams: Team A (5 players), Team B (4 players), Team C (3 players), Team D (2 players), and Team E (1 player). The system first executes step S10434A, sorting the teams in descending order of the number of members as A→B→C→D→E. In step S10434B, Team A (5 players), which has the most unmatched members, is selected as the basic matching unit. Step S10434C begins filling the gaps. Assuming the match requires 8 players per side, the system needs to find 3 players to fill the gap for Team A. At this point, Team B (4 players) exceeds the requirement and is excluded. Team C (3 players) just meets the requirements, and the team score difference meets the preset threshold (e.g., ≤1.2W). Therefore, Team C is included in the basic matching unit, forming an 8-player combination. Step S10434D determines that the number of players in the unit meets the match requirement (8 players) and the score difference meets the quality criteria (e.g., 95% of matches have a score difference < 1.2W). If so, Team A and Team C are the final match pairings, and the match assignment is completed directly. If the remaining teams do not meet the conditions (e.g., Team D + Team E = 3 players but the score difference exceeds the limit), the next cycle begins to optimize the combination until the criteria are met. This process, by prioritizing larger teams and dynamically filling the remaining space, reduces the matching complexity from O(n^k) to close to O(nlogn), while ensuring both matching quality and efficiency.

[0151] It should be noted that this embodiment may also be an improvement based on any one or more of the first to fourth embodiments.

[0152] Understandably, the matching mechanisms in related technologies generally employ a brute-force approach, iterating through all possible combinations to find a match. This results in a time complexity of O(nk), meaning that as the number of players or teams (n) and the number of matching combination parameters (k) increases, the number of combinations the system needs to calculate grows exponentially, leading to extremely low computational efficiency and enormous resource consumption. Furthermore, this technology only supports two-team battles and cannot meet the needs of multiple teams playing simultaneously, exhibiting poor flexibility and scalability. For example, when a large number of players are online simultaneously waiting for matchmaking, the system needs to calculate and evaluate every possible team combination, significantly extending matchmaking wait times and making it difficult to adapt to complex and ever-changing multiplayer battle scenarios, severely limiting the performance of the game's matchmaking system and the player experience.

[0153] It is not difficult to see that in this embodiment, step S10434A arranges the candidate matching teams in the cross-partition candidate set in descending order of the number of members, step S10434B prioritizes the team with the most members as the basic matching unit, step S10434C includes the teams that meet the preset conditions, and step S10434D determines the matching result when the number of teams reaches the requirements for battle. By prioritizing filling in descending order of the number of members and recursively optimizing the remaining space, the system effectively solves the problem of "low combination efficiency" and avoids the high complexity of brute-force traversal of all combinations. While expanding the size of the matching pool, it ensures the quality of the matching combinations. The two work together to complete the complete matching link from coarse screening to fine matching, achieving a dual improvement in matching efficiency and matching quality, and providing players with a better matching experience.

[0154] Based on the first to sixth embodiments described above, the beneficial effects of the method provided in this application will be analyzed and explained below.

[0155] In terms of matching performance optimization, the solution demonstrates significant advantages after testing with 100,000 requests: matching time is reduced from 58.3 seconds in the traditional solution to 31.7 seconds, an efficiency improvement of 45.6%; system resource consumption is optimized simultaneously, with CPU utilization decreasing from 73% to 41% and peak memory usage reduced by 62%. This performance breakthrough is mainly attributed to two core technologies: First, by applying the distributed dynamic segmentation mechanism described in the first embodiment, the global matching pool can be divided into 20 independent matching segments for parallel computation, optimizing the algorithm complexity of the 16-player game scenario from O(n^16) to O(k^n). 2 (k=20); Secondly, the "large team priority" matching strategy described in the sixth embodiment is adopted. By processing matching teams with a large number of members in descending order, 82% of invalid calculation paths are effectively avoided, and the matching search efficiency is greatly improved. The synergistic application of the two technologies not only ensures the matching quality, but also achieves a comprehensive improvement in system performance.

[0156] Regarding the optimization and upgrading of match fairness, actual test data shows that the rate of exceeding the score difference limit (team score difference > 200 points) has been significantly reduced from 22.1% in the traditional scheme to 4.7%, a decrease of 78.7%; at the same time, the standard deviation of the score difference has been reduced by 52.1%. This breakthrough is mainly achieved by the dynamic score difference control system proposed in this application: First, through the segment width dynamic adjustment mechanism (50-200 point elastic range) as described in the second embodiment, the granularity of the matching interval is optimized in real time; second, the score difference penalty coefficient (0.1) as described in step S1013 is used to automatically weaken the influence of high and low score combinations in team score calculation; finally, combined with the intelligent diffusion trigger condition as described in step S1042, based on the joint judgment of waiting time and segment load, it is ensured that high-score players only engage in compliant cross-segment matching when necessary. The three technologies work together to improve matching efficiency while significantly improving competitive fairness.

[0157] Regarding significantly enhanced system scalability, this application improves compatibility by 300%, successfully supporting six complex battle modes, including 4v4v4v4 four-way free-for-all and 100-player battle royale (traditional solutions only support two basic modes). System throughput is also significantly enhanced, with a 220% increase in burst traffic handling capacity and a jump from 500 QPS to 1,600 QPS peak request processing capacity. This advantage stems from two core technological designs: first, the adoption of a parameterized rule engine as described in the third embodiment, which allows for rapid adaptation to new battle modes by adjusting configuration parameters such as team number thresholds and segment width coefficients; second, based on the elastic resource scheduling framework described in the fifth embodiment, which achieves automatic scaling and optimal allocation of computing resources through dynamically increasing or decreasing the number of instances in matching segments (e.g., expanding from 20 to 50) and intelligent load balancing strategies. These two technological innovations enable the system to not only rapidly scale across multiple modes but also effectively cope with peak traffic surges.

[0158] As shown in Table 1, the verification data is as follows. It is evident that, through verification using JMeter stress testing, Monte Carlo simulation, and other methods, key indicators such as 4v4v4v4 matchmaking time, score difference exceeding the limit rate, and 100-player matchmaking success rate are significantly superior to traditional solutions. For example, in 4v4v4v4 mode, matchmaking time is reduced by 45.6%; the score difference exceeding the limit rate decreases by 78.7%; and the 100-player matchmaking success rate increases from 82.4% to 96.7%.

[0159] Table 1 Validation Data

[0160] Metrics Traditional solution This proposal Test method 4v4v4v4 match time 58.3 seconds 31.7 seconds JMeter stress test Difference > 200 game rate 22.10％ 4.70％ Monte Carlo simulation (100 million samples) 100-person game match success rate 82.40％ 96.70％ Redis real-time statistics CPU occupancy rate (peak) 73％ 41％ Linux performance monitoring tools

[0161] In summary, this proposal achieves a breakthrough improvement in matchmaking speed, game quality, and system scalability. The technical effects have been verified by both practical testing and theoretical analysis, demonstrating significant patent value.

[0162] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this application. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this application.

[0163] Furthermore, some embodiments of this application also provide an electronic device. The electronic device may be equipped with the game-based team matching system described in the first embodiment. The electronic device may be various forms of digital computer, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, etc. The electronic device may also be various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices.

[0164] The electronic device includes: one or more processors; and a memory storing computer program instructions that, when executed, cause the processor to perform the steps of the methods provided in any one or more of the above embodiments. Figure 3 An exemplary structural diagram of the electronic device is disclosed. The electronic device includes one or more processors 1101, a memory 1102, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components are interconnected via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations. The components, their connections and relationships, and their functions shown herein are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0165] The electronic device may further include an input device 1103 and an output device 1104. The processor 1101, memory 1102, input device 1103 and output device 1104 may be connected by a bus or other means, as shown in the figure, which is connected by a bus.

[0166] Input device 1103 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the electronic device, such as a touch screen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 1104 may include a display device, auxiliary lighting device (e.g., LED), and haptic feedback device (e.g., vibration motor). The display device may include, but is not limited to, a liquid crystal display, a light-emitting diode display, and a plasma display. In some embodiments, the display device may be a touch screen.

[0167] To provide interaction with the user, the electronic device can be a computer. The computer has: a display device (e.g., a cathode ray tube or LCD monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback); and input from the user can be received in any form (e.g., voice input or tactile input).

[0168] In this embodiment, a computer-readable medium stores a computer program / instructions that, when executed by a processor, implement the steps of the methods provided in any one or more of the above embodiments. This computer-readable medium may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into that device. The aforementioned computer-readable medium carries one or more computer-readable instructions.

[0169] The memory 1102 can serve as a non-transitory computer-readable storage medium, used to store non-transitory software programs, non-transitory computer-executable programs, and modules. The processor 1101 executes various functional applications and data processing of the server by running the non-transitory software programs, instructions, and modules stored in the memory 1102, thereby implementing the program instructions / modules corresponding to the methods provided in any one or more of the embodiments described above in this application.

[0170] The memory 1102 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 1102 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 1102 may optionally include memory remotely located relative to the processor 1101, and these remote memories can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0171] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. Computer-readable media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0172] Computer-readable media include permanent and non-permanent, removable and non-removable media, which can store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory, static random access memory, dynamic random access memory, other types of random access memory, read-only memory, electrically erasable programmable read-only memory, flash memory or other memory technologies, read-only optical discs, digital versatile optical discs or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0173] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0174] In the above embodiments, all or part of the implementation can be achieved through software, hardware, firmware, or any combination thereof. For example, it can be implemented using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In some embodiments, the software program of this application can be executed by a processor to implement the above steps or functions. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, magnetic or optical drives, floppy disks, and similar devices. In addition, some steps or functions of this application can be implemented in hardware, for example, as circuitry that cooperates with a processor to perform the various steps or functions.

[0175] The computer program product provided in this application includes one or more computer programs / instructions. When executed by a processor, these computer programs / instructions generate, in whole or in part, the processes or functions described in this application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0176] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0177] The scope of this application is defined by the appended claims rather than the foregoing description, and is therefore intended to encompass all variations falling within the meaning and scope of equivalents of the claims. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a device claim may also be implemented by a single unit or device in software or hardware. Terms such as "first," "second," etc., are used only for distinguishing descriptions and do not indicate any particular order, nor should they be construed as indicating or implying relative importance.

[0178] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily made by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims, and the above embodiments should be regarded as exemplary and non-limiting.

Claims

1. A game-based team matching method, characterized by, The method comprises: According to the teaming request of the player, the team score of the matched team is determined; the matched team is used to represent the basic battle unit generated based on the teaming request; According to the number of current online players, the segment width is dynamically calculated; According to the team score and the segment width, a dynamic segment set is determined; wherein the segment set is a flexible matching interval set based on the dynamic adjustment of the segment boundary and the segment width in real-time matching load; According to the dynamic segment set, a multi-team matching result is determined; Wherein, according to the team score and the segment width, the dynamic segment set is determined, which comprises: taking the team score as the reference, dividing the score interval into a plurality of continuous flexible segments according to the segment width; wherein the segment boundary is dynamically adjusted according to the real-time score distribution; according to the plurality of continuous flexible segments, the dynamic segment set is determined; Wherein, according to the dynamic segment set, the multi-team matching result is determined, which comprises: monitoring the waiting time and / or segment load of the team in each segment; according to the waiting time and / or segment load, it is judged whether the cross-segment diffusion mechanism is triggered; the cross-segment diffusion mechanism is used to balance the matching speed and fairness by dynamically expanding the matching segment range; according to the cross-segment diffusion mechanism, the multi-team matching result is determined; Wherein, according to the waiting time and / or segment load, it is judged whether the cross-segment diffusion mechanism is triggered, which comprises: obtaining the current segment load and the system average load; according to the waiting time, the current segment load and the system average load, the diffusion trigger probability is determined; according to the diffusion trigger probability, it is judged whether the diffusion mechanism is triggered.

2. The method of claim 1, wherein, According to the teaming request of the player, the team score of the matched team is determined, which comprises: According to the teaming request of the player, the original score of the player in the matched team is obtained; According to the original score, the average score, the highest score and the lowest score of the matched team are determined; wherein the highest score is the maximum value in the original score, and the lowest score is the minimum value in the original score; According to the average score, the highest score and the lowest score, the team score of the matched team is determined.

3. The method of claim 2, wherein, According to the average score, the highest score and the lowest score, the team score of the matched team is determined by the following formula: team score = average score - penalty coefficient × (highest score - lowest score).

4. The method of claim 1, wherein, According to the number of current online players, the segment width is dynamically calculated, which comprises: The number of current online players is obtained; When the number of current online players is greater than a preset threshold, the segment width is determined as a preset fixed value; When the number of current online players is less than or equal to the preset threshold, the segment width is calculated according to the number of current online players, the highest score and the lowest score of the current online players.

5. The method of claim 4, wherein, According to the number of current online players, the highest score and the lowest score of the current online players, the segment width is calculated by the following formula: W = ceil((MaxScore-MinScore) / 10^(log10(N)-1)) Wherein, the MaxScore represents the highest score of the current online players, the MinScore represents the lowest score of the current online players, the ceil represents the upward rounding function, W represents the segment width, and N represents the number of the current online players.

6. The method of claim 1, wherein, The diffusion trigger probability is determined according to the waiting time length, the current segment load, and the system average load, and is specifically realized by the following formula: P = a1 x ln(t + 1) + b1 x (current segment load / system average load); Wherein, P represents the diffusion trigger probability, t represents the waiting time length, a1 represents the first time factor weight coefficient, and b1 represents the first load factor weight coefficient.

7. The method of claim 1, wherein, The multi-team matching result is determined according to the cross-segment diffusion mechanism, and includes: When the diffusion trigger probability exceeds a preset probability threshold, the matching range is expanded from the current segment width to a target segment width, with the team score of the current matching team as the center; A low-load partition is screened, which satisfies that the current load rate is lower than a preset proportion of the system average load rate, and the team score in the segment is in the interval determined by the target segment width; A cross-partition candidate set is generated according to the candidate matching teams in the low-load partition; The multi-team matching result is determined according to the cross-partition candidate set.

8. The method of claim 7, wherein, The probability threshold is determined by the following formula: ； Wherein, P_cross represents the probability threshold, N_pending represents the total number of the current pending players, a2 represents the second time factor weight coefficient, b2 represents the second load factor weight coefficient, and g represents the load normalization base.

9. The method of claim 8, wherein, The cross-partition candidate set is generated according to the candidate matching teams in the low-load partition, and includes: The absolute difference value between the team score of the candidate matching team and the current matching team is calculated; The candidate matching teams are sorted in ascending order according to the absolute difference value to generate the cross-partition candidate set.

10. The method of claim 7, wherein, The multi-team matching result is determined according to the cross-partition candidate set, and includes: The candidate matching teams in the cross-partition candidate set are arranged in descending order according to the number of members; The matching team with the largest number of members and not matched is selected as a basic matching unit; Other candidate teams that satisfy a preset matching condition are dynamically included in the basic matching unit; When the number of teams in the basic matching unit reaches the battle requirement, the multi-team matching result is determined.

11. An electronic device, comprising: The electronic device includes: One or more processors; and A memory storing computer program instructions, which, when executed, cause the processor to perform the steps of the method of any one of claims 1 to 10.

12. A computer readable medium having stored thereon computer programs / instructions, characterized in that, The computer program / instructions, when executed by the processor, implement the steps of the method of any one of claims 1 to 10.

13. A computer program product comprising computer programs / instructions, characterized in that, The computer program / instructions, when executed by the processor, implement the steps of the method of any one of claims 1 to 10.

Images