Method and device for recommending game map, and storage medium

Abstract

The application discloses a game map recommendation method and device, and a storage medium. The method comprises the following steps: calculating a health index of a game platform according to game data of each game map in the game platform, wherein the game map comprises a game map created by a game player; if the health index is greater than an index threshold value, selecting a long-tail recommended map in a long-tail map, wherein the long-tail map refers to a game map with a score less than a score threshold value; and adding the long-tail recommended map to a recommendation list. The technical scheme of the application realizes the construction of a quantitative evaluation system of ecological health degree, and realizes the dynamic regulation and control of the recommendation strategy of the game map based on the system.

Description

Technical Field

[0001] This application pertains to the field of game data processing, specifically relating to methods, devices, and storage media for recommending game maps. Background Technology

[0002] In the sandbox game genre, the diversity of user-created game maps is a core competitive advantage for the platform's sustainable development. As a crucial link between massive amounts of content creation and player needs, the map recommendation system's core mission is not only to satisfy players' immediate interests but also to maintain the long-term health of the platform's ecosystem. Currently, most mainstream map recommendation solutions focus on optimizing single user interaction metrics and have not yet established a dynamic control system linked to the platform's overall ecosystem health.

[0003] On the one hand, existing technologies lack the ability to quantitatively assess ecosystem health, failing to establish unified indicators that objectively reflect the balance of traffic distribution and content diversity, making it difficult to accurately determine whether the platform ecosystem is unbalanced and to define the timing and intensity of regulation. On the other hand, recommendation strategies exhibit static and fixed characteristics, unable to adapt to dynamic changes in the ecosystem. They either overemphasize the exposure of popular content, exacerbating the ecosystem imbalance, or adopt a fixed proportion of long-tail recommendation models that lack targeting, ultimately failing to achieve a dynamic balance between user experience and ecosystem health.

[0004] Therefore, how to construct a quantitative evaluation system for ecological health and realize dynamic adjustment of game map recommendation strategies based on this system has become a technical problem that urgently needs to be solved in the field of sandbox game map recommendation. Summary of the Invention

[0005] The purpose of this application is to construct a quantitative assessment system for ecological health and to dynamically adjust the recommendation strategy based on the game map of this system.

[0006] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0007] According to one aspect of the embodiments of this application, a method for recommending game maps is provided, the method comprising:

[0008] Based on the game data of each game map in the game platform, calculate the health index of the game platform, where the game maps include game maps created by game players;

[0009] If the health index is greater than the index threshold, then a long-tail recommended map is selected from the long-tail map, where the long-tail map refers to a game map with a score less than the score threshold.

[0010] Add the long-tail recommendation map to the recommendation list.

[0011] According to one aspect of the embodiments of this application, calculating the health index of the game platform based on the play data of each game map in the game platform includes:

[0012] Acquire game data for each of the game maps in different time windows, wherein each time window overlaps at least at a target time, and the target time refers to the time when the game platform health index needs to be calculated.

[0013] Based on the game data corresponding to each time window, calculate the initial health index of the game platform for each time window;

[0014] The health index is calculated based on the weighting coefficients corresponding to each time window and the initial health index.

[0015] According to one aspect of the embodiments of this application, the method further includes:

[0016] The development level of the game platform is determined based on the number of game players;

[0017] The index threshold is determined based on the development level of the game platform, and the development level is negatively correlated with the index threshold.

[0018] According to one aspect of the embodiments of this application, if the health index is greater than an index threshold, then a long-tail recommended map is selected from the long-tail map, including:

[0019] If the health index is greater than the index threshold, then game maps with scores less than the score threshold will be designated as long-tail maps.

[0020] Based on the game data of each long-tail map, the potential value of each long-tail map is calculated using a potential calculation model.

[0021] Based on the long-tail map potential value from largest to smallest, the number of long-tail maps with the highest potential value are selected as the recommended long-tail maps.

[0022] According to one aspect of the embodiments of this application, the method further includes:

[0023] The development level of the game platform is determined based on the number of game players;

[0024] The control coefficient is determined based on the development level of the game platform, and the control coefficient is positively correlated with the development level of the game platform;

[0025] The intensity of regulation is calculated based on the regulation coefficient, health index, and index threshold.

[0026] The first quantity is calculated based on the control intensity and the length of the recommendation list.

[0027] According to one aspect of the embodiments of this application, the method further includes:

[0028] Based on the game map ratings from highest to lowest, the second number of game maps are selected as regular recommended maps and added to the recommendation list. The ratings of each of the regular recommended maps are greater than a rating threshold, and the sum of the first and second numbers is the length of the recommendation list.

[0029] According to one aspect of the embodiments of this application, before adding the long-tail recommendation map to the recommendation list, the method further includes:

[0030] Based on the potential value of the long-tail recommendation map, the position of each long-tail recommendation map in the recommendation list is determined.

[0031] According to one aspect of the embodiments of this application, after adding the long-tail recommendation map to the recommendation list, the method further includes:

[0032] After a set time period, the feedback data of each long-tail recommendation map is obtained;

[0033] The potential calculation model is updated based on the feedback data from each of the long-tail recommendation maps.

[0034] According to one aspect of the embodiments of this application, a game map recommendation device is provided, including a memory, a processor, and a readable program stored in the memory, wherein the processor executes the readable program to implement the method described in any of the above.

