Method and device for verifying combat in game

Abstract

The embodiment of the invention provides a battle verification method and device in a game, and the method comprises the steps: receiving a verification request for battle data of a player when it is detected that the load of a battle verification server reaches a preset threshold value or a time-limited activity starts, the player having a corresponding identification code; under the condition that it is judged that the identification code of the player is in the first risk pool, verification processing is conducted on the battle data immediately, and a first verification result is obtained; under the condition that the identification code of the player is judged to be in the second risk pool, after the load of the combat verification server is smaller than a preset threshold value or the time-limited activity is finished, verifying the combat data to obtain a second verification result. According to the method, high-risk and low-risk distinguishing is carried out on players, and the combat data of the low-risk players is subjected to delayed verification, so that the verification consumption of a large part of activity periods is delayed to a low-load period after the activities are finished, and the highest load of a server is reduced.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of Internet technology, and in particular to a method, apparatus, computer equipment, computer-readable storage medium, and computer program product for verifying combat in a game. Background Art

[0002] Game systems usually have a function to verify in-game combat data. By strictly checking combat data such as skill damage, combat settlement, and attribute bonuses, it can not only prevent plug-in tampering or client cheating from disrupting the balance, but also avoid player loss due to numerical anomalies or logical loopholes.

[0003] To enhance player engagement and extend the game's lifecycle, the game offers numerous limited-time events. These feature gameplay is released on a recurring basis (e.g., weekly, holiday, or seasonal basis), leveraging the buzz of these events to stimulate consumption and foster social interaction. The verification process for battle report collections for these limited-time events is also time-limited and typically processed during the event's duration. This results in a low service load during other times. However, to ensure the ability to process battle report data during the event, full server costs must be incurred, resulting in high system operation and maintenance costs.

[0004] It should be noted that the above content is not necessarily prior art, nor is it intended to limit the scope of patent protection of this application. Summary of the Invention

[0005] The embodiments of the present application provide a method, apparatus, computer device, computer-readable storage medium, and computer program product for verifying combat in a game to solve or alleviate one or more of the technical problems raised above.

[0006] One aspect of an embodiment of the present application provides a combat verification method in a game, the method comprising: receiving a verification request for combat data of a player having a corresponding identification code upon detecting that a load of the combat verification server reaches a preset threshold or a time-limited event begins; If it is determined that the player's identification code is in the first risk pool, immediately verifying the battle data to obtain a first verification result; If it is determined that the player's identification code is in the second risk pool, waiting for the load of the battle verification server to be less than a preset threshold or the time-limited activity to end, and then verifying the battle data to obtain a second verification result; The risk level of the players in the first risk pool is higher than the risk level of the players in the second risk pool.

[0007] Optionally, immediately performing verification processing on the combat data to obtain a first verification result includes: adding said combat data to an immediate verification list; The combat data in the immediate verification list is immediately verified to obtain a first verification result.

[0008] Optionally, the method further includes: In the case where the first verification result indicates that the player has cheated, the player is marked as a cheating player.

[0009] Optionally, the method further includes: After all combat data in the immediate verification list is processed, the cheating player is banned.

[0010] Optionally, after waiting for the load of the battle verification server to be less than a preset threshold or the time-limited activity to end, performing verification processing on the battle data to obtain a second verification result includes: Obtaining a basic verification ratio corresponding to the player, and determining basic verification data from the combat data according to the basic verification ratio; Add all remaining combat data except the basic verification data to the delayed verification list; After waiting for the load of the battle verification server to be less than a preset threshold or the time-limited activity to end, the battle data in the delayed verification list is verified to obtain a second verification result.

[0011] Optionally, the method further includes: Adding the basic verification data to the immediate verification list; The basic verification data in the immediate verification list is immediately verified to obtain a third verification result.

[0012] Optionally, obtaining the basic verification ratio corresponding to the player includes: Obtaining risk behavior data corresponding to the player; A basic verification ratio corresponding to the player is determined according to the risk behavior data.

[0013] Optionally, the method further includes: If the second verification result indicates that the player has cheated, the identification code of the player is added to a second risk pool.

[0014] Optionally, the battle data has a corresponding battle ID. After the step of receiving a verification request for the player's battle data, the method further includes: Determining the risk level corresponding to the player according to the battle ID; According to the risk level corresponding to the player, a target risk pool adapted to the player is determined from the first risk pool and the second risk pool.

[0015] Optionally, after the step of receiving a verification request for the player's combat data, the method further comprises: Obtaining personal information corresponding to the player; the personal information includes registration time and active time data; Determining a risk level corresponding to the player based on the personal information; According to the risk level corresponding to the player, a target risk pool adapted to the player is determined from the first risk pool and the second risk pool.

[0016] Another aspect of an embodiment of the present application provides a combat verification device in a game, the device comprising: a request receiving module for receiving a verification request for combat data of a player having a corresponding identification code when detecting that the load of the combat verification server reaches a preset threshold or a time-limited activity begins; an immediate verification module, configured to immediately verify the combat data to obtain a first verification result if it is determined that the player's identification code is in the first risk pool; a delayed verification module, configured to, upon determining that the player's identification code is in the second risk pool, wait for the load of the battle verification server to be less than a preset threshold or for the time-limited activity to end, and then verify the battle data to obtain a second verification result; The risk level of the players in the first risk pool is higher than the risk level of the players in the second risk pool.

