Reward output upper limit control method and device and storage medium

By dynamically determining the target output monitoring items and obtaining the output quantity and output limit configuration, the problem of not being able to independently monitor core scarce items in the existing technology is solved, realizing timely upper limit control of reward output and improving the stability and balance of the game's economic system.

CN121998703APending Publication Date: 2026-05-08SHANGYU SOFTWARE (SHENZHEN) CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
SHANGYU SOFTWARE (SHENZHEN) CO LTD
Filing Date
2026-01-06
Publication Date
2026-05-08

AI Technical Summary

Technical Problem

The existing item production control mechanism cannot independently monitor core scarce items, resulting in the inability to detect and effectively intervene in unexpected large-scale production in a timely manner, affecting game balance and economic stability.

Method used

By responding to reward output requests, the system dynamically determines the target output monitoring items, including subject type, scenario identifier, and cycle configuration, obtains the output quantity and output limit configuration, compares them in real time to determine the actual allowed distribution quantity, and updates the output quantity after distribution, thereby achieving timely and independent upper limit control of reward output.

Benefits of technology

It enables timely, independent, and configurable upper limit control over various reward output behaviors, ensuring the accuracy and consistency of output data and improving the stability and balance of the game's economic system.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121998703A_ABST
    Figure CN121998703A_ABST
Patent Text Reader

Abstract

The invention discloses a reward output upper limit control method and device and a storage medium, relates to the technical field of data processing, and discloses a reward output upper limit control method, which comprises the following steps: in response to a reward output request, determining a target output monitoring item corresponding to the reward output request; obtaining the target output quantity of the target output monitoring item in the current period and the corresponding output upper limit configuration; according to the target output quantity and the output upper limit configuration, determining the actual allowable issuing quantity of the reward information in the reward output request; and performing reward information issuing according to the actual allowable issuing quantity, and updating the target output quantity of the target output monitoring item in the current period. According to the method and the device, independent periodic output monitoring items are configured for different reward outputs, and quantity statistics and upper limit control of each output behavior in a corresponding period are realized, so that the rationality and controllability of reward output in a game are guaranteed, and the stability and the balance degree of a game economic system are improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, device and storage medium for controlling the upper limit of reward output. Background Technology

[0002] In massively multiplayer online games (MMOs), item production control is crucial for maintaining game balance and economic stability. Current item production control mechanisms typically rely on the collection and analysis of in-game economic data, such as player density, currency circulation, transaction prices, and item circulation speed, and adjust the overall drop rules uniformly based on these macro indicators.

[0003] However, such control methods mainly target all items or general economic parameters, and do not establish an independent monitoring mechanism for core scarce items. When such items are produced in unexpected large quantities due to configuration errors or abnormal acquisition, the system cannot specifically identify and track their production status, making it difficult to detect and intervene effectively in a timely manner.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a method, device and storage medium for controlling the upper limit of reward output, which aims to solve the technical problem that the reward output regulation mechanism cannot independently and timely control the upper limit of various reward outputs.

[0006] To achieve the above objectives, embodiments of this application provide a method for controlling the upper limit of reward output, the method comprising: In response to a reward output request, a target output monitoring item corresponding to the reward output request is determined. The target output monitoring item includes subject type, scene identifier, period configuration, and reward information. Obtain the target output monitoring item's target output quantity and corresponding output limit configuration within the current period; Based on the target output quantity and the output limit configuration, determine the actual allowable quantity of the reward information in the reward output request; Rewards will be distributed based on the actual allowed amount, and the target output monitoring item will be updated to reflect the target output quantity in the current period.

[0007] In one embodiment, the step of determining the target output monitoring item corresponding to the reward output request in response to the reward output request includes: In response to the reward output request, obtain the request event, the reward information, and the request subject identifier carried by the reward output request; Based on the pre-configured mapping relationship, determine at least one candidate output monitoring item associated with the request event; Based on the reward information and the request subject identifier, the target output monitoring item is determined from the candidate output monitoring items.

[0008] In one embodiment, the step of obtaining the target output monitoring item's target output quantity and corresponding output limit configuration within the current period includes: Based on the period configuration of the target output monitoring item, the current logical period corresponding to the target output monitoring item is determined, and the period configuration includes the period type and the reset period; Based on the logical cycle, obtain the target output monitoring item's target output quantity within the logical cycle, and obtain the output upper limit configuration corresponding to the logical cycle.

[0009] In one embodiment, the step of obtaining the target output monitoring item's target output quantity and corresponding output limit configuration within the current period includes: Determine whether the target output monitoring item has an inheritance relationship; If an inheritance relationship is configured, the corresponding inheritance source monitoring item is determined based on the inheritance relationship; If the inherited source monitoring item and the target output monitoring item have the same subject type and correspond to the same logical cycle, then obtain the output quantity of the inherited source monitoring item within the logical cycle; The quantity produced by the inherited source monitoring item is added to the quantity produced by the target output monitoring item itself, and this is taken as the target quantity produced by the target output monitoring item in the current period. If no inheritance relationship is configured, or if the inherited source monitoring item and the target output monitoring item do not have the same subject type or do not correspond to the same logical period, then the output quantity of the target output monitoring item itself will be used as the target output quantity of the target output monitoring item in the current period.

[0010] In one embodiment, the step of determining the actual allowable quantity of reward information in the reward production request based on the target already produced quantity and the production cap configuration includes: Obtain the number of rewards requested in the reward output request; Based on the output limit configuration and the target output quantity, determine the remaining distributable amount of the reward information in the current period; The actual allowable amount to be distributed is determined based on the number of rewards and the remaining distributable amount.

[0011] In one embodiment, after the steps of distributing reward information according to the actual allowed distribution quantity and updating the target output monitoring item's target output quantity in the current period, the method further includes: Determine whether the updated target output quantity has reached the output limit configuration; If the target output quantity reaches the output limit configuration, an upper limit trigger warning is generated, and the distribution of the reward information is not intercepted due to the generation of the upper limit trigger warning.

[0012] In one embodiment, the reward output cap control method further includes: Iterate through the preset period types; For each cycle type, obtain the current logical cycle of the cycle type and determine whether the current time exceeds the preset valid time range of the current logical cycle; If the current time exceeds the preset valid time range, the current logical cycle is marked as an expired logical cycle, and the target output quantity recorded in all output monitoring items associated with the cycle type within the expired logical cycle is reset. At the same time, the logical cycle corresponding to the cycle type is also reset.

