Game alliance battle matching method and device and medium

Abstract

The embodiment of the invention provides a game alliance battle matching method and device and a medium, and relates to the technical field of the Internet, and the method comprises the steps: classifying each game alliance according to the historical battle participation information of a plurality of game alliances to participate in the alliance battle, and carrying out the scoring of each class of game alliance, and obtaining strength evaluation data of each game alliance. According to the method, all game alliances are grouped according to battle conditions, all the game alliances belonging to the same battle condition group are paired in combination with strength evaluation data, and after-battle performance data and credit scores of the paired alliances are updated to historical battle participation information, so that the rationality of battle matching of the game alliances is improved.

Description

Technical Field

[0001] This invention relates to the field of Internet technology, and more specifically, to a method, device, and medium for matchmaking in game alliance battles. Background Technology

[0002] In massively multiplayer online strategy games (MMO-SLGs), group versus group (GvG) battles are a core gameplay element, typically taking the form of periodic resource battles, cross-server territory wars, and seasonal GvG. This type of gameplay emphasizes the overall strength, coordinated strategies, and long-term operational capabilities of an alliance, rather than the instantaneous skill level of an individual player. Therefore, it places higher demands on the fairness of the matchmaking system, which directly determines the player's gaming experience and retention rate. However, the rationality of matchmaking in related technologies still needs improvement. Summary of the Invention

[0003] One of the objectives of this invention includes, for example, providing a game league matchmaking method, device, and medium to at least partially improve the fairness of game league matchmaking.

[0004] The embodiments of the present invention can be implemented as follows: In a first aspect, embodiments of the present invention provide a game alliance matchmaking method, including: Based on the historical participation information of multiple game alliances to be included in the alliance battle, the game alliances are classified and scored for each category to obtain strength assessment data for each game alliance. The game alliances are grouped according to the battle conditions, and the game alliances belonging to the same battle condition group are matched based on the strength evaluation data. The battle record data and credit score after the alliance battles are completed according to the pairing will be updated to the historical battle information.

[0005] In an optional implementation, the step of classifying the game alliances based on their historical participation information and scoring each alliance to obtain strength assessment data for each alliance includes: Based on the historical participation information of multiple game alliances to participate in the alliance battle, the dynamics of each game alliance are divided into multiple categories corresponding to different battle intensities. Each category corresponds to different multi-dimensional alliance feature data and weight coefficients. Based on the category to which each game alliance belongs, the corresponding multidimensional alliance feature data and weight coefficients are determined. A dual-channel hybrid scoring method that multiplies relative ranking and normalized score is used to obtain the strength evaluation data of the game alliance.

[0006] In an optional implementation, the step of determining the corresponding multidimensional alliance feature data and weight coefficients based on the category to which each game alliance belongs, and obtaining the strength evaluation data of the game alliance by using a dual-channel hybrid scoring method that multiplies relative ranking and normalized score, includes: Determine the corresponding multidimensional alliance feature data and weight coefficients based on the category to which each game alliance belongs; The combat-related features in the multidimensional alliance feature data are subjected to logarithmic transformation and outlier processing to obtain preprocessed features. The preprocessed features are oriented, grouped and ranked, and then the grouped and ranked features are subjected to a power transformation based on the weight coefficients to obtain a relative ranking. The preprocessed features are grouped and normalized, and then weighted and averaged using the weight coefficients to obtain a normalized score. Multiplying the relative ranking and the normalized score yields the strength assessment data for the game league.

[0007] In an optional implementation, grouping the game alliances according to match conditions includes: Obtain the multidimensional grouping variables for each game alliance; the multidimensional grouping variables include server region, battlefield type, match region, registration type, time period, and processing path; The battle conditions for each game alliance are determined according to the multidimensional grouping variables. Game alliances with the same server region, battlefield type, matchmaking region, registration type, time period, and processing path are identified as belonging to the same battle conditions and are grouped into the same group.

[0008] In an optional implementation, the step of combining the strength assessment data to pair up each of the game alliances belonging to the same battle condition group includes: For each game alliance, auxiliary evaluation data is calculated by calling the corresponding auxiliary distance matrix according to the category to which the game alliance belongs; wherein, each type of game alliance has a corresponding auxiliary distance matrix, and the auxiliary distance items included in each auxiliary distance matrix are different, the auxiliary distance items include the number of participants and combat power; By combining the strength assessment data and the auxiliary assessment data, each game alliance belonging to the same battle condition group is paired up.

[0009] In an optional implementation, the step of calling the corresponding auxiliary distance matrix to calculate the auxiliary evaluation data includes: standardizing the numerical features in the multidimensional alliance feature data and each of the auxiliary distance terms to obtain the auxiliary evaluation data; The process of combining the strength assessment data and the auxiliary assessment data to pair up game alliances belonging to the same battle condition group includes: Using the Euclidean distance of the aforementioned strength assessment data as the main component, and superimposing the aforementioned auxiliary assessment data, the basic assessment data is obtained; Based on the aforementioned basic evaluation data, a same-direction penalty and opposite-direction reward mechanism is adopted to minimize the total distance of all pairings in the pairing scheme, and to pair each of the aforementioned game alliances belonging to the same battle condition group.

[0010] In an optional implementation, the same-direction penalty and opposite-direction reward mechanism includes: For any two game alliances belonging to the same battle condition group, detect the direction of change of each of them on each set variable. If the difference values ​​of each set variable have opposite signs, mark the pairing as a reward candidate; if the difference values ​​of each set variable have the same sign, use the standardized Euclidean distance of the set variables with the same difference sign as the penalty value and mark it.