[0017] Another aspect of an embodiment of the present application provides a computer device, including: at least one processor; and a memory communicatively coupled to the at least one processor; Wherein: the memory stores instructions that can be executed 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 battle verification method in the game as described above.

[0018] Another aspect of an embodiment of the present application provides a computer-readable storage medium having computer instructions stored therein. When the computer instructions are executed by a processor, the combat verification method in the game as described above is implemented.

[0019] Another aspect of an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the battle verification method in the game as described above.

[0020] The embodiments of the present application adopt the above-mentioned technical solution, which may include the following advantages: by distinguishing between high-risk and low-risk players and proposing a delayed verification function, the combat data of high-risk players will be verified immediately, which can ensure the accuracy of cheating data verification during limited-time activities; and for the combat data of low-risk players, the delayed verification function is utilized, so that a large part of the verification consumption during the server overload period or the activity period can be postponed to the low-load period after the activity ends, thereby reducing the maximum load of the server and reducing the operation and maintenance costs of the combat verification system. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The accompanying drawings illustrate exemplary embodiments and constitute a part of the specification. Together with the description of the specification, they serve to explain exemplary implementation of the embodiments. The illustrated embodiments are for illustrative purposes only and do not limit the scope of the claims. Throughout the drawings, the same reference numerals designate similar, but not necessarily identical, elements.

[0022] Figure 1 A diagram schematically illustrates an operating environment of a battle verification method in a game according to the first embodiment of the present application; Figure 2 Schematically shows a flow chart of a battle verification method in a game according to the first embodiment of the present application; Figure 3 A block diagram schematically illustrates a battle verification device in a game according to the second embodiment of the present application; and Figure 4 The following schematically shows a hardware architecture diagram of a computer device according to the third embodiment of the present application. DETAILED DESCRIPTION

[0023] In order to make the purpose, technical solutions and advantages of this application more clear, the present application is further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0024] It should be noted that the descriptions of "first", "second", etc. in the embodiments of the present application are for descriptive purposes only and should not be understood as indicating or implying their relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" or "second" may explicitly or implicitly include at least one of such features. In addition, the technical solutions between the various embodiments can be combined with each other, but this must be based on the fact that they can be implemented by ordinary technicians in this field. When the combination of technical solutions is contradictory or cannot be implemented, it should be deemed that such a combination of technical solutions does not exist and is not within the scope of protection required by this application.

[0025] It should be noted that in all aspects of this application involving data collection, storage, use, transmission, and processing, all data must strictly adhere to the laws, regulations, industry standards, and regulatory requirements of the data's source and use locations, as well as the relevant countries and regions, to ensure the legality and compliance of data activities. During the collection phase, the purpose, method, and scope of collection will be clearly stated to the data subject in a conspicuous manner. Collection will be carried out only after obtaining the data subject's legal authorization, ensuring that the collection process adheres to the "minimum necessary" principle and does not exceed the scope of data collection. During storage, the storage period will be limited, and after the storage purpose has been achieved, data will be promptly deleted, anonymized, or encrypted. During the use phase, strict data security protection mechanisms will be implemented, using field-level desensitization technology to process raw data according to pre-set desensitization rules. A variety of desensitization strategies, such as data generalization, data anonymization, and data encryption, will be employed for different data types to effectively mitigate the risk of sensitive information leakage and ensure that the data ultimately used is securely desensitized data, fully protecting the rights and interests of data subjects and data security. During the transmission and processing phases, the confidentiality and security of data will be ensured during transmission and processing.

[0026] In the description of this application, it should be understood that the numerical labels before the steps do not indicate the order in which the steps are executed. They are only used to facilitate the description of this application and to distinguish each step. Therefore, they cannot be understood as limitations on this application.

[0027] First, an explanation of the terms involved in this application is provided: Battle Verification Service: This service processes battle reports to determine whether a player is cheating.

[0028] Battle Report: A collection of information related to a player's battles in the game, including data such as the player's and opponent's roles, lineups, and operation records.

[0029] Event: A limited-time event in the game that will be open for a period of time, such as 5 days at the end of each month. During the event, a large amount of combat data and battle reports will be generated.

[0030] Secondly, to facilitate those skilled in the art to understand the technical solutions provided in the embodiments of the present application, the relevant technologies are described below: In-game combat data is a core collection of information used to measure the effectiveness of character, equipment, or system interactions. It covers basic attributes (such as attack damage, defense, and health), dynamic values ​​(such as critical hit rate, skill damage multiplier, and healing effects), behavioral records (such as number of attacks, kills, and damage taken), and environmental parameters (such as terrain bonuses and attribute restraint coefficients). This data, calculated and synchronized in real time to drive combat logic, determines the effectiveness of player strategies and influences game balance. It also provides developers with a quantitative basis for numerical optimization, anti-cheat monitoring, and content updates, ultimately forming the underlying foundation for player experience and system design.