[0013] In one embodiment, after the steps of distributing reward information according to the actual allowed distribution quantity and updating the target output monitoring item's target output quantity in the current period, the method further includes: Record the distribution details corresponding to the reward output request. The distribution details include the request initiation time, request subject identifier, target output monitoring item identifier, type of reward requested, reward identifier and reward quantity, as well as the actual allowed distribution quantity. Based on the logical cycle corresponding to the target output monitoring item, the distribution details data are summarized and statistically analyzed; Based on the summarized statistical results, a periodic output report is generated.

[0014] This application embodiment also provides a reward output cap control device, the reward output cap control device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the reward output cap control method as described above.

[0015] This application embodiment also provides a storage medium, which is a computer-readable storage medium, and stores a computer program thereon. When the computer program is executed by a processor, it implements the steps of the reward output cap control method described above.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: This application dynamically determines the target output monitoring item corresponding to the reward output request when responding to the reward output request, and identifies the current logical cycle based on the cycle configuration included in the target output monitoring item. This allows reward output control to be bound to specific subject types, scene identifiers, and time dimensions. By obtaining the output quantity of the target output monitoring item within the current logical cycle and comparing it with the output limit configuration in real time, the actual allowable amount of the corresponding reward can be determined before reward distribution, avoiding over-distribution. Furthermore, by updating the output quantity within the current logical cycle immediately after distribution, it ensures that subsequent reward output request decisions are based on the latest output data, thereby guaranteeing the accuracy and consistency of output data within the current logical cycle. In addition, the entire process does not rely on global economic indicators; it only needs to complete closed-loop control according to the preset monitoring item configuration, realizing timely, independent, and configurable upper limit control of various reward output behaviors. Attached Figure Description

[0017] Figure 1 A flowchart illustrating the first embodiment of the reward output cap control method in this application; Figure 2 A flowchart illustrating the second embodiment of the reward output cap control method for this application; Figure 3 A flowchart illustrating the third embodiment of the reward output cap control method in this application; Figure 4 A flowchart illustrating the fourth embodiment of the reward output cap control method for this application; Figure 5 A flowchart illustrating the fifth embodiment of the reward output cap control method for this application; Figure 6 A flowchart illustrating the sixth embodiment of the reward output cap control method in this application; Figure 7 A flowchart illustrating the seventh embodiment of the reward output cap control method in this application; Figure 8 A flowchart illustrating the eighth embodiment of the reward output cap control method in this application; Figure 9 This is a schematic diagram of the reward output cap control device in the hardware operating environment involved in the reward output cap control method in this application embodiment.

[0018] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0019] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0020] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0021] In massively multiplayer online games (MMOs), item production control is crucial for maintaining game balance and economic stability. Current item production control mechanisms typically rely on the collection and analysis of in-game economic data, such as player density, currency circulation, transaction prices, and item circulation speed, and adjust the overall drop rules uniformly based on these macro indicators.

[0022] However, such control methods mainly target all items or general economic parameters, and do not establish an independent monitoring mechanism for core scarce items. When such items are produced in unexpected large quantities due to configuration errors or abnormal acquisition, the system cannot specifically identify and track their production status, making it difficult to detect and intervene effectively in a timely manner.

[0023] In view of the above problems, this application proposes a method for controlling the upper limit of reward output. In response to a reward output request, the method determines a target output monitoring item corresponding to the reward output request. The target output monitoring item includes a subject type, scene identifier, period configuration, and reward information. It then obtains the target output quantity of the target output monitoring item in the current period and the corresponding output upper limit configuration. Based on the target output quantity and the output upper limit configuration, it determines the actual allowed distribution quantity of the reward information in the reward output request. Finally, it executes the distribution of reward information according to the actual allowed distribution quantity and updates the target output quantity of the target output monitoring item in the current period.

[0024] This application provides a solution that dynamically determines the target output monitoring item corresponding to the reward output request when responding to the reward output request, and identifies the current logical cycle based on the cycle configuration included in the target output monitoring item. This allows reward output control to be bound to specific subject types, scenario identifiers, and time dimensions. By obtaining the output quantity of the target output monitoring item within the current logical cycle and comparing it with the output limit configuration in real time, the actual allowable distribution quantity of the corresponding reward is determined before reward distribution, avoiding over-distribution. Furthermore, by updating the output quantity within the current logical cycle immediately after distribution, it is ensured that subsequent reward output request decisions are based on the latest output data, thereby guaranteeing the accuracy and consistency of output data within the current logical cycle. In addition, the entire process does not rely on global economic indicators; it only needs to complete closed-loop control according to the preset monitoring item configuration, realizing timely, independent, and configurable upper limit control of various reward output behaviors.

[0025] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a game server, cloud server, computer, mobile phone, etc., or an electronic device capable of realizing the above functions, a reward output cap control system, etc. The following description uses a reward output cap control system (hereinafter referred to as the system) as an example to illustrate this embodiment and the following embodiments.

[0026] Please refer to the reward output cap control method of the first embodiment proposed in this application. Figure 1 The method includes steps S10 to S40: Step S10: In response to the reward output request, determine the target output monitoring item corresponding to the reward output request. The target output monitoring item includes subject type, scene identifier, period configuration and reward information.

[0027] It should be noted that a reward production request refers to a reward distribution application instruction received by the game system, triggered by player behavior or specific game events (such as completing a task, defeating a monster, opening a treasure chest, etc.). The target production monitoring item is the basic unit used for quantitative control of specific reward production behavior. It refines the environmental conditions for item production into core control elements such as subject, scene, cycle, and reward. This greatly satisfies the need to independently monitor and statistically analyze the production information of specified items for various subjects (such as players, legions, servers, gameplay, etc.) under diverse preset conditions within a specified period, thereby achieving specialized monitoring of key rewards or items.

[0028] Subject type refers to the category of the object being controlled for reward output, including individual players, legions, servers, and specific gameplay. Scene identifier is information used to distinguish the specific game context in which rewards are distributed, including daily task scenarios, holiday event scenarios, and dungeon challenge scenarios; for example, "a specific subject completing a certain type of operation at a specified time and under certain conditions" can be defined as a scene. Period configuration is a parameter configuration used to limit the time range for reward output control, including period type and reset period. Reward information is data related to the specific content of the reward, including reward type, reward identifier, and reward quantity.

