Settlement processing method and device for ranking list, electronic equipment and readable storage medium

Abstract

Embodiments of the present application provide a settlement processing method and device for a ranking list, electronic equipment and a readable storage medium. The method comprises: in response to an update instruction for a current player score in a current settlement period, obtaining ranking list data and version update data; updating the ranking list data to obtain ranking list data of the current settlement period, and updating version update record data; determining the ranking list ranking of the player in each settlement period according to the ranking list data of the current settlement period and the version update record data; and performing settlement processing according to the ranking list ranking of the player in each settlement period. By additionally maintaining relevant data of historical settlement periods when updating the player score on the ranking list each time, since the relevant data of the historical settlement periods is maintained, the ranking list snapshot settlement that has passed through the settlement period but does not need to clear the list in the season can be applied, and the settlement demand for a relatively short period that may exist in a long period of the season can be met.

Description

Ranking system settlement processing methods, devices, electronic equipment and readable storage media Technical Field

[0001] This invention relates to the field of game technology, and in particular to a ranking system settlement processing method, a ranking system settlement processing device, a corresponding electronic device, and a corresponding computer-readable storage medium. Background Technology

[0002] Games typically provide leaderboards to record players' combat power and season points. Leaderboards usually come with reward-related logic, sending rewards to players based on their ranking on the leaderboard at the end of the season. However, some games may have a large number of players on the leaderboard, and considering the pressure on the database, they cannot distribute rewards to all players at once. Therefore, at the end of the season, a leaderboard snapshot that reflects the end of the season is needed to distribute rewards to players based on this snapshot.

[0003] Generally, long-term seasons (such as monthly or quarterly) leaderboards will have a clearing process. Currently, the settlement method for leaderboard snapshots usually involves clearing the leaderboards after settling the leaderboard snapshot for a certain season. The aforementioned settlement method is not applicable to leaderboard snapshots that have passed the settlement cycle within the season but do not require clearing, and it cannot meet the settlement needs of relatively short-term cycles that may exist within long-term seasons. Summary of the Invention

[0004] In view of the above problems, embodiments of the present invention are proposed to provide a ranking system settlement processing method, a ranking system settlement processing apparatus, a corresponding electronic device, and a corresponding computer-readable storage medium to overcome or at least partially solve the above problems.

[0005] This invention discloses a ranking system settlement processing method, the method comprising:

[0006] In response to an update command for the current player's score in the current settlement period, the system retrieves leaderboard data and version update data. The leaderboard data maintains leaderboard data updated according to the settlement period, and the version update record data maintains new values ​​updated in each settlement period and old values ​​overwritten during updates. The system updates the leaderboard data to obtain leaderboard data for the current settlement period and updates the version update record data. Based on the leaderboard data and version update record data for the current settlement period, the system determines the player's leaderboard ranking for each settlement period. Settlement processing is then performed based on the player's leaderboard ranking for each settlement period.

[0007] This invention also discloses a ranking list settlement processing device, the device comprising:

[0008] The update command response module is used to respond to update commands for the current player's score in the current settlement period, and to obtain leaderboard data and version update data. The leaderboard data is used to maintain leaderboard data updated according to the settlement period, and the version update record data is used to maintain new values ​​updated in each settlement period and old values ​​overwritten during updates in each settlement period. The data update module is used to update the leaderboard data to obtain leaderboard data for the current settlement period, and to update the version update record data. The leaderboard ranking determination module is used to determine the player's leaderboard ranking in each settlement period based on the leaderboard data and version update record data for the current settlement period. The settlement processing module is used to perform settlement processing based on the player's leaderboard ranking in each settlement period.

[0009] This invention also discloses an electronic device, including: a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements any of the aforementioned leaderboard settlement processing methods.

[0010] This invention also discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the aforementioned leaderboard settlement methods.

[0011] The embodiments of the present invention have the following advantages:

[0012] In this embodiment of the invention, when updating the current player's score in the current settlement period, an update command can be responded to, updating the leaderboard data and version update record data. This allows the player's leaderboard ranking in each settlement period to be determined based on the leaderboard data of the current settlement period and the updated version update record data, and settlement processing is performed based on the player's leaderboard ranking in each settlement period. By maintaining relevant data from historical settlement periods in addition to the leaderboard data of the current settlement period each time the player's score on the leaderboard is updated, specifically, version update record data of the old values ​​that were overwritten before the update and the new values ​​after the update can be maintained. The player's leaderboard ranking in each settlement period is calculated based on the leaderboard data of the current settlement period and combined with data from multiple settlement periods. Because relevant data from historical settlement periods is maintained, this method is applicable to leaderboard snapshot settlements that have passed through a settlement period within the season but do not require clearing the leaderboard, thus meeting the settlement needs of relatively short periods that may exist within a long-term season. Attached Figure Description

[0013] Figure 1 is a flowchart of the steps of an embodiment of a ranking system settlement processing method of the present invention;

[0014] Figure 2 is a flowchart of another embodiment of the ranking system settlement processing method of the present invention;

[0015] Figures 3A to 3I are schematic diagrams of example settlement ranking lists provided in embodiments of the present invention;

[0016] Figure 4 is a schematic diagram of the logic for deleting a player provided in an embodiment of the present invention;

[0017] Figure 5 is a structural block diagram of an embodiment of a ranking system settlement processing device according to the present invention. Detailed Implementation

[0018] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0019] Leaderboard snapshots, reflecting the end of a season in a game, typically serve as proof for season settlement and reward distribution to players. These snapshots usually represent a leaderboard corresponding to a settlement period. The settlement period can be a long-term period (e.g., monthly, quarterly) or a relatively short-term period within a long-term season. For example, using a monthly season as a basis, the total score is calculated based on daily rankings within that season, facilitating the distribution of rewards to players based on the calculated total score.

[0020] In one approach to settling accounts based on leaderboard snapshots, a separate leaderboard can be used for each settlement period. At the start of the next settlement period, players from the previous period's leaderboard are not retained; the leaderboard information for the previous period is cleared. Players need to log in or participate again to re-enter the leaderboard. During subsequent settlements, the leaderboard from the old settlement period is not updated, and rewards are distributed based on the retained leaderboard snapshot. However, because this settlement method clears the leaderboard from the previous period at the start of the next settlement period, in short settlement periods (e.g., daily settlements), players who were previously at the top of the leaderboard on the second day may not be listed yet, while the first online player may suddenly appear at the top. This results in a poor player experience.

[0021] In another approach, a break could exist after the game's season ends, during which leaderboard scores would not change; the leaderboard would essentially be frozen for a period. This break could be used to settle historical results and distribute leaderboard rewards, which would then be updated directly on the original leaderboard at the start of the next settlement period. However, this break is not suitable for players who require a continuously updating game experience.

[0022] In another approach, the entire leaderboard can be copied at the end of the settlement period to serve as a snapshot, and subsequent settlements can be based on this copied snapshot. However, since the entire leaderboard needs to be copied at settlement time, the time cost of copying the entire leaderboard is high when the leaderboard is large.

[0023] As mentioned above, the technology for settling leaderboard snapshots is not applicable to leaderboard snapshot settlements that have passed their settlement cycle within a season but do not require clearing the leaderboard. To address this issue, the core idea of ​​this invention is to maintain relevant data from historical settlement cycles when updating player scores, in addition to the currently maintained leaderboard data. Specifically, this includes maintaining version update records of the old values ​​overwritten before the update and the new values ​​after the update. Based on the current settlement cycle's leaderboard data and version update records, the player's ranking in each settlement cycle (historical version) is calculated using the inclusion-exclusion principle. This allows for settlement processing based on the player's leaderboard ranking in each settlement cycle. Because historical settlement cycle data is maintained, this technology is applicable to leaderboard snapshot settlements that have passed their settlement cycle within a season but do not require clearing the leaderboard, meeting the settlement needs of potentially shorter cycles within a long season. Furthermore, by progressively maintaining leaderboard snapshots when player scores are updated, there is no need to generate snapshots in a blocking manner across versions, thus avoiding the blocking generation of leaderboard snapshots. Furthermore, the leaderboard data, version update data, and update version mapping relationships used employ common structures such as ordered sets and hash tables, enabling the leaderboard settlement method proposed in this embodiment to be easily implemented on commonly used databases (such as Redis), making it simple to apply.