[0031] Game systems usually have a function to verify in-game combat data. By strictly checking combat data such as skill damage, combat settlement, and attribute bonuses, it can not only prevent plug-in tampering or client cheating from disrupting the balance, but also avoid player loss due to numerical anomalies or logical loopholes.

[0032] To enhance player engagement and extend the game's lifecycle, the game offers numerous limited-time events. These feature gameplay, recurring on a fixed schedule (e.g., weekly, holiday, or seasonal), leverage the excitement of these events to stimulate consumption and foster social interaction. The verification process for battle report collections for these limited-time events is also periodic, typically performed during the event's duration. This results in a low service load during other times. However, to ensure the ability to process battle report data during the event, full server costs must still be covered.

[0033] To this end, an embodiment of the present application provides a technical solution for in-game combat verification. In this technical solution, upon detecting that the load of a combat verification server has reached a preset threshold or a limited-time event has begun, a verification request for combat data of a player with a corresponding identification code is received. If the player's identification code is determined to be in a first risk pool, the combat data is immediately verified to obtain a first verification result. If the player's identification code is determined to be in a second risk pool, the combat data is verified to obtain a second verification result after the load of the combat verification server has fallen below a preset threshold or the limited-time event has ended. The risk level of players in the first risk pool is higher than that of players in the second risk pool. By distinguishing between high- and low-risk players and providing a delayed verification function, the combat data of high-risk players is immediately verified, ensuring the accuracy of cheating data verification during the limited-time event. For combat data of low-risk players, the delayed verification function is utilized, allowing a large portion of verification time during the server overload period or during the event to be postponed to a low-load period after the event ends, reducing the server's peak load and, in turn, the operational and maintenance costs of the combat verification system. See below for details.

[0034] Finally, for ease of understanding, an exemplary operating environment is provided below.

[0035] like Figure 1 As shown, the environment diagram includes a service platform 2, a network 4, and a client 6, wherein: The service platform 2 can be comprised of a single or multiple computing devices. These multiple computing devices can include virtualized computing instances. Virtualized computing instances can include virtual machines, such as emulations of computer systems, operating systems, servers, and the like. A computing device can load a virtual machine based on a virtual image and / or other data defining the specific software (e.g., operating system, specialized application, server) used for the emulation. As demand for different types of processing services changes, different virtual machines can be loaded and / or terminated on one or more computing devices. A hypervisor can be implemented to manage the use of different virtual machines on the same computing device.

[0036] The service platform 2 can be configured to communicate with clients 6 and the like via a network 4. The network 4 includes various network devices, such as routers, switches, multiplexers, hubs, modems, bridges, repeaters, firewalls, proxy devices, and / or the like. The network 4 can include physical links, such as coaxial cable links, twisted pair cable links, fiber optic links, combinations thereof, or wireless links, such as cellular links, satellite links, Wi-Fi links, and the like.

[0037] Service platform 2 can provide storage, reading, writing, querying, deleting and other services, such as providing combat verification services in the game for the client.

[0038] Client 6 can be an electronic device running an operating system such as Windows, Android™, or iOS, such as a smartphone, tablet, laptop, virtual reality device, gaming device, set-top box, in-vehicle terminal, or smart TV. Based on these operating systems, various applications can be run, such as combat verification in games.

[0039] The client 6 may provide / configure a user access page for manipulating the service platform 2 or uploading objects, etc.

[0040] It should be noted that the above devices are exemplary, and the number and type of devices can be adjusted in different scenarios or according to different needs.

[0041] The following describes the technical solution of the present application through multiple embodiments, taking the service platform 2 as the execution body. It should be noted that these embodiments can be implemented in many different forms and should not be construed as being limited to the embodiments described here.

[0042] Example 1 Figure 2 The flowchart of the battle verification method in the game according to the first embodiment of the present application is schematically shown.

[0043] like Figure 2 As shown, the battle verification method in the game may include steps S202 to S206, wherein: Step S202, receiving a verification request for combat data of a player having a corresponding identification code when detecting that the load of the combat verification server reaches a preset threshold or a time-limited activity starts; In this embodiment, the battle verification server is responsible for verifying players' combat data to prevent players from cheating in battles. To reduce server load, the server's load data, including CPU load, memory load, and disk I / O load, is analyzed in real time. This data is digitally evaluated and scored, and the resulting load value is compared with a preset threshold to determine whether the server is overloaded. If the battle verification server load reaches a preset threshold or a time-limited event begins, a battle verification diversion mode is triggered to divert some combat data to a server where the server's load falls below the preset threshold or the time-limited event ends, for processing.

[0044] Specifically, after a player completes a regular battle in the game or a battle in a limited-time event, the client generates the player's battle data and automatically initiates a verification request for the battle data. This request explicitly includes the player's identification code, which serves as unique identification information for locating and retrieving the player's battle data within the system. This identification code allows the system to accurately distinguish between different players' battles, preventing data confusion or misjudgment.

[0045] In addition to the player identification code, the request may also include basic attributes (such as attack power, defense value, health value), dynamic values ​​​​(such as critical hit rate, skill damage multiplier, healing effect), behavior records (such as number of attacks, number of kills, damage taken) and environmental parameters (such as terrain gain, attribute restraint coefficient), etc. This information is used by the server to perform detailed combat data verification to prevent plug-ins from tampering with data or client-side cheating to disrupt the balance.