[0029] In this embodiment, after the system's service process starts, it first executes the preset configuration loading operations of reward_limit_cfg.csv (reward configuration file) and reward_limit_event.csv (reward event mapping file) to initialize all output monitoring items. Simultaneously, reward_limit_cfg.csv and reward_limit_event.csv are stored in memory using a table data structure. The reward configuration file includes output monitoring item identifiers, subject types, scene identifiers, reward types, reward identifiers, period configurations (including period type and reset period), output cap configurations, and inheritance relationship configurations; the reward event mapping file is used to establish the association between request events and corresponding output monitoring item identifiers.

[0030] Furthermore, the system singleton c_reward_limit_system is instantiated to construct the core data structure and index to support subsequent fast querying and real-time control. Specifically, during the construction of the system singleton, multiple data containers and index structures are constructed, including: (1) constructing the individual data container individual_data to store the individual output data of the output records of individual subjects (such as individual players, legions); (2) constructing the integral data container integral_data to store the integral output data of the output records of the integral subjects (such as servers, gameplay); (3) constructing the period timer container period_timer to maintain the current logical period state of each period type; (4) constructing the monitoring item index rls_type_index, the period type index rls_period_index, and the monitoring item inheritance index rls_inherit_index; (5) constructing the index guidance directories rls_index_dir and rls_data_dir to organize and locate various indexes and data containers.

[0031] Subsequently, based on the CSV configuration (reward configuration file and reward event mapping file) already stored in memory, the configuration content is parsed, and the corresponding configuration data is populated into the aforementioned data container, index, and index guidance directory one by one to complete the system initialization.

[0032] Based on the table data structure stored in memory, populate the aforementioned personal data container, overall data container, periodic timer container, and multi-dimensional index guide directory.

[0033] In this embodiment, the specific configuration dimensions of reward_limit_cfg.csv can be found in Table 1: Table 1. Description of configuration dimensions in reward_limit_cfg.csv

[0034] As an example, cycle types include day, week, month, and year, which can be distinguished by numbers or other identifiers, such as number 1 for day, number 2 for week, number 3 for month, and number 4 for year. The reset cycle is a specific number, which, together with the cycle type, defines the length of a logical cycle. For example, when the cycle type is 1 (day) and the reset cycle is 3, it means that a logical cycle consists of 3 calendar days, and the system will reset the output data of the output monitoring item within the current logical cycle every 3 days.

[0035] As another example, reward types include different forms such as items and currency points, which can also be defined by numbers or other identifiers, such as 1 representing items and 2 representing currency points; the reward identifier corresponds to the specific distinguishing information of different reward types, including item identifiers and currency point identifiers. Among them, the item identifier uses the unique type number (i.e., type_id) of the item in the game database, while the currency point identifier is the corresponding type index.

[0036] Understandably, since items usually exist as independent data entities, their types and attributes need to be distinguished by type_id; while the types of currency points are limited and fixed (such as gold coins), the system assigns a unique type index to them, and the corresponding currency point type can be clearly identified by directly using this type index.

[0037] Step S20: Obtain the target output monitoring item's target output quantity and corresponding output limit configuration within the current period.

[0038] It should be noted that the current period is the reward control time interval that is being executed, determined by the period configuration of the target output monitoring item; the target output quantity is the cumulative number of rewards that have been successfully distributed by the target output monitoring item in the current period; the output limit configuration is the maximum number of rewards that can be distributed within a logical period for the target output monitoring item.

[0039] As an example, if the cycle type in the cycle configuration of the output monitoring item is "Daily" and the reset cycle is 1, the system will use the calendar day as the logical cycle. For example, if the current system time is 15:00 on December 24, 2025, then the current cycle is from 00:00:00 on December 24, 2025 to 00:00:00 on December 25, 2025. If the reset cycle is greater than 1, the start and end times of the current cycle will be calculated sequentially based on the end time of the previous logical cycle (i.e., the time when the last reset occurred).

[0040] The system can build a distributed data storage architecture, storing the periodic output data of different target output monitoring items in corresponding personal data containers and overall data containers respectively; when it is necessary to obtain the output quantity of the target, the corresponding data container is directly indexed by the identifier of the target output monitoring item, and the cumulative output data within the current period is filtered by combining the time range parameter of the current period.

[0041] To obtain the output cap configuration, it can be pre-loaded into the reward configuration file in memory. While obtaining the target output quantity, the corresponding output cap configuration can be retrieved simultaneously from the reward configuration file. Furthermore, a configuration caching update mechanism can be set up to update the reward configuration file in memory in real time when the output cap configuration changes, ensuring that the obtained output cap configuration is the latest and most valid data.

[0042] As an example, the period configuration for the target output monitoring item is daily and resets at midnight every day. After the system receives the reward output request at 10:00 a.m. and determines the target output monitoring item, it indexes the personal data container through the output monitoring item identifier, filters out the reward distribution records from midnight to 10:00 a.m., and accumulates them to obtain the target output quantity. At the same time, it queries the reward configuration file in memory to obtain the daily output limit configuration corresponding to the output monitoring item.

[0043] Step S30: Based on the target output quantity and the output limit configuration, determine the actual allowable quantity of the reward information in the reward output request.

[0044] It should be noted that the actual allowable distribution quantity is calculated based on the total output quantity of the target and the output limit configuration, and represents the actual number of rewards that can be distributed within the current cycle.

[0045] In this embodiment, the system can use a difference calculation method to determine the actual allowed distribution quantity. First, it calculates the difference between the output ceiling configuration and the target output quantity to obtain the remaining distributable amount in the current period. Then, it compares this remaining distributable amount with the reward quantity requested in the reward output request. If the requested quantity is less than or equal to the remaining distributable amount, the requested quantity is determined as the actual allowed distribution quantity; if the requested quantity is greater than the remaining distributable amount, the remaining distributable amount is determined as the actual allowed distribution quantity. When the remaining distributable amount is zero, the actual allowed distribution quantity is also zero, and the system can generate an insufficient amount prompt message.

[0046] As an example, for a specific item, the daily output limit of the target output monitoring item is configured to be 30 of the specified item. In the current period, the target output quantity of the specified item is 28. The number of items requested to be distributed in the reward output request is 3. The system calculates that the remaining distributable quota of the specified item is 2. Since the number of items requested to be distributed is greater than the remaining distributable quota, the actual allowed quantity to be distributed is finally determined to be 2 items.

[0047] This implementation method combines the target output monitoring item's target output quantity within the current logical cycle with the corresponding output limit configuration to calculate the actual allowed distribution quantity of reward information in the reward output request. This effectively avoids over-limit distribution caused by the cumulative distribution exceeding the configured limit, thereby achieving reliable upper limit control over reward output.

