Method for checking irregularities of unmanned aerial vehicle racing game, electronic device and medium

Abstract

This application relates to the field of game security technology, and in particular to a method, electronic device, and medium for detecting violations in drone racing games. The method for detecting violations in drone racing games of this application requires first receiving drone state data packets corresponding to multiple motion state frames from the target terminal; decoding each drone state data packet to obtain a set of state data for the target drone model corresponding to each motion state frame; performing data verification on the drone state data packets and the state data sets to obtain data verification results; based on the state data sets corresponding to multiple consecutive motion state frames, performing continuous behavior analysis on the target drone model to obtain continuous behavior analysis information; and based on the continuous behavior analysis information, performing violation detection operations on the simulated motion states of the target drone model in multiple motion state frames. This effectively detects violations in drone racing games.

Description

Technical Field

[0001] This application relates to the field of game security technology, and in particular to a method, electronic device, and medium for detecting violations in drone racing games. Background Technology

[0002] Drone racing online games and simulators are highly popular among players due to their high-speed flight and skill-intensive controls. The technical architecture of these games places extremely high demands on the real-time synchronization of data between the client and server. The server needs to receive and process drone status data packets from multiple clients at a high frequency within a given time frame to maintain the real-time consistency of the game world. This high dependence on continuous data streams, while ensuring a smooth flight experience, also provides potential opportunities for unauthorized data manipulation.

[0003] In related technologies, the core methods of game anti-cheat solutions focus on detecting unauthorized memory modifications and identifying cheat processes. However, drone racing games are highly dependent on continuous, high-frequency physical state synchronization. Clients need to report state data, including real-time 3D coordinates, velocity vectors, attitude angles, and timestamps, to the server at a high frequency. Traditional anti-cheat solutions have significant shortcomings in this regard. The fundamental difficulty lies in the inherent uncertainty of the network transmission environment; high latency and packet jitter can cause the state data reported by the client to exhibit abnormal characteristics on the server side. Therefore, how to effectively detect violations in drone racing games has become a pressing issue for the industry. Summary of the Invention

[0004] This application aims to address at least one of the technical problems existing in the prior art. To this end, this application proposes a method, electronic device, and medium for detecting violations in drone racing games, which can effectively detect violations in drone racing games.

[0005] The method for detecting violations in a drone racing game according to the first aspect of this application, applied to a target server, includes:

[0006] Receive UAV state data packets corresponding to multiple motion state frames from the target terminal; wherein, the UAV state data packets are used to describe the simulated motion state of the target UAV model in each of the motion state frames;

[0007] Decode each of the UAV state data packets to obtain the state data set of the target UAV model corresponding to each of the motion state frames;

[0008] The UAV status data packet and the status data set are validated to obtain the data validation result.

[0009] Based on the state data set corresponding to multiple consecutive motion state frames, continuous behavior analysis is performed on the target UAV model to obtain continuous behavior analysis information.

[0010] Based on the continuous behavior analysis information, violation detection operations are performed on the simulated motion state of the target drone model in multiple motion state frames.

[0011] According to some embodiments of this application, before performing violation detection operations on the simulated motion state of the target UAV model in multiple motion state frames based on the continuous behavior analysis information, the method further includes:

[0012] Receive multiple game event data corresponding to each of the motion state frames from the target terminal; wherein, the multiple game event data are used to describe the game mechanism events triggered by the target drone model in each of the motion state frames;

[0013] Based on the game event data corresponding to multiple motion state frames, mechanism behavior analysis is performed on the target drone model to obtain mechanism behavior analysis information.

[0014] The step of performing violation detection operations on the simulated motion state of the target drone model in multiple motion state frames based on the continuous behavior analysis information includes:

[0015] Based on the continuous behavior analysis information and the mechanism behavior analysis information, the violation detection operation is performed on the target UAV model in the simulated motion state of multiple motion state frames.

[0016] According to some embodiments of this application, the mechanism behavior analysis information includes mechanism trigger verification results. The mechanism behavior analysis, based on the game event data corresponding to multiple motion state frames, is performed on the target drone model to obtain mechanism behavior analysis information, including:

[0017] Obtain the location of the target drone model on the game map. Figure 3 3D model and collider parameters;

[0018] If multiple game event data include mechanism event data, the corresponding motion state frame will be determined as the mechanism trigger frame;

[0019] The system retrieves the target historical trajectory data and the state data set cached before the trigger frame; wherein, the target historical trajectory is the historical trajectory data of the target UAV model before the trigger frame.

[0020] Based on the aforementioned land Figure 3The spatial-temporal logic recalculation and determination are performed on the dimensional model, the collision body parameters, the target historical trajectory data, and the state data set to obtain the mechanism trigger verification result.

[0021] According to some embodiments of this application, the mechanism behavior analysis information further includes time-related anomaly information. The step of performing mechanism behavior analysis on the target drone model based on the game event data corresponding to multiple motion state frames to obtain mechanism behavior analysis information includes:

[0022] Obtain the theoretical maximum time taken by the target drone model in the game physics engine, and the time limit conversion factor corresponding to the theoretical maximum time;

[0023] Based on the game event data corresponding to multiple motion state frames, determine the motion time from the motion start event to the motion end event;

[0024] Based on the theoretical limit time and the time limit conversion factor, abnormal time consumption of the motion is investigated to obtain abnormal time information.

[0025] According to some embodiments of this application, the step of performing the violation detection operation on the simulated motion state of the target UAV model in multiple motion state frames based on the continuous behavior analysis information and the mechanism behavior analysis information includes:

[0026] Based on the continuous behavior analysis information, a first number of abnormal continuous behaviors of the target UAV model in multiple motion state frames are determined;

[0027] Based on the mechanism behavior analysis information, a second number of abnormal mechanism behaviors of the target UAV model in multiple motion state frames are determined;

[0028] Based on the first number of abnormal continuous behaviors and the second number of abnormal mechanism behaviors, violation behavior analysis is performed to obtain violation behavior analysis results;

[0029] Based on the analysis results of the violations, the corresponding review benchmark data is retrieved from each of the pre-cached state data sets;

[0030] Based on the aforementioned verification benchmark data, the trajectory of the target UAV model is verified to obtain the verification results of violations.

[0031] Based on the results of the violation review, the violation investigation operation is performed.

[0032] According to some embodiments of this application, the data verification result includes a data tampering verification result and a data paradigm verification result. The step of performing data verification on the UAV state data packet and the state data set to obtain the data verification result includes:

[0033] The hash integrity of the drone status data packet is verified to obtain the data tampering verification result.

[0034] The data paradigm is validated on the state data set to obtain the data paradigm validation result.

[0035] According to some embodiments of this application, the continuous behavior analysis information includes suspicious speed data, and the continuous behavior analysis of the target UAV model based on the state data set corresponding to multiple consecutive motion state frames to obtain continuous behavior analysis information includes:

[0036] Obtain the theoretical maximum speed of the target drone model in the game physics engine;

[0037] For each set of state data, extract the corresponding three-dimensional coordinate parameters and timestamp parameters of the target UAV model;

[0038] Based on the corresponding three-dimensional coordinate parameters and timestamp parameters of each consecutive motion state frame, the instantaneous motion velocities of the target UAV model are calculated.

[0039] Based on the theoretical maximum speed, abnormal speeds are detected in multiple instantaneous speeds of the motion to obtain the suspicious speed data.

[0040] According to some embodiments of this application, the continuous behavior analysis information further includes suspicious displacement data, and the step of performing continuous behavior analysis on the target UAV model based on the state data set corresponding to multiple consecutive motion state frames to obtain continuous behavior analysis information further includes:

[0041] Obtain the theoretical maximum speed and theoretical maximum acceleration of the target drone model in the game physics engine, and obtain the inter-frame time difference between adjacent motion state frames of the target drone model;

[0042] Based on the theoretical maximum velocity, the theoretical maximum acceleration, and the inter-frame time difference, the theoretically achievable displacement threshold is calculated.

[0043] For each set of state data, extract the corresponding three-dimensional coordinate parameters of the target UAV model;

[0044] For each pair of adjacent motion state frames, based on the three-dimensional coordinate parameters of the adjacent motion state frames, multiple motion model displacements of the target UAV model are calculated.

[0045] Based on the theoretically achievable displacement threshold, abnormal displacements of multiple motion models are investigated to obtain the suspicious displacement data.

[0046] Secondly, embodiments of this application provide an electronic device, including: a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method for detecting violations in a drone racing game as described in any one of the embodiments of the first aspect of this application.