[0011] In an optional implementation, the method of employing a same-direction penalty and opposite-direction reward mechanism, with the goal of minimizing the total distance of all pairings in the pairing scheme, involves pairing each game alliance belonging to the same battle condition group, including: For the two game alliances marked as reward candidates, the pairing distance between them is reduced proportionally to obtain the final pairing distance; For two game leagues marked with penalty values, the pairing distances of the two leagues are added together with the penalty values ​​to obtain the final pairing distance; Based on the final pairing distance, an anti-clustering pairing algorithm is applied to pair each game alliance belonging to the same battle condition group, with the goal of minimizing the sum of the distances of all pairings in the pairwise pairing scheme.

[0012] Secondly, embodiments of the present invention provide an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the game alliance matchmaking method described in any of the foregoing embodiments.

[0013] Thirdly, embodiments of the present invention provide a computer-readable storage medium, the computer-readable storage medium including a computer program, wherein when the computer program is executed, it controls the electronic device where the computer-readable storage medium is located to perform the game alliance battle matching method described in any of the foregoing embodiments.

[0014] The beneficial effects of this invention include, for example, classifying game alliances based on historical participation information and scoring each type of alliance separately, laying the foundation for fairer and more reasonable matchmaking. Combining strength assessment data with matchmaking for game alliances belonging to the same matchmaking condition group improves the feasibility and balance of matchmaking. Updating the historical participation information with match results and credit scores after alliance matches ensures data real-time performance and accuracy, thus providing a more reliable basis for subsequent matchmaking, further enhancing the fairness and competitive rationality of matchmaking, and strengthening the health and sustainability of the game ecosystem. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 The diagram illustrates an application scenario provided by an embodiment of the present invention.

[0017] Figure 2 This illustration shows one of the flowcharts of a game alliance matchmaking method provided by an embodiment of the present invention.

[0018] Figure 3 The second schematic diagram illustrates a game alliance matchmaking method provided by an embodiment of the present invention.

[0019] Figure 4 The third illustration shows a flowchart of a game alliance matchmaking method provided by an embodiment of the present invention.

[0020] Figure 5 The fourth illustration shows a flowchart of a game alliance matchmaking method provided by an embodiment of the present invention.

[0021] Figure 6 The fifth illustration shows a flowchart of a game alliance matchmaking method provided by an embodiment of the present invention.

[0022] Icons: 100 - Electronic device; 110 - Memory; 120 - Processor; 130 - Communication module. Detailed Implementation

[0023] The fairness of game matchmaking directly determines players' gaming experience and retention rate. Among related technologies, the rationality of game matchmaking still needs to be improved.

[0024] Research has found that the main reasons affecting the rationality of game matchmaking include: I. The Problem of "False Combat Power" Caused by Single-Dimensional Assessment: The current matchmaking mechanism mainly ranks alliances in descending order based on the single quantitative indicator of "troop combat power." However, in the actual game environment, the true combat power of an alliance is a composite capability indicator composed of multiple dimensions of growth, including hero level, equipment quality, weapon enhancement level, commander skill level, and the activity level of participating personnel. Because a single troop combat power value cannot accurately reflect this multi-dimensional comprehensive strength, it frequently leads to assessment biases such as "high score, low ability" (inflated combat power value but insufficient actual combat power) or "low score, high ability" (unremarkable combat power value but excellent performance in actual combat), affecting the accuracy of matchmaking.

[0025] II. Hard Isolation and Intra-Group Imbalance Caused by Segmented Random Matching Strategy: The current matching logic mainly adopts a simple "segmented random" strategy, dividing the ranked participating alliances into several groups according to a fixed number (e.g., every 20) for random pairing. This matching logic has the following problems: Hard isolation of adjacent rankings: Adjacent ranking alliances at the group boundary (such as 20th and 21st) are forcibly divided into different groups, resulting in the most similar potential rivals being unable to be matched.

[0026] Imbalance in skill levels within a group: There may be a significant skill gap between the top and bottom teams in the same group (such as the 1st and 20th ranked teams). Random matchmaking can easily result in "crushing" games with a huge skill gap, which seriously affects the competitiveness and fairness of the game.

[0027] Third, the neglect of key matching parameters such as the scale of participation and historical experience: The existing scheme does not take the scale of participants into account in the matching considerations, resulting in frequent unfair matches with severely unequal numbers of participants (such as a 30-player alliance versus a 15-player alliance). At the same time, the same evaluation criteria are used for newly established alliances and mature alliances that have participated for a long time, without distinguishing the usability and reference value of historical performance data. This results in established alliances with rich GvG combat experience being treated the same as newly established alliances participating for the first time, leading to insufficient accuracy in the evaluation.

[0028] IV. Blind Spot in Evaluating the Dispersion of Internal Strength Distribution: Current schemes primarily focus on the average or total strength of alliances, neglecting the uniformity of individual member strength distribution within the alliance. Alliances with the same average kill count may exhibit completely different internal structures, such as a uniform distribution of member strength (each contributing equally) or polarization (a few elite members leading a large number of weaker members). Due to the lack of quantitative analysis of dispersion indicators (such as the variance-to-mean ratio, VMR) in current schemes, alliances with vastly different internal structures may be judged as having comparable strength, leading to distorted matching results.

[0029] Based on the above research, this invention provides a game league matchmaking scheme that uses multi-dimensional feature dynamic hierarchical scoring and anti-clustering global optimal pairing to match game leagues, thereby improving the rationality of matchmaking.

[0030] The shortcomings of the above solutions are the result of the inventors' practical experience and careful research. Therefore, the discovery process of the above problems and the solutions proposed by the embodiments of the present invention in the following text should be considered as contributions made by the inventors during the invention process.

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

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