[0046] Step S204: if it is determined that the player's identification code is in the first risk pool, immediately verify the battle data to obtain a first verification result; The first risk pool is a pre-defined system collection used to identify high-risk players. This identification is based on, but is not limited to, personal information such as their battle ID, registration time, and active time; historical behavior data such as cheat usage and unusual trading activity; and real-time monitoring of unusual behavior, such as short-term data fluctuations and associations with known risky accounts.

[0047] In this embodiment, the system compares the player's identification code with records in the first risk pool to determine whether the current player belongs to a high-risk group. If the player's identification code is determined to be in the first risk pool, the system immediately initiates the verification process. Specifically, the verification process includes but is not limited to: combat data integrity verification (e.g., to determine if the data packet has been tampered with); analysis of the rationality of combat behavior (e.g., whether the operational logic conforms to human behavior patterns); and compliance verification of combat results (e.g., whether they comply with the rules and restrictions of limited-time events).

[0048] After the verification process is complete, the system generates a first verification result. This result can be presented as a detailed report, including anomalies and recommended actions. It can also be presented in binary format, such as "1" indicating cheating and "0" indicating normal behavior. This first verification result will serve as a direct basis for subsequent actions (such as account penalties) and may be recorded in the player behavior log for retrospective analysis.

[0049] Step S206, when it is determined that the player's identification code is in the second risk pool, wait until the load of the battle verification server is less than a preset threshold or the time-limited activity ends, and then verify the battle data to obtain a second verification result; The risk level of the players in the first risk pool is higher than the risk level of the players in the second risk pool.

[0050] The second risk pool is a pre-defined system collection used to identify low-risk players. The system compares the player's ID with records in the second risk pool to determine whether the current player falls into this low-risk group. If a player's ID is determined to be in the second risk pool, a delayed verification process is applied. Verification of this battle data is then processed after the battle verification server load drops below a preset threshold or the limited-time event ends.

[0051] After the verification process is complete, the system generates a second verification result. This result can be presented as a detailed report, including anomalies and recommended actions. It can also be presented in binary format, such as "1" indicating cheating and "0" indicating normal behavior. This second verification result will serve as a direct basis for subsequent actions (such as account penalties) and may be recorded in the player's behavior log for retrospective analysis.

[0052] In this embodiment, in order to reduce the maximum load of the server and reduce the operation and maintenance costs of the battle verification server, players are divided into high-risk and low-risk players. The combat data of high-risk players is verified immediately, while the combat data of low-risk players is verified only after the load of the battle verification server is less than a preset threshold or the limited-time activity ends.

[0053] In an optional embodiment of the present application, the immediately performing verification processing on the combat data to obtain a first verification result includes: The combat data is added to an immediate verification list; and the combat data in the immediate verification list is immediately verified to obtain a first verification result.

[0054] The immediate verification list is a priority queue dynamically maintained in system memory, used to store combat data that requires prioritization. The data structure of the immediate verification list can include: a player identifier (unique key); a combat data summary (such as a hash value or key operation sequence); a data-added timestamp (for prioritization); and a verification status flag (initially "pending").

[0055] Once battle data is added to the immediate verification list, the verification process begins immediately, without waiting for other tasks to complete. The verification process takes precedence over regular data verification tasks, ensuring that battle data from high-risk players is processed first.

[0056] Specifically, the verification process may include: 1. Data integrity verification to confirm that the data has not been tampered with; 2. Combat behavior rationality analysis, such as assessing whether combat behavior conforms to human behavior patterns based on preset rules (such as operation interval thresholds and skill release logic), or using machine learning models (such as anomaly detection algorithms) to identify potential cheating; 3. Result compliance verification, such as verifying whether combat results comply with the rules and restrictions of limited-time events (such as reward acquisition conditions and ranking logic), or checking whether the data involves known vulnerability exploits (such as cheat feature matching). After the verification process is complete, the system generates a first verification result. This result can be presented in the form of a detailed report, including anomalies and remediation suggestions, or in binary format, with "1" indicating cheating and "0" indicating normal.

[0057] In an optional embodiment of the present application, the method further includes: In the case where the first verification result indicates that the player has cheated, the player is marked as a cheating player.

[0058] In this embodiment, if the first verification result clearly indicates that the player has cheated, the player is immediately marked as a cheating player and the subsequent risk management process is triggered.

[0059] Specifically, the first verification result is parsed and judged, which can be achieved in the following two ways: 1. Result format: The first verification result can be in binary form, such as "1" for cheating and "0" for normal; 2. Judgment logic: The system parses the verification result using preset rules or algorithms. For example, if the result contains a risk level, such as "riskLevel": 4, a threshold ≥ 3 is used to determine cheating; or directly match keywords (such as "result": "DETECTED_CHEAT").

[0060] If the first verification result indicates that the player has cheated, the player is marked as a cheater. Specifically, the player's identification code can be added to a cheating player collection, such as a Redis Set or database table. The marking may include the following information: marking timestamp, marking source, and the associated verification result ID (for retroactive auditing).