[0035] According to one aspect of the embodiments of this application, a readable storage medium is provided, on which a readable program / instruction is stored, which, when executed by a processor, implements the method described in any one of the above-described embodiments.

[0036] In this application, a health index of the game platform is calculated based on game data from various game maps on the platform. Game maps include those created by game players. If the health index is greater than the index threshold, long-tail recommended maps are selected from the long-tail maps, which are game maps with ratings lower than the rating threshold. The long-tail recommended maps are then added to the recommendation list.

[0037] In this embodiment, a health index is calculated using gameplay data from all maps (including player-created maps) on the game platform, enabling a quantitative perception of the platform's ecosystem status and addressing the pain point of traditional recommendations lacking ecosystem health assessment standards. When the health index exceeds a threshold, long-tail maps with scores below the threshold are included in the recommendation list, providing exposure channels for high-quality maps that have not yet received high scores. This effectively breaks the traffic monopoly of top-tier maps and solves the problems of insufficient exposure for long-tail maps and the burying of high-quality niche content. At the same time, by selectively supplementing long-tail maps, the diversity of recommended content is enriched, reducing user fatigue, improving the experience, and encouraging player creativity. This ensures both immediate user interest and the balance of traffic distribution and long-term platform ecosystem health.

[0038] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0039] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0040] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0041] Figure 1 A schematic diagram of a recommended method for a game map according to one embodiment of this application is shown.

[0042] Figure 2 A flowchart illustrating a method for calculating a health index of a game platform based on play data from various game maps in a game platform, according to one embodiment of this application, is shown.

[0043] Figure 3 A flowchart illustrating the determination of an exponential threshold according to one embodiment of this application is shown.

[0044] Figure 4 A flowchart illustrating a method for selecting a long-tail recommended map from a long-tail map if the health index is greater than an index threshold, according to one embodiment of this application, is shown.

[0045] Figure 5 A flowchart illustrating the calculation of a first quantity according to one embodiment of this application is shown.

[0046] Figure 6 A flowchart illustrating the updating of a potential calculation model according to one embodiment of this application is shown.

[0047] Figure 7 A block diagram of a computer device structure for implementing a recommended method for a game map, according to an embodiment of this application, is shown. Detailed Implementation

[0048] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0049] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0050] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0051] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

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

[0053] Please see Figure 1 , Figure 1A schematic diagram of a game map recommendation method according to an embodiment of this application is shown. This application embodiment provides the execution steps of a game map recommendation method, including:

[0054] Step S110: Calculate the health index of the game platform based on the game data of each game map in the game platform. The game maps include game maps created by game players.

[0055] Step S120: If the health index is greater than the index threshold, then select the long-tail recommended map from the long-tail map. The long-tail map refers to the game map with a score less than the score threshold.

[0056] Step S130: Add the long-tail recommendation map to the recommendation list.

[0057] The three steps described above are described in detail below.

[0058] In step S110, game data of all game maps (including player-created maps) within the game platform are collected, and the platform health index is calculated using a preset algorithm.

[0059] Game maps refer to virtual environments available for players to explore on a gaming platform. These include official game maps and user-generated content (UGC) maps created and uploaded by players, and are a core recommended element of the gaming platform. In some embodiments, game maps may only include those created by game players.

[0060] Game data refers to data generated by player interactions with the game map, including but not limited to map play counts, dwell time, completion rate, and replay rate. It serves as fundamental data for assessing map popularity and ecosystem health. The health index is a core indicator used to quantify the health status of the game map ecosystem on a gaming platform. Essentially, it's a quantitative value reflecting the evenness of traffic distribution across the platform's maps; a high or low value directly reflects the degree of ecosystem imbalance.

[0061] In some embodiments, the health index is calculated in the following manner.

[0062]

[0063] Where G refers to the health index, N refers to the total number of game maps, and x represents the number of times a game map has been played. i This refers to the number of times the i-th game map has been played.

[0064] Please see Figure 2 , Figure 2A flowchart illustrating the calculation of a game platform's health index based on play data from various game maps in a game platform, according to an embodiment of this application, is shown. This embodiment provides step S110 for calculating the game platform's health index based on play data from various game maps in a game platform, including:

[0065] Step S111: Obtain game data for each game map in different time windows. Each time window must overlap at least at the target time, which is the time when the game platform health index needs to be calculated.

[0066] Step S112: Calculate the initial health index of the game platform for each time window based on the game data corresponding to each time window.

[0067] Step S113: Calculate the health index based on the weighting coefficients corresponding to each time window and the initial health index.

[0068] The above three steps are described in detail below.

[0069] In step S111, multiple overlapping time windows containing the target time are acquired, and complete game data for all game maps within each time window is collected to ensure that the data covers both short-term fluctuations and long-term trends. The number of time windows can be customized.

[0070] The target time refers to the specific time point that triggers the calculation of the platform's health index (such as 3 a.m. every day). It is the core benchmark for integrating data from multiple time windows to ensure the relevance and consistency of data collection.