[0033] It should be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0034] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0035] It should be noted that, where there is no conflict, the features in the embodiments of the present invention can be combined with each other.

[0036] Please refer to Figure 1 This is a block diagram of an electronic device 100 provided in this embodiment. The electronic device 100 in this embodiment can be a server, processing device, processing platform, etc., capable of data interaction and processing, such as a service system for matchmaking. The electronic device 100 includes a memory 110, a processor 120, and a communication module 130. The memory 110, processor 120, and communication module 130 are electrically connected directly or indirectly to each other to achieve data transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses or signal lines.

[0037] The memory 110 is used to store programs or data. The memory 110 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0038] The processor 120 is used to read / write data or programs stored in the memory 110 and to perform corresponding functions.

[0039] The communication module 130 is used to establish a communication connection between the electronic device 100 and other communication terminals through the network, and to send and receive data through the network.

[0040] It should be understood that, Figure 1 The structure shown is only a schematic diagram of the electronic device 100. The electronic device 100 may also include components that are larger than... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown. Figure 1 The components shown can be implemented using hardware, software, or a combination thereof.

[0041] Please refer to the following: Figure 2 This is a flowchart illustrating a game alliance matchmaking method provided in an embodiment of the present invention. It can be derived from... Figure 1 The electronic device 100 performs the operation, for example, by the processor 120 within the electronic device 100. The game alliance matchmaking method includes steps S110, S120, and S130.

[0042] S110: Based on the historical participation information of multiple game alliances to be involved in the alliance battle, the game alliances are classified and scored separately for each category to obtain the strength assessment data of each game alliance.

[0043] S120, group the game alliances according to the battle conditions, and match each game alliance belonging to the same battle condition group with the strength evaluation data.

[0044] S130, update the battle record data and credit score after the alliance battle is completed according to the pairing to the historical battle information.

[0045] By classifying and grouping game alliances, and then pairing them with each alliance within each group based on strength assessment data, this method of detailed analysis of game alliances from multiple dimensions improves the rationality of matchmaking. By combining the battle performance data and credit score updates of the alliances after the pairings are completed, a more reliable foundation is provided for the next round of matchmaking, effectively improving the problem of unreasonable matchmaking caused by uniformly pairing game alliances from a single dimension.

[0046] In S110, classifying game alliances based on historical participation information can be flexibly implemented. For example, based on the historical participation status of multiple game alliances to participate in alliance battles, such as sign_type (indicating whether a player has joined, is preparing, or confirmed to participate in a battle), historical GvG battle records, etc., game alliances can be dynamically divided into multiple categories corresponding to different battle intensities.

[0047] For example, in some games, the dynamics of each game's league can be divided into two categories: "Conquest Season" and "Non-Conquest Season," where the match intensity level of the "Conquest Season" is higher than that of the "Non-Conquest Season." It is understandable that the dynamics of each game's league can also be divided into three or more categories to further refine the match intensity levels.

[0048] This system includes different multi-dimensional alliance feature data (also known as feature dimension sets) and weight coefficients for each category. By determining the corresponding multi-dimensional alliance feature data and weight coefficients based on the category to which each game alliance belongs, the strength evaluation data of the game alliance can be obtained. For example, strength evaluation data can be obtained through weighted summation, fuzzy comprehensive evaluation, etc.

[0049] In order to take into account both the relative position and absolute ability level of the game league in the overall picture, this embodiment takes the dual-channel hybrid scoring method of multiplying relative ranking and normalized score to obtain the strength evaluation data of the game league as an example for illustration.

[0050] Please refer to the following: Figure 3 The strength assessment data of the game alliance can be obtained through S111, S112, S113, S114 and S115.

[0051] S111, determine the corresponding multi-dimensional alliance feature data and weight coefficients according to the category to which each game alliance belongs.

[0052] S112, Perform logarithmic transformation and outlier processing on the combat-related features in the multidimensional alliance feature data to obtain preprocessed features.

[0053] S113, the preprocessed features are oriented, grouped and ranked, and the grouped and ranked features are subjected to a power transformation in combination with the weight coefficients to obtain a relative ranking.

[0054] S114, the preprocessed features are grouped and normalized, and then weighted and averaged using the weight coefficients to obtain a normalized score.

[0055] S115, Multiply the relative ranking and the normalized score to obtain the strength assessment data of the game league.

[0056] By combining relative ranking and normalized scores in a dual-channel hybrid scoring method, the strength of each game league can be assessed more comprehensively and accurately. Relative ranking reflects a game league's position within its category, ensuring the relativity of the assessment. Normalized scores eliminate dimensional differences between different characteristics, guaranteeing fairness and comparability. The resulting strength assessment data integrates these two advantages, considering not only a game league's relative performance within its category but also its actual scores on various specific indicators, thus providing a more scientific and objective overall evaluation.

[0057] To more clearly illustrate the processing flow of strength assessment data, we take the dynamics of each game league as divided into two categories: "Conquest Season" and "Non-Conquest Season". For each type of game league, we use a dual-channel hybrid scoring method that multiplies relative ranking and normalized score to obtain strength assessment data (rank_value). The following example illustrates the extraction of multidimensional league feature data and the calculation flow of strength assessment data.

[0058] Among them, the collection of multi-dimensional alliance feature data can be based on the association of multi-source heterogeneous data, extracting four core data categories from the game data warehouse: registration character data, character multi-dimensional panel features, combat score data, and credit score, and completing feature engineering preprocessing at the Structured Query Language (SQL) layer.