[0047] Thirdly, embodiments of this application provide a computer-readable storage medium storing a program that is executed by a processor to implement the method for detecting violations in a drone racing game as described in any one of the embodiments of the first aspect of this application.

[0048] The method, electronic device, and medium for detecting violations in drone racing games according to embodiments of this application have at least the following beneficial effects:

[0049] The method for detecting violations in drone racing games according to embodiments of this application, applied to a target server, first requires receiving drone state data packets corresponding to multiple motion state frames from a target terminal. These drone state data packets describe the simulated motion state of the target drone model in each motion state frame. Each drone state data packet is decoded to obtain a set of state data for the target drone model corresponding to each motion state frame. Data verification is performed on the drone state data packets and the set of state data to obtain a data verification result. Based on the state data sets corresponding to multiple consecutive motion state frames, continuous behavior analysis is performed on the target drone model to obtain continuous behavior analysis information. Based on the continuous behavior analysis information, violation detection operations are performed on the simulated motion state of the target drone model in multiple motion state frames. In this way, violation detection can be effectively performed on drone racing games.

[0050] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0051] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which:

[0052] Figure 1This is a flowchart illustrating a method for investigating violations in drone racing games, as described in this application.

[0053] Figure 2 This is another flowchart illustrating the method for investigating violations in drone racing games in this application embodiment;

[0054] Figure 3 This is another flowchart illustrating the method for investigating violations in drone racing games in this application embodiment;

[0055] Figure 4 This is another flowchart illustrating the method for investigating violations in drone racing games in this application embodiment;

[0056] Figure 5 This is another flowchart illustrating the method for investigating violations in drone racing games in this application embodiment;

[0057] Figure 6 This is another flowchart illustrating the method for investigating violations in drone racing games in this application embodiment;

[0058] Figure 7 This is another flowchart illustrating the method for investigating violations in drone racing games in this application embodiment;

[0059] Figure 8 This is another flowchart illustrating the method for investigating violations in drone racing games in this application embodiment;

[0060] Figure 9 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0061] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application.

[0062] In the description of this application, "several" means one or more, "more than" means two or more, "greater than," "less than," and "exceeding" are understood to exclude the stated number, while "above," "below," and "within" are understood to include the stated number. The use of "first" and "second" in the description is merely for distinguishing technical features and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or implicitly indicating the order of the indicated technical features.

[0063] In the description of this application, it should be understood that the orientation descriptions, such as up, down, left, right, front, and back, are based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application.

[0064] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0065] In the description of this application, it should be noted that, unless otherwise explicitly defined, terms such as "setting," "installation," and "connection" should be interpreted broadly. Those skilled in the art can reasonably determine the specific meaning of the above terms in this application based on the specific content of the technical solution. Furthermore, the identification of specific steps in the following text does not imply a limitation on the order of steps or execution logic. The execution order and logic between each step should be understood and inferred from the content described in the embodiments.

[0066] Drone racing online games and simulators are highly popular among players due to their high-speed flight and skill-intensive controls. The technical architecture of these games places extremely high demands on the real-time synchronization of data between the client and server. The server needs to receive and process drone status data packets from multiple clients at a high frequency within a given time frame to maintain the real-time consistency of the game world. This high dependence on continuous data streams, while ensuring a smooth flight experience, also provides potential opportunities for unauthorized data manipulation.

[0067] In the actual operation of these games, common violations mainly revolve around the unauthorized modification of client-side data. By altering local client data, violators can cause drones to exhibit abnormal behaviors in the game's physics engine, such as teleportation, acceleration, and wall-clipping, which defy normal motion laws. In stages involving track determination, they can falsify successful completion signals for passing obstacles or other checkpoints to inflate race progress. Furthermore, there are instances where race time data is directly modified to obtain false results. These violations directly undermine the competitive fairness of drone racing games, which is based on physics rules, and their damage to the credibility of competitions is particularly severe in formal competition scenarios.

[0068] The technical approaches of existing anti-cheat solutions for related games largely originate from the traditional first-person shooter game field, focusing on detecting unauthorized memory modifications and identifying cheat processes. However, drone racing games are characterized by a high reliance on continuous, high-frequency physical state synchronization. Clients need to report state data, including real-time 3D coordinates, velocity vectors, attitude angles, and timestamps, to the server at a high frequency. In this context, traditional anti-cheat solutions have significant shortcomings. The fundamental difficulty lies in the inherent uncertainty of the network transmission environment. High latency and packet jitter can cause the state data reported by the client to exhibit abnormal characteristics on the server side. Existing technologies lack effective mechanisms to distinguish between legitimate abnormal states caused by network factors and genuine violations, easily leading to misjudgments or missed detections. Therefore, existing technologies lack dedicated anti-cheat measures specifically tailored to the high-frequency physical synchronization characteristics of drone racing games, failing to accurately distinguish between network anomalies and violations, resulting in insufficient guarantees of fair competition.

[0069] This application aims to address at least one of the technical problems existing in the prior art. To this end, this application proposes a method, electronic device, and medium for detecting violations in drone racing games, which can effectively detect violations in drone racing games.

[0070] The following explanation is based on the accompanying drawings.

[0071] Reference Figure 1 The method for detecting violations in drone racing games according to embodiments of this application, applied to a target server, may include:

[0072] Step S101: Receive UAV state data packets corresponding to multiple motion state frames from the target terminal; wherein, the UAV state data packets are used to describe the simulated motion state of the target UAV model in each motion state frame.

[0073] Step S102: Decode each UAV state data packet to obtain the state data set of the target UAV model corresponding to each motion state frame;

[0074] Step S103: Perform data verification on the UAV status data packet and status data set to obtain the data verification result;

[0075] Step S104: Based on the state data set corresponding to multiple consecutive motion state frames, perform continuous behavior analysis on the target UAV model to obtain continuous behavior analysis information.

[0076] Step S105: Based on continuous behavior analysis information, perform violation detection operations on the simulated motion state of the target UAV model in multiple motion state frames.

[0077] It should be clarified that the violation detection method in this application embodiment can run on the target server. By independently receiving and processing continuous motion state data from the target terminal, it bypasses the reliance on traditional target terminal local memory monitoring or process scanning, and uses objective physical calculation results as the core basis for violation determination. In drone racing games, the target terminal needs to report physical synchronization data to the server at a high frequency to maintain the real-time consistency of the game world. This application embodiment utilizes this high-frequency data stream to build a verification chain on the server side that does not rely on the target terminal's self-declaration.

[0078] In some embodiments, step S101 involves receiving a UAV state data packet corresponding to multiple motion state frames from the target terminal; wherein the UAV state data packet is used to describe the simulated motion state of the target UAV model in each motion state frame.

[0079] It should be noted that in the data input and structured processing stage, the target server first receives drone state data packets corresponding to multiple motion state frames from the target terminal. A motion state frame refers to a discrete state snapshot recorded at fixed time intervals during game execution, with each frame corresponding to the game world state at a specific moment. The drone state data packet is a data transmission unit sent by the target terminal to the server via a network protocol, used to describe the simulated motion state of the target drone model in each motion state frame. Its payload content includes at least physical parameters such as real-time three-dimensional coordinates, velocity vector, attitude angle, and timestamp.

[0080] In step S102 of some embodiments, each UAV state data packet is decoded to obtain a set of state data of the target UAV model corresponding to each motion state frame.

[0081] It should be noted that since UAV status data packets are generally stored in an encoded form at the network layer, they cannot be directly used for numerical calculations or logical judgments. Therefore, this embodiment requires decoding each UAV status data packet, parsing it into a structured data object with clearly defined fields according to a predetermined communication protocol format, thereby obtaining the status data set of the target UAV model corresponding to each motion state frame. This status data set may contain semantically meaningful three-dimensional coordinate parameters, velocity vector components, attitude angle values, and timestamps, serving as the basic data carrier for all subsequent verification and analysis operations.

[0082] In step S103 of some embodiments, the UAV status data packet and status data set are verified to obtain the data verification result;

[0083] It should be noted that after obtaining the structured data, this embodiment of the application performs data verification on the UAV status data packets and status data sets to obtain data verification results. The technical role of this step is to establish a trustworthy threshold at the data entry level, limiting the subsequent analysis objects to the scope of valid data. Specifically, the verification of the original UAV status data packets is mainly used to identify whether the data integrity has been damaged during the transmission process from the target terminal to the server; the verification of the decoded status data sets is mainly used to exclude obviously invalid data objects such as those with garbled formats, out-of-bounds values, or logical contradictions. By covering the verification mechanism at both the original packet and decoded data levels, this embodiment of the application can filter out noise input caused by network transmission errors, data packet jitter, or incompatibility of the target terminal version, reduce the interference of network environment uncertainty on subsequent judgment results, and avoid misjudgments caused by occasional data errors.