[0048] Step S40: Distribute reward information according to the actual allowed distribution quantity, and update the target output monitoring item's target output quantity in the current period.

[0049] It should be noted that the execution of reward information distribution refers to the process by which the system distributes the corresponding reward content to the target entity according to the actual allowed distribution quantity; updating the target output quantity refers to the process of adding the actual allowed distribution quantity to the statistical data of the target output monitoring item for the current period after the reward distribution is completed, and completing the data storage operation.

[0050] When executing reward distribution operations, the system can employ a transaction processing mechanism to ensure the atomicity of reward distribution and data updates, avoiding anomalies such as successful reward distribution without data updates or data updates without reward distribution. After reward distribution is completed, the actual allowed distribution quantity is synchronized to the corresponding data container in real time, updating the current period's target output quantity for the target output monitoring item. Simultaneously, the updated data is persisted to the relational database in real time. Furthermore, a data update verification mechanism can be configured to ensure the accuracy of data updates by comparing the difference between the target output quantity before and after the update with the actual allowed distribution quantity.

[0051] As an example, the system distributes the two items to the player's game inventory according to the actual allowed distribution quantity of the two items. At the same time, the quantity of the two items is added to the daily output quantity of the target output monitoring item. The updated data changes from 28 items to 30 items. The system then synchronizes the updated data into the MySQL database and completes data verification.

[0052] This embodiment constructs independent output monitoring items defined by multiple dimensions such as subject, scenario, cycle, and reward, establishing a dedicated control anchor point for each type of reward output event. Upon responding to a reward output request, it obtains in real-time the target output monitoring item's already produced quantity within the current logical cycle and compares it with a preset output cap configuration to determine the actual allowed distribution quantity, effectively preventing over-distribution. Simultaneously, by executing reward distribution and data update operations, it ensures consistency between the counting status and the distribution behavior. Therefore, it solves the technical problem that the reward output control mechanism lacks specialized monitoring capabilities, making it unable to implement independent and reliable cap control for specific reward output behaviors, effectively improving the stability and balance of the game's economic system.

[0053] Based on the above embodiments of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 In the reward output cap control method, step S10 includes steps S110 to S130: Step S110: In response to the reward production request, obtain the request event, the reward information and the request subject identifier carried by the reward production request.

[0054] Step S120: Determine at least one candidate output monitoring item associated with the request event based on the pre-configured mapping relationship.

[0055] Step S130: Determine the target output monitoring item from the candidate output monitoring items based on the reward information and the request subject identifier.

[0056] It should be noted that the request event is a specific event behavior used to mark the source of the reward production request, which can accurately distinguish different reward trigger events; the request subject identifier is used to identify the entity that initiates the reward production request, including but not limited to player ID, legion ID or server ID, which can be directly mapped to a specific monitoring subject; the candidate production monitoring item refers to a set of one or more production monitoring items associated with the request event among a number of pre-configured production monitoring items.

[0057] Upon receiving a reward generation request, the system first parses the data structure carried by the request, extracting key fields such as the request event, reward information (reward_info), and request subject identifier (individual_id). The reward information (reward_info) includes the reward type, reward identifier, and corresponding reward quantity. Subsequently, the system singleton c_reward_limit_system performs a pre-add reward data processing step (pre_add_reward_count) on the reward generation request. This pre-processing step identifies and binds the target output monitoring items corresponding to each reward in the request and prepares the count status of the corresponding reward items within the current logical cycle, providing a basis for subsequent upper limit verification and data updates.

[0058] To determine the relationship between request events and output monitoring items, the system can read and generate a mapping table from the reward_limit_event.csv configuration file loaded during the initialization phase. This mapping table uses a key-value pair structure, with the request event as the key and a list of one or more output monitoring item identifiers (i.e., output monitoring item IDs) as the value, thereby clarifying the set of reward cap rules associated with each request event.

[0059] After obtaining the request event, the system directly retrieves the list of output monitoring item IDs associated with the request event through key-value matching, which serves as a candidate set of output monitoring items.

[0060] When determining the target output monitoring item from the candidate output monitoring items, a multi-level condition matching strategy can be adopted: First, the reward information corresponding to all rewards in the request event is parsed from reward_info. Then, the set of candidate output monitoring items is initially screened according to the reward type and reward identifier in the reward information to exclude output monitoring items whose reward content does not match. Subsequently, the request subject identifier is combined with the subject type configured for each candidate output monitoring item (such as individual player, legion or server) to filter out candidate output monitoring items with the same subject dimension, thereby determining the corresponding target output monitoring item for each reward in the current reward output request.

[0061] Understandably, since the same event in the game may trigger the distribution of multiple types of rewards (such as distributing multiple different items at the same time, or a combination of items and currency points), and each type of reward may be subject to independent production rules, it is necessary to perform production monitoring item matching and upper limit verification on each reward item included in the reward production request to ensure that each type of reward is distributed within its corresponding period quota, thereby achieving special monitoring and upper limit control of specific rewards or items.

[0062] As an example, after a player completes a dungeon challenge, a reward request is triggered. The system extracts the request event as "Dungeon Completion Reward," and the reward information includes the reward type as "Item," the reward identifier as a purple-quality weapon (type_id), the reward quantity as 1, and the request subject identifier as the player's personal account ID. Subsequently, the system queries the mapping table to determine the candidate output monitoring items associated with the "Dungeon Completion Reward" request event, including: personal dungeon item monitoring items, guild dungeon contribution monitoring items, and server dungeon honor monitoring items. Next, the system performs a first-level filter based on the reward type "Item" and the reward identifier (type_id), excluding guild dungeon contribution monitoring items (corresponding to currency points) and server dungeon honor monitoring items (corresponding to honor points) whose reward content does not match. Then, combining the request subject identifier (personal account ID) with the subject type of each candidate output monitoring item, the system finally determines the personal dungeon item monitoring item with the subject type "individual player" as the target output monitoring item for this reward request.

[0063] This embodiment achieves structured identification of the request context by extracting the request event, reward information, and request subject identifier from the reward output request. Through a pre-configured mapping relationship between request events and output monitoring items, it quickly locates candidate output monitoring items corresponding to the request event. Based on reward information (including reward type and reward identifier) ​​and the request subject identifier, it performs multi-dimensional condition matching to accurately filter out the target output monitoring items corresponding to each reward item. This embodiment supports binding independent output monitoring rules to each reward when the reward output request contains multiple reward items, ensuring that each type of reward is distributed within its corresponding periodic quota. This achieves independent upper limit control of output behavior under different reward types, different subjects, and different scenarios without relying on global economic indicators.