[0059] Registration data collection: Extract current registration information from the game's league match registration log table (league role signup guild vsguild, lg role signup gvg), such as server region (area_type), alliance ID (alliance id), match team ID (matchteam id), registration type (sign_type), time slot (slot), role ID (role_id), and role match power (match power).

[0060] Character multidimensional panel feature extraction: Associate the character daily status table (lg role daily statusv2) and extract features such as combat power, survival days, weighted kill count, 90-day change in kill count, and field battle training dummies score from the data window over the past 90 days. The definitions of each feature are as follows.

[0061] Combat Power: The highest combat power value of the most recent day.

[0062] Lifeday: The number of days between the character's registration date and the current date.

[0063] Weighted kill count (info_kill_sum): The sum is calculated by weighting the unit level, with weights of T1×0.2, T2×2, T3×4, T4×10, and T5×20.

[0064] 90-day change in kills (info_kill_sum_d90): Under the same weighted caliber, the difference between the maximum and minimum values ​​within a 90-day window, reflecting the activity trend.

[0065] Field Battle Dummy Score (gvg_battle): Evaluates a player's combat performance.

[0066] Battle score data extraction: Associate the battle score record table (lg role wood battle match) and extract the field battle score (gvg_battle) within the past 180 days to distinguish between alliances with historical battle records and newly participating alliances.

[0067] Credit Score Extraction and Truncation: The system correlates the credit score table (lg role gvg reputation), extracts the average credit score over the past 180 days (point_current), and performs threshold truncation. Scores below the set threshold are truncated to that threshold, and scores above 100 are truncated to 100. For roles with no GvG records and no credit score data, a default threshold value is assigned.

[0068] To eliminate the noise interference from a large number of inactive registered characters in the alliance evaluation, the core participating characters for each alliance are selected according to the following rules: For alliances with sign_type of 1 or 2 (Conquest Season): The top 30 are ranked by a combination of field training dummy ranking and combat power ranking.

[0069] For alliances of other sign_type: rank the top 30 based on combat power.

[0070] The role-level data was then aggregated to the alliance level. All aggregated metrics were multiplied by the role credit score (point_current / 100) and weighted to generate the following alliance-level features: signup_role_num: The number of registered characters, meaning the scale of participation.

[0071] avg_lifeday: Credit score weighted average lifespan, meaning: Alliance maturity.

[0072] avg_matchpower: Credit score weighted average matchmaking power, meaning: average matchmaking power level per person.

[0073] matchpower: Credit score weighted total matchmaking power, meaning: total alliance power.

[0074] total_kill: Credit score weighted total kills, meaning: total combat output of the alliance.

[0075] total_kill_d90: Credit score weighted total kills change over 90 days, meaning: recent activity trend.

[0076] vmr_kill: Variance-to-mean ratio of kills (VMR), meaning: the dispersion of kill distribution within the league.

[0077] avg_gvg_battle: Credit score weighted average field battle dummy score, meaning: the average combat level developed by the average player.

[0078] total_gvg_battle: Credit Score Weighted Total Field Battle Stakes Score, meaning: Total League Development Battle Score.

[0079] vmr_gvg_battle: Variance-to-Mean Ratio (VMR), meaning the dispersion of training level within the alliance.

[0080] Based on the multidimensional alliance feature data, and according to the game alliance participation type and historical data availability, two feature weight configuration schemes were defined for conquest season alliances and non-conquest season alliances.

[0081] Among them, the Conquest Season Alliance (sign_type is 1 or 2, and total_gvg_battle>0): selects four core feature dimensions from the multi-dimensional alliance feature data: avg_gvg_battle, total_gvg_battle, signup_role_num, and vmr_gvg_battle, and uses the field battle training dummy score (player development combat score) as the main evaluation basis.

[0082] avg_gvg_battle: Weight 0.331, positive (+1), the higher the average score on the field training dummies, the higher the skill rating.

[0083] total_gvg_battle: Weight 1.000, positive (+1), total field battle stakes score (highest weight), used as the core evaluation dimension.

[0084] signup_role_num: Weight 0.117, positive (+1), a moderate positive contribution to the number of participants.

[0085] vmr_gvg_battle: Weight 0.121, inverse (-1), the greater the divergence of the field battle stakes (severe differentiation), the lower the score.

[0086] Non-Conquest Season League (sign_type is 3, 4, or 5, or sign_type is 1 or 2 but total_gvg_battle = 0): Seven feature dimensions are selected, and the panel data and activity are evaluated together.

[0087] avg_lifeday: Weight 0.310, positive (+1), average lifespan, reflecting the maturity of the alliance.

[0088] avg_matchpower: Weight 0.203, positive (+1), average matchmaking power per person.

[0089] matchpower: Weight 0.721, positive (+1), total alliance strength (highest weight).

[0090] signup_role_num: Weight 0.181, positive (+1), number of participants.

[0091] total_kill: Weight 0.415, positive (+1), total number of kills.

[0092] vmr_kill: Weight 0.188, reverse (-1), the greater the kill dispersion, the lower the score.

[0093] total_kill_d90: Weight 0.415, positive (+1), the change in kills over the past 90 days, reflecting the activity trend.

[0094] Please refer to the following: Figure 4 Based on the above settings, the strength assessment data can be calculated using a dual-channel hybrid scoring method that multiplies relative ranking and normalized score through steps S116, S117, S118, and S119.

[0095] S116, Feature preprocessing: Perform a natural logarithmic transformation on all features containing "kill", "power", and "pay" (i.e., add 1 to the original value and then take the logarithm) to compress the influence of extreme values ​​and make the data distribution smoother. Replace missing values ​​with 0, and replace non-finite values ​​with 0.