[0071] A time window refers to a specific time interval (such as 24 hours, 7 days, or 30 days) used to collect game data. It serves as the basis for dividing the time dimension in health index calculation, and multiple time windows must overlap at the target time. In some embodiments, there are three time windows: a short-term time window (e.g., a 24-hour time window), a medium-term time window (e.g., a 7-day time window), and a long-term time window (e.g., a 30-day time window). Each time window traces backward from the current time (or the target time) for a set duration; for example, a 24-hour time window corresponds to a set duration of 24 hours, and a 7-day time window corresponds to a set duration of 7 days.

[0072] When determining the time window, the current time (or the target time) is used as the endpoint, and the corresponding set time length is traced backward to obtain the corresponding time window. That is, the current time is the latest time in the time window.

[0073] For example, a 24-hour time window is defined such that the time interval is traced back 24 hours from the target time as the endpoint. For instance, if the target time is 3:00 AM on October 26, the corresponding 24-hour window is from 3:00 AM on October 25 to 3:00 AM on October 26, fully covering the map play data of the most recent day.

[0074] When determining the 7-day time window, the target time is used as the endpoint, and the time interval formed by looking back 7 days is used. Using the target time mentioned above, the corresponding 7-day window is from 3:00 on October 19th to 3:00 on October 26th, covering the travel data of the most recent week.

[0075] When determining the 30-day time window, the target time is used as the endpoint, and the time interval formed by looking back 30 days is used. Using the above target time, the corresponding window is from 3:00 on September 26 to 3:00 on October 26, covering the play data of the most recent month.

[0076] All three take the target time as the unified endpoint, ensuring that all windows converge and overlap at the target time, thus guaranteeing the consistency of the time base for data collection.

[0077] The short-term time window is highly real-time, capable of quickly capturing short-term traffic fluctuations (such as a new map suddenly becoming popular or a popular map experiencing a short-term decline in popularity), and promptly reflecting real-time changes in the platform ecosystem, providing data support for rapid adjustments. However, the data is highly random and easily affected by sudden factors (such as short-term peak travel periods during holidays or concentrated promotion by individual creators), leading to significant fluctuations in the health index calculation results, making it difficult to reflect the true ecosystem trend.

[0078] The medium-term time window balances real-time performance and stability, encompassing play data over a certain period to smooth out occasional daily fluctuations, while also responding quickly to ecosystem changes (such as the gradual gaining of user acceptance for a certain type of long-tail map). It is a core window that balances immediate adjustments and trend judgment. However, its response speed to extreme short-term ecosystem changes is slightly slower than that of the 24-hour window. If the platform suddenly experiences a surge in traffic monopoly, it may not be able to trigger regulation immediately.

[0079] Long-term time windows provide data with a long coverage period, accurately reflecting long-term trends in the platform ecosystem (such as the persistence of traffic monopoly by top-tier maps and the overall survival status of long-tail maps). The calculation results are stable and reliable, avoiding short-term fluctuations from misleading regulatory decisions. However, they exhibit significant response lag and cannot capture recent ecosystem changes (such as the failure to promptly identify high-quality long-tail maps that have emerged in the past 3 days). Relying solely on this window may lead to delays in regulatory action.

[0080] In step S112, for the game data of each time window, a unified algorithm is used to calculate the initial health index of the corresponding time window to ensure the independence and accuracy of the initial health parameters corresponding to a single time window.

[0081] In some embodiments, if there is only one initial health parameter, then the initial health parameter is directly used as the health parameter. This is equivalent to using the health index of the game data corresponding to each time window as the initial health index for that time window, and then calculating the final health index by using the initial health indices of multiple time windows.

[0082] In some embodiments, the initial health index is calculated in the following manner.

[0083]

[0084] Where G refers to the initial health index of a time window, N refers to the total number of game maps in that time window, and x represents the number of times a game map is played within that time window. i This refers to the number of times the i-th game map is played within the given time window.

[0085] In step S113, the initial health index of all time windows is weighted and summed according to preset weight coefficients to obtain the final platform health index. The sum of the weight coefficients of all time windows is 1.

[0086] In some embodiments, the weighting coefficient for the medium-term time window is the largest because the data in the medium-term time window is relatively balanced. In some embodiments, the weighting coefficient for the short-term time window is 0.3, the weighting coefficient for the medium-term time window is 0.5, and the weighting coefficient for the long-term time window is 0.2.

[0087] In some embodiments, the product of the weight coefficient corresponding to the calculated time window and the initial health index is used as a sub-health index, and the sub-health indices corresponding to each time window are added together to obtain the health index.

[0088] This application's embodiment effectively solves the problem of inaccurate assessment results due to the susceptibility to random fluctuations when evaluating ecological health using a single time window by employing a multi-window data acquisition, single-window initial index calculation, and weighted fusion to obtain the final health index. First, the overlapping design of multiple time windows ensures comprehensive data coverage, capturing both short-term traffic fluctuations and medium- to long-term ecological trends, avoiding the limitations of single-window data. Second, the separate calculation of the initial health index guarantees the independence and accuracy of assessments across different time dimensions, providing a reliable foundation for the final index synthesis. Finally, the introduction of weighting coefficients achieves a precise balance of the impact of different time windows, enabling the final health index to quickly respond to dynamic changes in the ecosystem while filtering out interference from random fluctuations, significantly improving the accuracy and stability of ecological health assessment. This scheme provides a scientific and reliable quantitative basis for subsequent ecological regulation, ensuring the targetedness and effectiveness of regulation strategies and laying a solid foundation for maintaining the long-term health of the platform ecosystem.