[0084] Reference Figure 2 According to some embodiments of this application, the data verification result includes data tampering verification result and data paradigm verification result. Data verification is performed on the UAV state data packet and state data set to obtain the data verification result, which may include:

[0085] Step S201: Perform hash integrity verification on the UAV status data packet to obtain the data tampering verification result;

[0086] Step S202: Perform data normalization verification on the state data set to obtain the data normalization verification result.

[0087] This application's embodiments divide data verification results into data tampering verification results and data paradigm verification results, corresponding to two different levels of verification steps, respectively used to address integrity risks in the data transmission link and quality risks after data decoding. As the raw network data unit transmitted from the target terminal to the server, the UAV status data packet may face the risk of data corruption or illegal tampering during its journey through the network link to the server; while the decoded status data packet, as a structured data object, may experience format-level anomalies due to differences in target terminal versions, protocol parsing errors, or field mapping deviations. By distinguishing data verification into integrity verification for the raw packet and paradigm verification for the decoded data, this application's embodiments can identify transport layer risks and application layer risks at different data processing stages, avoiding the deficiency that a single verification step cannot cover the entire data quality problem across the entire link.

[0088] In some embodiments, step S201 involves performing hash integrity verification on the UAV status data packet to obtain a data tampering verification result.

[0089] It should be noted that hash integrity verification is performed on the UAV status data packets to obtain data tampering verification results. Hash integrity verification is a data integrity verification mechanism based on hash algorithms. Its technical principle lies in utilizing the one-wayness and collision resistance of hash functions to generate a fixed-length unique digest value for input data of arbitrary length. Any bit-level change in the original data content will cause an unpredictable and significant change in the digest value. In this verification process, when the target terminal sends the UAV status data packet, it pre-calculates a hash digest value for the packet data payload and appends this digest value to the packet header. In this embodiment, after receiving the UAV status data packet, the digest value of the received data is independently recalculated using the same hash algorithm, and the calculation result is compared with the original digest value of the sender attached to the packet header. If they match, it indicates that the UAV status data packet has remained intact during transmission and has not been tampered with; if they do not match, it indicates that the data content has been illegally modified or a serious transmission error has occurred in the transmission link from the target terminal to the server. The data tampering verification result is recorded as this comparison result, reflecting the integrity status of the original transmitted data and providing a reliable original input for subsequent processing.

[0090] In some embodiments, the target terminal needs to pre-calculate and append the original hash value, enabling the target server to independently reproduce the hash calculation process at the receiving end. This establishes an objective basis for determining data integrity even without trusting the network transmission environment. This embodiment requires that the original hash value, data payload, and preset hash algorithm be continuously invoked in subsequent steps to ensure the reliability of the verification result. A feasible specific step is as follows:

[0091] Receive UAV status data packets from the target terminal. The packets consist of a data payload and a packet header. The packet header contains the original hash value generated by the target terminal based on the data payload using a preset hash algorithm before sending.

[0092] Extract the original hash value from the packet header, and call the same preset hash algorithm as the target terminal to independently perform hash calculation on the received data payload to generate a local hash value;

[0093] The local hash value is compared with the original hash value. If they match, a data tampering verification result is generated. If the data tampering verification result indicates that the verification passed, the drone status data packet is sent to the decoding stage. If they do not match, the data tampering verification result indicates that the verification failed, the packet is discarded and a transmission anomaly is recorded.

[0094] In some embodiments, step S202 involves performing a data paradigm check on the state data set to obtain a data paradigm check result.

[0095] It should be noted that data paradigm validation is performed on the state dataset to obtain the data paradigm validation result. The state dataset is a structured data object obtained after decoding UAV state data packets, and each field within it already possesses clear physical semantics. Data paradigm validation performs a compliance check on this structured data, verifying whether it conforms to the data paradigm requirements defined by the predetermined communication protocol, including specifications such as field structure, data type, and numerical constraints. This validation can identify invalid data objects generated during the decoding process, such as missing fields, type mismatches, or values ​​exceeding reasonable boundaries, thus obtaining the data paradigm validation result. This validation result reflects the application-layer usability of the decoded data, ensuring that the data entering subsequent continuous behavioral analysis has basic standardization and rationality, can correctly carry physical parameters, and support subsequent calculations.

[0096] In some embodiments, after the raw data that has passed integrity verification is converted into a structured set of state data, compliance screening of the state data set can be performed from three progressive levels: format, value, and logic. This ensures that the state data set that needs to enter the physical law analysis stage is not only transmitted completely, but also semantically correct, numerically reasonable, and logically consistent. This application embodiment requires that the decoded state data set be progressively filtered in each level of verification, and only data that passes all verifications can be cached and used for continuous behavior analysis, avoiding invalid data interfering with physical calculations. A feasible specific step is as follows:

[0097] The UAV status data packet that has passed the data tampering verification is decoded and parsed into a status data set containing three-dimensional coordinate parameters, velocity vector components, attitude angle values ​​and timestamp fields.

[0098] Perform format validation on the status data set to verify whether the number of fields, the data type of each field, and the byte order conform to the predetermined communication protocol specifications.

[0099] For the state data set that passes the format validation, perform numerical range validation to verify whether the three-dimensional coordinate parameters are within the boundary of the track map, whether the velocity vector components are valid floating-point numbers, and whether the timestamp is a positive number.

[0100] For the set of state data that has passed the numerical range check, perform a rationality check to verify whether the logical relationship between each field is valid. For example, verify whether the timestamp sequence is strictly increasing and whether the attitude angle value conforms to mathematical constraints.

[0101] If the above format validation, numerical range validation, and rationality validation all pass, a data paradigm validation result is generated. If the data paradigm validation result indicates that the validation passed, the state data set is included in the server cache as a valid input for subsequent continuous behavior analysis. If the data paradigm validation result indicates that the validation failed, the state data set is discarded and the subsequent processing of the motion state frame is terminated.

[0102] It should be understood that the data tampering verification result and the data paradigm verification result together constitute the data verification result, providing assurance for subsequent steps from two dimensions: transmission integrity and data standardization. The former ensures that the server analysis is based on the original, authentic data sent by the target terminal, eliminating data distortion caused by third-party tampering or network noise interference in the transmission link; the latter ensures that the decoded structured data conforms to the predetermined protocol specifications and can accurately express the motion state parameters of the target UAV model. The two are independent yet sequentially linked, allowing transmission errors caused by network environment uncertainties and format anomalies caused by differences in target terminal versions to be identified and filtered in a layered manner, preventing invalid or distorted data from entering the continuous behavior analysis stage, thereby improving the reliability of the entire violation detection method.

[0103] In step S104 of some embodiments, continuous behavior analysis is performed on the target UAV model based on the state data set corresponding to multiple consecutive motion state frames to obtain continuous behavior analysis information.

[0104] It should be noted that, based on data verification, this application embodiment performs continuous behavior analysis on the target drone model based on the state data set corresponding to multiple consecutive motion state frames, obtaining continuous behavior analysis information. This step is the core technical link in distinguishing between network anomalies and behavioral violations. Unlike isolated analysis of single-frame data, continuous behavior analysis utilizes the spatiotemporal correlation between adjacent motion state frames, performs cross-frame correlation calculations based on physical parameters in the state data set, and verifies whether the simulated motion state of the target drone model conforms to the theoretical constraints set by the game physics engine. Network anomalies typically manifest as random, irregular single-frame data jumps or brief loss, and the resulting abnormal states are often not persistent; while violations, such as teleportation or acceleration achieved by modifying the target terminal's local data, will exhibit systematic and persistent deviations from physical laws in multiple consecutive frames. By establishing cross-frame physical continuity constraints, this application embodiment can identify motion anomalies with persistent characteristics, thereby distinguishing occasional network jitter from intentional data forgery.

[0105] Reference Figure 3According to some embodiments of this application, the continuous behavior analysis information includes suspicious speed data. Step S104 performs continuous behavior analysis on the target UAV model based on the state data set corresponding to multiple consecutive motion state frames to obtain continuous behavior analysis information, which may include:

[0106] Step S301: Obtain the theoretical maximum speed of the target drone model in the game physics engine;

[0107] Step S302: For each set of state data, extract the corresponding three-dimensional coordinate parameters and timestamp parameters of the target UAV model;