[0024] Referring to Figure 1, a flowchart of an embodiment of a ranking system settlement processing method of the present invention is shown, which may specifically include the following steps:

[0025] Step 101: Respond to the update command for the current player's score in the current settlement period, and obtain leaderboard data and version update data;

[0026] In this embodiment of the invention, in order to realize the settlement processing of leaderboard snapshots that have passed the settlement cycle but do not need to be cleared, when updating player scores, in addition to the leaderboard data of the current settlement cycle that usually needs to be maintained, relevant data of historical settlement cycles can be maintained in addition. Based on the relevant data of historical settlement cycles maintained, the player's ranking in each settlement cycle can be calculated, and the settlement processing can be carried out based on the player's leaderboard ranking in each settlement cycle. This can be applied to the settlement of leaderboard snapshots that have passed the settlement cycle within the season but do not need to be cleared, and can meet the settlement needs of relatively short cycles that may exist in long-term seasons.

[0027] When updating leaderboard data, additional maintenance of relevant data from historical settlement periods can be achieved. This can specifically involve maintaining version update records of both the old values ​​that were overwritten before the update and the new values ​​after the update. In practical applications, leaderboard data and version update data can be obtained by responding to the update command for the current player's score in the current settlement period. This allows for subsequent updates to the leaderboard data and version update records for the current settlement period, respectively.

[0028] The acquired leaderboard data is primarily used to maintain leaderboard data updated according to the settlement cycle. Specifically, player scores are typically updated according to the settlement cycle, which can refer to a relatively short period within a long season. The leaderboard data acquired in response to the update command can be from the previous settlement cycle, allowing for subsequent updates. The updated leaderboard data can then reflect the current settlement cycle. It's important to note that the acquired and updated leaderboards are essentially the same across different settlement cycles; the difference lies in the specific data displayed on the leaderboard.

[0029] Version update log data can be used to maintain relevant periods of historical settlement cycles. It primarily maintains the new values ​​updated on the leaderboard in each settlement cycle, as well as the old values ​​overwritten when the leaderboard is updated in each settlement cycle. There is a separate version update log for each settlement cycle; that is, the version update log data can be maintained based on each version. Each version update log can contain a first set of data for maintaining the new values ​​updated in the version corresponding to each settlement cycle, and a second set of data for maintaining the old values ​​overwritten when the version corresponding to each settlement cycle is updated.

[0030] In some embodiments of the present invention, the version update record data can also be used to maintain the current version (latest_version, abbreviated as lv) corresponding to the current settlement cycle. The value of the current version usually increases as the game cycle progresses. For example, assuming a settlement cycle of one day, the current version latest_version = 1 for the first day of the game cycle, and the current version can be updated for the second day of the game cycle, specifically updated to the current version latest_version = 2, and so on.

[0031] In the specific implementation, the leaderboard data and version update record data are implemented using a skip list plus hash table data structure. These two structures mainly maintain an ordered structure of key-value pairs, meaning that the leaderboard data and version update record data are essentially implemented using ordered sets. The key can be a player ID, and the value can be the corresponding player's score. This supports quick queries such as retrieving a player's score, counting the number of players with a score greater than a certain player's score, and adding or modifying player scores. Furthermore, based on commonly used data structures, the leaderboard settlement method proposed in this embodiment can be easily implemented on commonly used databases (such as Redis), making it simple to apply.

[0032] It should be noted that, for the data structure used for leaderboard data and version update record data, in addition to using ordered sets, other data structures that can support quick queries for player scores, queries for the number of players with scores greater than a certain player score, and requests to add or modify player scores can also be used, such as binary balanced trees. This embodiment of the invention does not limit this.

[0033] Step 102: Update the leaderboard data to obtain the leaderboard data for the current settlement period, and update the version update record data;

[0034] In addition to the ranking data for the current settlement period that is usually maintained, this embodiment of the invention also maintains relevant data for historical settlement periods when updating the ranking data. While updating the ranking data in response to the update command, it can also update the version update record data.

[0035] Specifically, the version update record data can be used to maintain the new values ​​updated in each settlement cycle, as well as the old values ​​that are overwritten during each settlement cycle update. When updating the version update record data, the old values ​​that are overwritten can be recorded while updating the current player's score to the new value, and the current version corresponding to the current settlement cycle can be maintained.

[0036] In practical applications, this can manifest as updating leaderboard data and version update records based on the acquired update version mapping relationship. The acquired update version mapping relationship is primarily used to maintain the settlement cycle corresponding to each player's score update. Specifically, it represents each player's update version, i.e., the version corresponding to each player's score update. This is implemented as a key-value hash table and does not need to be ordered.

[0037] It should be noted that, since the update version mapping is essentially based on key-value pairs, only one update version mapping is allowed for different settlement cycles. The settlement cycle when updating player scores for different players based on the same update version mapping is recorded. This embodiment of the invention does not impose any limitations on this.

[0038] Step 103: Determine the player's ranking in each settlement period based on the leaderboard data and version update record data of the current settlement period;

[0039] In one embodiment of the present invention, in the case of a relatively short settlement period within a long-term season, for example, under the premise of a monthly major season, the total points are calculated based on the daily rankings within the major season, so as to facilitate the distribution of rewards to players based on the calculated total points. In this case, the player's ranking in each settlement period, especially the leaderboard ranking in the historical settlement period, can be determined so as to carry out settlement processing based on the player's leaderboard ranking in each settlement period.

[0040] Specifically, since the leaderboard snapshot is maintained incrementally as player scores are updated, there is no need to generate snapshots in a blocking manner across versions. In other words, there will be no blocking situation in generating leaderboard snapshots. At this time, the leaderboard rankings of historical settlement periods can be calculated based on the leaderboard data of the current settlement period and the version update record data.

[0041] In practice, player rankings across different settlement periods (historical versions) can be calculated using the inclusion-exclusion principle, based on leaderboard data from the current settlement period and version update records. The inclusion-exclusion principle is a counting method that prevents overlapping parts from being counted repeatedly by first ignoring the overlapping parts during the calculation and then excluding the duplicated overlapping parts.

[0042] In this embodiment of the invention, when calculating the ranking of historical versions, since the leaderboard data of the current settlement period contains the latest updated player scores, the data of the historical settlement period cannot be directly queried through the leaderboard data. In order to determine the historical ranking of a player in any historical settlement period, it is also necessary to calculate the historical player scores that are greater than the player's scores in the old values ​​that are overwritten in the leaderboard data. That is, it is necessary to calculate the sum of the number of players with scores greater than the historical player scores in the leaderboard data and the number of players with scores greater than the historical player scores in the old values. However, there may be some duplicate data. This part of the data can actually be the new values ​​updated in the current settlement period. In this case, it is also necessary to subtract the number of players with scores greater than the historical player scores in the new values ​​to implement the calculation according to the inclusion-exclusion principle, so as to obtain the number of players with scores greater than a certain historical player score in the corresponding historical settlement period.

[0043] Step 104: Settle accounts based on the player's ranking on the leaderboard in each settlement period.

[0044] After calculating the players' leaderboard rankings for each settlement period, especially the historical settlement periods, settlement processing can be carried out based on the players' leaderboard rankings for each settlement period. This settlement processing is reflected in the settlement of the entire season.

[0045] The settlement process is mainly achieved through the maintained leaderboard data, version update record data, and update version mapping relationship. It does not need to record leaderboard snapshots of historical settlement periods; it only needs to maintain the latest version of the leaderboard snapshot.