[0089] Please see Figure 3 , Figure 3 A flowchart illustrating the determination of an exponential threshold according to an embodiment of this application is shown. Embodiments of this application provide steps for determining an exponential threshold, including:

[0090] Step S201: Determine the development level of the game platform based on the number of game players;

[0091] Step S202: Determine the index threshold based on the development level of the game platform. The development level and the index threshold are negatively correlated.

[0092] The two steps described above are described in detail below.

[0093] In step S201, the current number of game players on the platform is counted, and the platform's development level is determined by comparing it with a preset range of player numbers. This establishes a correlation between the number of game players and the development stage, providing a basis for the dynamic adaptation of subsequent index thresholds and preventing the threshold settings from becoming disconnected from the actual scale of the platform.

[0094] The number of game players refers to the total number of registered players on a game platform or the number of active players within a set period (which can be determined according to the platform's statistical methods). It is a core indicator for measuring the platform's scale and market coverage, directly reflecting the platform's development volume. The platform's development stages (such as initial stage, growth stage, and mature stage) based on the number of game players are classification standards adapted to different ecosystem governance needs, reflecting the platform's current operational scale and ecosystem maturity.

[0095] In step S202, based on the determined platform development level and the rule that the development level is negatively correlated with the index threshold, the corresponding index threshold is retrieved or calculated.

[0096] In the early stages of development, the index threshold is lenient (relatively high), allowing for moderate traffic concentration to rapidly accumulate content; in the growth stage, the index threshold is moderate, balancing content diversity and user experience; in the mature stage, the index threshold is strict (relatively low), strictly controlling traffic monopoly to maintain a healthy ecosystem, achieving a dynamic match between the threshold and the platform's development.

[0097] This application's embodiments achieve dynamic adaptation of the index threshold by linking player numbers, development levels, and index thresholds, effectively addressing the pain point of existing technologies where fixed index thresholds cannot match the ecosystem governance needs of platforms at different development stages. First, dividing development levels based on player numbers provides a quantitative basis for setting the index threshold, avoiding biases from subjective experience and ensuring a precise match between the index threshold and the platform's scale and ecosystem maturity. Second, the negative correlation design aligns with platform development patterns: a lenient index threshold in the initial stage helps the platform quickly accumulate content and attract users; a moderate index threshold in the growth stage balances traffic distribution and user experience; and a strict index threshold in the mature stage effectively curbs traffic monopolies and maintains ecosystem diversity, enabling precise targeting of ecosystem governance at different stages. Finally, the dynamic index threshold makes ecosystem regulation more flexible and adaptable, avoiding both overly strict index thresholds that restrict content accumulation in the initial stage and overly lenient thresholds that lead to ecosystem deterioration in the mature stage. It also provides a scientific and reasonable judgment standard for subsequent health index assessment and regulation strategy implementation, helping the platform achieve dual optimization of ecosystem health and user experience at different development stages, enhancing the platform's long-term competitiveness and sustainable development capabilities.

[0098] In step S120, the relationship between the health index and the index threshold is first determined. If the health index is less than or equal to the index threshold (i.e., the ecosystem is not unbalanced), then game maps whose scores are ranked from highest to lowest are selected as regular recommended maps and added to the recommendation list. In other words, the recommendation list only contains regular recommended maps, and no further adjustments are needed.

[0099] If the health index is greater than the index threshold (i.e., ecological imbalance), then maps with scores below the score threshold are defined as long-tail maps, and long-tail recommended maps are selected from them.

[0100] In some embodiments, the scoring threshold is a preset value, a dynamically calculated value, or a value that can be adjusted as needed by a technician.

[0101] The index threshold refers to a critical value used to judge the health of a platform's ecosystem. It is dynamically adjusted or preset by the platform based on its development stage (such as the number of players) and is a key basis for triggering regulatory strategies. Long-tail maps refer to game maps with ratings below a preset rating threshold. These maps typically have low exposure and sparse initial data, representing potentially high-quality content that has not been fully explored. Long-tail recommended maps are maps with potential value selected from the long-tail maps and are the core objects subsequently included in the recommendation list.

[0102] Please see Figure 4 , Figure 4 A flowchart illustrating the process of selecting a long-tail recommended map from a long-tail map if the health index is greater than an index threshold, according to an embodiment of this application, is provided. This embodiment provides step S120 of selecting a long-tail recommended map from a long-tail map if the health index is greater than an index threshold, including:

[0103] Step S121: If the health index is greater than the index threshold, then the game map with a score less than the score threshold is used as the long-tail map.

[0104] Step S122: Calculate the potential value of each long-tail map based on the game data of each long-tail map using the potential calculation model.

[0105] Step S123: Select the first number of long-tail maps as long-tail recommended maps according to the long-tail map potential value from largest to smallest.

[0106] The above three steps are described in detail below.

[0107] In step S121, under the premise that the health index is greater than the index threshold (ecological imbalance), all game maps that do not meet the score threshold are classified as long-tail maps based on the score threshold.

[0108] Among them, the rating threshold refers to the critical standard for distinguishing popular maps from long-tail maps. It can be set according to the platform's average rating, content quality benchmarks, etc., to ensure the targeted selection of long-tail maps.

[0109] In step S122, multi-dimensional game data of each long-tail map is collected, input into the pre-trained potential calculation model, and the potential value of each long-tail map is output.

[0110] Potential calculation models refer to pre-trained machine learning models (such as GBDT or DNN models) used to comprehensively evaluate the potential value of long-tail maps based on multi-dimensional data. The potential value is a quantitative indicator representing the potential value of a long-tail map (the value can range from 0 to 1). The higher the value, the more likely the map is to gain user recognition, and it is the core criterion for selecting long-tail recommended maps.

[0111] In some embodiments, the potential calculation model can determine the potential value of each long-tail map through multiple dimensions. For example, it can be evaluated through three levels: map features, creator features, and matching degree features. Each level can include features of one or more dimensions.

[0112] For example, map features (8 dimensions): map name length, number of tags, map type, publication time, map complexity, map completion, map innovation, and map aesthetics. Creator features (5 dimensions): creator's historical average number of plays, number of followers, publication frequency, historical map quality score, and creator activity level. Matching features (3 dimensions): tag matching degree, interest similarity, and user profile matching degree.

[0113] In some embodiments, different types of games have different types of game maps, so when different types of games use the technical solution described in this application, they can use different levels of features, and each level of features can have a different number of dimensions to evaluate the potential value of the long-tail map.

[0114] In step S123, all long-tail maps are sorted from high to low according to their potential value, and the first number of long-tail maps are selected as the long-tail recommended maps.

[0115] In some embodiments, the first quantity can be preset. The first quantity is less than or equal to the length of the recommended list. In other embodiments, the first quantity can be calculated.

[0116] In this embodiment, by defining long-tail maps, calculating potential values, and selecting high-potential maps, the core pain points of existing technologies—such as the difficulty in cold-starting long-tail maps, the burying of high-quality niche content, and the difficulty in balancing recommendation quality and ecosystem balance—are effectively addressed. First, long-tail maps are clearly defined using a scoring threshold, accurately identifying potential high-quality content that needs support and avoiding ambiguity in long-tail map selection. Second, by leveraging a potential calculation model to comprehensively evaluate value using multi-dimensional game data, the limitations of a single scoring indicator are overcome. This allows for the accurate identification of maps with low scores but high potential, providing a fair exposure channel for high-quality long-tail content, greatly incentivizing player creativity, and enriching the diversity of platform maps. Finally, the top-ranked long-tail maps are selected as recommended long-tail maps based on their potential values, ensuring high user acceptance. This breaks the traffic monopoly of top-ranked maps and avoids negatively impacting user experience by blindly recommending low-quality long-tail maps. It achieves a balance between balanced traffic distribution, high-quality content, and a healthy platform ecosystem, providing strong support for the platform's long-term sustainable development.

[0117] Please see Figure 5 , Figure 5A flowchart illustrating the calculation of a first quantity according to an embodiment of this application is shown. This application provides steps for calculating the first quantity, including:

[0118] Step S301: Determine the development level of the game platform based on the number of game players;

[0119] Step S302: Determine the control coefficient based on the development level of the game platform. The control coefficient is positively correlated with the development level of the game platform.

[0120] Step S303: Calculate the regulatory intensity based on the regulatory coefficient, health index, and index threshold;

[0121] Step S304: Calculate the first quantity based on the control intensity and the length of the recommended list.

[0122] The above four steps are described below.

[0123] In step S301, the number of currently active game players on the platform is first counted (such as the total number of registered users or the number of daily active users). Then, the platform is compared with the preset player number range standard (such as less than 100,000 game players is the initial stage, 100,000 to 1 million game players is the growth stage, and more than 1 million game players is the mature stage) to accurately match the development level of the platform.

[0124] In step S302, based on the development levels already divided in step S301, and according to the preset rule that the development level is positively correlated with the control coefficient, the specific values ​​of the corresponding control coefficient that have been stored in advance are retrieved. The higher the level, the larger the control coefficient and the stronger the control intensity.

[0125] The intensity of regulation should be deeply linked to the platform's development stage to adapt to the ecological governance needs at different stages—the regulation coefficient should be smaller in the early stage to avoid excessive regulation from affecting the accumulation of high-quality content and user growth; the regulation coefficient should be larger in the mature stage to strengthen the curb on traffic monopoly and maintain the long-term health of the ecosystem.

[0126] In step S303, based on the regulation coefficient determined in step S302, and combined with the degree of deviation between the current health index and the index threshold (the greater the health index is below the threshold, the more severe the ecological imbalance), the regulation intensity is calculated, quantifying the urgency of ecological regulation. This breaks the limitation of judging the intensity of regulation from a single dimension, achieving a dual consideration of the needs of the development stage and the immediate ecological state, avoiding the problem of excessive regulation for slight imbalances or insufficient regulation for severe imbalances, and ensuring that the intensity of regulation is accurately matched with actual needs.

[0127] The regulation coefficient is a core parameter used to quantify the intensity of ecological regulation at different development stages of the platform. Its value is positively correlated with the development level. It is a key link connecting the platform's long-term development needs with immediate regulatory actions, ensuring that the intensity of regulation is accurately matched with the platform's development stage.

[0128] For example, the preset algorithm uses the product of the difference between the index threshold and the health index and the regulation coefficient as the regulation intensity.

[0129] In some embodiments, the intensity of regulation can be calculated using the following formula.

[0130]

[0131] in, This refers to the intensity of regulation. G refers to the control coefficient, and G refers to the health index. t This refers to the exponential threshold.

[0132] In step S304, the number of long-tail recommended maps to be recommended is calculated using a preset formula, with the control intensity as the core weight and the total length of the recommendation list.

[0133] For example, the first quantity is the product of the control intensity and the length of the recommended list. In some embodiments, the first quantity may also be a preset value, a dynamically calculated value, or an adjustable value by a technician as needed.

[0134] In this embodiment, by employing a full-link quantitative logic encompassing player count, development level, control coefficient, control intensity, and a first quantity, the core pain point of existing technologies—namely, the fixed number of long-tail map recommendations and their inability to adapt to the platform's development stage and the degree of ecological imbalance—is effectively addressed. First, development levels are categorized based on player count and matched with a positively correlated control coefficient, ensuring that the control strategy aligns with the platform's ecological governance needs at different stages. This avoids excessive control impacting content accumulation in the initial stage and strengthens control to curb traffic monopoly in the mature stage. Second, the control intensity is calculated by combining the deviation between the health index and the index threshold, precisely linking the number of long-tail map recommendations to the degree of ecological imbalance. This avoids recommending too many low-quality long-tail maps during slight imbalances or insufficient control during severe imbalances. Finally, the first quantity is obtained through quantitative calculation, transforming abstract ecological control needs into concrete and executable recommendation schemes. This ensures reasonable exposure of long-tail maps, solving the cold start problem, while preventing an excessively high proportion of long-tail maps from affecting users' demand for popular content. This achieves a deep unity of balanced traffic distribution, enhanced content diversity, and optimized user experience, providing strong support for the long-term healthy and sustainable development of the platform's ecosystem.

[0135] In some embodiments, the first quantity can also be calculated in the following manner.

[0136] When multiple time windows are used to calculate the health index, the initial control intensity is first calculated based on the health index (i.e., the initial health index) corresponding to each time window, using the methods described in steps S301 to S303. Then, the control intensity is calculated based on the quantity weights corresponding to each time window and the initial control intensity (the quantity weights of all time windows are summed to 1).

[0137] For example, in some embodiments, the product of the quantity weight corresponding to the time window and the initial control intensity is calculated as the sub-control intensity, and the sub-control intensities corresponding to each time window are added together to obtain the control intensity. Then, the first quantity is calculated based on the control intensity and the length of the recommendation list.

[0138] In some embodiments, the initial control intensity corresponding to each time window can be calculated using the following formula and can be performed in the following manner.

[0139]

[0140] in, This refers to the initial adjustment intensity within a time window. This refers to the control coefficient (the control coefficient corresponding to each time window can be the same or different), and G refers to the initial health index for that time window. t This refers to the exponential threshold corresponding to that time window (the exponential threshold corresponding to each time window can be the same or different).

[0141] In step S130, the selected long-tail recommended maps are included in the final recommendation list and displayed. This breaks the traffic monopoly of popular maps, provides exposure channels for long-tail maps, and enriches the diversity of the recommendation list content.

[0142] In some embodiments, the selected long-tail recommended maps are included in the final recommendation list and displayed to gamers along with regular popular maps.

[0143] In this embodiment, the core logic of quantifying ecological health, filtering long-tail maps, and updating the recommendation list effectively solves the core problems of traditional recommendation systems, such as traffic monopoly, cold start of long-tail maps, and decay of ecological diversity. First, the introduction of a health index enables visualization and quantitative assessment of the platform's ecological status, breaking the blindness of traditional recommendations based on popularity and providing an objective basis for ecological regulation, enabling accurate identification of traffic distribution imbalances. Second, filtering long-tail maps for ecological imbalance scenarios and including them in the recommendation list provides fair exposure opportunities for maps with potential value but below the threshold score, completely solving the cold start problem of even good products needing marketing, greatly encouraging players' creative enthusiasm, and enriching the diversity of platform map content from the supply side. Finally, the integration of long-tail recommended maps with regular recommended content effectively balances the traffic distribution between top and mid-to-lower-tail maps, preventing users from getting trapped in information cocoons and experiencing aesthetic fatigue, increasing user interest in exploring new content and platform retention, while maintaining the long-term health and vitality of the platform ecosystem, achieving the dual goals of user experience optimization and sustainable ecological development.

[0144] In some embodiments, the potential value data of all long-tail recommendation maps is first extracted and sorted from high to low. Then, combined with the user attention distribution characteristics of the recommendation list (such as the 3rd to 5th positions, 8th to 10th positions, etc., areas of concentrated attention), corresponding positions are assigned to long-tail recommendation maps of different potential value levels. Long-tail recommendation maps with higher potential values ​​are assigned to high-quality positions where user attention is more concentrated and exposure efficiency is higher. Long-tail recommendation maps with relatively low potential values ​​but meeting the quality threshold are assigned to other reasonable positions to avoid wasting high-quality position resources. Finally, each long-tail recommendation map is placed in its corresponding position.

[0145] In some embodiments, long-tail recommendation maps are categorized into high, medium, and low tiers based on their potential values. These long-tail recommendation maps are sorted from highest to lowest potential value and evenly inserted into a list composed of regular recommendation maps. High-potential long-tail maps are inserted at smaller intervals; for example, one high-potential long-tail map is inserted every first-value interval of regular recommendation maps. This continues until a medium-potential long-tail map is inserted every second-value interval of regular recommendation maps, and a low-potential long-tail map is inserted every third-value interval of regular recommendation maps. This ensures that long-tail maps with higher potential are exposed more densely. The first value is less than the second value, and the second value is less than the third value.

[0146] In some embodiments, a predefined percentage of the top of the recommended list is designated as the user's attention focus area. Long-tail recommended maps with potential values ​​greater than a set potential threshold are prioritized and placed in this area. The remaining long-tail maps are then placed in the back of the list in order of their potential values. Each long-tail recommended map is spaced a set number of regular recommended maps apart, which highlights high-potential content without crowding out popular resources.

[0147] In some embodiments, long-tail recommendation maps are divided into three tiers—high, medium, and low—based on their potential value. High-potential long-tail recommendation maps are placed in preset key positions in the recommendation list, such as the 5th, 10th, and 15th positions. Medium-potential long-tail recommendation maps are placed in secondary key positions, such as the 20th, 25th, and 30th positions. Low-potential long-tail recommendation maps are placed in non-key positions, such as the 35th position and beyond. Each tier of long-tail recommendation map is alternated with the regular recommendation map to achieve precise matching between potential and position. Key, secondary, and non-key positions can be customized.

[0148] In some embodiments, long-tail recommended maps are assigned positions based on their potential value in descending order, using the total length of the recommended list as a basis. The long-tail map with the highest potential value is placed in a designated position, such as the 3rd position. Then, the next long-tail recommended map is placed at intervals of a set number of regular recommended maps, with larger intervals for lower potential values, ensuring that high-potential content receives more attention.

[0149] In some embodiments, a second number of game maps are selected as regular recommended maps and added to the recommendation list in descending order of their ratings. The ratings of the regular recommended maps are greater than a rating threshold. The sum of the first and second numbers is the length of the recommendation list. That is, the recommendation list includes both regular recommended maps and long-tail recommended maps. In some embodiments, the second number is a preset value, a dynamically calculated value, or can be adjusted as needed by technical personnel.

[0150] First, the calculation basis for the game map rating is clarified (integrating multi-dimensional user interaction data). All maps with ratings higher than the rating threshold within the platform are sorted in descending order of rating. Then, based on the total length of the recommendation list and the determined first number (the number of long-tail recommended maps), the second number is calculated (the second number is the difference between the length of the recommendation list and the first number). Finally, the top "second number" of maps are extracted from the sorted high-quality maps and added to the recommendation list as regular recommended maps, which together with the subsequent long-tail recommended maps constitute the complete recommendation content.

[0151] This application's embodiments clearly define the selection criteria and quantity ratio of conventional recommended maps, ensuring that a sufficient proportion of high-popularity and highly recognized content is retained in the recommended list to meet users' core needs for high-quality and popular maps; at the same time, by using the sum of the first and second quantities as the quantitative relationship of the recommended list length, it provides a clear quantitative framework for ecosystem regulation, avoiding excessive occupation of recommended resources by long-tail maps and balancing users' immediate interests with the long-term health of the ecosystem.

[0152] Please see Figure 6 , Figure 6 A flowchart illustrating an update of a potential calculation model according to an embodiment of this application is shown. Embodiments of this application provide steps for updating a potential calculation model, including:

[0153] Step S401: After a set time period, obtain feedback data from each long-tail recommendation map;

[0154] Step S402: Update the potential calculation model based on the feedback data from each long-tail recommendation map.

[0155] The two steps above will be described in detail below.

[0156] In step S401, a reasonable feedback collection period is first preset based on the platform's operation strategy and user behavior cycle (e.g., capturing immediate feedback within 24 hours and capturing mid-term feedback within 7 days). After the set period ends, comprehensive user feedback data corresponding to each long-tail recommendation map is collected, including interaction data (click-through rate, playtime) and preference data (likes, favorites). Subsequently, the collected raw data is cleaned (outliers and invalid data are removed), denoised (malicious clicks and inflated metrics are filtered), and standardized to form a structured feedback dataset. In some embodiments, the set period is a preset value, a dynamically calculated value, or can be adjusted as needed by technical personnel.

[0157] In step S402, the processed feedback data is fused with historical training data to construct new training samples (e.g., long-tail recommendation maps with playtime exceeding the platform average and a replay rate greater than a set play rate threshold are marked as high-value positive samples) (e.g., long-tail recommendation maps with playtime not exceeding the platform average and a replay rate less than a set play rate threshold are marked as low-value positive samples). Based on the sample size and model status, incremental learning (fine-tuning model parameters using only new feedback data to save resources) or full retraining (retraining with both new and old data to improve accuracy) is selected to update the map potential calculation model. After the update, the model performance (e.g., AUC, prediction accuracy) is tested using a validation set to ensure that the model prediction accuracy is significantly improved compared to before the update, and then it is applied to subsequent long-tail map screening.

[0158] This application's embodiments effectively address the core pain points of traditional potential assessment models—namely, their static and rigid nature, and their inability to adapt to changes in user needs and dynamic ecological adjustments—by setting a time interval for collecting feedback and updating the model based on that feedback in a closed-loop logic. First, the precise design of the time frame ensures the completeness and timeliness of the feedback data. The structured dataset, after removing invalid data, provides high-quality support for model updates, avoiding model optimization failures due to data bias. Second, the flexible update method of incremental learning and full retraining ensures that the model can quickly respond to recent changes in user preferences, while also strengthening the model's generalization ability through full training. This significantly improves the accuracy of the model's prediction of long-tail map potential, making the subsequently selected long-tail recommendation maps more in line with user needs and reducing the impact of low-quality recommendations on user experience. Finally, this closed-loop mechanism enables the map potential calculation model to undergo continuous iteration of practice, feedback, and optimization. This not only continuously improves the content quality and user acceptance of the recommendation list but also allows the recommendation strategy to dynamically adapt to changes in the platform ecosystem. This further solves the cold start problem of long-tail maps, incentivizes creators to produce more high-quality content, and enhances users' desire to explore the platform and retention rate. Ultimately, it achieves synergistic optimization of model accuracy, recommendation quality, ecosystem health, and user experience, providing core technical support for the long-term sustainable development of the platform.

[0159] Figure 7 A block diagram of a computer device structure for implementing a recommended method for a game map, according to an embodiment of this application, is shown.

[0160] It should be noted that, Figure 7 The computer device 800 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0161] like Figure 7 As shown, the computer device 800 includes a central processing unit (CPU) 801, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 802 or programs loaded from storage section 808 into random access memory (RAM). The RAM 803 also stores various programs and data required for device operation. The CPU 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output interface 805 (I / O interface) is also connected to the bus 804.