[0064] Based on the above embodiments of this application, in the third embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 In the method for controlling the upper limit of reward output, step S20 includes steps S210 to S220: Step S210: Determine the current logical cycle corresponding to the target output monitoring item based on the cycle configuration of the target output monitoring item. The cycle configuration includes cycle type and reset cycle.

[0065] Step S220: Based on the logical period, obtain the target output monitoring item's target output quantity within the logical period, and obtain the output upper limit configuration corresponding to the logical period.

[0066] It should be noted that the logical cycle is a reward control time interval defined by the cycle type and reset cycle in the cycle configuration. This time interval has clear start and end nodes, and the output data within the cycle will be automatically reset after the node is reached.

[0067] The system can pre-build a cycle calculation function based on cycle configuration. After receiving the cycle configuration information of the target output monitoring item, the system calls this cycle calculation function and inputs three core parameters: cycle type, reset cycle, and current system time. The system then uses time interval deduction to determine the specific start and end times of the current logical cycle. For cases where the reset cycle is greater than 1, the cycle calculation function will use the end time of the previous logical cycle as the starting point for calculation, ensuring the continuity and accuracy of the logical cycles.

[0068] When retrieving the target output quantity and output limit configuration, the system can perform a fast query based on the individual_data and integral_data containers built during initialization. Specifically, using the target output monitoring item identifier and the time parameter of the current logical period as conditions, the system retrieves all output records within the corresponding period in the corresponding data container and accumulates the reward quantities in the records to obtain the target output quantity. Subsequently, using the target output monitoring item identifier as an index, the system locates the output limit configuration corresponding to the target output monitoring item through the index-guided directory rls_index_dir to obtain the maximum number of rewards allowed to be issued within the current logical period.

[0069] Optionally, based on the reward information in the item production request, the target production monitoring item can be determined first, and then the corresponding production limit configuration can be obtained by using the target production monitoring item identifier as an index.

[0070] Furthermore, based on the monitoring subject corresponding to the target output monitoring item, if the subject type of the target output monitoring item is an individual type (such as player, legion), then the corresponding target output quantity is queried from the individual data container individual_data based on the request subject identifier individual_id; if the subject type of the target output monitoring item is an integral type (such as server, gameplay), then the corresponding target output quantity is queried from the integral data container integral_data based on the request subject identifier individual_id. This process achieves efficient access through an index structure, avoids full table scans, and ensures response performance in high-concurrency scenarios.

[0071] This embodiment determines the current logical cycle based on the cycle configuration of the target output monitoring item, and obtains the output quantity and corresponding output limit configuration of the target output monitoring item within the current cycle based on this logical cycle, thereby achieving precise upper limit control of reward output requests. Specifically, the system uses a cycle calculation function, combined with cycle type, reset cycle, and current system time, to dynamically calculate the start and end times of the logical cycle, ensuring the accuracy and continuity of cycle definition. Simultaneously, through an efficient query mechanism between personal data containers and the overall data container, it quickly locates and accumulates the actual output quantity within a specific logical cycle, and combines this with the output limit configuration to perform upper limit verification, preventing reward distribution from exceeding the set limit. This embodiment not only supports flexible configuration of non-natural cycles (such as every 3 days, weekly, etc.), but also maintains efficient response in high-concurrency scenarios, effectively improving the accuracy and reliability of reward output control.

[0072] Based on the above embodiments of this application, in the fourth embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 4 In the method for controlling the upper limit of reward output, step S20 includes steps S230 to S270: Step S230: Determine whether the target output monitoring item is configured with an inheritance relationship.

[0073] It should be noted that the inheritance relationship is a preset statistical association rule between the target output monitoring item and other output monitoring items, which is used to realize the cumulative calculation of output data between different output monitoring items.

[0074] Step S240: If an inheritance relationship is configured, determine the corresponding inheritance source monitoring item based on the inheritance relationship.

[0075] It should be noted that the inherited source monitoring item is the upstream output monitoring item whose data is inherited by the target output monitoring item, and its output data can be combined and used by the sub-output monitoring items when the conditions are met.

[0076] Step S250: If the inherited source monitoring item and the target output monitoring item have the same subject type and correspond to the same logical cycle, then obtain the output quantity of the inherited source monitoring item within the logical cycle.

[0077] Step S260: The output quantity of the inherited source monitoring item is added to the output quantity of the target output monitoring item itself, and the result is the target output quantity of the target output monitoring item in the current period.

[0078] Step S270: If no inheritance relationship is configured, or the inherited source monitoring item and the target output monitoring item do not have the same subject type or do not correspond to the same logical cycle, then the output quantity of the target output monitoring item itself shall be used as the target output quantity of the target output monitoring item in the current cycle.

[0079] In this embodiment, when the system loads the reward_limit_cfg.csv configuration file during the initialization phase, an inheritance relationship configuration field can be set for each output monitoring item in the reward_limit_cfg.csv configuration file. This field stores the identification information of the inherited source monitoring item. When the inheritance relationship configuration field of an output monitoring item contains an inherited source monitoring item identifier, the mapping relationship between the output monitoring item and its corresponding inherited source monitoring item is recorded, and a monitoring item inheritance index rls_inherit_index is constructed to support fast lookup.

[0080] When determining whether a target output monitoring item has an inheritance relationship configured, the system directly reads the value of the inheritance relationship configuration field through the target output monitoring item identifier. If the field is not empty, it can be determined that the target output monitoring item has an inheritance relationship.

[0081] After determining the inherited source monitoring item corresponding to the target output monitoring item, the system can quickly locate the configuration information and data storage location of the inherited source monitoring item through the pre-built monitoring item inheritance index rls_inherit_index. Then, it verifies whether the main types of the inherited source monitoring item and the target output monitoring item are consistent, and simultaneously calls the period calculation function to determine the current logical period of both, judging whether they are in the same time interval. Only if both verifications pass will the subsequent accumulation operation of the produced quantity be performed.

[0082] During the accumulation of the output quantities corresponding to the source monitoring items and the target output monitoring items, the system can adopt a transaction processing mechanism to ensure that the reading of the output quantities corresponding to the source monitoring items and the calculation of the final target output quantities corresponding to the target output monitoring items are executed synchronously, thus avoiding statistical errors caused by asynchronous data updates.