[0046] In practical applications, under the premise of a monthly major season, the total points are calculated based on the daily rankings within the major season. This facilitates the distribution of rewards to players based on the calculated total points. Assuming the settlement period is daily, corresponding points can be set according to the specific ranking of players on the leaderboard. Based on the set points and a player's ranking in the historical settlement period, the points for each settlement period can be determined. Then, when settling the season, the points from each settlement period can be aggregated to distribute rewards to players based on the total points.

[0047] In this embodiment of the invention, when updating player scores on the leaderboard each time, in addition to maintaining the leaderboard data for the current settlement period, relevant data for historical settlement periods are also maintained. Specifically, version update records of old values ​​that were overwritten before the update and new values ​​after the update can be maintained. Based on the leaderboard data for the current settlement period and combined with data from multiple settlement periods, the player's leaderboard ranking in each settlement period is calculated. Since relevant data for historical settlement periods are maintained, it can be applied to leaderboard snapshot settlements that have passed through the settlement period within the season but do not require clearing the leaderboard, thus meeting the settlement needs for relatively short periods that may exist within a long season.

[0048] Referring to Figure 2, a flowchart of another embodiment of the ranking system settlement processing method of the present invention is shown, which may specifically include the following steps:

[0049] Step 201: In response to the update instruction for the current player's score in the current settlement period, update the leaderboard data and version update record data according to the update version mapping relationship;

[0050] In this embodiment of the invention, in order to realize the settlement processing of leaderboard snapshots that have passed the settlement cycle but do not need to be cleared, when updating player scores, in addition to the leaderboard data of the current settlement cycle that usually needs to be maintained, relevant data of historical settlement cycles can be maintained in addition. Based on the relevant data of historical settlement cycles maintained, the player's ranking in each settlement cycle can be calculated, and the settlement processing can be carried out based on the player's leaderboard ranking in each settlement cycle. This can be applied to the settlement of leaderboard snapshots that have passed the settlement cycle within the season but do not need to be cleared, and can meet the settlement needs of relatively short cycles that may exist in long-term seasons.

[0051] Specifically, maintaining relevant data from historical settlement periods when updating leaderboard data can be achieved by additionally maintaining version update records of both the old values ​​that were overwritten before the update and the new values ​​after the update. In practical applications, leaderboard data and version update data can be obtained by responding to an update command for the current player's score in the current settlement period. This allows for updating the obtained leaderboard data and version update records to obtain the leaderboard data and version update record data for the current settlement period, respectively.

[0052] Specifically, the leaderboard data and version update record data can be updated by obtaining the update version mapping relationship. The obtained leaderboard data can be mainly used to maintain the leaderboard data updated according to the settlement cycle. For different settlement cycles, the obtained and updated leaderboards are essentially the same, the difference being that the data recorded on the leaderboard is different. That is, the leaderboard data obtained in response to the update command can be the leaderboard data of the previous settlement cycle; the updated leaderboard data can be the leaderboard data of the current settlement cycle.

[0053] Version update log data can be used to maintain relevant periods of historical settlement cycles. It primarily maintains the new values ​​updated on the leaderboard in each settlement cycle, as well as the old values ​​overwritten when the leaderboard is updated in each settlement cycle. It has a corresponding version update log for each settlement cycle, and each version update log can contain a first set of data for maintaining the new values ​​updated in the version corresponding to each settlement cycle, and a second set of data for maintaining the old values ​​overwritten when the version corresponding to each settlement cycle is updated.

[0054] The update version mapping is primarily used to maintain the settlement period corresponding to each player's score update. Specifically, it represents each player's update version, i.e., the version corresponding to each player's score update. The update version mapping shows the correspondence between the updated player score, the corresponding player, and the settlement period, and can include the player's corresponding update version. Specifically, the update version mapping can be implemented as a key-value hash table, where the key is the player's ID and the value is the version corresponding to each player's score update.

[0055] Different settlement cycles can be determined based on different versions, specifically, different settlement cycles correspond to different version numbers. Therefore, the current settlement cycle has a corresponding current version, and a certain historical settlement cycle also has a corresponding version.

[0056] During the process of updating leaderboard data and version update record data based on the updated version mapping relationship, the updated version mapping relationship can be implemented as a key-value hash table. It can be represented as the key being the player's ID and the value being the version corresponding to each player when updating their score. At this time, the updated version corresponding to the player can be queried through the aforementioned key-value pairs to obtain the corresponding query results. Based on different query results, different update methods can be applied to the leaderboard data and version update record data.

[0057] Specifically, in one scenario, if the update version mapping does not exist for a player (i.e., there is no current settlement period for that player), since the update version mapping exists only once for each settlement period, it can record any historical settlement period from when a player's score was updated to the current settlement period. This indicates that the player is a new addition to the leaderboard and was not previously on the leaderboard. Therefore, the update version mapping does not contain data for any settlement period for that player. In this case, the current player's score can be updated to the first data set in both the leaderboard data and the version update record data, and the update version corresponding to the player can be set to the current version in the update version mapping.

[0058] In another scenario, if a player's corresponding updated version exists in the updated version mapping relationship, and the player's corresponding updated version is inconsistent with the current version, it means that the player has been modified in a historical version. In this case, the player's original score can be obtained, the current player score can be updated to the leaderboard data and the first data set, and the original player score can be updated to the second data set in the version record data.

[0059] In another scenario, if a player's corresponding updated version exists in the updated version mapping relationship, and the player's corresponding updated version is consistent with the current version, it means that the player's version has been updated during the specified period. In this case, the current player's score can be updated to the first data set in the leaderboard data and version update record data.

[0060] For example, the leaderboard data maintained for the current settlement period is essentially an ordered set of the latest versions. We can assume the leaderboard data for the current settlement period is `latest_rank`, and the version update data is `version_record`, which may contain a first data set `version_record.new` and a second data set `version_record.old`. The update version mapping is `version_map`. Also, assume that player x's player score is set to 100 in the current settlement period.

[0061] In one example, if the updated version corresponding to player x does not exist in the updated version mapping, the key-value pair "player x = 100" can be updated to the current settlement period's leaderboard data `latest_rank` and the first data set `version_record.new`, and the updated version corresponding to player x in the updated version mapping `version_map` can be set to the current version `latest_version`. In another example, if the updated version corresponding to a player exists in the updated version mapping, but the updated version corresponding to the player is inconsistent with the current version, player x's original player score can be recorded, for example, 90. Then, the key-value pair "player x = 100" can be updated to the leaderboard data latest_rank and the first data set version_record.new for the current settlement period, and the key-value pair "player x = 90" can be updated to the second data set version_record.old. In another example, if there is an updated version corresponding to the player in the updated version mapping relationship, and the updated version corresponding to the player is consistent with the current version, then the key-value pair "player x = 100" can be updated to the leaderboard data latest_rank and the first data set version_record.new for the current settlement period.

[0062] Step 202: Based on the leaderboard data and version update record data of the current settlement period, obtain the target player's score in any target version;

[0063] In one embodiment of the present invention, in the case of a relatively short settlement period within a long-term season, for example, under the premise of a monthly major season, the total points are calculated based on the daily rankings within the major season, so as to facilitate the distribution of rewards to players based on the calculated total points. In this case, the player's ranking in each settlement period, especially the leaderboard ranking in the historical settlement period, can be determined so as to carry out settlement processing based on the player's leaderboard ranking in each settlement period.

[0064] Specifically, the target player's score in any target version can be obtained. Any target version can be the current version or any historical version. The updated player score in the current version can be called the target player score, and the historical player score in any historical version can also be called the target player score.

[0065] Specifically, when the target version is the current version, the target player's score in the current version can be directly obtained from the leaderboard data of the current settlement period; and / or, when the target version is less than the current version, since the version update data of historical versions is maintained, the player's historical score in a certain historical version can be traced back along the version. Specifically, the version update record data of the current version can be traversed to the version update record data of the target version to determine the target player's score in the target version.