[0108] Step S303: Calculate multiple instantaneous motion velocities of the target UAV model based on the corresponding three-dimensional coordinate parameters and timestamp parameters of each consecutive motion state frame;

[0109] Step S304: Based on the theoretical maximum speed, perform abnormal speed checks on multiple instantaneous speeds to obtain suspicious speed data.

[0110] This application's embodiments demonstrate a server-side verification process centered on the velocity dimension in continuous behavior analysis. The technical concept lies in using the dynamic constraints built into the game's physics engine as an objective benchmark, and independently calculating the actual motion state of the target drone model using the original spatial and temporal parameters from the continuous motion state frames cached on the server. This establishes a velocity determination mechanism independent of the target terminal's self-declaration. The entire process, from benchmark establishment, original parameter extraction, physical quantity calculation to anomaly detection, forms a complete verification chain based on kinematic principles.

[0111] In some embodiments, step S301 involves obtaining the theoretical maximum speed of the target drone model in the game physics engine.

[0112] It should be noted that the embodiments of this application obtain the theoretical maximum speed of the target drone model in the game physics engine. The theoretical maximum speed refers to the speed limit preset by the game physics engine based on the target drone model's power configuration, air resistance parameters, and track environment constraints. It represents the speed limit that the model can reach in the virtual physical world through legal operations, and serves as a rigid benchmark for subsequent anomaly investigation.

[0113] In step S302 of some embodiments, for each set of state data, the three-dimensional coordinate parameters and timestamp parameters corresponding to the target UAV model are extracted;

[0114] It should be noted that, in this embodiment, for each set of state data, the corresponding three-dimensional coordinate parameters and timestamp parameters of the target UAV model are extracted. The three-dimensional coordinate parameters describe the spatial position of the target UAV model in a specific motion state frame, usually represented by coordinate values ​​in a three-dimensional Cartesian coordinate system; the timestamp parameter records the absolute or relative time corresponding to that motion state frame. These two parameters are the most basic spatial and temporal inputs for kinematic calculations, and are extracted directly from the data-verified state data set, ensuring the reliability of the data source for calculation.

[0115] In step S303 of some embodiments, multiple instantaneous motion velocities of the target UAV model are calculated based on the corresponding three-dimensional coordinate parameters and timestamp parameters of each consecutive motion state frame.

[0116] It should be noted that the embodiments of this application calculate multiple instantaneous velocities of the target UAV model based on the corresponding three-dimensional coordinate parameters and timestamp parameters of each consecutive motion state frame. Instantaneous velocity refers to the average speed of the target UAV model within a very short time period. Its calculation principle is based on the definition of velocity in classical kinematics, that is, calculating the spatial displacement by the change in three-dimensional coordinates between two adjacent motion state frames, then removing this value and using the difference in timestamp parameters between adjacent frames to obtain the rate of change of displacement per unit time. Since this calculation process is entirely executed on the server side, based on verified original coordinate and time data, the obtained instantaneous velocity is a kinematic result independently observed by the server, rather than a velocity vector declaration reported by the target terminal.

[0117] In some embodiments, step S304 involves checking multiple instantaneous motion speeds for abnormal speeds based on the theoretical maximum speed to obtain suspicious speed data.

[0118] It should be noted that this application embodiment uses the theoretical maximum speed to perform abnormal speed checks on multiple instantaneous motion speeds, obtaining suspicious speed data. The technical principle of abnormal speed checks lies in comparing each instantaneous motion speed, independently calculated by the server, with the theoretical maximum speed. If a certain instantaneous motion speed exceeds the theoretical maximum speed, it indicates that the motion state of the target drone model during that time period exceeds the physical limits allowed by the game's physics engine, exhibiting characteristics that violate the laws of dynamics. Such instantaneous motion speeds exceeding physical limits are marked as suspicious speed data, becoming an important component of continuous behavior analysis information, and providing objective evidence of speed anomalies for subsequent violation detection operations.

[0119] It should be understood that obtaining the theoretical maximum speed establishes a boundary for anomaly detection; the extraction of three-dimensional coordinate parameters and timestamp parameters provides standardized input material for kinematic calculations; the instantaneous velocity calculated based on these parameters constitutes the independent observation value on the server side; finally, by comparing the observation value with the physical boundary, suspicious velocity data is filtered out. This application's embodiment transforms abstract physical rules into quantifiable judgment criteria, enabling the server to identify potential speed violations through objective mathematical calculations without relying on unilateral declarations from the target terminal.

[0120] Reference Figure 4 According to some embodiments of this application, the continuous behavior analysis information further includes suspicious displacement data. Step S104, based on the state data set corresponding to multiple consecutive motion state frames, performs continuous behavior analysis on the target UAV model to obtain continuous behavior analysis information, and may further include:

[0121] Step S401: Obtain the theoretical maximum speed and theoretical maximum acceleration of the target drone model in the game physics engine, and obtain the inter-frame time difference between adjacent motion state frames of the target drone model.

[0122] Step S402: Calculate the theoretically achievable displacement threshold based on the theoretical maximum velocity, theoretical maximum acceleration, and inter-frame time difference;

[0123] Step S403: For each set of state data, extract the corresponding three-dimensional coordinate parameters of the target UAV model;

[0124] Step S404: For each pair of adjacent motion state frames, calculate multiple motion model displacements of the target UAV model based on the three-dimensional coordinate parameters of the adjacent motion state frames.

[0125] Step S405: Based on the theoretically achievable displacement threshold, abnormal displacement is investigated for multiple motion model displacements to obtain suspicious displacement data.

[0126] This application extends continuous behavior analysis from the velocity dimension to the displacement dimension. By establishing a theoretically achievable displacement threshold based on the dynamic constraints of a game physics engine, the actual spatial displacement of the target drone model between adjacent motion state frames is independently verified. While instantaneous velocity detection can identify obvious speeding anomalies, some violations may be controlled to keep the velocity vector within the theoretical limit, while simultaneously achieving large-span spatial jumps by tampering with coordinate data. Verification in the displacement dimension, through the upper limit of the spatial distance between adjacent frames, provides a supplementary perspective independent of velocity calculation for judging physical plausibility.

[0127] In some embodiments, step S401 involves obtaining the theoretical maximum speed and theoretical maximum acceleration of the target drone model in the game physics engine, and obtaining the inter-frame time difference between adjacent motion state frames of the target drone model.

[0128] It should be noted that, in this embodiment, the theoretical maximum speed and theoretical maximum acceleration of the target drone model in the game physics engine are first obtained, and the inter-frame time difference between adjacent motion state frames is also obtained. The theoretical maximum speed refers to the upper limit of speed set by the game physics engine based on the target drone model's power configuration and environmental constraints; the theoretical maximum acceleration refers to the upper limit of acceleration that the model can achieve under the engine's dynamics rules; and the inter-frame time difference is the difference between the timestamp parameters of two adjacent motion state frames, representing the time interval between two state snapshots.

[0129] In step S402 of some embodiments, a theoretically achievable displacement threshold is calculated based on the theoretical maximum velocity, the theoretical maximum acceleration, and the inter-frame time difference.

[0130] It should be noted that, based on three parameters—the theoretical maximum speed, the theoretical maximum acceleration, and the inter-frame time difference—this embodiment calculates the theoretically achievable displacement threshold. This calculation is based on classical kinematics principles, considering the constraint that an object can achieve a maximum spatial displacement within a given time interval, accelerating from its initial state without exceeding the theoretical maximum acceleration, and with its final speed not exceeding the theoretical maximum speed. This threshold represents the maximum distance the target UAV model can move through legal operations within a specific inter-frame time difference, serving as a rigid boundary for subsequent anomaly detection.

[0131] In step S403 of some embodiments, for each set of state data, the three-dimensional coordinate parameters corresponding to the target UAV model are extracted;

[0132] It should be noted that, in the actual displacement observation stage, the embodiments of this application extract the three-dimensional coordinate parameters corresponding to the target UAV model for each state data set. These parameters describe the spatial position coordinates of the target UAV model in a specific motion state frame.

[0133] In some embodiments, step S404 involves calculating multiple motion model displacements of the target UAV model based on the three-dimensional coordinate parameters of each pair of adjacent motion state frames.