[0083] As an example, a holiday event dungeon reward monitoring item A is configured with an inheritance relationship, pointing to a daily dungeon reward monitoring item B. When a player triggers a holiday event dungeon reward request, the system matches monitoring item A and finds that it inherits from monitoring item B. If the subject type of both monitoring item A and monitoring item B is "individual player," and their current logical cycles are consistent (e.g., both are "daily" cycles, and the reset cycle is 1 day), then the system adds the quantity of item C already distributed by monitoring item B within that logical cycle to the quantity of item C already distributed by monitoring item A itself, as the total quantity produced by monitoring item A, and participates in the corresponding reward limit verification. This means that the holiday event dungeon and the daily dungeon share the same daily quota for item (item C), preventing players from obtaining item C in excess through multiple event entry points.

[0084] This embodiment introduces inheritance relationship configuration into output monitoring items, enabling a target output monitoring item to include the output quantity of its inherited source monitoring items within its own counting range, provided that the subject type is the same and the logical cycle is the same. This mechanism, based on independent output monitoring items defined by dimensions such as subject, scenario, cycle, and reward, achieves quota sharing and count aggregation across scenarios or events. When multiple output monitoring items correspond to the same type of reward, the same subject, and have aligned cycles, there is no need to repeatedly set upper limit rules, and the risk of exceeding the limit for a certain reward due to multiple activity entry points issuing the same reward is avoided. Simultaneously, the inheritance relationship is recorded in the configuration, making the source path of output data clear and traceable. Therefore, while maintaining the independence of each output monitoring item configuration, the system significantly improves rule reuse capabilities and the consistency of economic regulation, effectively supporting independent and consistent upper limit output control for specific rewards in scenarios such as complex activity overlap or function iteration.

[0085] Based on the above embodiments of this application, in the fifth embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 5 In the method for controlling the upper limit of reward output, step S30 includes steps S310 to S330: Step S310: Obtain the number of rewards requested in the reward output request.

[0086] Step S320: Based on the output limit configuration and the target output quantity, determine the remaining distributable amount of the reward information in the current period.

[0087] Step S330: Determine the actual allowable amount to be distributed based on the reward amount and the remaining distributable amount.

[0088] It should be noted that the remaining disbursable amount refers to the upper limit of the number of rewards that can still be disbursed within the current logical cycle of the target output monitoring item after deducting the quantity already produced. Its value is determined by the difference between the output upper limit configuration and the target quantity already produced. The actual allowed disbursement quantity refers to the number of rewards that the system ultimately determines can be disbursed to the corresponding entity of the reward output request. It is the decision-making basis for balancing the request disbursement demand and the control upper limit.

[0089] When the system obtains the number of rewards requested, it directly extracts the value of the corresponding field from the reward information reward_info and performs a valid value check simultaneously. The check includes determining whether the reward number is a non-negative integer and whether it exceeds the maximum allowed threshold for a single reward request, in order to prevent invalid or malicious input from interfering with subsequent calculation logic.

[0090] The system then reads the output cap configuration of the corresponding reward bound to the target output monitoring item, and, combined with the target output monitoring item's already produced quantity in the current period, calculates the remaining distributable amount of the corresponding reward through difference calculation. To ensure the reasonableness of the value, the system also adds a lower limit constraint logic; if the calculation result is less than zero, the remaining distributable amount is automatically set to zero, ensuring the reasonableness of the amount value.

[0091] When determining the actual allowable amount to be distributed, the system adopts a numerical comparison strategy, comparing the requested amount of reward with the remaining amount that can be distributed, and taking the smaller value as the actual allowable amount to be distributed; if the remaining amount that can be distributed for a certain reward is zero, then no matter how much the requested amount of reward is, the actual allowable amount to be distributed is determined to be zero.

[0092] As an example, if the production cap of item C in a certain target output monitoring item is configured to be 20, and the target output quantity of item C in the current period is 18, then the remaining distributable amount of item C is 2; if the reward output request requests the distribution of the reward quantity of item C as 3, then the actual allowed distribution quantity of item C is 1; if the requested reward quantity of item C is 1, then 1 is directly used as the actual allowed distribution quantity of item C; if the target output quantity of item C has reached 20, and its remaining distributable amount is zero, then the actual allowed distribution quantity of item C is zero.

[0093] This embodiment extracts the requested reward quantity from reward production requests, combines the production cap configuration with the target already produced quantity, dynamically calculates the remaining distributable amount of the corresponding rewards, and determines the actual allowed distribution quantity based on the minimum of the remaining distributable amount and the reward quantity. This achieves real-time and precise cap control over reward distribution. This mechanism effectively avoids over-limit distribution problems caused by concurrent requests, repeated triggers, or configuration deviations. While ensuring player experience, it ensures that the quota rules of the game's economic system are strictly enforced, improving the reliability of reward production control.

[0094] Based on the above embodiments of this application, in the sixth embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 6 After step S40, the method for controlling the upper limit of reward output includes steps S41 to S42: Step S41: Determine whether the updated target output quantity has reached the output limit configuration.

[0095] Step S42: If the target output quantity has reached the output limit configuration, an upper limit trigger warning is generated, and the distribution of the reward information is not intercepted due to the generation of the upper limit trigger warning.

[0096] It should be noted that the updated target output quantity refers to the cumulative output quantity of the target output monitoring item within the current logical cycle, which is updated synchronously by the system after the reward distribution for this reward output request is completed; the upper limit trigger warning refers to the warning message generated by the system when the cumulative output quantity reaches the preset upper limit, which is used to indicate that the control threshold has been triggered. Its purpose is to inform the operations staff that the periodic quota of the relevant reward has been exhausted, rather than to intercept the reward distribution process that has passed the verification.

[0097] In this embodiment, after the reward distribution and data update are completed, the updated target output quantity and the corresponding output limit configuration are directly retrieved and compared. If the updated target output quantity is greater than or equal to the output limit configuration, it is determined that the limit threshold has been reached, and an upper limit trigger warning is issued.

[0098] When an upper limit is generated and an alert is triggered, the system can use a structured alert message format. The message content includes key information such as the target output monitoring item identifier, the corresponding reward type, the reward identifier, the current logical cycle, the output upper limit configuration, and the updated output quantity, which makes it easy for operators to quickly locate the source of the alert.

[0099] Meanwhile, the system can push the upper limit trigger warning to the preset management backend and log storage module, which not only ensures that the operators can perceive the warning in time, but also realizes the retention and archiving of the warning data, which is convenient for subsequent review and analysis.