[0066] It should be noted that there may be cases where a player is not listed in a historical version. In this case, there is no ranking and no reward should be given to the player, meaning that the player does not have a score in that historical version. Therefore, when tracing back to the previous version to find the player's historical score in a certain historical version, different processing methods can be applied based on whether the player's score exists in the historical version.

[0067] Specifically, during the traversal, if the value corresponding to the target player is empty in both the first and second sets of the traversed version update data, it indicates that the player's score has not changed in that version, and the traversal continues; and / or, if the value corresponding to the target player is not empty in the first set of the traversed version update data, but the value corresponding to the target player is empty in the second set of the traversed version update data, it indicates that the player has changed from not being on the leaderboard to being on the leaderboard in that version, and the player had no score in the historical version, and the traversal stops; and / or, if the value corresponding to the target player is any value in the first set of the traversed version update data, but the value corresponding to the target player is not empty in the second set of the traversed version update data, it indicates that the player originally had a score in that version, and the value corresponding to the target player can be determined to be the target player's score in the target version, and the traversal stops.

[0068] In some embodiments of the present invention, if the player score of the target player in the target version has not been determined when the traversal is stopped, that is, no explanation is returned during the traversal, then the player score of the target player in the current version can be determined as the player score of the target player in the target version.

[0069] Step 203: Determine the target player's leaderboard ranking in any target version based on the number of players whose player score is greater than the target player's score in any target version;

[0070] In practical applications, a player's ranking in each settlement period (i.e., historical version) can be calculated using the inclusion-exclusion principle, based on the leaderboard data and version update records of the current settlement period. Specifically, based on the target player's score in any target version, the number of players with a score higher than the target player's score in any target version can be determined. Then, using the inclusion-exclusion principle, the target player's leaderboard ranking in any target version can be calculated based on the number of players with a higher score than the target player.

[0071] The inclusion-exclusion principle is a counting method used to prevent overlapping parts from being counted repeatedly. It involves initially ignoring the overlapping parts during the calculation and then excluding the duplicated overlapping parts. Specifically, in one scenario where the target version is the current version, the number of players with scores higher than the target player can be calculated from the leaderboard data of the current settlement period. This determines the number of players with scores higher than the target player in the current version, meaning there is no duplicate counting as mentioned above, and the inclusion-exclusion principle is not required in this case.

[0072] In another scenario, when the target version is less than the current version, the update history data is iterated from the current version to the target version. Based on the number of players with a higher score than the target player in each of the iterated versions, the number of players with a higher score in any target version is determined. Specifically, this can begin by iterating through the update history data of the current version, calculating the number of players with a higher score in the previous version than the target player in each of the iterated versions, and using this number as a base, calculating the number of players with a higher score in the version before that previous version, and so on, until the target version is reached. In this case, there may be instances of duplicate calculations, requiring adherence to the inclusion-exclusion principle.

[0073] The process of calculating the number of players whose scores in the previous version were greater than the target player's score in the traversed versions can be represented as follows: obtaining the number of players whose scores were greater than the target player's score in the leaderboard data of the next version compared to the previous version, the number of players whose scores were greater than the target player's score in the second set of version record data of the next version compared to the previous version, and the number of players whose scores were greater than the target player's score in the first set of version record data of the next version compared to the previous version; then, using the sum of the number of players whose scores were greater than the target player's score in the leaderboard data of the next version compared to the previous version and the number of players whose scores were greater than the target player's score in the second set of version record data of the next version compared to the previous version, and the difference between the sum of ...

[0074] The process of calculating the number of players whose scores were higher than the target score in the previous version, using the number of players in the previous version as the base number, and then calculating the number of players whose scores were higher than the target score in the version-above-previous version, can be specifically represented as follows: Obtain the number of players whose scores were higher than the target score from the second set of the previous version's version record data, and the number of players whose scores were higher than the target score from the first set of the previous version's version record data. Then, using this base number as the base number, calculate the sum of this base number and the number of players whose scores were higher than the target score from the second set of the previous version's version record data, and the difference between this base number and the number of players whose scores were higher than the target score from the first set of the previous version's version record data. This difference yields the number of players whose scores were higher than the target score in the version-above-previous version that has been traversed. Here, the base number can refer to the number of players with scores higher than the target score in the leaderboard of the settlement period corresponding to the previous version, obtained when calculating the number of players in the version-above-previous version.

[0075] In this embodiment of the invention, when calculating the ranking of historical versions, since the leaderboard data of the current settlement period contains the latest updated player scores, the data of the historical settlement period cannot be directly queried through the leaderboard data. In order to determine the historical ranking of a player in any historical settlement period (i.e., historical version), it is also necessary to calculate the historical player scores that are greater than the player's scores in the old values ​​that are overwritten in the leaderboard data. That is, it is necessary to calculate the sum of the number of players with scores greater than the historical player scores in the leaderboard data and the number of players with scores greater than the historical player scores in the old values. However, there may be some duplicate data. This part of the data can actually be the new values ​​updated in the current settlement period. In this case, it is also necessary to subtract the number of players with scores greater than the historical player scores in the new values ​​to implement the calculation according to the inclusion-exclusion principle, so as to obtain the number of players with scores greater than a certain historical player score in the corresponding historical settlement period.

[0076] Specifically, we can obtain the number of players whose scores are higher than the target player's score in the leaderboard data of the current settlement period, the number of players whose scores are higher than the target player's score in the second data set of the current version's record data, and the number of players whose scores are higher than the target player's score in the first data set of the current version's record data. Then, based on the sum of the number of players whose scores are higher than the target player's score in the leaderboard data of the current settlement period and the number of players whose scores are higher than the target player's score in the second data set of the current version's record data, and the difference between the sum of ... The number of players can be calculated by combining the number of players with scores higher than the target score in the current settlement period's leaderboard data with the sum of the number of players with scores higher than the target score in the second data set of the previous version's version record data, and the difference between the sum of ...

[0077] For example, the leaderboard data maintained for the current settlement period is essentially an ordered set of the latest versions. We can assume the leaderboard data for the current settlement period is `latest_rank`, and the version update data is `version_record`, which can contain a first data set `version_record.new` and a second data set `version_record.old`. The update version mapping is `version_map`. Furthermore, when any target version is a historical version, the target player's score can be the historical player's score, assuming the historical player's score is `history_score`.

[0078] As an example, when the target version being queried is equal to the current version (latest_version), the number of players with a score greater than history_score can be calculated directly from the leaderboard data (latest_rank) of the current settlement period. Based on the calculated number of players, the player's ranking on the leaderboard for the current version can be determined.