[0061] After marking a player as a cheater, the player's combat data can be marked as processed. Furthermore, if the first verification result indicates that the player did not cheat, the player's combat data can be directly marked as processed. Verification of the remaining combat data in the immediate verification list continues until all combat data in the immediate verification list is verified, ending the immediate verification process.

[0062] In an optional embodiment of the present application, the method further includes: After all combat data in the immediate verification list is processed, the cheating player is banned.

[0063] In this embodiment, after all battle data in the immediate verification list is processed, the system enters the risk management process after marking. Depending on the severity of the cheating, different bans of varying lengths may be imposed, such as a 7-day ban or a permanent ban. Furthermore, cheating players can be banned from receiving rewards from limited-time events or added to a long-term monitoring list to increase the frequency of subsequent behavior verification.

[0064] In an optional embodiment of the present application, after waiting for the load of the battle verification server to be less than a preset threshold or the time-limited activity to end, performing verification processing on the battle data to obtain a second verification result includes: Obtain a basic verification ratio corresponding to the player, and determine basic verification data from the combat data according to the basic verification ratio; add all combat data remaining except the basic verification data to a delayed verification list; wait until the load of the combat verification server is less than a preset threshold or the time-limited activity ends, and then verify the combat data in the delayed verification list to obtain a second verification result.

[0065] In this embodiment, all combat data for high-risk players is entered into an immediate verification pool, ensuring full verification for high-risk players. Low-risk players, on the other hand, will have a certain percentage of immediate verification, known as the base verification ratio. This base verification ratio divides the player's data into two parts: one portion enters the immediate verification pool, and the remaining portion enters the delayed verification pool. The base verification ratio is related to the player's historical behavior; players with a history of cheating will require a higher percentage of verification.

[0066] Specifically, if the player's identification code is determined to be in the second risk pool, the player's corresponding basic verification ratio is obtained, and basic verification data is selected from the battle data based on the basic verification ratio. This step can be performed by random sampling. Then, all battle data other than the basic verification data is added to a delayed verification list. For the battle data in the delayed verification list, the battle data in the delayed verification list can be verified to obtain a second verification result after the battle verification server load drops below a preset threshold or the limited-time event ends.

[0067] As an example, assuming the basic verification ratio is 20%, it means that 80% of the player's combat data will enter the delayed verification pool, and 20% of the combat data will enter the immediate verification pool. In this way, if a low-risk player cheats multiple times, there is still about a 20% probability of being verified immediately and subsequently banned.

[0068] In an optional embodiment of the present application, the method further includes: The basic verification data is added to the immediate verification list; and the basic verification data in the immediate verification list is immediately verified to obtain a third verification result.

[0069] In this embodiment, for low-risk players, the selected basic verification data will also be included in the immediate verification list. After the basic verification data is added to the immediate verification list, the verification process will be started immediately without waiting for other tasks to be completed.

[0070] Specifically, the verification process may include: 1. Data integrity verification to confirm that the data has not been tampered with; 2. Combat behavior rationality analysis, such as assessing whether combat behavior conforms to human behavior patterns based on preset rules (such as operation interval thresholds and skill release logic), or using machine learning models (such as anomaly detection algorithms) to identify potential cheating; 3. Result compliance verification, such as verifying whether combat results comply with the rules and restrictions of limited-time events (such as reward acquisition conditions and ranking logic), or checking whether the data involves known vulnerability exploits (such as cheat feature matching). After the verification process is complete, the system generates a third verification result. This result can be presented in the form of a detailed report, including anomalies and handling suggestions, or in binary format, such as "1" indicating cheating and "0" indicating normal.

[0071] In an optional embodiment of the present application, obtaining the basic verification ratio corresponding to the player includes: Obtain risk behavior data corresponding to the player; and determine a basic verification ratio corresponding to the player based on the risk behavior data.

[0072] Among them, risk behavior data can include: violation data in historical activities, other types of battle verification result data, the frequency of other players' complaint feedback, abnormal login data in the past period of time, or correlation data with known risk accounts (such as team formation, transaction object risk tags), etc.

[0073] In this embodiment, by collecting the player's historical and real-time risk behavior data and combining it with a preset risk assessment model, the basic verification ratio corresponding to the player is dynamically calculated and determined, which is used for subsequent sampling verification of combat data or full verification strategy adjustment.

[0074] Specifically, a preset risk assessment model predefines the scoring and calculation rules for each behavior. This preset risk assessment model can be a weighted scoring model or a machine learning model (such as Random Forest or XGBoost). After obtaining the player's corresponding risk behavior data, the preset risk assessment model is used to quantitatively evaluate the risk behavior data. The player's corresponding basic verification ratio is then calculated based on the assessed risk value.

[0075] In the specific implementation, low-risk players will have a preset ratio of baseline verification. For example, if the preset ratio is 20%, the calculation of the basic verification ratio of low-risk players can be based on the preset ratio, plus a ratio determined by the player's behavioral risk value. If the player's behavioral risk value is X and the basic verification ratio is (20+X)%, then (20+X)% of the player's battle reports will be immediately verified. If X reaches 80 or higher, all of these players will be immediately verified.