[0134] It should be noted that, after extracting the corresponding three-dimensional coordinate parameters of the target UAV model for each set of state data, this embodiment calculates multiple motion model displacements of the target UAV model based on the three-dimensional coordinate parameters of adjacent motion state frames for each pair of adjacent motion state frames. The motion model displacement refers to the actual displacement calculated from the spatial coordinate difference between the three-dimensional coordinate parameters of two adjacent frames, which can be derived based on the Euclidean distance formula or the spatial straight-line distance formula. This calculation process is entirely executed on the server side, based on the original coordinate data that has undergone data verification. Therefore, the obtained motion model displacement is a spatial motion result independently observed by the server and is not affected by the self-declared parameters reported by the target terminal.

[0135] In step S405 of some embodiments, abnormal displacement is investigated for multiple motion model displacements based on the theoretically achievable displacement threshold to obtain suspicious displacement data.

[0136] It should be noted that, in the anomaly detection phase, this embodiment of the application performs anomaly detection on the displacements of multiple motion models based on theoretically achievable displacement thresholds to obtain suspicious displacement data. The detection principle involves comparing the displacements of each motion model, independently calculated by the server, with the theoretically achievable displacement thresholds. If a motion model displacement exceeds the theoretically achievable displacement threshold, it indicates that within the time interval between adjacent frames, the spatial position change of the target drone model exceeds the limits of motion capabilities allowed by the game's physics engine, exhibiting characteristics that violate the laws of spatial continuity. Such motion model displacements exceeding physical limits are marked as suspicious displacement data, which, together with suspicious velocity data, constitute continuous behavior analysis information, providing objective spatial anomaly evidence for subsequent violation detection operations.

[0137] In some embodiments, step S105 involves performing a violation detection operation on the simulated motion state of the target drone model across multiple motion state frames based on continuous behavior analysis information.

[0138] It should be noted that, based on the aforementioned continuous behavior analysis information, this embodiment of the application performs violation detection operations on the simulated motion state of the target drone model across multiple motion state frames. This step transforms the objective physical quantities independently calculated by the server into specific judgment criteria. Since this judgment logic is based on valid data that has undergone data verification and the recalculation results based on the game physics engine rules, rather than directly accepting the self-declared parameters reported by the target terminal, its detection results are objective. When the continuous behavior analysis information indicates that the simulated motion state of the target drone model exhibits abnormal characteristics exceeding physical limits, this embodiment of the application performs corresponding violation detection accordingly.

[0139] Reference Figure 5According to some embodiments of this application, before step S105, which performs violation detection operations on the simulated motion state of the target drone model in multiple motion state frames based on continuous behavior analysis information, the method may further include:

[0140] Step S501: Receive multiple game event data corresponding to each motion state frame from the target terminal; wherein, the multiple game event data are used to describe the game mechanism events triggered by the target drone model in each motion state frame;

[0141] Step S502: Based on the game event data corresponding to multiple motion state frames, perform mechanism behavior analysis on the target drone model to obtain mechanism behavior analysis information;

[0142] In step S105, based on continuous behavior analysis information, a violation detection operation is performed on the simulated motion state of the target UAV model in multiple motion state frames, which may include:

[0143] Step S503: Based on continuous behavior analysis information and mechanism behavior analysis information, perform violation behavior investigation operation on the simulated motion state of the target UAV model in multiple motion state frames.

[0144] This application, based on continuous behavior analysis, introduces a mechanism behavior analysis dimension based on game event data, forming a cross-checking system combining physical layer verification and rule layer verification. While continuous behavior analysis can identify abnormal movements of the target drone model exceeding physical limits from a kinematic perspective, some violations may be cleverly controlled to maintain physical parameters within a reasonable range while simultaneously exploiting loopholes in game rules to falsely report critical events. Game event data, as reported information describing game mechanism events triggered by the target drone model, can carry logical states related to track rules, mechanism interactions, and performance records, providing the target server with a rule verification entry point independent of physical motion parameters. By executing mechanism behavior analysis and continuous behavior analysis in parallel, this application allows for cross-verification of the target terminal's reported data from two independent dimensions: physical authenticity and rule compliance, reducing the risk of a single verification dimension being selectively bypassed.

[0145] In step S501 of some embodiments, multiple game event data corresponding to each motion state frame are received from the target terminal; wherein, the multiple game event data are used to describe the game mechanism events triggered by the target drone model in each motion state frame;

[0146] It should be noted that, in this embodiment, the target terminal receives multiple game event data corresponding to each motion state frame. Game event data are logical event messages reported by the target terminal to the server when a game mechanic event is triggered in a specific motion state frame. These messages describe the game mechanic events triggered by the target drone model in each motion state frame. Game mechanic events refer to key node behaviors defined in the game logic that are related to track rules or competitive mechanisms, such as passing through gates in the track, completing a specific section, or triggering a score record. Unlike drone state data packets that describe physical motion states, game event data focuses on reporting the logical results of the target drone model's interaction with the game world, rather than its kinematic parameters. By receiving this data, this embodiment obtains game rule-level event information claimed by the target terminal as occurring at a specific moment.

[0147] In step S502 of some embodiments, based on game event data corresponding to multiple motion state frames, mechanism behavior analysis is performed on the target drone model to obtain mechanism behavior analysis information;

[0148] It should be noted that, based on game event data corresponding to multiple motion state frames, the target server performs mechanism behavior analysis on the target drone model to obtain mechanism behavior analysis information. The technical principle of mechanism behavior analysis is that, in this embodiment, it does not directly accept game mechanism events unilaterally reported by the target terminal. Instead, it independently recalculates and verifies the authenticity of game mechanism events based on a set of verified historical trajectory and state data of the target drone model cached on the server side, combined with the spatial and logical definitions of relevant mechanism elements in the game map. This analysis process is based on the game's built-in rule system. By comparing the event triggering conditions claimed by the target terminal with the spatial location, time sequence, and collider parameters independently controlled by the server, it determines whether the game mechanism event conforms to the preset triggering logic of the game rules. The mechanism behavior analysis information records the verification results of such rule conformity, reflecting the authenticity of the target drone model's behavior at the game mechanism level.

[0149] Reference Figure 6 According to some embodiments of this application, the mechanism behavior analysis information includes the mechanism trigger verification result. Step S502 performs mechanism behavior analysis on the target drone model based on the game event data corresponding to multiple motion state frames to obtain mechanism behavior analysis information, which may include:

[0150] Step S601: Obtain the location of the target drone model on the game map. Figure 3 3D model and collider parameters;

[0151] Step S602: If multiple game event data contain mechanism event data, determine the corresponding motion state frame as the mechanism trigger frame;

[0152] Step S603: Call the set of target historical trajectory data and status data cached before the mechanism trigger frame; wherein, the target historical trajectory is the historical trajectory data of the target UAV model before the mechanism trigger frame;

[0153] Step S604, based on the ground Figure 3 The spatiotemporal logic recalculation and determination are performed on the dimensional model, collision body parameters, target historical trajectory data, and state data set to obtain the mechanism trigger verification result.

[0154] This application embodiment demonstrates a server-side independent verification process centered around mechanism trigger verification in mechanism behavior analysis. Regarding event information reported by the target terminal claiming to have triggered a game mechanism, this application embodiment does not directly accept this unilateral statement. Instead, it independently recalculates and determines the spatiotemporal dimensions based on the server-side cached static geometric data of the game world and the cached dynamic historical motion data of the target drone model, thereby verifying the authenticity of the mechanism trigger event.

[0155] In some embodiments, step S601 involves obtaining the location of the target drone model on the game map. Figure 3 3D model and collider parameters;

[0156] It should be noted that the embodiments of this application obtain the location of the target drone model on the game map. Figure 3 3D model and collider parameters. Figure 3 A 3D model refers to the geometric representation of a game map in three-dimensional space, including the spatial coordinates and geometric shape information of game elements such as tracks and mechanisms. Collision parameters, on the other hand, define the spatial boundary parameters that define the effective trigger range of interactive elements such as mechanisms in three-dimensional space, typically existing in the form of bounding boxes, collision meshes, or trigger volumes. These parameters are pre-stored on the server as basic static data of the game world, forming an objective spatial benchmark for mechanism trigger verification, ensuring that the verification process does not rely on potentially tampered map data loaded locally on the target terminal.

[0157] In step S602 of some embodiments, if multiple game event data include mechanism event data, the corresponding motion state frame is determined as the mechanism trigger frame;

[0158] It should be noted that this application embodiment checks whether multiple game event data contain mechanism event data. If so, the corresponding motion state frame is identified as a mechanism trigger frame. Mechanism event data refers to a logical event message reported by the target terminal, claiming that the target drone model triggered a certain type of mechanism in the game at a specific moment; a mechanism trigger frame is a motion state frame marked as the occurrence of such a claimed triggering event, representing the time node of the mechanism interaction claimed by the target terminal. Through this identification step, this application embodiment locates key frames that need to be verified from the continuous game event data stream, concentrating subsequent verification resources on these specific moments when mechanism interactions are claimed to have occurred.