[0162] The following components are connected to the input / output interface 805: an input section 806 including a keyboard, mouse, etc.; an output section 807 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 808 including a hard disk, etc.; and a communication section 809 including a network interface card such as a local area network card, modem, etc. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to the input / output interface 805 as needed. A removable medium 811, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 810 as needed so that computer programs read from it can be installed into the storage section 808 as needed.

[0163] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 809, and / or installed from removable medium 811. When the computer program is executed by central processing unit 801, it performs the various functions defined in the device of this application.

[0164] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium, a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor device, apparatus, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution device, apparatus, or apparatus. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution device, apparatus, or apparatus. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0165] The flowcharts and 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 a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based device that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0166] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0167] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the methods according to the embodiments of this application.

[0168] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0169] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for recommending game maps, characterized in that, The method includes: Based on game data from various game maps within the game platform, a health index for the game platform is calculated. These game maps include those created by game players. The health index is a core indicator used to quantify the health status of the game map ecosystem on the game platform, reflecting a quantitative value that indicates the evenness of traffic distribution across the game platform's maps. If the health index is greater than the index threshold, then game maps with scores less than the score threshold are designated as long-tail maps, where long-tail maps refer to game maps with scores less than the score threshold. Based on the game data of each long-tail map, the potential value of each long-tail map is calculated through a potential calculation model; where the potential calculation model refers to a pre-trained machine learning model used to comprehensively evaluate the potential value of the long-tail map based on the data. Based on the long-tail map potential value from largest to smallest, select the number of long-tail maps as the long-tail recommended maps; Add the long-tail recommendation map to the recommendation list.