[0076] The game not only features battle verification during limited-time events, but also other types of regular battle verification. Players caught cheating in these battles will be screened out, with each cheating incident receiving a risk score of 20. Low-risk players, if confirmed to be cheating during delayed verification, will receive a record of suspected cheating for the event, with a risk score of 40. These records are used to determine a player's overall behavioral risk score, with higher behavioral risk scores leading to stricter verification.

[0077] In an optional embodiment of the present application, the method further includes: If the second verification result indicates that the player has cheated, the identification code of the player is added to a second risk pool.

[0078] In this embodiment, after verifying the combat data of a low-risk player, if the second verification result clearly indicates that the player has cheated, the identification code of the player is added to the second risk pool so that the combat data of the player can be verified according to high-risk specifications during the next activity.

[0079] After adding the player's identification code to the second risk pool, the player's battle data can be marked as processed. Furthermore, if the second verification result indicates that the player did not engage in cheating, the player's battle data can be directly marked as processed. Verification of the remaining battle data in the delayed verification list continues until all battle data in the delayed verification list has been verified, ending the delayed verification process.

[0080] In an optional embodiment of the present application, the battle data has a corresponding battle ID. After the step of receiving a verification request for the player's battle data, the method further includes: The risk level corresponding to the player is determined according to the battle ID; and a target risk pool adapted to the player is determined from the first risk pool and the second risk pool according to the risk level corresponding to the player.

[0081] The battle ID uniquely identifies a piece of battle data. The battle ID is calculated based on the number of battles each player has fought in the game. In other words, a larger battle ID indicates more battles a player has fought.

[0082] Analysis shows that new players, due to their shorter game time and lower account investment, are more motivated to cheat to gain benefits. Veteran players, on the other hand, have higher account investment and, to avoid being banned, have less motivation to cheat. The battle ID can be used to distinguish between regular players and veterans.

[0083] In this embodiment, the risk level corresponding to the player is determined based on the player's battle ID, and then the target risk pool adapted to the player is determined from the first risk pool and the second risk pool based on the player's corresponding risk level, wherein players with high risk levels are adapted to the first risk pool, and players with low or high risk levels are adapted to the second risk pool.

[0084] As an example, the following Table 1 shows a table obtained by analyzing the cheating data of previous players:

[0085] Table 1 Table 1 shows that the probability of cheating decreases significantly when a player's battle ID is greater than 10,000. Players with battle IDs greater than 10,000 can be considered low-risk players, while players with battle IDs less than 10,000 can be considered high-risk players.

[0086] In an optional embodiment of the present application, after the step of receiving a verification request for the player's combat data, the method further includes: Obtaining personal information corresponding to the player; the personal information includes registration time and active time data; determining the risk level corresponding to the player based on the personal information; and determining a target risk pool adapted for the player from the first risk pool and the second risk pool based on the risk level corresponding to the player.

[0087] In this embodiment, high-risk and low-risk players can also be distinguished based on their personal information. This involves obtaining the player's personal information, which may include registration time and active time data. The player's risk level is then determined based on this personal information. Furthermore, based on the player's risk level, the target risk pool for the player is determined from the first and second risk pools. High-risk players are matched to the first risk pool, while low-risk players are matched to the second risk pool.

[0088] This embodiment distinguishes between high-risk and low-risk players and proposes a delayed verification function. The combat data of high-risk players will be verified immediately, which can ensure the accuracy of cheating data verification during limited-time activities. For the combat data of low-risk players, the delayed verification function is used to postpone a large part of the verification consumption during the server overload period or the activity period to the low-load period after the activity ends, reducing the maximum load of the server and further reducing the operation and maintenance costs of the combat verification system.

[0089] Example 2 Figure 3 The block diagram of the battle verification device in the game according to the second embodiment of the present application is schematically shown. The device can be divided into one or more program modules, one or more program modules are stored in a storage medium and executed by one or more processors to complete the embodiment of the present application. The program module referred to in the embodiment of the present application refers to a series of computer program instruction segments that can complete specific functions. The following description will specifically introduce the functions of each program module in this embodiment. Figure 3 As shown, the battle verification device 300 in the game may include: a request receiving module 301, an immediate verification module 302 and a delayed verification module 303, wherein: a request receiving module 301 for receiving a verification request for combat data of a player having a corresponding identification code when detecting that the load of the combat verification server reaches a preset threshold or a time-limited activity starts; An immediate verification module 302 is configured to immediately verify the combat data to obtain a first verification result if it is determined that the player's identification code is in the first risk pool; The delayed verification module 303 is configured to, if it is determined that the player's identification code is in the second risk pool, wait for the load of the battle verification server to be less than a preset threshold or the time-limited activity to end, and then verify the battle data to obtain a second verification result; The risk level of the players in the first risk pool is higher than the risk level of the players in the second risk pool.

[0090] In an optional embodiment of the present application, the immediate verification module 302 is specifically configured to: adding said combat data to an immediate verification list; The combat data in the immediate verification list is immediately verified to obtain a first verification result.