[0079] As another example, when the target version being queried is less than the current version (latest_version), for example, the previous version (lv-1) compared to the current version, we can obtain the following: the number of players in the leaderboard data of the next version compared to the previous version whose player score is greater than the historical player score (history_score) (latest_rank, greater than history_score); the number of players in the second set of version record data of the next version compared to the previous version whose player score is greater than the target player score (history_score) (version_record[lv].old, greater than history_record); and the number of players in the first set of version record data of the next version compared to the previous version whose player score is greater than the historical player score (history_score) (version_record[lv].new, greater than history ... Based on the value of `latest_rank` (greater than `history_score`) + `version_record[lv].old` (greater than `history_record`) - `version_record[lv].new` (greater than `history_record`), we can determine the number of players in version (lv-1) whose score is greater than `history_score`. This is the sum of the number of players in the leaderboard data whose score is greater than the historical score and the number of players in the old value whose score is greater than the historical score. However, there may be some duplicate data. This data can actually be the new value updated in the current settlement period. In this case, we need to subtract the number of players in the new value whose score is greater than the historical score, expressed as `latest + old – new`, to follow the inclusion-exclusion principle in the calculation.

[0080] In another example, when the target version being queried is less than the current version `latest_version`, for example, compared to the previous version (lv-2) of the previous version (lv-1), the number of players whose player scores in the previous version are greater than the target player score is used as the base number. That is, the number of players in version (lv-1) can be represented as "latest_rank (greater than history_score) + version_record[lv].old (greater than history_record) - version_record[lv].new (greater than history_record)" denoted as x1. In this case, x1 can be used as the base number, along with the second data from the previous version's version record data. The sum of the number of players in the set whose player score is greater than the target player score (version_record[lv-1].old, which is greater than history_record) and the difference between this sum and the number of players in the first data set of the previous version's version record data (version_record[lv-1].new), is expressed as the value of x1 + version_record[lv-1].old (greater than history_record) - version_record[lv-1].new, which gives the number of players in the previous version (lv-2) before the previous version (lv-1) whose player score is greater than the historical player score (history_score).

[0081] It should be noted that the calculation of the number of players with scores higher than the historical player scores in other versions can be deduced from the above example, and will not be elaborated upon in this embodiment of the invention.

[0082] Step 204: Settle accounts based on the player's ranking on the leaderboard in each settlement period.

[0083] After calculating the players' leaderboard rankings for each settlement period, especially the historical settlement periods, settlement processing can be carried out based on the players' leaderboard rankings for each settlement period. This settlement processing is reflected in the settlement of the entire season.

[0084] The settlement process is mainly achieved through the maintained leaderboard data, version update record data, and update version mapping relationship. It does not need to record leaderboard snapshots of historical settlement periods; it only needs to maintain the latest version of the leaderboard snapshot.

[0085] In practical applications, under the premise of a monthly major season, the total points are calculated based on the daily rankings within the major season. This facilitates the distribution of rewards to players based on the calculated total points. Assuming the settlement period is daily, corresponding points can be set according to the specific ranking of players on the leaderboard. Based on the set points and a player's ranking in the historical settlement period, the points for each settlement period can be determined. Then, when settling the season, the points from each settlement period can be aggregated to distribute rewards to players based on the total points.

[0086] To help those skilled in the art further understand the ranking system settlement method proposed in the embodiments of the present invention, the following description is provided in conjunction with illustrative diagrams:

[0087] Referring to Figures 3A to 3I, an example schematic diagram of the settlement ranking list provided by an embodiment of the present invention is shown.

[0088] The leaderboard data maintained for the current settlement period is essentially an ordered set of the latest versions. We can assume the leaderboard data for the current settlement period is `latest_rank`, and the version update data is `version_record`, which can contain a first data set `version_record.new` and a second data set `version_record.old`. The update version mapping is `version_map`. Additionally, we can maintain the current version `latest_version` corresponding to the current settlement period. The value of the current version usually increases as the game cycle progresses. For example, assuming a settlement period of one day, for the first day of the game cycle, the current version `latest_version` = 1, while for the second day of the game cycle, the current version can be updated, specifically updated to `latest_version` = 2, and so on.

[0089] As shown in Figure 3A, the initial data situation of the maintained data structure can be represented. At the beginning, the current version latest_version = 1. At this time, there is no data in the corresponding leaderboard data latest_rank and the updated version mapping relationship version_map. The first data set version_record.new and the second data set version_record.old of the version update data version_record for version 1 are both empty.

[0090] When updating data under latest_version=1, as shown in Figure 3B, the data will change due to changes in player behavior. For example, if the player score corresponding to player a1 is updated to 100 points, since player a1 has no data in the original update version mapping relationship version_map, when updating the data, the player score can be updated to the first data set version_record.new of the leaderboard data latest_rank and the version update data version_record with version 1, that is, version_record[1].new. At the same time, after the update, it can also be recorded in the update version mapping relationship version_map that the update of player a1 was updated under latest_version=1, that is, the update version corresponding to player a1 can be set to latest_version=1. Similarly, for the subsequent updates of player scores of players a2 to a5, it can be represented by modifying the data such as a2=90, a3=80, a4=70, a5=60 accordingly. Since the current version latest_version=1, if you want to query the data, you can directly query in latest_rank.

[0091] As the event progresses, at some point, latest_version will become 2, as shown in Figure 3C. After latest_version = 2, the data in a1 changes, and there will be a new version_record with version = 2. The corresponding old and new are both null values, and the version_record with the historical version 1 will also remain.

[0092] Specifically, assuming that the score of a1 is modified to 75 at this time, as shown in Figure 3D, the data changes after a1 = 75 can be shown (version_record[1] is not drawn). Then, in version_map, the corresponding version is found to be 1, which is not equal to the current latest_version(2). Therefore, the original value of 100 will be recorded. a1 = 100 will be inserted into old and a1 = 75 will be inserted into new respectively. The corresponding latest_rank will also be updated to a1 = 75. After the update, version_map will be updated to a1 = 2.

[0093] After that, the data of a1 can continue to change. For example, a1 = 85, as shown in Figure 3E, can show the data modification after a1 = 85 (version_record[1] is not shown). When updating, it will be found that the value of a1 in version_map is 2, which is the same as the current latest_version. Therefore, the score of a1 = 85 only needs to be updated to latest_rank and version_record[2].new.

[0094] To obtain the player's ranking in the historical version leaderboard, the score for each historical version must first be determined. The score for each historical version is determined in the following way:

[0095] Step 1: If the queried history_version equals latest_version, the score can be obtained directly from latest_rank. Step 2: Otherwise, it will iterate from history_version+1 to version_record. During the iteration, the old and new values ​​in version_record[i] will be queried. Depending on the old and new values, the following will be handled: (1) old = null, new = null, it means that no score change has occurred in this version, so continue to iterate through version i+1; (2) old = null, new! = null, it means that the player has changed from not being on the list to being on the list in this version. Therefore, the player actually has no score in the old version, so null will be returned to indicate that the player has no score in the historical version, and the iteration will stop; (3) old! = null, new is any value, it means that the player originally had a score in this version. At this time, whether the new value is null is irrelevant. The score of the historical version can be returned directly, that is, the value of old will be returned, and the iteration will stop. In some examples, if no result is returned in the above iteration, the score in latest_rank can be returned.

[0096] To query the ranking of a1, a2, a3, and a6 with history_version=1, the general process of querying the ranking of a1, a2, a3, and a6 can be shown in Figure 3E.

[0097] First, we need to obtain the score of a1 when history_version = 1. According to the method for determining the historical version score mentioned in section 4, we first obtain the values ​​of old and new from version_record[2], which are 100 and 85 respectively. Since old is not null, the score of a1 when history_version = 1 is 100. Next, we calculate how many players have a score greater than 100 according to the principle of inclusion and exclusion. There are 0 players with a score greater than 100 in latest_rank, version_record[2].old is also 0, and version_record[2].new is also 0. That is, there are 0 + 0 - 0 = 0 players with a score greater than 100. Therefore, the ranking of player a1 when history_version = 1 is 1st.

[0098] The score for a2 is calculated similarly. First, the scores from version[2].old and new are null and null respectively. Therefore, the next version is traversed. Since latest_version = 2, the traversal has no result. The score in latest_rank is returned as 90, which means that a2's historical version score is 90. Next, the number of players with scores greater than 90 is calculated from latest_rank, version_record[2].old and version_record[2].new, which are 0, 1 and 0 respectively. Finally, there are 0 + 1 - 0 = 1 players with scores greater than 90. Therefore, player a2 ranks 2nd in history_version = 1.

[0099] Following the same process as a2, we can obtain a4's score of 70 when history_version=1. Next, from latest_rank, version_record[2].old, and version_record[2].new, we find that the number of players with scores greater than 70 is 3, 1, and 1 respectively. Therefore, the number of players with scores greater than 70 is 3 + 1 - 1 = 3. Finally, a4's ranking in history_version=1 is 4th. It can be seen that in this example, when calculating a score greater than 70, latest + old will calculate a1 twice. At this point, we need to subtract old to subtract the extra calculation to get the correct value.

[0100] As shown in Figure 3F, suppose a new player a6 is added to the list, that is, when latest_version=2, the number of new players a6=50. You can see that the corresponding data will be updated. If you query the score of a6 when history_version=1, according to the calculation process, the score is first obtained from version_record[2].old and new, which are null and new respectively. According to the rules, null is returned directly. Finally, when history_version=1, the score of a6 is null, which means that it is not on the list. At this time, the returned value is that a6 has no ranking.

[0101] To illustrate the following description, we will make a corresponding score modification for a3 and a4, as shown in Figure 3G. Assuming latest_version = 2, a3 = 75 and a4 = 110.

[0102] Optionally, as shown in Figure 3H, when latest_version is switched to 3, the corresponding data changes are as follows, and it can be seen that data related to version_record[3] has been added. At this time, as shown in Figure 3I, the data changes of a1=65 and a5=105 under latest_version=3 can also be shown.

[0103] In one embodiment of the present invention, when it is necessary to query the ranking of a1 and a5 when history_version=1 under latest_version=3, the specific process may include:

[0104] (1) Query the rank of a1 in historical version 1

[0105] First, we need to query the ranking of a1 in historical version 2. We first need to obtain a1's score when history_version = 1. Specifically, we can get the scores from version_record[2].old and new, which are 100 and 85 respectively. Therefore, a1's historical player score in history_version = 1 is 100. Then, we need to calculate how many players had a score greater than 100 when history_version = 1, that is, calculate the number of players with a historical player score greater than 100 when history_version = 1.

[0106] First, the number of players with scores greater than 100 in latest_rank, version_record[3].old, and version_record[3].new are 2, 0, and 1 respectively. Based on the calculation 2+0-1=1, the result 1 here means that there is 1 player with a score greater than 100 when history_version=2. Next, we can continue to use this result to calculate the number of players with scores greater than 100 in version_record[2].old and version_record[2].new. We can see that there are 0 and 1 players with scores greater than 100 in version_record[2].old and version_record[2].new respectively. So finally, 1+0-1=0, which means that there are 0 players with scores greater than 100 when history_version=1, indicating that player a1 ranks 1st.

[0107] (2) Query the ranking of a5 in historical version 1.

[0108] The process of querying the rank of a5 when history_version=1 is similar. First, the scores of a5 obtained in version_record[2].old and new are both null. Assuming that the scores of version_record[3].old and new are 60 and 105 respectively when iterating through the next version, then the score of a5 when history_version=1 is 60.

[0109] Next, we calculate the number of players with scores greater than 60 using `latest_rank`, `version_record[3].old`, and `version_record[3].new`, which are 5, 1, and 2 respectively. Then, we obtain the number of players with scores greater than 60 using `version_record[2].old` and `version_record[2].new`, which are 3 and 3 respectively. Finally, we calculate 5 + 1 - 2 + 3 - 3 = 4, indicating that there are 4 players with scores greater than 60. Player a5 was ranked 5th in historical version 1.

[0110] As can be seen, when querying data spanning multiple historical versions, the overall calculation is performed in the manner of latest_rank + version_record[i].old – version_record[i].new + version_record[i-1].old – version_record[i-1].new.

[0111] In some embodiments of the present invention, referring to FIG4, a schematic diagram of the logic for deleting a player provided by the embodiments of the present invention is shown. Suppose that player a4 is deleted when latest_version = 3. At this time, in addition to the update of scores, the leaderboard also removes players. The removal of players can be regarded as a special update operation. For example, removing a4 can be regarded as a4 = null. When removing, the version will also be checked according to version_map to see if the version is consistent. If they are inconsistent, the old value will be retained in version_record.old first. Then, a4 needs to be removed from latest_rank and version_record.new respectively (no operation if it does not exist). After all operations are completed, a4 in version_map is also deleted.

[0112] In some embodiments of the present invention, garbage collection of historical versions can also be implemented. Specifically, as the game progresses, a large number of version_records are retained, but based on storage cost considerations and the balance of player activity, many historical versions will no longer be used for awarding prizes. For example, the logic of awarding prizes every day will eventually only allow players to receive the rewards of the previous settlement period. When latest_version = 3, the corresponding version_record[1] is actually meaningless and can be deleted. In the embodiments of the present invention, data is usually managed by version. At this time, garbage collection can be implemented based on the version management. Specifically, the corresponding version that does not need to be maintained can be deleted. In practical applications, in addition to maintaining the latest version of the leaderboard data latest_version, min_version can also be maintained, which represents the minimum number of historical version data to be retained. For example, when the version_record with version = 1 is deleted, the corresponding min_version will be modified to 2, indicating that the data in [min_version, latest_version] is currently retained.

[0113] In some embodiments of the present invention, performance improvements in querying historical versions can also be achieved. Specifically, each time the leaderboard is updated, in addition to updating latest_rank, version_record.new needs to be updated when latest_version and version_map are equal, and version_record.old and version_record.new need to be updated when they are not equal. In this case, the number of updates will increase from 1 to 2-3 times. Since the update itself is relatively fast, there will be no significant difference. In terms of space usage, only the data updated in the current version will have 1-2 extra copies stored (in old and new). Compared to some solutions that completely copy the leaderboard, the space usage is much smaller. The data management principle in a complete copy is that existing players need an extra copy of the data, while the data management principle in this solution is that active players need an extra copy of the data. In terms of query performance, querying the current version's data directly from latest_rank maintains the same performance. For queries of the previous x versions, x more queries of old and x more queries of new are needed, resulting in 2x more queries. However, considering that the queries are all one-time queries when the leaderboard snapshot is being distributed, and that the gameplay usually limits the size of x (e.g., daily rewards within a one-month cycle), then x is at most 30 (x will be smaller if there are restrictions on receiving rewards from historical settlement cycles). In this embodiment of the invention, it is no longer necessary to block the generation of leaderboard snapshots for historical settlement cycles. Instead, old and new in version_record are maintained and updated during normal updates, which can achieve a certain degree of gradual snapshotting.

[0114] It should be noted that, for the data structure used for leaderboard data and version update record data, in addition to ordered sets, other data structures that can support quick queries of player scores, the number of players with scores greater than a certain player, and adding or modifying player scores can also be used, such as balanced binary trees. This allows for functions such as obtaining the number of players with scores greater than a certain player in O(logn) time complexity, calculating the score of player x in O(1) time complexity, and adding or modifying a player's score in O(logn) time complexity. This embodiment of the invention does not impose any limitations on these functions. Here, time complexity refers to how quickly the running time expands as the input size increases; O(1) means the running time is independent of the input size and is completed within a fixed time; O(logn) means that doubling the input size only increases the number of operations by one.

[0115] In this embodiment of the invention, when updating player scores, in addition to the leaderboard data for the current settlement period that is usually maintained, relevant data from historical settlement periods are also maintained when updating the leaderboard data. Specifically, version update record data of the old values ​​that were overwritten before the update and the new values ​​after the update can be maintained. Based on the leaderboard data and version update record data of the current settlement period, the player's ranking in each settlement period, i.e., the historical version, is calculated using the inclusion-exclusion principle. This allows for settlement processing based on the player's leaderboard ranking in each settlement period. Because relevant data from historical settlement periods is maintained, it is applicable to leaderboard snapshot settlements that have passed through the settlement period within the season but do not require clearing the leaderboard, thus meeting the settlement needs of relatively short periods that may exist in long-term seasons. Furthermore, by progressively maintaining leaderboard snapshots when player scores are updated, there is no need to generate snapshots in a blocking manner across versions, i.e., there is no situation where leaderboard snapshots are generated in a blocking manner. In addition, the leaderboard data, version update data, and update version mapping relationships used adopt common structures such as ordered sets and hash tables, which enables the leaderboard settlement method proposed in this embodiment of the invention to be easily implemented on common databases (such as Redis), making it simple to apply.

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

[0117] Referring to Figure 5, a structural block diagram of an embodiment of a leaderboard settlement processing device of the present invention is shown, which may specifically include the following modules:

[0118] The update instruction response module 501 is used to respond to the update instruction for the current player's score in the current settlement period and to obtain leaderboard data and version update data. The leaderboard data is used to maintain the leaderboard data updated according to the settlement period, and the version update record data is used to maintain the new values ​​updated in each settlement period and the old values ​​that are overwritten when updated in each settlement period.

[0119] The data update module 502 is used to update the leaderboard data to obtain the leaderboard data for the current settlement period, and to update the version update record data.

[0120] The leaderboard ranking determination module 503 is used to determine the player's leaderboard ranking in each settlement period based on the leaderboard data and version update record data of the current settlement period.

[0121] Settlement processing module 504 is used to process settlements based on the player's ranking on the leaderboard in each settlement period.

[0122] In one embodiment of the present invention, the data update module 502 may include the following sub-modules:

[0123] The Update Version Mapping Relationship Acquisition Submodule is used to obtain the updated version mapping relationship; the updated version mapping relationship is used to maintain the settlement cycle corresponding to the update of each player's score;

[0124] The data update submodule is used to update the leaderboard data and version update record data according to the update version mapping relationship, so as to obtain the leaderboard data and version update record data for the current settlement period respectively.

[0125] In one embodiment of the present invention, different settlement cycles are determined based on different versions, and version update record data is maintained separately for each version, including a first data set for maintaining the new values ​​updated in the version corresponding to each settlement cycle, and a second data set for maintaining the old values ​​overwritten when the version corresponding to each settlement cycle is updated; the update version mapping relationship includes the update version corresponding to the player;

[0126] The data update submodule may include the following units:

[0127] The current version acquisition unit is used to obtain the current version for the current settlement period;

[0128] The first data update unit is used to update the current player's score to the first data set in the leaderboard data and version update record data when there is no corresponding update version for the player in the update version mapping relationship, and to set the corresponding update version for the player to the current version in the update version mapping relationship;

[0129] The second data update unit is used to update the current player's score to the leaderboard data and the first data set when there is an updated version corresponding to the player in the updated version mapping relationship, and the updated version corresponding to the player is inconsistent with the current version. It also retrieves the player's original score and updates the original player score to the second data set in the version record data.

[0130] The third data update unit is used to update the current player's score to the first data set in the leaderboard data and version update record data when there is an updated version corresponding to the player in the update version mapping relationship, and the updated version corresponding to the player is the same as the current version.

[0131] In one embodiment of the present invention, different settlement cycles are determined based on different versions; the leaderboard ranking determination module 503 may include the following sub-modules:

[0132] The target player score acquisition submodule is used to obtain the target player score in any target version based on the leaderboard data and version update record data of the current settlement period;

[0133] The Player Count Determination Submodule is used to determine the number of players whose scores are greater than the target player's score in any target version, based on the target player's score in any target version.

[0134] The Leaderboard Ranking Determination submodule is used to determine the leaderboard ranking of a target player in any given target version, based on the number of players.

[0135] In one embodiment of the present invention, the target player score acquisition submodule may include the following units:

[0136] The first target player score acquisition unit is used to acquire the target player's score in the current version from the leaderboard data of the current settlement period when the target version is the current version.

[0137] The second target player score acquisition unit is used to determine the target player's score in the target version by traversing from the version update record data of the current version to the version update record data of the target version when the target version is lower than the current version.

[0138] In one embodiment of the present invention, the version update record data is maintained based on each version, including a first data set for maintaining the new values ​​updated by the version corresponding to each settlement period, and a second data set for maintaining the old values ​​that are overwritten when the version corresponding to each settlement period is updated.

[0139] The second target player score acquisition unit may include the following sub-units:

[0140] The target player score acquisition subunit is used to determine the following during the traversal process: if the value corresponding to the target player is empty in both the first and second sets of the traversed version update data, the traversal continues; and / or, if the value corresponding to the target player is not empty in the first set of the traversed version update data, but the value corresponding to the target player is empty in the second set of the traversed version update data, the traversal stops; and / or, if the value corresponding to the target player is any value in the first set of the traversed version update data, but the value corresponding to the target player is not empty in the second set of the traversed version update data, the value corresponding to the target player is determined to be the target player's score in the target version, and the traversal stops; and / or, if the target player's score in the target version has not been determined when the traversal stops, the target player's score in the current version is determined to be the target player's score in the target version.

[0141] In one embodiment of the present invention, the player count determination submodule may include the following units:

[0142] The first player count determination unit is used to calculate the number of players with scores greater than the target player's score from the leaderboard data of the current settlement period when the target version is the current version, and to determine the number of players with scores greater than the target player's score in the current version.

[0143] The second player count determination unit is used to iterate from the version update record data of the current version to the version update record data of the target version when the target version is less than the current version. Based on the number of players whose player scores are greater than the target player score in the iterated versions, the unit determines the number of players whose player scores are greater than the target player score in any target version.

[0144] In one embodiment of the present invention, the second player number determination unit may include the following sub-units:

[0145] The sub-unit for determining the number of players starts by iterating through the version update record data of the current version. It calculates the number of players whose player score in the previous version is greater than the target player score in the version being iterated through. Using the number of players whose player score in the previous version is greater than the target player score as the base number, it calculates the number of players whose player score in the version before the previous version is greater than the target player score, until the target version is reached.

[0146] Specifically, the process of calculating the number of players whose player score in the previous version is greater than the target player score in the traversed versions can include: obtaining the number of players whose player score is greater than the target player score in the leaderboard data of the next version compared to the previous version, the number of players whose player score is greater than the target player score in the second data set of the version record data of the next version compared to the previous version, and the number of players whose player score is greater than the target player score in the first data set of the version record data of the next version compared to the previous version; and calculating the number of players whose player score is greater than the target player score in the previous version by using the sum of the number of players whose player score is greater than the target player score in the leaderboard data of the next version compared to the previous version and the difference between the sum of ...

[0147] The process of calculating the number of players whose scores are higher than the target score in the previous version, using the number of players in the previous version as the base number, and calculating the number of players whose scores are higher than the target score in the version before the previous version, can specifically include: obtaining the number of players whose scores are higher than the target score in the second data set of the version record data of the previous version, and the number of players whose scores are higher than the target score in the first data set of the version record data of the previous version; using the number of players whose scores are higher than the target score in the previous version as the base number, and the sum of the base number and the number of players whose scores are higher than the target score in the second data set of the version record data of the previous version, and the difference between the base number and the number of players whose scores are higher than the target score in the first data set of the version record data of the previous version, to calculate the number of players whose scores are higher than the target score in the version before the previous version in the traversed versions.

[0148] In this embodiment of the invention, the leaderboard settlement processing device provides that, each time player scores on the leaderboard are updated, in addition to maintaining the leaderboard data for the current settlement period, it also maintains relevant data for historical settlement periods. Specifically, it can maintain version update records of old values ​​that were overwritten before the update and new values ​​after the update. Based on the leaderboard data for the current settlement period and combined with data from multiple settlement periods, it calculates the player's leaderboard ranking for each settlement period. Because it maintains relevant data for historical settlement periods, it can be applied to leaderboard snapshot settlements that have passed through the settlement period within the season but do not require clearing the leaderboard, thus meeting the settlement needs for relatively short periods that may exist within a long season.

[0149] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0150] This invention also provides an electronic device, comprising:

[0151] It includes a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When the computer program is executed by the processor, it implements the various processes of the above-described leaderboard settlement processing method embodiment and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0152] This invention also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the various processes of the above-described leaderboard settlement processing method embodiment and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0153] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0154] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, embodiments of the present invention can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0155] Embodiments of the present invention are described with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0156] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0157] These computer program instructions may also be loaded onto a computer or other programmable data processing terminal equipment to cause a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable terminal equipment, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0158] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

[0159] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device 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 terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0160] The above provides a detailed description of a ranking system settlement processing method, a ranking system settlement processing device, a corresponding electronic device, and a corresponding computer-readable storage medium provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for processing the settlement of a leaderboard, characterized in that, The method includes: responding to an update instruction for the current player's score in the current settlement period, acquiring leaderboard data and version update record data; wherein, the leaderboard data is used to maintain leaderboard data updated according to the settlement period, and the version update record data is used to maintain new values ​​updated in each settlement period and old values ​​overwritten during updates in each settlement period; acquiring an update version mapping relationship; the update version mapping relationship is used to maintain the settlement period corresponding to the update of each player's score; different settlement periods are determined based on different versions, and the version update record data is maintained separately for each version, including a first data set for maintaining new values ​​updated in the version corresponding to each settlement period, and a second data set for maintaining old values ​​overwritten during updates in the version corresponding to each settlement period; the update version mapping relationship includes the update version corresponding to the player; updating the leaderboard data and the version update record data according to the update version mapping relationship to obtain the leaderboard data and version update record data for the current settlement period respectively; determining the player's leaderboard ranking in each settlement period according to the leaderboard data and version update record data for the current settlement period; and based on the... The process involves calculating player rankings across various settlement periods. Specifically, updating the leaderboard data and version update record data based on the update version mapping relationship includes: obtaining the current version for the current settlement period; if the update version mapping relationship does not exist for the player, updating the current player score to a first data set in the leaderboard data and version update record data, and setting the player's corresponding update version to the current version in the update version mapping relationship; and / or, if the update version mapping relationship exists for the player, and the player's corresponding update version is inconsistent with the current version, updating the current player score to the leaderboard data and the first data set, obtaining the player's original score, and updating the original player score to a second data set in the version update record data; and / or, if the update version mapping relationship exists for the player, and the player's corresponding update version is consistent with the current version, updating the current player score to the first data set in the leaderboard data and version update record data.