2. The method according to claim 1, characterized in that, Based on the play data of each game map on the game platform, calculate the health index of the game platform, including: Acquire game data for each of the game maps in different time windows, wherein each time window overlaps at least at a target time, and the target time refers to the time when the game platform health index needs to be calculated. Based on the game data corresponding to each time window, calculate the initial health index of the game platform for each time window; The health index is calculated based on the weighting coefficients corresponding to each time window and the initial health index.

3. The method according to claim 1, characterized in that, The method further includes: The development level of the game platform is determined based on the number of game players; The index threshold is determined based on the development level of the game platform, and the development level is negatively correlated with the index threshold.

4. The method according to claim 1, characterized in that, The method further includes: The development level of the game platform is determined based on the number of game players; The control coefficient is determined based on the development level of the game platform, and the control coefficient is positively correlated with the development level of the game platform; The intensity of regulation is calculated based on the regulation coefficient, health index, and index threshold. The first quantity is calculated based on the control intensity and the length of the recommendation list.

5. The method according to claim 1, characterized in that, The method further includes: Based on the game map ratings from highest to lowest, the second number of game maps are selected as regular recommended maps and added to the recommendation list. The ratings of each of the regular recommended maps are greater than a rating threshold, and the sum of the first and second numbers is the length of the recommendation list.

6. The method according to claim 1, characterized in that, Before adding the long-tail recommendation map to the recommendation list, the method further includes: Based on the potential value of the long-tail recommendation map, the position of each long-tail recommendation map in the recommendation list is determined.

7. The method according to claim 1, characterized in that, After adding the long-tail recommendation map to the recommendation list, the method further includes: After a set time period, the feedback data of each long-tail recommendation map is obtained; The potential calculation model is updated based on the feedback data from each of the long-tail recommendation maps.

8. A device for recommending game maps, comprising a memory, a processor, and a readable program stored in the memory, characterized in that, The processor executes the readable program to implement the method of any one of claims 1 to 7.

9. A readable storage medium, characterized in that, It stores a readable program / instruction that, when executed by a processor, implements the method of any one of claims 1 to 7.

Images