[0096] S117, Relative Ranking Calculation (Ranking Channel): After adjusting each preprocessed feature value for positive / negative directions according to the direction coefficient (sign), the ranking number is calculated within the area_type group. Then, the ranking number of each feature is transformed by a power (using the weight coefficient of the feature as the exponent), and the average of all features is taken as the score result of this channel.

[0097] Based on the aforementioned relative ranking calculation logic, features with higher weights will have their ranking differences amplified after power transformation, thus gaining greater influence in the final score. This channel captures the relative position of a game league in the global ranking, i.e., its rank among all game leagues.

[0098] S118, Normalized Score Calculation (Scoring Channel): For each preprocessed feature value, Min-Max normalization is performed within the area_type group, mapping the value of each feature to between 0 and 1 (minimum value mapped to 0, maximum value mapped to 1). Then, only features with a positive directional coefficient (+1) are weighted and averaged to obtain the normalized score.

[0099] Based on the normalized scoring calculation logic described above, the Scoring channel captures the absolute ability level of a game league, that is, where the various indicators of this game league are located within the extreme range. Inverse features (such as dispersion VMR, a larger value means that the teams are more unevenly distributed) are not included in this channel calculation, and their impact has been reflected in the inverse ranking in the Ranking channel.

[0100] S119, Hybrid Rating: Multiply the ratings from the two channels to obtain the final strength assessment value (rank_value), which is used as the strength assessment data.

[0101] The hybrid scoring uses a multiplicative structure to ensure that only game leagues with high overall rankings and strong absolute capabilities receive high scores. If a game league has a high ranking but a low absolute value (e.g., a high ranking in a weaker region), or a high absolute value but a low ranking (e.g., a mediocre performance in a highly competitive region), its final score will be suppressed, thus avoiding the bias that may arise from a single channel.

[0102] After obtaining the strength assessment data of each game alliance based on S110, in S120, the game alliances are grouped according to the battle conditions. Based on the strength assessment data, the game alliances belonging to the same battle condition group can be flexibly matched.

[0103] Please refer to the following: Figure 5 Grouping the various game alliances according to the battle conditions can be achieved through S121 and S122.

[0104] S121, obtain the multidimensional grouping variables of each game alliance.

[0105] The multidimensional grouping variables include server region, battlefield type, matching region, registration type, time period, and processing path.

[0106] S122, determine the battle conditions of each game alliance according to the multidimensional grouping variables, and determine the game alliances with the same server region, battlefield type, match region, registration type, time period and processing path as belonging to the same battle conditions and classify them into the same group.

[0107] For example, game leagues are grouped by multidimensional grouping variables to ensure that matchmaking occurs only between game leagues that are in the same competitive environment. The multidimensional grouping variables include: area_type: Server region (China / Global).

[0108] battletype: Battlefield type.

[0109] match_zone: Matching zone.

[0110] sign_type: Registration type (1-5).

[0111] slot: time period.

[0112] sub_type: Handles path identifiers (v2 / v3).

[0113] After grouping the various game leagues, the matchmaking process is executed independently within each group.

[0114] In S120, based on the aforementioned strength assessment data, pairing up the game alliances belonging to the same battle condition group can be achieved in the following way: For each game alliance, auxiliary evaluation data is calculated by calling the corresponding auxiliary distance matrix according to the category to which the game alliance belongs. Each type of game alliance has its own auxiliary distance matrix, and the auxiliary distance items included in each auxiliary distance matrix differ. These auxiliary distance items include the number of participants and their combat power. In one implementation, the numerical features in the multi-dimensional alliance feature data and each of the auxiliary distance items can be standardized to obtain the auxiliary evaluation data.

[0115] By combining the strength assessment data and the auxiliary assessment data, pairing up game alliances within the same battle condition group can be flexibly implemented. For example, using the Euclidean distance of the strength assessment data as the main component, and superimposing the auxiliary assessment data, a basic assessment data is obtained. Based on this basic assessment data, a same-direction penalty and opposite-direction reward mechanism is adopted to minimize the total distance of all pairings in each pairing scheme, thus pairing up game alliances within the same battle condition group.

[0116] For example, auxiliary evaluation data can be obtained through data standardization and calculation of the basic distance matrix.

[0117] Data standardization involves Z-score standardization of all numerical features used in distance calculations. This is achieved by subtracting the mean of each feature value from its standard deviation, transforming it into a standardized value with a mean of 0 and a standard deviation of 1. Features with a standard deviation of 0 (i.e., the same feature value across all game leagues) are uniformly set to 0.

[0118] By standardizing the data, the differences in dimensions and numerical ranges between different features are eliminated, enabling them to participate in distance calculations on the same scale.

[0119] Basic distance matrix calculation: Based on the game alliances of different categories (non-conquest season, conquest season), different basic distance matrices (also known as auxiliary distance matrices) are constructed through algorithmic paths.

[0120] v2 path (non-conquest season): Based on the Euclidean distance of rank_value, a two-dimensional auxiliary distance term is superimposed on the number of participants and combat power. The auxiliary distance term is divided by 2·ln(n), (where n is the number of teams, with a lower limit of 8), so that its contribution decreases as the team size increases logarithmically.

[0121] The rank_value distance reflects the overall strength difference, while the secondary distance item additionally penalizes the difference in the number of players and combat power. The purpose of dividing by the logarithmic scaling factor is to automatically reduce the relative weight of the secondary distance item when the match pool is large, because in a large pool, the rank_value itself can provide sufficient differentiation, avoiding the secondary distance item from excessively interfering with the main distance.