[0159] In some embodiments, step S603 involves calling a set of target historical trajectory data and status data cached before the mechanism trigger frame; wherein, the target historical trajectory is the historical trajectory data of the target UAV model before the mechanism trigger frame;

[0160] It should be noted that this application embodiment calls the target historical trajectory data and state data set cached before the trigger frame. The target historical trajectory data refers to the historical spatial position sequence of the target UAV model in each motion state frame before the trigger frame, cached by the server after data verification, recording the complete motion path of the target UAV model before reaching the claimed trigger time; the state data set is the structured physical parameter set corresponding to each historical motion state frame, after decoding and verification. The technical significance of calling this data is that this application embodiment needs to understand the objective motion state of the target UAV model before the claimed trigger mechanism, so as to determine whether its motion path truly meets the spatiotemporal conditions required by the trigger mechanism in subsequent recalculation.

[0161] Step S604 in some embodiments, based on Figure 3 The spatiotemporal logic recalculation and determination are performed on the dimensional model, collision body parameters, target historical trajectory data, and state data set to obtain the mechanism trigger verification result.

[0162] It should be noted that the embodiments of this application are based on the ground Figure 3The system uses a 3D model, collider parameters, target historical trajectory data, and state data set to perform spatiotemporal logic recalculation to determine the triggering mechanism, thus obtaining the mechanism trigger verification result. The technical principle of this spatiotemporal logic recalculation is that, in this embodiment, the theoretical spatial position of the target UAV model at the trigger frame is independently calculated using the aforementioned static environmental parameters and dynamic historical data. This position is then compared with the effective trigger space defined by the mechanism collider parameters. Simultaneously, the system combines the target's historical trajectory data to verify whether its movement path possesses the temporal continuity and spatial reachability required to trigger the mechanism. This determination process is entirely executed on the server side. By cross-checking the triggering time claimed by the target terminal with the theoretical triggering conditions independently derived by the server, it determines whether the triggering behavior described by the mechanism event data conforms to the game's built-in physical and logical rules. The mechanism trigger verification result records the result of this independent recalculation, reflecting the authenticity of the mechanism triggering event reported by the target terminal.

[0163] It should be understood that, Figure 3 The acquisition of the dimensional model and collider parameters establishes an immutable spatial benchmark for verification; the identification of mechanism event data focuses the verification on the keyframes where interactions are claimed to have occurred; the retrieval of target historical trajectory data and state data sets provides verified objective motion evidence; and the final spatiotemporal logic recalculation judgment integrates the above static benchmark and dynamic evidence to form a verification result independent of the target terminal's declaration. This demonstrates the server-side technical concept of independently verifying game rule events by combining local static data with cached dynamic data, ensuring the objectivity and reliability of mechanism behavior analysis information.

[0164] Reference Figure 7 According to some embodiments of this application, the mechanism behavior analysis information also includes time-related anomaly information. Step S502, based on game event data corresponding to multiple motion state frames, performs mechanism behavior analysis on the target drone model to obtain mechanism behavior analysis information, which may include:

[0165] Step S701: Obtain the theoretical limit time and the time limit conversion factor corresponding to the theoretical limit time for the target drone model in the game physics engine;

[0166] Step S702: Based on the game event data corresponding to multiple motion state frames, determine the motion time from the motion start event to the motion end event;

[0167] Step S703: Based on the theoretical limit time and the time limit conversion factor, perform abnormal time consumption investigation on the motion consumption time to obtain abnormal time information.

[0168] This application extends mechanism behavior analysis from mechanism trigger verification to the time dimension. By establishing a theoretical limit time benchmark based on a game physics engine, it independently verifies the actual time taken for a target drone model to complete a specific movement process. The technical concept is that even if the target terminal does not exhibit obvious anomalies in physical motion parameters and mechanism trigger event reporting, it may still illegally compress the actual movement time to obtain false scores. The time dimension verification, by introducing the preset limit time boundary of the game physics engine, provides a temporal verification perspective independent of spatial interaction for rule compliance determination, thus forming a complete coverage of mechanism behavior analysis together with mechanism trigger verification.

[0169] In some embodiments, step S701 involves obtaining the theoretical limit time for the target drone model in the game physics engine, and the time limit conversion factor corresponding to the theoretical limit time.

[0170] It should be noted that this application embodiment obtains the theoretical limit time for the target drone model in the game physics engine and the corresponding time limit conversion factor. The theoretical limit time refers to the shortest possible time to complete a specific motion process calculated by the game physics engine through physical simulation based on track geometry parameters, target drone model power configuration, and environmental constraints. It represents the performance boundary achievable by legal operation under ideal conditions. The time limit conversion factor is a predetermined proportional coefficient less than 1, used to further define the theoretical limit boundary of human operation based on the theoretical limit time, to exclude unattainable values ​​caused by extreme idealization assumptions. Based on these two parameters, this application embodiment establishes a time determination benchmark that has a physical basis and takes into account the feasibility of actual operation.

[0171] In step S702 of some embodiments, the motion time from the start event to the end event is determined based on the game event data corresponding to multiple motion state frames.

[0172] It should be noted that this application embodiment determines the motion time from the start event to the end event based on game event data corresponding to multiple motion state frames. The start event and end event refer to the time points when the target drone model, as described by the game event data, triggers a specific game mechanism, such as the start signal and finish line crossing signal. The motion time is the difference between the timestamps corresponding to these two events, representing the actual time taken for the target terminal to claim to complete the motion process. This determination process relies on the server receiving and parsing the game event data reported by the target terminal, extracting the timestamp parameters marking the start and end states for calculation.

[0173] In step S703 of some embodiments, abnormal time consumption is investigated based on theoretical limit time and time limit conversion factor to obtain abnormal time consumption information.

[0174] It should be noted that this application embodiment uses a theoretical limit time and a time limit conversion factor to investigate abnormal time consumption during movement, thereby obtaining time-related abnormal information. The technical principle of abnormal time consumption investigation is as follows: This application embodiment first multiplies the theoretical limit time by the time limit conversion factor to obtain an effective limit threshold for actual judgment; then, it compares the claimed movement time of the target terminal with this effective limit threshold. If the movement time is less than the effective limit threshold, it indicates that the claimed completion time of the target terminal exceeds the theoretical limit boundary of human operation, suggesting that the time data has been illegally tampered with or that a game vulnerability has been exploited to skip the normal movement process. Such movement time exceeding the limit boundary is marked as time-related abnormal information, which, together with the mechanism trigger verification result, constitutes mechanism behavior analysis information, providing objective time-series anomaly evidence for subsequent violation investigation operations.

[0175] It should be understood that the theoretical limit time and the time limit conversion factor establish a time benchmark based on physical simulation for anomaly detection; the parsing of game event data provides event node inputs for actual time consumption calculation; and anomaly time consumption detection based on these parameters transforms abstract physical limits into quantifiable time determination standards. This chain enables the server to identify potential time tampering violations through objective time comparison without relying on unilateral declarations from the target terminal. Combined with the aforementioned mechanism trigger verification, the mechanism behavior analysis information constructs a complete verification system for the server-side's compliance with the game rules of the target drone model from two dimensions: the authenticity of spatial interaction and the rationality of temporal sequence.

[0176] In step S503 of some embodiments, based on continuous behavior analysis information and mechanism behavior analysis information, a violation detection operation is performed on the simulated motion state of the target UAV model in multiple motion state frames.

[0177] It should be noted that this embodiment of the application performs violation detection operations on the simulated motion state of the target drone model in multiple motion state frames based on continuous behavior analysis information and mechanism behavior analysis information. The core technology of this step lies in establishing cross-validation logic between the physical dimension and the rule dimension. Continuous behavior analysis information reveals from a kinematic perspective whether the target drone model has abnormal motions exceeding the limits of the physics engine; mechanism behavior analysis information reveals from a game rule perspective whether the target drone model has falsely reported or forged key events. The two correspond to different violation methods and verification paths, and are independent yet complementary to each other. When the detection operation simultaneously refers to these two types of analysis information, this embodiment of the application can identify data tampering behaviors that appear normal at the physical level but have logical contradictions at the rule level, and can also confirm whether abnormal motion states at the physical level are accompanied by violations at the game rule level. This dual-dimensional cross-validation mechanism improves the coverage and accuracy of violation detection, enabling the server to build a more complete profile of abnormal behavior, thereby making more accurate violation detection results.