2. The method according to claim 1, characterized in that, Different settlement cycles are determined based on different versions; determining a player's ranking in each settlement cycle based on the leaderboard data and version update record data of the current settlement cycle includes: obtaining the target player's score in any target version based on the leaderboard data and version update record data of the current settlement cycle; determining the number of players with a score greater than the target player's score in any target version based on the target player's score in any target version; and determining the target player's ranking in any target version based on the number of players.

3. The method according to claim 2, characterized in that, The step of obtaining the target player's score in any target version based on the leaderboard data and version update record data of the current settlement period includes: when the target version is the current version, obtaining the target player's score in the current version from the leaderboard data of the current settlement period; and / or, when the target version is less than the current version, traversing from the version update record data of the current version to the version update record data of the target version to determine the target player's score in the target version.

4. The method according to claim 3, characterized in that, The version update record data is maintained separately for each version, including a first data set for maintaining the new values ​​updated in the version corresponding to each settlement period, and a second data set for maintaining the old values ​​that are overwritten when the version corresponding to each settlement period is updated. The step of traversing from the current version update record data to the target version update record data to determine the target player's score in the target version includes: during the traversal, if the value corresponding to the target player is empty in the first and second data sets of the traversed version update record data, then the traversal continues; and / or, if the value corresponding to the target player is not empty in the first data set of the traversed version update record data, and the value corresponding to the target player is empty in the second data set of the traversed version update record data, then the traversal stops; and / or, if the value corresponding to the target player is any value in the first data set of the traversed version update record data, and the value corresponding to the target player is not empty in the second data set of the traversed version update record data, then the value corresponding to the target player is determined to be the target player's score in the target version, and the traversal stops; and / or, if the target player's score in the target version has not been determined when the traversal stops, then the target player's score in the current version is determined to be the target player's score in the target version.