[0122] v3 Path (Conquest Season): Based on the Euclidean distance of rank_value, only a one-dimensional auxiliary distance term of the number of participants is added, and it is also scaled by dividing by 2·ln(n). Since the rank_value of the Conquest Season has fully incorporated the information of the staking stakes, the combat power dimension is no longer repeatedly included in the distance matrix, and only the number of participants dimension is retained as an auxiliary constraint.

[0123] Based on the Euclidean distance of strength assessment data as the main body, and superimposed with the auxiliary assessment data, the basic assessment data is obtained. Then, the matching rationality is further improved through the same-direction penalty and opposite-direction reward mechanism.

[0124] The same-direction penalty and opposite-direction reward mechanism can include: for any two game alliances belonging to the same battle condition group, detecting the direction of change of each of them on various set variables; if the differences of the set variables have opposite signs, marking the pairing as a reward candidate; if the differences of the set variables have the same sign, using the standardized Euclidean distance of the set variables with the same difference sign as the penalty value and marking it.

[0125] For example, a reward and punishment correction mechanism based on the feature change trend is introduced on the basic distance matrix, with opposite-direction rewards and same-direction penalties.

[0126] The anisotropic reward matrix calculation involves: for any two game alliances, detecting the direction of change in variables var1 (number of participants, signup_role_num) and var2 (v2 path: total_kill, v3 path: average avg_gvg_battle points per player on training dummies). If the differences between the two variables have opposite signs—that is, one game alliance has more participants but lower combat metrics, and the other has fewer participants but higher combat metrics—then the pairing of the two game alliances is marked as a reward candidate with a reward value of 1; otherwise, it is 0. It is also required that the differences between the two variables are both non-zero to avoid misjudging completely identical game alliances.

[0127] Given that game leagues with a large number of players but low kill / stakes ratios are complementary to game leagues with a small number of players but high kill / stakes ratios, and that each side has its own strengths and weaknesses after pairing up, making the game more suspenseful, we reduce the distance between them by using opposite rewards to promote pairing.

[0128] The calculation of the same-direction penalty matrix includes: if the difference between two variables has the same sign, that is, one game league is stronger than the other in terms of both the number of players and combat indicators, then the standardized Euclidean distance between the two variables is calculated as the penalty value; otherwise, it is 0.

[0129] Given that the two game alliances have a similar gap in both numbers and combat metrics, with one side having a clear advantage, pairing them up would easily result in a one-sided victory. Therefore, a similar penalty is implemented to increase the distance between them. The penalty value is proportional to the degree of the similar gap; the greater the gap, the heavier the penalty, and the less inclined to pair them up.

[0130] Please refer to the following: Figure 6 After completing the calculation of the opposite reward matrix and the same penalty matrix, pairing can be performed through S123, S124, and S125.

[0131] S123, for the two game alliances marked as reward candidates, proportionally reduce their pairing distance to obtain the final pairing distance.

[0132] S124, For two game alliances marked with penalty values, the pairing distances of the two alliances are added together with the penalty values ​​to obtain the final pairing distance.

[0133] S125, based on the final pairing distance, apply an anti-clustering pairing algorithm to pair each of the game alliances belonging to the same battle condition group, with the goal of minimizing the sum of the distances of all pairings in the pairing scheme, and pair each of the game alliances belonging to the same battle condition group.

[0134] based on Figure 6 The proposed scheme integrates the out-of-direction reward matrix and the same-direction penalty matrix into the base distance matrix: for game alliances marked as having out-of-direction rewards, their base distance is reduced proportionally. For game alliances marked as having same-direction penalties, a penalty value is added to the base distance. The adjustment range of both rewards and penalties is divided by an adjustment coefficient, such as 3·ln(n), to ensure that the adjustment range adaptively scales with team size, avoiding over-adjustment in small matchmaking pools.

[0135] The finely adjusted distance matrix no longer only reflects the "overall strength difference" between game leagues, but also incorporates the prior knowledge of "pairing fairness". It is based on the fact that opponents with similar strengths but different strengths and weaknesses are more suitable for pairing, while pairings that completely overwhelm each other should be avoided, thereby further optimizing the rationality of pairing.

[0136] In this embodiment, based on the constructed global distance matrix, a distance fine-tuning mechanism of same-direction penalty and opposite-direction reward is introduced. When one of the two game alliances shows a same-direction advantage in terms of the number of participants and combat indicators (e.g., the alliance with more participants also has higher kill counts), their pairing distance is increased to avoid clashes between strong and weak alliances. When the two alliances show opposite characteristics (e.g., more participants but lower kill counts), their pairing distance is decreased to promote complementary pairings. This mechanism mathematically refines the distance matrix, making the final pairings more balanced.

[0137] To minimize the sum of distances among all pairwise pairings, we can use the anti-clustering global optimal pairing algorithm. We apply the anti-clustering pairing algorithm to the fine-tuned distance matrix to find the globally optimal pairing scheme. The optimization objective is to find the pairwise pairing scheme that minimizes the sum of distances among all possible pairwise pairings.

[0138] The anti-clustering pairing algorithm can also have other configurations. For example, it can be configured as match_extreme_first=TRUE, which prioritizes pairing game alliances with extreme values ​​(the strongest and weakest) in the distance matrix, ensuring that alliances with extreme strength are matched with the closest opponents first.

[0139] For example, when the number of game alliances in a group is odd, the game alliance with the lowest rank_value, i.e., the alliance with the lowest strength ranking, can be marked as having a bye and will not participate in this round of pairing. The remaining even-numbered alliances will proceed with the pairing algorithm normally.