[0091] In an optional embodiment of the present application, the device further includes: In the case where the first verification result indicates that the player has cheated, the player is marked as a cheating player.

[0092] In an optional embodiment of the present application, the device further includes: The player ban module is used to ban the cheating player after all the combat data in the immediate verification list are processed.

[0093] In an optional embodiment of the present application, the delay verification module 303 includes: A basic verification ratio acquisition submodule, configured to acquire a basic verification ratio corresponding to the player, and determine basic verification data from the combat data according to the basic verification ratio; A delayed verification list data adding submodule, used to add all remaining combat data except the basic verification data to the delayed verification list; The delayed verification submodule is used to wait until the load of the battle verification server is less than a preset threshold or the time-limited activity ends, and then verify the battle data in the delayed verification list to obtain a second verification result.

[0094] In an optional embodiment of the present application, the device further includes: The basic verification data verification module is configured to add the basic verification data to the immediate verification list; and immediately perform verification processing on the basic verification data in the immediate verification list to obtain a third verification result.

[0095] In an optional embodiment of the present application, the basic verification ratio acquisition submodule is specifically used to: Obtaining risk behavior data corresponding to the player; A basic verification ratio corresponding to the player is determined according to the risk behavior data.

[0096] In an optional embodiment of the present application, the device further includes: The player adding module is configured to add the player's identification code to a second risk pool if the second verification result indicates that the player has cheated.

[0097] In an optional embodiment of the present application, the combat data has a corresponding combat ID, and the apparatus further includes: The first player distinguishing module is configured to determine the risk level corresponding to the player according to the battle ID; and determine a target risk pool adapted to the player from the first risk pool and the second risk pool according to the risk level corresponding to the player.

[0098] In an optional embodiment of the present application, the device further includes: The first player differentiation module is configured to obtain personal information corresponding to the player; the personal information includes registration time and active time data; determine the risk level corresponding to the player based on the personal information; and determine a target risk pool adapted to the player from the first risk pool and the second risk pool based on the risk level corresponding to the player.

[0099] Example 3 Figure 4 The following schematically shows a hardware architecture diagram of a computer device 10000 suitable for implementing a combat verification method in a game according to the third embodiment of the present application. In some embodiments, the computer device 10000 may be a terminal device such as a smartphone, a wearable device, a tablet computer, a personal computer, a vehicle-mounted terminal, a game console, a virtual device, a workbench, a digital assistant, a set-top box, a robot, etc. In other embodiments, the computer device 10000 may be a rack server, a blade server, a tower server, or a cabinet server (including an independent server or a server cluster composed of multiple servers). Figure 4 As shown, the computer device 10000 includes but is not limited to: a memory 10010, a processor 10020, and a network interface 10030 that can communicate with each other via a system bus. Memory 10010 includes at least one type of computer-readable storage medium, including flash memory, a hard disk, a multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic storage, a magnetic disk, an optical disk, and the like. In some embodiments, memory 10010 may be an internal storage module of computer device 10000, such as a hard disk or memory of computer device 10000. In other embodiments, memory 10010 may also be an external storage device of computer device 10000, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a flash memory card, and the like equipped on computer device 10000. Of course, memory 10010 may also include both internal storage modules and external storage devices of computer device 10000. In this embodiment, the memory 10010 is generally used to store the operating system and various application software installed on the computer device 10000, such as the program code of the battle verification method in the game. In addition, the memory 10010 can also be used to temporarily store various data that has been output or will be output.

[0100] In some embodiments, processor 10020 may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other chips. Processor 10020 is typically used to control the overall operation of computer device 10000, such as performing control and processing related to data exchange or communication with computer device 10000. In this embodiment, processor 10020 is used to execute program code stored in memory 10010 or process data.

[0101] Network interface 10030 may include a wireless network interface or a wired network interface. Network interface 10030 is typically used to establish a communication link between computer device 10000 and other computer devices. For example, network interface 10030 is used to connect computer device 10000 to an external terminal via a network, establishing a data transmission channel and a communication link between computer device 10000 and the external terminal. The network may be a wireless or wired network such as an intranet, the Internet, the Global System of Mobile Communications (GSM), Wideband Code Division Multiple Access (WCDMA), a 4G network, a 5G network, Bluetooth, or Wi-Fi.

[0102] It should be pointed out that Figure 4 Only a computer device having components 10010 - 10030 is shown, but it should be understood that implementing all of the shown components is not a requirement, and greater or fewer components may alternatively be implemented.

[0103] In this embodiment, the battle verification method in the game stored in the memory 10010 can also be divided into one or more program modules and executed by one or more processors (such as processor 10020) to complete the embodiment of the present application.

[0104] Example 4 An embodiment of the present application further provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the steps of the battle verification method in the game of the embodiment are implemented.