5. The method according to claim 2, characterized in that, The step of determining the number of players whose scores are greater than the target player's score in any target version based on the target player's score in any target version includes: when the target version is the current version, calculating the number of players whose scores are greater than the target player's score from the leaderboard data of the current settlement period, and determining the number of players whose scores are greater than the target player's score in the current version; and / or, when the target version is less than the current version, traversing from the version update record data of the current version to the version update record data of the target version, and determining the number of players whose scores are greater than the target player's score in any target version based on the number of players whose scores are greater than the target player's score in the traversed versions.

6. The method according to claim 5, characterized in that, The step of traversing the version update record data from the current version to the version update record data of the target version, and determining the number of players with a score greater than the target player score in any target version based on the number of players with a score greater than the target player score in the traversed versions, includes: starting from traversing the version update record data of the current version, calculating the number of players with a score greater than the target player score in the previous version in the traversed versions, and using the number of players with a score greater than the target player score in the previous version as a base number, calculating the number of players with a score greater than the target player score in the version before the previous version, until the target version is reached.

7. The method according to claim 6, characterized in that, The calculation of the number of players whose player score in the previous version is greater than the target player score in the traversed versions includes: obtaining the number of players whose player score is greater than the target player score in the leaderboard data of the next version compared to the previous version, the number of players whose player score is greater than the target player score in the second data set of the version record data of the next version compared to the previous version, and the number of players whose player score is greater than the target player score in the first data set of the version record data of the next version compared to the previous version; and using the sum of the number of players whose player score is greater than the target player score in the leaderboard data of the next version compared to the previous version and the difference between the sum of ...

8. The method according to claim 6 or 7, characterized in that, The step of using the number of players whose scores were higher than the target score in the previous version as a base number to calculate the number of players whose scores were higher than the target score in the version before the previous version includes: obtaining the number of players whose scores were higher than the target score in the second data set of the version record data of the previous version, and the number of players whose scores were higher than the target score in the first data set of the version record data of the previous version; using the number of players whose scores were higher than the target score in the previous version as a base number, and using the sum of the base number and the number of players whose scores were higher than the target score in the second data set of the version record data of the previous version, and the difference between the base number and the number of players whose scores were higher than the target score in the first data set of the version record data of the previous version, to calculate the number of players whose scores were higher than the target score in the version before the previous version in the traversed versions.

9. A ranking list settlement processing device, characterized in that, The device includes: an update command response module, used to respond to an update command for the current player's score in the current settlement period, and to acquire leaderboard data and version update record data; wherein, the leaderboard data is used to maintain leaderboard data updated according to the settlement period, and the version update record data is used to maintain new values ​​updated in each settlement period and old values ​​overwritten during updates in each settlement period; an update version mapping relationship acquisition submodule, used to acquire update version mapping relationships; the update version mapping relationships are used to maintain the settlement period corresponding to the update of each player's score; different settlement periods are determined based on different versions, and the version update record data is maintained based on each version, including a first data set for maintaining new values ​​updated in the version corresponding to each settlement period, and a second data set for maintaining old values ​​overwritten during updates in the version corresponding to each settlement period; the update version mapping relationship includes the update version corresponding to the player; a data update submodule, used to update the leaderboard data and the version update record data according to the update version mapping relationship, to obtain the leaderboard data and version update record data for the current settlement period respectively; and a leaderboard ranking determination module, used to determine the player's ranking in each settlement period based on the leaderboard data and version update record data for the current settlement period. The system includes a leaderboard ranking system for each settlement period; a settlement processing module for performing settlement processing based on the player's leaderboard ranking in each settlement period; wherein the data update submodule includes: a current version acquisition unit for acquiring the current version for the current settlement period; a first data update unit for updating the current player's score to a first data set in the leaderboard data and the version update record data if the updated version corresponding to the player does not exist in the updated version mapping relationship, and setting the updated version corresponding to the player in the updated version mapping relationship as the current version; and / or, a second data update unit for updating the current player's score to the leaderboard data and the first data set if the updated version corresponding to the player exists in the updated version mapping relationship, and the updated version corresponding to the player is inconsistent with the current version, and acquiring the player's original player score, and updating the original player score to a second data set in the version update record data; and / or, a third data update unit for updating the current player's score to the first data set in the leaderboard data and the version update record data if the updated version corresponding to the player exists in the updated version mapping relationship, and the updated version corresponding to the player is consistent with the current version.

10. An electronic device, characterized in that, include: A processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the settlement processing method for the leaderboard as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, which, when executed by a processor, implements the settlement processing method for the leaderboard as described in any one of claims 1 to 8.

Images