[0140] To further improve the rationality of pairing, a ranking priority mapping table (pool_level_map) can be configured to define the priority order of different sign_types when summarizing global rankings, for example: sign_type 1, pool_level 0 (highest priority), main alliance.

[0141] sign_type 3, pool_level 1, secondary league A.

[0142] sign_type 2, pool_level 2, secondary league.

[0143] sign_type 4, pool_level 3, secondary league B.

[0144] sign_type 5, pool_level 4 (lowest priority), supplementary alliance.

[0145] When ranking globally, the ranking numbers of each sign_type group are accumulated sequentially from low to high according to pool_level to ensure that the ranking of high-priority alliances is always higher than that of low-priority alliances.

[0146] In this embodiment, an anti-clustering pairing algorithm is used instead of the traditional local segmented random algorithm. The algorithm searches for the pairing combination with the minimum total difference in the fine-tuned global N×N distance matrix and performs optimization from a global perspective. Mathematically, it ensures that the total difference of all pairings is minimized, thereby effectively improving the segmented boundary isolation problem.

[0147] After pairing is completed based on S120, in S130 the battle record data and credit score after the alliance battle are completed according to the pairing will be updated to the historical battle information, thereby further improving the real-time and rationality of the matching basis.

[0148] By introducing a credit score (point_current) as a weighting factor during the feature aggregation stage, all indicators for each participating member, such as kill count, combat power, and field training dummies score, are weighted according to their credit score before being aggregated to the game alliance level. Players with low credit scores, such as those who frequently go AFK or passively participate in combat, have their contributions to the overall alliance evaluation reasonably suppressed, making the evaluation results closer to actual combat strength.

[0149] To more clearly illustrate the overall implementation principle of the matching scheme, the following scenario will be used as an example.

[0150] The matchmaking method for game league battles is triggered when the system determines that the current week is an even-numbered week (week(dt) %% 2==0) after the registration deadline for each GVG season. The command line receives the region parameter (cn / global), credit score threshold (threshold), and environment identifier (online / test).

[0151] After triggering the matching process, a data query is performed. Connecting to the game data warehouse via Trino, a parameterized SQL query is executed to retrieve multidimensional feature data for all registered game alliances in the current period. The query date range covers four days before registration to one day after registration to ensure data integrity. The process automatically terminates when the data volume falls below 1000 records to prevent abnormal execution.

[0152] After obtaining multidimensional feature data through data query, matching calculations are performed, and all scoring calculations and pairing algorithms are executed at runtime. Figures 1 to 6 (For each corresponding step), output the match ID (match_id) and global ranking (rank1) for each game league. Intermediate results are saved as a CSV file for auditing and traceability.

[0153] After matching is completed, the matching result is formatted into a POST request body that the game server can recognize, with the format: ab_set_match matchteamid1:rank1:value1:matchteamid2:rank2:value2;..., and uploaded to the game server of the corresponding region via the Hypertext Transfer Protocol (HTTP) POST interface. The cn region and global region correspond to different intranet / extranet addresses, respectively.

[0154] After the game server receives the matchmaking results, during the game execution phase, it organizes two-on-two game alliances into GVG battle instances based on match_id, and schedules matches according to rank 1. The match results and credit score updates after the match settlement will serve as input for the matchmaking algorithm of the next season, forming a closed loop.

[0155] The mapping relationship between each data point and the game is as follows: match_id, used in the game: to determine which two alliances will play against each other.

[0156] Rank 1, game-side purpose: to determine the order of match schedules (global ranking).

[0157] rank_value, game-side uses: to display a strength reference value or for calculating battle rewards.

[0158] Bye marker (match_id contains "NA"), game-side purpose: This alliance will not participate in the match this round.

[0159] Based on the pairing scheme described in this embodiment, a comprehensive expansion of the evaluation dimensions of game alliances is achieved through multi-dimensional feature data. Compared with the one-dimensional troop combat power value used for evaluation in related technologies, this embodiment dynamically layers the game alliances according to sign_type and field stake score records, and divides them into different categories. Each category is specifically analyzed using combat power, field stake score, kill activity, number of players, and dispersion, which significantly improves the rationality of the evaluation and provides a foundation for the reliability of subsequent matching.

[0160] Compared to related technologies that randomly pair individuals in groups of 20, this embodiment uses a global N×N distance matrix for optimal pairing, minimizing the total difference in global pairings and improving upon the boundary isolation (hard separation of 20 / 21 individuals) present in related technologies, thus achieving globally unified calculation. Explicitly incorporating differences in the number of individuals into the distance matrix improves fairness, and dynamic fine-tuning through same-direction penalties and opposite-direction rewards ensures reasonable and reliable matching.

[0161] By introducing a credit score weighting mechanism, the contribution of passively participating players (AFK, low credit scores) to the game league evaluation is reasonably suppressed. Through the VMR dispersion index, game leagues with extremely polarized internal strengths are no longer overestimated. The adoption of a dual-channel hybrid scoring system (ranking × score) simultaneously considers both relative position and absolute ability, avoiding the bias of a single evaluation dimension, further improving evaluation accuracy, and ensuring reasonable matching.

[0162] Based on the above, embodiments of the present invention also provide a computer-readable storage medium, the computer-readable storage medium including a computer program, wherein the computer program, when running, controls the electronic device where the computer-readable storage medium is located to execute the above-described game alliance battle matchmaking method.

[0163] The above-described scheme in this invention ensures the rationality and reliability of matchmaking from multiple dimensions, thereby guaranteeing fairness in matches. In terms of strength, a multi-dimensional feature-based comprehensive scoring system eliminates the phenomenon of "fake combat power." Regarding the number of participants, the difference in the number of participants is incorporated into the distance matrix to avoid overwhelming opponents with superior numbers. In terms of trend, same-direction penalties prevent "strong-strong clashes" and "weak-weak duels," while opposite-direction rewards promote complementary pairings. In terms of the global dimension, an anti-clustering algorithm ensures global optimality and eliminates segment boundary isolation, significantly improving the rationality of matchmaking.