[0105] In this embodiment, computer-readable storage media include flash memory, hard disks, multimedia cards, card-type memories (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic storage, magnetic disks, optical disks, and the like. In some embodiments, the computer-readable storage medium may be an internal storage unit of a computer device, such as the computer device's hard disk or memory. In other embodiments, the computer-readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a flash memory card, and the like. Of course, the computer-readable storage medium may also include both the internal storage unit and external storage devices of the computer device. In this embodiment, the computer-readable storage medium is typically used to store the operating system and various application software installed on the computer device, such as the program code for the battle verification method in the game described in the embodiment. Furthermore, the computer-readable storage medium may also be used to temporarily store various types of data that has been output or is about to be output.

[0106] Example 5 An embodiment of the present application further provides a computer program product, including a computer program, which implements the method in the above embodiment when executed by a processor.

[0107] Obviously, those skilled in the art should understand that the modules or steps of the above-mentioned embodiments of the present application can be implemented using general-purpose computer devices. They can be concentrated on a single computer device or distributed on a network composed of multiple computer devices. Alternatively, they can be implemented using program codes executable by the computer device, so that they can be stored in a storage device and executed by the computer device. In some cases, the steps shown or described can be performed in a different order than herein, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. Thus, the embodiments of the present application are not limited to any specific combination of hardware and software.

[0108] It should be noted that the above are only preferred embodiments of the present application and do not limit the scope of patent protection of the present application. Any equivalent structure or equivalent process transformation made using the contents of the description and drawings of this application, or directly or indirectly applied in other related technical fields, are also included in the scope of patent protection of the present application.

Claims

1. A combat verification method in a game, characterized in that: The method comprises: receiving a verification request for combat data of a player having a corresponding identification code upon detecting that a load of the combat verification server reaches a preset threshold or a time-limited event begins; If it is determined that the player's identification code is in the first risk pool, immediately verifying the battle data to obtain a first verification result; If it is determined that the player's identification code is in the second risk pool, waiting for the load of the battle verification server to be less than a preset threshold or the time-limited activity to end, and then verifying the battle data to obtain a second verification result; The risk level of the players in the first risk pool is higher than the risk level of the players in the second risk pool.

2. The battle verification method in the game according to claim 1, characterized in that: The immediately performing verification processing on the combat data to obtain a first verification result includes: adding said combat data to an immediate verification list; The combat data in the immediate verification list is immediately verified to obtain a first verification result.

3. The battle verification method in the game according to claim 2, characterized in that: The method further comprises: In the case where the first verification result indicates that the player has cheated, the player is marked as a cheating player.

4. The method for verifying combat in a game according to claim 3, wherein: The method further comprises: After all combat data in the immediate verification list is processed, the cheating player is banned.

5. The battle verification method in the game according to claim 1, characterized in that: After the load of the battle verification server is less than a preset threshold or the time-limited activity ends, verifying the battle data to obtain a second verification result, including: Obtaining a basic verification ratio corresponding to the player, and determining basic verification data from the combat data according to the basic verification ratio; Add all remaining combat data except the basic verification data to the delayed verification list; After waiting for the load of the battle verification server to be less than a preset threshold or the time-limited activity to end, the battle data in the delayed verification list is verified to obtain a second verification result.

6. The battle verification method in the game according to claim 5, characterized in that: The method further comprises: Adding the basic verification data to the immediate verification list; The basic verification data in the immediate verification list is immediately verified to obtain a third verification result.

7. The method for verifying combat in a game according to claim 6, wherein: The obtaining of the basic verification ratio corresponding to the player includes: Obtaining risk behavior data corresponding to the player; A basic verification ratio corresponding to the player is determined according to the risk behavior data.

8. The in-game combat verification method according to claim 1, characterized in that: The method further comprises: If the second verification result indicates that the player has cheated, the identification code of the player is added to a second risk pool.

9. The method for verifying combat in a game according to claim 1, wherein: The battle data has a corresponding battle ID. After the step of receiving a verification request for the player's battle data, the method further includes: Determining the risk level corresponding to the player according to the battle ID; According to the risk level corresponding to the player, a target risk pool adapted to the player is determined from the first risk pool and the second risk pool.

10. The battle verification method in a game according to claim 1, characterized in that: After the step of receiving a verification request for the player's combat data, the method further includes: Obtaining personal information corresponding to the player; the personal information includes registration time and active time data; Determining a risk level corresponding to the player based on the personal information; According to the risk level corresponding to the player, a target risk pool adapted to the player is determined from the first risk pool and the second risk pool.

11. A combat verification device in a game, characterized in that: The device comprises: a request receiving module for receiving a verification request for combat data of a player having a corresponding identification code when detecting that the load of the combat verification server reaches a preset threshold or a time-limited activity begins; an immediate verification module, configured to immediately verify the combat data to obtain a first verification result if it is determined that the player's identification code is in the first risk pool; a delayed verification module, configured to, upon determining that the player's identification code is in the second risk pool, wait for the load of the battle verification server to be less than a preset threshold or for the time-limited activity to end, and then verify the battle data to obtain a second verification result; The risk level of the players in the first risk pool is higher than the risk level of the players in the second risk pool.

12. A computer device, characterized in that: include: at least one processor; and a memory communicatively coupled to the at least one processor; wherein: The memory stores instructions that can be executed 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 battle verification method in the game according to any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, which, when executed by a processor, implement the battle verification method in the game according to any one of claims 1 to 10.

14. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the battle verification method in the game according to claims 1 to 10 are implemented.

Images