[0178] It should be understood that, in the embodiments of this application, the receipt of game event data provides a logical input for mechanism behavior analysis that is independent of physical data; the mechanism behavior analysis establishes a verification benchmark at the rule level through independent recalculation on the server side; the final investigation operation comprehensively judges the continuous behavior analysis information at the physical level and the mechanism behavior analysis information at the rule level, forming a progressive verification closed loop from the authenticity of physical movement to the compliance of game rules. In addition to pure physical calculation, the game's built-in mechanism is introduced as an auxiliary judgment basis, which enhances the server's ability to identify complex violation scenarios.

[0179] Reference Figure 8 According to some embodiments of this application, step S503, based on continuous behavior analysis information and mechanism behavior analysis information, performs a violation detection operation on the simulated motion state of the target UAV model in multiple motion state frames, which may include:

[0180] Step S801: Based on continuous behavior analysis information, determine the first number of abnormal continuous behaviors of the target UAV model in multiple motion state frames;

[0181] Step S802: Based on the mechanism behavior analysis information, determine the second number of abnormal mechanism behaviors of the target UAV model in multiple motion state frames;

[0182] Step S803: Based on the first number of consecutive abnormal behaviors and the second number of abnormal mechanism behaviors, perform violation behavior analysis to obtain violation behavior analysis results;

[0183] Step S804: Based on the results of the violation analysis, retrieve the corresponding review benchmark data from the pre-cached sets of state data;

[0184] Step S805: Based on the verification benchmark data, perform trajectory verification on the target UAV model to obtain the violation verification result;

[0185] Step S806: Based on the results of the violation review, perform a violation investigation operation.

[0186] This application's embodiments demonstrate the complete execution chain of violation investigation operations, forming a closed-loop judgment process that progresses from automated screening to refined review, from abnormal behavior quantification, comprehensive analysis, benchmark data retrieval, trajectory verification to final investigation execution. Continuous behavior analysis information and mechanism behavior analysis information reveal the abnormal characteristics of the target drone model from two dimensions: physical motion laws and game rule mechanisms, respectively. However, occasional anomalies in a single dimension may be caused by network fluctuations or operational errors and may not constitute conclusive evidence of violation. By separately counting the number of abnormal behaviors in both dimensions and then performing comprehensive analysis and trajectory verification, this application's embodiments can aggregate scattered anomalies into continuous and systematic behavior patterns, thereby reducing the probability of misjudgment and improving the reliability of the investigation conclusions.

[0187] In some embodiments, steps S801 to S802 involve determining a first number of abnormal continuous behaviors of the target UAV model in multiple motion state frames based on continuous behavior analysis information; and determining a second number of abnormal mechanism behaviors of the target UAV model in multiple motion state frames based on mechanism behavior analysis information.

[0188] It should be noted that, based on continuous behavior analysis information, this application's embodiments determine a first number of abnormal continuous behaviors of the target UAV model across multiple motion state frames; simultaneously, based on mechanism behavior analysis information, it determines a second number of abnormal mechanism behaviors of the target UAV model across multiple motion state frames. The first number of abnormal continuous behaviors refers to the cumulative number of suspicious velocity data or suspicious displacement data marked as exceeding physical limits during the continuous behavior analysis process; the second number of abnormal mechanism behaviors refers to the cumulative number of mechanism trigger verification results or time-related abnormal information marked as not conforming to the game rule triggering logic during the mechanism behavior analysis process. By transforming abstract analysis information into a countable number of abnormal behaviors, this application's embodiments provide a quantitative input basis for subsequent comprehensive judgment, enabling the investigation conclusions to be based on statistical significance rather than relying on a single isolated anomaly.

[0189] In some embodiments, step S803 involves performing violation behavior analysis based on a first number of consecutive abnormal behaviors and a second number of abnormal mechanism behaviors to obtain violation behavior analysis results.

[0190] It should be noted that this application embodiment analyzes violations based on a first number of consecutive abnormal behaviors and a second number of abnormal mechanism behaviors to obtain violation analysis results. This application embodiment cross-correlates the anomaly counts in the physical dimension with the anomaly counts in the rule dimension to evaluate the distribution pattern of abnormal behaviors of the target drone model throughout the game. If the number of anomalies in both dimensions reaches or exceeds their respective preset thresholds, or if the abnormal behaviors exhibit a sequential co-occurrence characteristic, it indicates that the abnormal state of the target drone model is persistent and consistent across multiple dimensions, suggesting a high degree of suspicion of systemic violations. The violation analysis results record this comprehensive evaluation conclusion, providing a basis for determining whether to initiate a deeper review.

[0191] In some embodiments, step S804 involves retrieving corresponding review benchmark data from pre-cached sets of state data based on the results of violation analysis.

[0192] It should be noted that, based on the results of violation analysis, this application retrieves the corresponding review benchmark data from pre-cached sets of state data. The review benchmark data refers to the set of original state data of the verified target drone model in each motion state frame, cached by the server after data verification. This data includes complete three-dimensional coordinate parameters, timestamp parameters, and other physical state information. The significance of this technical step is that, once comprehensive analysis indicates a high degree of suspicion of violation, this application requires backtracking and extracting the original data material for in-depth review, ensuring that the review process is based on authentic and complete historical records, rather than relying on potentially tampered or compressed real-time streaming data.

[0193] In some embodiments, step S805 involves performing trajectory verification on the target UAV model based on verification benchmark data to obtain the violation verification result;

[0194] It should be noted that the embodiments of this application perform trajectory verification on the target drone model based on verification benchmark data to obtain the violation verification result. Trajectory verification refers to the server using the continuous three-dimensional coordinate parameters and timestamp parameters in the verification benchmark data to reconstruct the complete flight path of the target drone model in virtual three-dimensional space and compare it with the game map. Figure 3 The static environmental data, such as the 3D model and collision parameters, are overlaid and compared to visually verify the physical continuity and logical rationality of the flight trajectory. This process can be executed automatically by the server or provided to judges or review systems for manual judgment through visual replay. The result of the violation review records the conclusion of this in-depth review, confirming or ruling out the suspected violation identified in the previous comprehensive analysis.

[0195] In this embodiment, the pre-cached and verified original state data sequence on the server is restored into an observable flight trajectory in a 3D virtual environment, and then spatiotemporally overlaid with static rule elements such as in-game mechanisms and collision objects, thereby providing an intuitive interface for verifying physical realism for the referee or review system. A feasible specific step is as follows:

[0196] From the pre-cached verification benchmark data, retrieve the set of state data of the target UAV model in multiple motion state frames that have been verified, as the flight data black box data;

[0197] Call the game Figure 3 Based on the 3D model and track collision parameters, a 3D virtual verification environment is constructed.

[0198] Based on the three-dimensional coordinate parameters and timestamp parameters in the flight data black box data, the complete flight trajectory of the target UAV model is reconstructed in a three-dimensional virtual verification environment;

[0199] The reconstructed complete flight trajectory is overlaid with the collision parameters of the mechanism in the three-dimensional virtual verification environment to generate a trajectory visualization verification interface;

[0200] Based on the trajectory visualization verification interface, it is determined whether there is any abnormal movement state of the drone in the flight trajectory, including unexplained teleportation, clipping anomalies, and whether the mechanism door is established, so as to obtain the verification result of the violation.

[0201] In some embodiments, step S806 involves performing a violation investigation operation based on the violation review results.

[0202] It should be noted that this embodiment of the application performs violation investigation operations based on the violation review results. If the review results confirm the existence of anomalies such as inexplicable trajectory teleportation, clipping, or logical inconsistencies in mechanism triggering, the server implements corresponding penalty measures; if the review results indicate that the anomaly can be explained by network fluctuations or legitimate operations, the suspicion is withdrawn and normal match data is retained. This step transforms the conclusions of the aforementioned quantitative analysis, comprehensive evaluation, and in-depth review into the final processing action, completing a full closed loop from data input to behavior determination.