[0100] To ensure that reward distribution is not intercepted, the system will remove the interception control instructions from the warning generation logic, retaining only the information push and log recording functions, thus completely decoupling the warning behavior from the reward distribution process.

[0101] This embodiment adds a limit-triggered early warning mechanism after reward distribution, enabling real-time awareness of reward period quota exhaustion. This helps operations personnel promptly grasp the reward management status and provides timely and accurate trigger signals for subsequent operational decisions such as activity adjustments and quota optimization. Simultaneously, by decoupling early warning generation from the reward distribution process, it ensures that reward distribution that has passed the limit verification is unaffected, avoiding interruptions to normal reward distribution due to the early warning mechanism. This ensures both the timeliness of reward limit management and the player's reward acquisition experience.

[0102] Based on the above embodiments of this application, in the seventh embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 7 After step S40, the method for controlling the upper limit of reward output includes steps S43 to S45: Step S43: Record the distribution details corresponding to the reward output request. The distribution details include the request initiation time, request subject identifier, target output monitoring item identifier, reward type, reward identifier and reward quantity requested, and the actual allowed distribution quantity.

[0103] Step S44: Summarize and statistically analyze the distribution details based on the logical cycle corresponding to the target output monitoring item.

[0104] Step S45: Generate a periodic output report based on the summarized statistical results.

[0105] It should be noted that the distribution details data refers to the complete process log generated from the initiation of each reward output request to the completion of the reward distribution operation, which is used to trace the context information of the specific distribution behavior; the summary statistics refers to the process of aggregating and calculating the distribution details data belonging to the same target output monitoring item or the same reward identifier within the same period according to the time dimension of the logical cycle; the periodic output report is a document that presents the summary statistics results in a visual and structured form, which is used to intuitively show the output status of each reward within the corresponding period.

[0106] After completing the actual reward distribution and count update, the system synchronously generates a distribution detail record to record the distribution details. When recording the distribution details, a preset structured data template can be used to encapsulate various types of information, including the request initiation time, request subject identifier, target output monitoring item identifier, requested reward type, reward identifier and reward quantity, as well as the actual allowed distribution quantity, to ensure the consistency of data format.

[0107] When summarizing and statistically analyzing the distribution details, the system can build a dual aggregation index based on the target output monitoring item identifier and the logical cycle identifier. Through batch processing tasks, the distribution details under the same index can be aggregated in batches according to the logical cycle. The statistical dimensions may include the total number of requests, the total number of distributions, the average number of distributions per transaction, and the distribution distribution of different request subjects for each output monitoring item in the current logical cycle.

[0108] When generating periodic output reports, the system can call the report generation engine to present the summarized statistical results in various formats such as tables, line charts, and bar charts. The report content is automatically associated with the corresponding output ceiling configuration, intuitively displaying the difference between the actual output and the output ceiling. At the same time, reports can be automatically generated at different periodic granularities such as daily, weekly, and monthly, and pushed to the operations management backend, supporting operations personnel to export and retrieve historical reports as needed.

[0109] This embodiment constructs a complete mechanism for tracing and analyzing reward distribution by recording distribution details, summarizing data according to logical cycles, and generating periodic output reports. Distribution details allow for tracing the context of each reward distribution, facilitating problem troubleshooting; periodic statistics and reports help operators intuitively grasp the quota usage and output trends of various rewards, providing data support for configuration optimization and activity adjustments. It also improves the system's maintainability and continuous optimization capabilities, contributing to the long-term stable operation of the game's economic system.

[0110] Based on the above embodiments of this application, in the eighth embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 8 The reward output cap control method further includes steps S50~S70: Step S50: Traverse the preset period types.

[0111] Step S60: For each cycle type, obtain the current logical cycle of the cycle type and determine whether the current time exceeds the preset valid time range of the current logical cycle.

[0112] Step S70: If the current time exceeds the preset valid time range, mark the current logical cycle as an expired logical cycle, reset the target output quantity recorded in the expired logical cycle for all output monitoring items associated with the cycle type, and reset the logical cycle corresponding to the cycle type.

[0113] It should be noted that the preset cycle type refers to the various reward control time cycles configured during the system initialization phase, including daily, weekly, monthly, and yearly cycles; the preset valid time range refers to the valid duration interval pre-set for each logical cycle, with its start and end nodes consistent with the time range of the logical cycle, used to determine whether the logical cycle is in a valid state; the expired logical cycle refers to a logical cycle whose current time has exceeded its preset valid time range, and the output data statistics task within this cycle has been completed; cycle reset refers to switching the expired logical cycle to a new logical cycle and clearing the historical output data within the expired logical cycle to ensure the accuracy of the output quantity statistics for each reward in the subsequent new logical cycle.

[0114] The system can employ a timed task scheduling mechanism to periodically trigger cycle type traversal operations, ensuring that no cycle validity checks are missed. During the traversal, the system reads all preset cycle types from the memory configuration; for each cycle type, it calls the cycle calculation function to obtain its current logical cycle and corresponding preset valid time range; then, it compares the current system time with the end node of the valid time range to complete the validity judgment.

[0115] When a logical cycle is determined to have expired, the system first constructs query conditions based on the cycle type identifier, filters out all output monitoring items associated with that cycle type, and then, through a transaction batch processing mechanism, synchronously resets the target output quantity of these output monitoring items within the expired logical cycle to zero. At the same time, the cycle reset function is called to calculate and update the new logical cycle corresponding to that cycle type, starting from the end time of the expired logical cycle. The entire reset process generates operation logs and persists them for easy traceability in subsequent operations and maintenance.

[0116] This embodiment iterates through preset cycle types and dynamically verifies the validity of their logical cycles. When it detects that the current time exceeds the valid range of the cycle, it automatically resets the output quantity of the relevant output monitoring items and resets the timestamp of the cycle. This avoids output data counting errors or cross-cycle output data mixing caused by untimely cycle updates, ensuring that output data statistics within each logical cycle are independent. Through timed cycle inspections and transactional batch reset operations, the system can complete cycle switching during normal operation, reducing reliance on manual maintenance and improving the accuracy and consistency of reward output control in the time dimension.

[0117] This application provides a reward output cap control device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the reward output cap control method in the above embodiment.