[0164] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of the invention. 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 marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive 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 a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0165] In addition, the functional modules in the various embodiments of the present invention can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

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

[0167] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for matchmaking in game alliance battles, characterized in that, include: Based on the historical participation information of multiple game alliances to be included in the alliance battle, the game alliances are classified and scored for each category to obtain strength assessment data for each game alliance. The game alliances are grouped according to the battle conditions, and the game alliances belonging to the same battle condition group are matched based on the strength evaluation data. The historical participation information will be updated based on the match results and credit score after the alliance battles are completed.

2. The game alliance matchmaking method according to claim 1, characterized in that, The process involves classifying the various game alliances based on their historical participation information in the alliance battles, and then scoring each alliance within its category to obtain strength assessment data for each alliance, including: Based on the historical participation information of multiple game alliances to participate in the alliance battle, the dynamics of each game alliance are divided into multiple categories corresponding to different battle intensities. Each category corresponds to different multi-dimensional alliance feature data and weight coefficients. Based on the category to which each game alliance belongs, the corresponding multidimensional alliance feature data and weight coefficients are determined. A dual-channel hybrid scoring method that multiplies relative ranking and normalized score is used to obtain the strength evaluation data of the game alliance.

3. The game alliance matchmaking method according to claim 2, characterized in that, The process involves determining the corresponding multidimensional alliance feature data and weight coefficients based on the category to which each game alliance belongs, and then using a dual-channel hybrid scoring method that multiplies relative ranking and normalized score to obtain the strength evaluation data of the game alliance, including: Determine the corresponding multidimensional alliance feature data and weight coefficients based on the category to which each game alliance belongs; The combat-related features in the multidimensional alliance feature data are subjected to logarithmic transformation and outlier processing to obtain preprocessed features. The preprocessed features are oriented, grouped and ranked, and then the grouped and ranked features are subjected to a power transformation based on the weight coefficients to obtain a relative ranking. The preprocessed features are grouped and normalized, and then weighted and averaged using the weight coefficients to obtain a normalized score. Multiplying the relative ranking and the normalized score yields the strength assessment data for the game league.

4. The game alliance matchmaking method according to claim 1, characterized in that, The process of grouping the various game alliances according to their match conditions includes: Obtain the multidimensional grouping variables for each game alliance; the multidimensional grouping variables include server region, battlefield type, match region, registration type, time period, and processing path; The battle conditions for each game alliance are determined according to the multidimensional grouping variables. Game alliances with the same server region, battlefield type, matchmaking region, registration type, time period, and processing path are identified as belonging to the same battle conditions and are grouped into the same group.

5. The game alliance matchmaking method according to claim 4, characterized in that, The process of pairing up game alliances within the same matchup group, based on the aforementioned strength assessment data, includes: For each game alliance, auxiliary evaluation data is calculated by calling the corresponding auxiliary distance matrix according to the category to which the game alliance belongs; wherein, each type of game alliance has a corresponding auxiliary distance matrix, and the auxiliary distance items included in each auxiliary distance matrix are different, the auxiliary distance items include the number of participants and combat power; By combining the strength assessment data and the auxiliary assessment data, each game alliance belonging to the same battle condition group is paired up.

6. The game alliance matchmaking method according to claim 5, characterized in that, The step of calling the corresponding auxiliary distance matrix to calculate the auxiliary evaluation data includes: standardizing the numerical features in the multidimensional alliance feature data and each of the auxiliary distance terms to obtain the auxiliary evaluation data; The process of combining the strength assessment data and the auxiliary assessment data to pair up game alliances belonging to the same battle condition group includes: Using the Euclidean distance of the aforementioned strength assessment data as the main component, and superimposing the aforementioned auxiliary assessment data, the basic assessment data is obtained; Based on the aforementioned basic evaluation data, a same-direction penalty and opposite-direction reward mechanism is adopted to minimize the total distance of all pairings in the pairing scheme, and to pair each of the aforementioned game alliances belonging to the same battle condition group.

7. The game alliance matchmaking method according to claim 6, characterized in that, The same-direction penalty and opposite-direction reward mechanism includes: For any two game alliances belonging to the same battle condition group, detect the direction of change of each of them on each set variable. If the difference values ​​of each set variable have opposite signs, mark the pairing as a reward candidate; if the difference values ​​of each set variable have the same sign, use the standardized Euclidean distance of the set variables with the same difference sign as the penalty value and mark it.

8. The game alliance matchmaking method according to claim 7, characterized in that, The method employs a same-direction penalty and opposite-direction reward mechanism to minimize the total distance of all pairings in a pairwise pairing scheme. This involves pairing each game alliance belonging to the same battle condition group, including: For the two game alliances marked as reward candidates, the pairing distance between them is reduced proportionally to obtain the final pairing distance; For two game leagues marked with penalty values, the pairing distances of the two leagues are added together with the penalty values ​​to obtain the final pairing distance; Based on the final pairing distance, an anti-clustering pairing algorithm is applied to pair each game alliance belonging to the same battle condition group, with the goal of minimizing the sum of the distances of all pairings in the pairwise pairing scheme.

9. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the game league matchmaking method according to any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a computer program that, when executed, controls the electronic device containing the computer-readable storage medium to perform the game alliance matchmaking method according to any one of claims 1 to 8.

Images