[0203] It should be understood that the quantitative statistics of abnormal continuous behavior and abnormal mechanism behavior provide a data foundation for comprehensive judgment; violation behavior analysis integrates scattered anomalies into behavioral pattern assessment; the retrieval of review benchmark data ensures the data integrity of in-depth analysis; trajectory review achieves refined verification of anomaly suspicion through spatiotemporal reconstruction; and the final investigation operation makes a definitive decision based on the review conclusion. This chain reflects the hierarchical investigation concept from automated anomaly detection to confirmatory review, taking into account both investigation efficiency and judgment accuracy, enabling the server to achieve efficient screening in ordinary scenarios and initiate in-depth review in suspicious scenarios, thereby constructing a complete violation behavior investigation system from shallow to deep and from quantity to quality. By cross-correlating the first number of abnormal continuous behaviors with the second number of abnormal mechanism behaviors, the embodiments of this application can identify a systematic anomaly pattern with multi-dimensional consistency, avoiding misjudgment caused by a single isolated anomaly; and the trajectory review based on pre-cached review benchmark data further transforms the abstract anomaly count into observable and verifiable spatiotemporal trajectory evidence, making the violation behavior investigation operation based on an objective and complete physical reconstruction.

[0204] It should be understood that the reception and decoding of UAV status data packets provides structured input for data verification and continuous behavior analysis; data verification filters out noisy and invalid data for continuous behavior analysis; continuous behavior analysis reveals physical motion anomalies through spatiotemporal correlation calculations of multi-frame data; and the final violation detection operation makes a judgment based on the aforementioned objective analysis results. This overall solution, from raw data reception, decoding, dual verification, continuous behavior analysis to violation detection, embodies the core technical approach of the server side targeting the high-frequency physical synchronization characteristics of UAV racing games. It can achieve independent server-side identification of target terminal data tampering behavior through the establishment of continuous physical constraints.

[0205] Reference Figure 9 , Figure 9 This illustration shows the hardware structure of an electronic device according to another embodiment. The electronic device may include:

[0206] The processor 901 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0207] The memory 902 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 902 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 902 and is called and executed by the processor 901 to execute the method for detecting violations in the drone racing game according to the embodiments of this application.

[0208] The input / output interface 903 is used to implement information input and output;

[0209] The communication interface 904 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0210] Bus 905 transmits information between various components of the device (e.g., processor 901, memory 902, input / output interface 903, and communication interface 904);

[0211] The processor 901, memory 902, input / output interface 903, and communication interface 904 are connected to each other within the device via bus 905.

[0212] This application also provides a computer program product, which includes a computer program. The processor of a computer device reads and executes the computer program, causing the computer device to perform the aforementioned method for detecting violations in a drone racing game.

[0213] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in this disclosure and the foregoing drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “including,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatuses.

[0214] It should be understood that in this disclosure, "at least one item" means one or more, and "more than one" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0215] It should be understood that in the description of the embodiments of this application, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

[0216] In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0217] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0218] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0219] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this disclosure. The aforementioned storage medium may include: a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and other media capable of storing program code.

[0220] It should also be understood that the various implementation methods provided in this application can be combined arbitrarily to achieve different technical effects.

[0221] The above is a detailed description of the embodiments of this disclosure. However, this disclosure is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this disclosure. All such equivalent modifications or substitutions are included within the scope defined by the claims of this disclosure.

Claims

1. A method for investigating violations in drone racing games, characterized in that, Applied to the target server, including: Receive UAV state data packets corresponding to multiple motion state frames from the target terminal; wherein, the UAV state data packets are used to describe the simulated motion state of the target UAV model in each of the motion state frames; Decode each of the UAV state data packets to obtain the state data set of the target UAV model corresponding to each of the motion state frames; The UAV status data packet and the status data set are validated to obtain the data validation result. Based on the state data set corresponding to multiple consecutive motion state frames, continuous behavior analysis is performed on the target UAV model to obtain continuous behavior analysis information. Receive multiple game event data corresponding to each of the motion state frames from the target terminal; wherein, the multiple game event data are used to describe the game mechanism events triggered by the target drone model in each of the motion state frames; Based on the game event data corresponding to multiple motion state frames, mechanism behavior analysis is performed on the target drone model to obtain mechanism behavior analysis information. The mechanism behavior analysis information includes mechanism trigger verification results. The mechanism behavior analysis, based on the game event data corresponding to multiple motion state frames, is performed on the target drone model to obtain mechanism behavior analysis information, including: Obtain the 3D model of the game map where the target drone model is located and the parameters of the collider; If multiple game event data include mechanism event data, the corresponding motion state frame will be determined as the mechanism trigger frame; The system retrieves the target historical trajectory data and the state data set cached before the trigger frame; wherein, the target historical trajectory is the historical trajectory data of the target UAV model before the trigger frame. Based on the map 3D model, the collision body parameters, the target historical trajectory data, and the state data set, a spatiotemporal logic recalculation judgment is performed to obtain the mechanism trigger verification result. Based on the continuous behavior analysis information and the mechanism behavior analysis information, the violation detection operation is performed on the target UAV model in the simulated motion state of multiple motion state frames.

2. The method for investigating violations in drone racing games according to claim 1, characterized in that, The mechanism behavior analysis information also includes time-related anomaly information. The mechanism behavior analysis, based on the game event data corresponding to multiple motion state frames, is performed on the target drone model to obtain mechanism behavior analysis information, including: Obtain the theoretical limit time for the target drone model in the game physics engine and the time limit conversion factor corresponding to the theoretical limit time; Based on the game event data corresponding to multiple motion state frames, determine the motion time from the motion start event to the motion end event; Based on the theoretical limit time and the time limit conversion factor, abnormal time consumption of the motion is investigated to obtain abnormal time information.

3. The method for investigating violations in drone racing games according to claim 1, characterized in that, The step of performing the violation detection operation on the simulated motion state of the target UAV model in multiple motion state frames based on the continuous behavior analysis information and the mechanism behavior analysis information includes: Based on the continuous behavior analysis information, a first number of abnormal continuous behaviors of the target UAV model in multiple motion state frames are determined; Based on the mechanism behavior analysis information, a second number of abnormal mechanism behaviors of the target UAV model in multiple motion state frames are determined; Based on the first number of abnormal continuous behaviors and the second number of abnormal mechanism behaviors, violation behavior analysis is performed to obtain violation behavior analysis results; Based on the analysis results of the violations, the corresponding review benchmark data is retrieved from each of the pre-cached state data sets; Based on the aforementioned verification benchmark data, the trajectory of the target UAV model is verified to obtain the verification results of violations. Based on the results of the violation review, the violation investigation operation is performed.

4. The method for investigating violations in drone racing games according to claim 1, characterized in that, The data verification results include data tampering verification results and data paradigm verification results. The data verification of the UAV status data packet and the status data set to obtain the data verification results includes: The hash integrity of the drone status data packet is verified to obtain the data tampering verification result. The data paradigm is validated on the state data set to obtain the data paradigm validation result.

5. The method for investigating violations in drone racing games according to claim 1, characterized in that, The continuous behavior analysis information includes suspicious speed data. The continuous behavior analysis of the target UAV model, based on the state data set corresponding to multiple consecutive motion state frames, yields continuous behavior analysis information, including: Obtain the theoretical maximum speed of the target drone model in the game physics engine; For each set of state data, extract the corresponding three-dimensional coordinate parameters and timestamp parameters of the target UAV model; Based on the corresponding three-dimensional coordinate parameters and timestamp parameters of each consecutive motion state frame, the instantaneous motion velocities of the target UAV model are calculated. Based on the theoretical maximum speed, abnormal speeds are detected in multiple instantaneous speeds of the motion to obtain the suspicious speed data.

6. The method for investigating violations in drone racing games according to claim 1 or 5, characterized in that, The continuous behavior analysis information also includes suspicious displacement data. The step of performing continuous behavior analysis on the target UAV model based on the state data set corresponding to multiple consecutive motion state frames to obtain continuous behavior analysis information further includes: Obtain the theoretical maximum speed and theoretical maximum acceleration of the target drone model in the game physics engine, and obtain the inter-frame time difference between adjacent motion state frames of the target drone model; Based on the theoretical maximum velocity, the theoretical maximum acceleration, and the inter-frame time difference, the theoretically achievable displacement threshold is calculated. For each set of state data, extract the corresponding three-dimensional coordinate parameters of the target UAV model; For each pair of adjacent motion state frames, based on the three-dimensional coordinate parameters of the adjacent motion state frames, multiple motion model displacements of the target UAV model are calculated; Based on the theoretically achievable displacement threshold, abnormal displacements of multiple motion models are investigated to obtain the suspicious displacement data.

7. An electronic device, characterized in that, include: The system includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method for detecting violations in drone racing games as described in any one of claims 1 to 6.

8. A computer-readable storage medium, characterized in that, The storage medium stores a program that is executed by a processor to implement the method for detecting violations in a drone racing game as described in any one of claims 1 to 6.

Images