[0118] The following is for reference. Figure 9 The diagram illustrates a structural schematic suitable for implementing a reward output cap control device in the embodiments of this application. The reward output cap control device in the embodiments of this application may include various hardware and software components for implementing the reward output cap control method. Figure 9 The illustrated reward output cap control device is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0119] like Figure 9 As shown, the reward output cap control device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the reward output cap control device. The processing unit 1001, the ROM 1002, and the RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, a touchpad, a keyboard, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 1003 including, for example, magnetic tape, a hard disk, etc.; and communication devices 1009. Communication device 1009 allows the reward output cap control device to communicate wirelessly or wiredly with other devices to exchange data. While the figures show reward output cap control devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0120] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0121] The reward output cap control device provided in this application, employing the reward output cap control method in the above embodiments, can solve the technical problem that the reward output regulation mechanism cannot independently and timely control the caps of various reward outputs. Compared with the prior art, the beneficial effects of the reward output cap control device provided in this application are the same as those of the reward output cap control method provided in the above embodiments, and other technical features in this reward output cap control device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0122] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0123] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0124] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the reward output cap control method in the above embodiments.

[0125] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0126] The aforementioned computer-readable storage medium may be included in the reward output cap control device; or it may exist independently and not be assembled into the reward output cap control device.

[0127] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the reward output cap control device, the reward output cap control device: in response to a reward output request, determines a target output monitoring item corresponding to the reward output request, the target output monitoring item including subject type, scene identifier, period configuration, and reward information; obtains the target output quantity of the target output monitoring item in the current period and the corresponding output cap configuration; determines the actual allowed distribution quantity of the reward information in the reward output request based on the target output quantity and the output cap configuration; executes the distribution of reward information based on the actual allowed distribution quantity, and updates the target output quantity of the target output monitoring item in the current period.

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

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

[0130] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0131] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described reward output cap control method. This solves the technical problem that reward output control mechanisms cannot independently and timely manage the caps of various reward outputs. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the reward output cap control method provided in the above embodiments, and will not be elaborated upon here.

[0132] This application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the reward output cap control method described above.

[0133] The computer program product provided in this application can solve the technical problem that the reward output control mechanism cannot independently and timely control the upper limit of various reward outputs. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the reward output upper limit control method provided in the above embodiments, and will not be repeated here.

[0134] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent scope of this application.

[0135] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system 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 system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0136] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0137] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for controlling the upper limit of reward output, characterized in that, The method for controlling the upper limit of reward output includes: In response to a reward output request, a target output monitoring item corresponding to the reward output request is determined. The target output monitoring item includes subject type, scene identifier, period configuration, and reward information. Obtain the target output monitoring item's target output quantity and corresponding output limit configuration within the current period; Based on the target output quantity and the output limit configuration, determine the actual allowable quantity of the reward information in the reward output request; Rewards will be distributed based on the actual allowed amount, and the target output monitoring item will be updated to reflect the target output quantity in the current period.

2. The reward output cap control method as described in claim 1, characterized in that, The step of determining the target output monitoring item corresponding to the reward output request in response to the reward output request includes: In response to the reward output request, obtain the request event, the reward information, and the request subject identifier carried by the reward output request; Based on the pre-configured mapping relationship, determine at least one candidate output monitoring item associated with the request event; Based on the reward information and the request subject identifier, the target output monitoring item is determined from the candidate output monitoring items.

3. The reward output cap control method as described in claim 1, characterized in that, The steps for obtaining the target output monitoring item's target output quantity and corresponding output limit configuration in the current period include: Based on the cycle configuration of the target output monitoring item, the current logical cycle corresponding to the target output monitoring item is determined, and the cycle configuration includes cycle type and reset cycle; Based on the logical cycle, obtain the target output monitoring item's target output quantity within the logical cycle, and obtain the output upper limit configuration corresponding to the logical cycle.

4. The reward output cap control method as described in claim 1, characterized in that, The steps for obtaining the target output monitoring item's target output quantity and corresponding output limit configuration in the current period include: Determine whether the target output monitoring item has an inheritance relationship; If an inheritance relationship is configured, the corresponding inheritance source monitoring item is determined based on the inheritance relationship; If the inherited source monitoring item and the target output monitoring item have the same subject type and correspond to the same logical cycle, then obtain the output quantity of the inherited source monitoring item within the logical cycle; The quantity produced by the inherited source monitoring item is added to the quantity produced by the target output monitoring item itself, and this is taken as the target quantity produced by the target output monitoring item in the current period. If no inheritance relationship is configured, or if the inherited source monitoring item and the target output monitoring item do not have the same subject type or do not correspond to the same logical period, then the output quantity of the target output monitoring item itself will be used as the target output quantity of the target output monitoring item in the current period.

5. The reward output cap control method as described in claim 1, characterized in that, The step of determining the actual allowable quantity of reward information in the reward production request based on the target already produced quantity and the production limit configuration includes: Obtain the number of rewards requested in the reward output request; Based on the output limit configuration and the target output quantity, determine the remaining distributable amount of the reward information in the current period; The actual allowable amount to be distributed is determined based on the number of rewards and the remaining distributable amount.

6. The reward output cap control method as described in claim 1, characterized in that, After the steps of distributing reward information according to the actual allowed distribution quantity and updating the target output monitoring item's target output quantity in the current period, the method further includes: Determine whether the updated target output quantity has reached the output limit configuration; If the target output quantity reaches the output limit configuration, an upper limit trigger warning is generated, and the distribution of the reward information is not intercepted due to the generation of the upper limit trigger warning.

7. The reward output cap control method as described in claim 1, characterized in that, The method for controlling the upper limit of reward output also includes: Iterate through the preset period types; For each cycle type, obtain the current logical cycle of the cycle type and determine whether the current time exceeds the preset valid time range of the current logical cycle; If the current time exceeds the preset valid time range, the current logical cycle is marked as an expired logical cycle, and the target output quantity recorded in all output monitoring items associated with the cycle type within the expired logical cycle is reset. At the same time, the logical cycle corresponding to the cycle type is also reset.

8. The reward output cap control method as described in claim 1, characterized in that, After the steps of distributing reward information according to the actual allowed distribution quantity and updating the target output monitoring item's target output quantity in the current period, the method further includes: Record the distribution details corresponding to the reward output request. The distribution details include the request initiation time, request subject identifier, target output monitoring item identifier, type of reward requested, reward identifier and reward quantity, as well as the actual allowed distribution quantity. Based on the logical cycle corresponding to the target output monitoring item, the distribution details data are summarized and statistically analyzed; Based on the summarized statistical results, a periodic output report is generated.

9. A reward output cap control device, characterized in that, The reward output cap control device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the reward output cap control method as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the reward output cap control method as described in any one of claims 1 to 8.