1 Introduction↩︎

Video games have grown immensely in popularity and profitability among today’s youngsters. Integrity and fair play are essential components of the gaming experience, especially in contemporary multiplayer games. First-person shooter (FPS) games are the genre in which the majority of these modern games belong. First-person shooter games are getting more and more popular, drawing thousands of gamers every day. At the forefront are games like Call of Duty: Modern Warfare, Valorant, Counter-Strike: Global Offensive, and many more. Balanced, skill-based encounters are essential for competitive and online first-person shooter games, allowing players to assess their skills on an even playing field.

Authentic and fair gameplay becomes more difficult to maintain as online gaming communities and organizations grow. Modern first-person shooter games are more complicated than ever, which causes more issues for gamers and less equitable gameplay. This is frequently the result of specific groups getting hold of game codes and abusing the title and its assets. This is when it becomes clear that an anti-cheat system is essential in the current game world.

The video game industry has grown rapidly in recent years as a result of developments in social connections, technology, and entertainment. The business has seen a rise in competitive esports gaming and grabbing the interest of millions with a huge worldwide audience from many cultures, regions, and styles. Due to which the popularity of playing FPS games have risen to a large extent in the gaming community. The gaming business has reached new heights because of technological advancements including amazing graphics and visuals, a real gaming experience, improved sound quality and other elements. This trend has important economic ramifications because game publishers and developers earn billions of dollars annually through esports gaming competitions, hardware sales, and game creation. The Online Multiplayer mode in esports games give players an opportunity to compete with different players around the world due to which the particular player can achieve its global rank among different players. Also the multiplayer functionality of video games promotes extensive communities and social interactions among the players around the world. Additionally, the video game industry promotes creativity and innovation.

Currently, the number of players using cheating techniques such as aimbots, wallhacks, and speed hacks are on the rise. Due to which the fairplay among the players in the multiplayer mode of the game is decreasing gradually. To detect these foul activities, multiple cheating detection techniques are formed including client-side anti-cheats and server-side anti-cheats. Client-side anti-cheats typically scan processes that read game’s memory or search for untrusted libraries and processes. Server-side anti-cheats, on the other hand, employ more elaborate methods, which can include log analysis or deep learning techniques for identifying cheating. Currently, we will be only focusing on detecting aimbot cheat using server-side techniques in the game Counter-Strike: Global Offensive.

2 Literature Survey↩︎

The need for anti-cheat in video games is growing, notably in the context of FPS games, there have been many efforts made in this field.

The GAN-Aimbots is a technique that was used to create an aimbot that mimics the mouse movements of a normal user and it was undetectable to most of the common anticheats. However, the results of this technique decreased and was caught when a strong aimbot was used by the cheater. Even though it was less likely to be considered suspicious by the experienced judges. The dataset that was considered for testing was of 23 players who played a few matches without cheat, a few with lightweight cheats, and the remaining with strong aimbots [1].

Cheating in games has been increasing day by day nowadays. If some of the players cheat then it affects the gaming behavior of other players in a bad way who play the game with sincerity. A statistical model was developed to understand such effect and consequences of it which concluded that continuous cheating amplify the spread of this problem and make it even more widespread and difficult to manage. This statistical model considered the dataset of about 40 servers [2].

The Dynamic Bayesian approach was used to identify cheater by considering their behavior in the game. The behavior of a normal player and a cheater will be different because the probability threshold of a cheater fluctuates while a generous player’s probability remains below the threshold. This approach also checks the aiming precision of various players. The training data used for this approach consisted of 16 players and it was trained and tested by the number of players cheating and other were normal players [3].

The interview-based study was done to understand the behavior of computer gamers experience and how they consider certain conditions. Cheating also affects the gaming experience of a gamer. The experiences in first-person shooter games are influenced by their goals and the variety in the game. If the goals and requirements of the gamer are not satisfied then it may have a bad impression on the gamer.This study considered over 12 people who were interviewed [4].

Datasets used SWAT(secure water treatment), WADI(water distribution), MSL(mars science laboratory rover). RNN based model shows superiority in terms of temporal dependencies but RNN restricts parallelization because it computes its output sequentially whereas transformer takes one sequence one at a time so parallel processing is possible and GNN based model provides results better than the others because dimensions of the dataset increases [5].

Dataset was collected using log files which were generated during gameplay and from the log files features were extracted such as hits taken, hits given, damage dealt and damage taken. Decision tree is highly dependent on individual player configuration which also leads to various numbers of false positives so it can only be used as a classifier. The naive bayes classifier was only applicable to single behavior dependency on categorical data. The keystroke dynamics based SVM’s had a wide array of accuracy ratings. This could be because of the huge numbers of features being considered [6].

Dataset used here was collected in real world context of players from the game Counter-Strike: Global Offensive. Results show that the model was able to clearly distinguish between fair and fraudulent gameplay. In each domain, a new hyperparameter search should be performed to find good functioning architecture. Cross validation was able to show that the model learnt things that are not player specific. Model detected unfair play even when they weren’t exposed to their behavior [7].

To detect aimbot machine learning classification techniques such as Support Vector Machine were used. To classify excellent players from cheaters behavioral data was used. It is determined that players who cheat have different behavioral patterns than genuine players. First classification is done to identify cheating and excellent players then another classification is used to classify cheating players from excellent players. The authors created a system named Aimdetect for Counter-Strike 1.6 and Counter-Strike: Global Offensive. The game servers were hosted publicly for others to join and play. Through this, they were able to maintain a low false positive rate as small as 0.7% [8].

Instead of using complete time series data for detecting cheating players the time series data is divided into frames of 60 seconds. Then statistical methods are applied to those 60 seconds of data to create features like the Number of Records, Number of Visible-Target Rows, Visible-To-Total Ratio, and more. These features are then fed to 2 classification models - Logistic Regression and Support Vector Machine. The system was able to achieve a high prediction accuracy of nearly 90% [9].

The authors discussed two new features - Time on Target (ToT) and Cursor Acceleration when acquiring aim (AccA). It was discovered that ToT was a better feature than AccA. Statistical method two-sample Kolmogorov-Smirnov tests were used to identify differences between honest and cheating players [10].

To detect Wall hack cheats four new features were discussed - Frequency of illegal traces, consecutively of illegal traces, Distance to world traces, Distance to entity traces. The intuition behind these features was that players who are using visual-based cheats don’t see entities such as a wall or other obstacles and have different behaviors near these entities. The paper then discussed that the system was able to provide an accuracy of 70% [11].

Detecting cheats in FPS games through visual analysis involves using advanced techniques like Deep Neural Networks (DNNs). These networks are trained on a bunch of frames containing both cheating and fair gameplay instances. By doing this, the DNN learns to distinguish between the two by looking at visual cues in the frames. The best DNN architecture for this task combines both global and local features. Although the DNN works really well, it doesn’t give exact numbers for metrics like sensitivity and precision. The visual cheats are classified in 3 categories minimal, medium and full each of which provides a different level of visual assistance. The dataset used for training includes frames from two popular shooter games, referred to as Game1 and Game2 in the paper [12].

When looking at ways to stop cheating in video games, various methods can be used. These methods are compared across different categories like how well they handle tampering, how easy they are to put into the game, how much they slow down the game, how invasive they are, and how well they work with different types of games. There are two main types: ones that work on the player’s computer (client-side) and ones that work on the game’s server (server-side). Server-side methods are good at stopping cheating but can make the game slow because they use a lot of resources. Client-side methods are lighter on resources, but a technically skilled person (cheater) might find ways to get around them more easily [13].

There’s this new thing called TSViz that helps us understand deep learning models, especially convolutional deep learning (CNN) models. With TSViz, we can explore and analyze the network in different ways and at different levels. It helps us figure out which parts of the network are making specific predictions and why certain filters in the network are important. Plus, it helps us see how well the network can handle noisy data that might mess up its predictions. They used an Internet Traffic Dataset to train the model for time-series forecasting, with inputs consisting of 50 time-steps. They trained it using small batches of 5 till 5000 epochs [14].

In  [15] proposed a generic system architecture for aimbot detection in FPS games, outlining potential deep learning and statistical approaches for tackling the problem. The present study builds directly upon that foundational architecture, extending it with a concrete implementation and systematic experimentation, evaluating 9 LSTM model configurations across 6 dataset configurations with varying temporal context windows, and introducing a comparative analysis against a Decision Tree baseline with particular emphasis on minimising false positive rates for production anti-cheat deployment.

3 System Architecture↩︎

Aimbot cheats make it much easier for players to dominate. Because of this, players that utilize aimbot cheats often don’t give other aspects of the game priority. This may include avoiding most of the tools provided by the game itself or not being affected by the movement inaccuracy which other individuals might have experienced when shooting. A few significant traits that are useful in recognizing anomalous plays include the behavioral data paired with the time series data that is generated by the players, such as player placement and the rate at which they react during battles. These characteristics, including time series data and player behavioral information, will be discovered in an attempt to distinguish between honest and dishonest individuals. We build a server-side aimbot detection classifier called "YAACS" (Yet Another Anti Cheat System) incorporating these features. A parser, a model developed using deep learning, and intermediate concentrations connection tools aimed for interaction with the game server will be included in this system.

3.1 Demo Files↩︎

The Source recorder is employed to create demo files, which include recorded events that may be viewed and replayed in-game. Playing back demo files takes you back to that specific tick in the game’s history. In the game, a tick is a particular point in time. Professional Counter-Strike matches tend to be played at a 128 tickrate, which means that 128 game state modifications occur in a second between the client and server. The tick rate is an indicator of how often the server updates its state. Additionally, the demonstrations are captured at a distinct pace known as the snapshot rate. The number of changes written to the demo file each second is determined by the snapshot rate. Usually, this is adjusted lower to limit bandwidth use to 32 or 64 ticks. Demos with a snapshot duration of 128 ticks and a tick rate of 128 ticks will be taken into consideration for our system as they will precisely offer game state information.Usually, this is adjusted lower to limit bandwidth use to 32 or 64 ticks. Demos with a snapshot duration of 128 ticks and a tick rate of 128 ticks will be taken into consideration for our system as they will precisely offer game state information.

3.2 Parsing, Feature Engineering, and data cleaning↩︎

The format of these demo files is different from what we require; therefore, a parser that can correctly parse such demo files must be used to resolve this problem. We are going to use a Python-demo parser for our system. This tool can provide us with access to the game events that we can monitor. Features such as player position, yaw, pitch, current tick, velocity between ticks, and more will be the main focus of our system. The deep learning model would then use these features after they have been cleaned, normalized, and standardized.

3.3 Game Server↩︎

The game server holds the actual game state. Clients fetch and update this game state as the game progresses. As the game is multiplayer this adds latency to the clients. In CounterStrike: Global Offensive latency is measured as the roundtrip time required for data to be transferred between client and server. This means if the game server is on time 150ms and the clients are on a latency of 50ms then the client state is at 125ms. To minimize this latency clients generally include mechanisms such as interpolation which eases out these effects.

3.4 Intermediatory Connection Utilities↩︎

Events are recorded to the demo file and players are linked to the game server. Our model requires to receive the parsed demo file from the game server in some way. We can accomplish this by using a script to determine whether the current match is finished. Following that, we move the match’s parsed demo file from the game server to the web server.

3.5 Web Server (Frontend and Backend)↩︎

It displays all the names of the players in the match, shows which of them were cheating, and displays reports regarding their movements, activity, results, etc. Frontend’s access is given to the admin of our Anti-cheat system. Backend ensures the website performs correctly, focusing on databases, back-end logic, and application programming interface (APIs)

3.6 Messaging Queue↩︎

Facilitates asynchronous communication between components of the YAA-C system, enabling seamless coordination and scalability in processing tasks and data flows.

3.7 Charter↩︎

Performs the task of creating all the analysis charts and diagrams from the match data obtained for post-match analysis.

3.8 Uploader↩︎

Performs the task of uploading data from the charter and model to the Mongo.

3.9 Mongo↩︎

It facilitates storing data of all analysis charts created and storing results of the model.

3.10 S3↩︎

S3 is used for storing the analyzed files for future analysis and improvement in the system.

3.11 Deep Learning Model↩︎

LSTM, RNN and decision tree will be the model we choose to distinguish between honest and dishonest players. RNNs meet our features well because they can be applied to time-series data and we are choosing decision tree to compare the results.

4 Methodology↩︎

4.1 Feature Identification↩︎

We need to track multiple features from the game server so that we can build an effective model. All the features passed from the game server are categorized into 2 types:

• Features used in model: These features are directly fed to the model we created. We will be further referring to these features as alpha features.

• Features used for monitoring and reporting: These features are primarily used for player identification, monitoring, and post-match report generation. We are calling these features beta features.

4.2 Feature Extraction and Engineering↩︎

We will be extracting the following features through our custom-built parser from the demo files provided by the game server.

1. Current Tick (beta feature): Denotes the current fight tick, initiating at 0 and advancing progressively. For instance, if there are ticks at (10, 11, 12, 14, 15), and the tick at 13 is missing, the new sequence of ticks will be (0, 1, 2, 4, 5). The Current Tick is computed as: \[\text{Current Tick} = \text{tick} - \text{Min Tick}\]

2. Player Id (beta feature): Represents the identifier of the player currently under tracking.
   

3. Player Name (beta feature): Indicates the name of the player currently being tracked.
   

4. Player Position (beta feature):

   • X: Current X coordinate of player.

   • Y: Current Y coordinate of player.

   • Z: Current Z coordinate of player.
     

5. Delta Position (alpha feature): Difference between the previous position of the player and the current position of the player.

   • \(\Delta X = X_{\text{currentTick}} - X_{\text{previousTick}}\)

   • \(\Delta Y = Y_{\text{currentTick}} - Y_{\text{previousTick}}\)

   • \(\Delta Z = Z_{\text{currentTick}} - Z_{\text{previousTick}}\)
     

6. View Angles (beta feature): Refers to the view angles of tracked players, excluding roll as it is typically unused in FPS games.

   • Yaw: Represents the horizontal direction where the player is currently looking, ranging from 0 to 359 degrees. For example, if the player is currently facing a yaw of 3 degrees and begins to move the mouse to the right, the subsequent yaws will follow a sequence such as \([2, 1, 0, 359, 358, 357, \ldots]\).

   • Pitch: Represents the vertical direction where the player is currently looking, with values ranging from \(-90\) to \(90\) degrees. For example, if the player is currently looking at a pitch of \(-6\) degrees and begins moving the mouse downward, the subsequent pitches will follow a sequence of angles which will form
     \([-5, -4, -3, -2, -1, 0, 1, 2, 3, \ldots]\).
     

7. Delta View Angles (alpha feature): Difference between the player’s previous and current view angles, consisting of:

   • \(\Delta\text{Yaw}\): The difference between the player’s previous and current yaw angles.

   • \(\Delta\text{Pitch}\): The difference between the player’s previous and current pitch angles.
     

8. Delta Aim Arc (alpha feature): Represents the length of the arc formed in 3D space with \(R\) as the distance between the player and the target, and two spherical angles \(\{\text{yaw}_{\text{previous tick}}, \text{pitch}_{\text{previous tick}}\}\), \(\{\text{yaw}_{\text{current tick}}, \text{pitch}_{\text{current tick}}\}\) after converting to space vectors.
   

9. Is Flashed (alpha feature): Indicates whether the player is currently flashed. The values are between 0 and 1, where 0 represents that the player is not flashed at all, and 1 represents that the player is fully flashed. Intermediate values are interpolated using a bezier curve.
   

10. Is Crouching (alpha feature): Indicates whether the player is currently crouching. A value of 1 indicates that the player is in between standing and crouching, a value of 2 indicates that the player is completely crouched, and a value of 0 indicates that the player is standing.
    

11. Is In Air (alpha feature): Indicates whether the player is currently in the air and not touching the ground. True represents that the player is in the air, while False represents that the player is on the ground.
    

12. Utility Damage Done (alpha feature): Represents the amount of utility damage done until this tick (inclusive), including HE grenades and Molotov cocktails as the damaging utility.
    

13. Support Utility Used (alpha feature): Represents the number of utility supports done until this tick (inclusive), including flashbang and smoke grenades as support utilities.
    

14. KDR (alpha feature): Represents the Kill-Death Ratio of the player.
    

15. Is Firing (alpha feature): Indicates whether the player is currently shooting the current weapon.
    

16. Target Id (beta feature): Id of the player who is currently being attacked in fight.
    

17. Target Name (beta feature): Name of the player who is currently being attacked in fight.
    

18. Delta View Angles (alpha feature): Difference between the player’s previous and current view angles, consisting of:

    • \(\Delta\text{Yaw}\): The difference between the player’s previous and current yaw angles.

    • \(\Delta\text{Pitch}\): The difference between the player’s previous and current pitch angles.
      

19. Target Position (beta feature):

    • targetX: Represents the current X coordinate of the target player.

    • targetY: Represents the current Y coordinate of the target player.

    • targetZ: Represents the current Z coordinate of the target player.
      

20. Target Delta Position (alpha feature):

    • targetDeltaX: Represents the difference between the current tick’s X coordinate and the previous tick’s X coordinate for the target player.

    • targetDeltaY: Represents the difference between the current tick’s Y coordinate and the previous tick’s Y coordinate for the target player.

    • targetDeltaZ: Represents the difference between the current tick’s Z coordinate and the previous tick’s Z coordinate for the target player.
      

21. Damage Done (alpha feature): Represents the total damage done to the enemy, including armor.
    

22. Distance To Target (alpha feature): Represents the distance of the player to the target in game units, where 1 game unit equals 1 inch.
    

23. Target Hit Area (alpha feature): On which body part the target player was shot at. Possible values include:

    • HITGROUP_GENERIC: This denotes explosion damage.

    • HITGROUP_HEAD: This denotes damage to the player’s head.

    • HITGROUP_CHEST: This denotes damage to the player’s chest.

    • HITGROUP_STOMACH: This denotes damage to the player’s stomach.

    • HITGROUP_LEFTARM: This denotes damage to the player’s leftarm.

    • HITGROUP_RIGHTARM: This denotes damage to the player’s rightarm.

    • HITGROUP_LEFTLEG: This denotes damage to the player’s leftleg.

    • HITGROUP_RIGHTLEG: This denotes damage to the player’s rightleg.

    • HITGROUP_GEAR: This denotes damage to the player’s gear.
      

24. Weapon Used (alpha feature): Which weapon was used in "weapon_weaponName" format.
    

25. Weapon Category (alpha feature): Represents the weapon’s category. Possible categories include:

    • weapon_category_pistol

    • weapon_category_smg

    • weapon_category_ar

    • weapon_category_sniper

    • weapon_category_shotgun

    • weapon_category_lmg
      

26. Is Scoping (alpha feature): Indicates whether the player is currently using the scope of the weapon. Returns True if scoping, otherwise False.
    

27. Is Target Blind (alpha feature): Indicates whether the target player is currently flashed. The values are between 0 and 1, where 0 represents that the target player is not flashed at all, and 1 represents that the target player is fully flashed. Intermediate values are interpolated using the bezier curve.
    

28. Shot Target Through Smoke (alpha feature): Indicates whether the target has been shot through smoke. Either True or False. This feature is difficult to capture as the problem is to check whether 2 points in 3D are inside of an Capsule.
    

29. Target Returned Damage (alpha feature): Represents the damage returned to the player by the target player in this round.
    

4.3 Data Preprocessing and Parsing↩︎

The collected demo files from both data sources need to be parsed. This parsing is done to extract useful features from the demo files. The demo file is a compressed format for storing game data efficiently. To parse these demo files we will be using our Python parser for parsing demos. This Python parser is a wrapper around a Rust parser publicly available (Python-demoparser), thus it will be significantly faster and memory efficient.

4.4 Dataset Configurations↩︎

Using our created parser we parsed all the demo files. We created 6 total datasets from our demo files with different configurations. The configurations listed are:

• Tick Delta Negative: How many ticks before a hurt event shall be considered for parsing?

• Tick Delta Positive: How many ticks after a hurt event shall be considered for parsing?

• Max Fight Size: How many ticks in total the fight sequence should compromise after the hurt events are merged? Fight sequences that are larger than this are broken down into multiple sequences.

4.5 Model Creation↩︎

There are 3 types of models which we have trained namely Single LSTM, Stacked LSTM, Stacked LSTM with Dense layers and in each of the model types there are 3 different models with varying configurations from each other. A detailed description of the Model configuration of every model is given as follows-

4.5.1 Single LSTM↩︎

1. Model 1: The model starts with an LSTM (Long Short-Term Memory) layer configured with 32 units. This layer processes input data shaped to match the input sequence dimensions given by the dataset samples. Following the LSTM layer, a dense layer with one neuron and a sigmoid activation function is added to produce a binary classification output.

2. Model 2: This model consists of an LSTM (Long Short-Term Memory) layer with 64 units, which processes sequential input data. The input shape is specified by the dataset samples, indicating the dimensions of the input data that the LSTM layer will accept. Following the LSTM layer, a dense layer with one neuron and a sigmoid activation function is added.

3. Model 3: The model architecture begins with an LSTM (Long Short-Term Memory) layer configured with 128 units, which is suitable for processing sequential input data. The specified input shape given by the dataset samples indicates the dimensions of the input data that the LSTM layer will handle. Following the LSTM layer, a dense layer is added with a single neuron and a sigmoid activation function.

4.5.2 Stacked LSTM↩︎

1. Model 1: The model is a Sequential neural network architecture comprising two LSTM layers with 32 units each. The input shape is determined by the dimensions of the dataset samples, where sample length represents the number of time steps and sample width denotes the number of features. The first LSTM layer returns sequences, while the second does not. Dropout layers with a rate of 1/10 are applied after each LSTM layer to mitigate overfitting. Finally, a Dense layer with a sigmoid activation function outputs a single value.

2. Model 2: The model is a Sequential neural network architecture with two LSTM layers, each consisting of 64 units. The input shape is defined by the dimensions of the dataset samples, where sample length represents the number of time steps and sample width denotes the number of features. Dropout layers with a rate of 1/10 are applied after each LSTM layer to prevent overfitting. The final layer is a Dense layer with a sigmoid activation function, outputting a single value.

3. Model 3: The model is structured as a Sequential neural network, featuring two LSTM layers, each with 128 units. The input shape is determined by the dimensions of the dataset samples, where sample length signifies the number of time steps, and sample width indicates the number of features. Dropout layers with a rate of 1/10 are inserted after each LSTM layer to prevent overfitting. Finally, a Dense layer with a sigmoid activation function is utilized to produce a single output value.

4.5.3 Stacked LSTM with Dense layers↩︎

1. Model 1: The Sequential model consists of two LSTM layers with 32 units each, followed by dropout layers with a rate of 1/10 to mitigate overfitting. Two Dense layers follow, the first with ReLU activation and units equal to sample length, and the second with half the number of units. Another dropout layer with the same rate is included, and the model concludes with a dense layer utilizing a sigmoid activation function, outputting a single value.

2. Model 2: It begins with an LSTM (Long Short-Term Memory) layer with 64 units and an input shape corresponding to the dimensions of the input dataset (sample length, sample width). The parameter ‘return sequences=True’ indicates that this LSTM layer will return sequences rather than a single output, which is useful for sequence-to-sequence models. Next, another LSTM layer with 64 units is added without return sequences=True, this layer will output a single vector for the entire sequence. Finally, the model ends with a dense layer containing a single neuron and a sigmoid activation function.

3. Model 3: The model comprises two LSTM layers, each with 128 units, followed by dropout layers with a rate of 1/10 to prevent overfitting. Subsequently, two dense layers are included, the first with ReLU activation and a number of units equal to sample length, and the second with half the number of units. Another dropout layer with the same rate follows. Finally, a dense layer with a sigmoid activation function outputs a single value.

4.6 Training of LSTM and Decision Tree Model↩︎

Once the dataset is prepared we are using the deep learning model LSTM and Decision Tree model. The training is done over GPU with 20 epochs. We then evaluated the models on the test dataset to assess their performance. We used the trained model to make predictions on new data.

4.7 Creating Intermediatory Connection Utilities↩︎

To ensure effective communication between YAACS and the game server, intermediary connection utilities (ICU) have been developed. These utilities are used to connect the proprietary game server with our YAA-C system.

4.8 Creating Charter↩︎

Once the created dataset from the parser is passed to YAA-CS charter is given the job of creating the relevant reports for post-match analysis results. These reports are charts answering various questions about the match. There are a total of 10 reports hand-picked by us which are-

• Most used Weapon in the match.

• Mostly targeted body parts in the match.

• Most used Weapon Category in the match.

• Movement preferred during fights in the match.

• When the Player could not see but shot landed on target in the match.

• Where do players see vertically in the match.

• Average Utility used in the match.

• Do players play with a scope on or off for ARs in the match.

• Do players play with scope on or off for SNIPERs in the match.

• Was the Player blind during fights in the match.

4.9 Creating Uploader↩︎

Once the dataset is processed by Model and Charter the match data is given to Uploader as a job. The Uploader connects with the database to update and create the required data.

4.10 Setting up S3, MongoDB and RabbitMQ↩︎

• We are using S3 for dataset storage where we are storing the datasets after parsing by the parser.

• We are using MongoDB for storing the admin user details, matches data, player data, and reports.

5 Experimentation Setup↩︎

Experimental setup includes the game server connected to the deep learning model using ICU, messaging queues and other components. The deep learning model will be first trained on the training dataset. Once a client connects to the game server and plays the game as usual, the deep learning model in the background will watch over the player’s actions and decisions. If the client then performs some cheating action it will be detected by the deep learning model and the server will be notified of the client’s misconduct.

5.1 Setting of Hyperparameters↩︎

There are hyperparameters which can be set when the dataset is being created. These can be used to pass fights of various sequence length to model.

All models created themself were created to test these different hyperparametes like number of memory cells, number of layers in LSTM, and more.

5.2 Module Wise Setup↩︎

5.2.1 Module Installation↩︎

Each component in YAA-C can be installed with either-

• Python: install script provided in source code

• JavaScript: Thorugh npm install.

5.2.2 Experiment Process↩︎

Once installed the typical experiment flow is mentioned below.

1. The YAA-C system is connected with the game server: This connection is done via installation and configuration of ICU and via an API key of YAA-CS.
   

2. The client connects: Many game clients connects to the game server. Some of these game clients are modified by using some type of cheating software to achieve aimbots.
   

3. The Match Starts: The game clients play the FPS game and some game clients use aimbots for their advantages.
   

4. The Match Ends: Once the match ends the game server emits the recorded game state in format of demo file. ICU captures this demo file and using parser converts it to a proper format. These parsed file is then sent to the game server.
   

5. Backend triggered: Once the match upload endpoint is hit on backend it sends the file to the S3 for storing and posts a job to RabbitMQ for processing of these match.
   

6. Charter triggered: Charter receives the job from RabbitMQ and starts processing it for report generation. Once the report values are rendered they are sent back to RabbitMQ as a job.
   

7. Model triggered: Model receives the job from RabbitMQ and starts processing it for fight sequence classification. Once the model completes classification on fighting sequences the data is sent back to RabbitMQ as a job.
   

8. Uploader triggered: Uploader receives the job from RabbitMQ and uploads it to appropriate place in the database.
   

9. Admin post-match analysis: Now the game server admin can view the analyzed match through the frontend UI, There we are showing them reports, fight sequences and player classifications.

6 Results of Experiments↩︎

We have initially 6 different datasets according to some parameters. Each of the datasets is focused on creating different-sized sequences so we can measure what sequence length fits our needs. For each of the datasets, three types of LSTM models are created namely Single LSTM, Stacked LSTM, Stacked LSTM with Dense layer, and in each of the LSTM models there are 3 unique models created with different model configurations. So results of all the models for every dataset are mentioned below:

In this study, we evaluated the effectiveness of time series models (LSTM variants) against a traditional single-shot model (Decision Tree) for cheat detection in FPS games using game tick sequence data. The experiments were conducted across 6 dataset configurations with varying temporal context windows, and 9 LSTM model configurations per dataset. The most critical metric for this domain is the False Positive Rate (FPR = FP / (FP + TN)), as falsely accusing an innocent player of cheating is a severe and often irreversible action. The Decision Tree baseline achieves:

\[\text{DT FPR} = \frac{565}{565 + 20542} = \frac{565}{21107} = 2.68\%\]

Across the LSTM experiments, the best FPR per dataset (taken as the model with the lowest FP count) is as follows:

This reveals a clear and monotonic relationship: larger temporal context windows consistently produce lower false positive rates, with Dataset 1’s best model (Stacked LSTM with Dense layers, Model 1) achieving an FPR of 0.97%, less than half the Decision Tree’s FPR of 2.68%.

Dataset 6, where the context window is reduced to a single tick, results in complete model collapse across all 9 LSTM configurations. Every model defaults to predicting the majority class (non-cheating), yielding zero true positives and an accuracy of:

\[\text{Majority class accuracy} = \frac{8418}{8418 + 2560} = \frac{8418}{10978} = \boldsymbol{76.7}\%\]

This confirms that temporal context is the essential signal for this classification task. Without it, even complex neural architectures fail entirely. Regarding model architecture, increasing LSTM units from 32 to 64 to 128 provides negligible improvement. For example in Dataset 4, accuracy across all 9 models ranges only from 0.905 to 0.906, a difference of 0.001 (0.1%). This suggests the bottleneck is the sequence construction (window size and tick context) rather than model capacity, and that simpler LSTM configurations are preferable given their lower computational cost.

The Decision Tree model does achieve a notably higher recall of 0.925, compared to the best LSTM recall of approximately 0.673 (Dataset 5, Single LSTM Model 1):

This means the Decision Tree catches more cheaters, but at the cost of a higher false accusation rate. In the context of FPS anti-cheat systems, we argue that missing a cheater is a less severe error than wrongly punishing an innocent player a missed cheater may be detected in future matches, whereas a wrongful ban directly harms a legitimate player’s experience. This domain-driven priority justifies favouring the lower FPR of the LSTM models despite the recall tradeoff.

In conclusion, the best overall configuration is the Stacked LSTM with Dense layers (Model 1) trained on Dataset 1 (Tick Delta Negative=56, Tick Delta Positive=24, Max Fight Size=128), achieving an accuracy of 88.6%, with an FPR of 0.97%, outperforming the Decision Tree baseline FPR of 2.68% by a factor of 2.76x.

Future work could explore attention-based sequence models (such as Transformers) or hybrid architectures that may further improve recall without sacrificing the low false positive rate achieved here.

7 Conclusion↩︎

In conclusion, this research demonstrates that deep learning-based sequence models offer a meaningful advantage over traditional single-shot classification approaches for aimbot detection in FPS games. Through systematic experimentation across 6 dataset configurations and 9 LSTM model variants, we show that temporal context is the defining factor in minimising false positive rates, with the best LSTM configuration achieving an FPR of 0.97%, 2.76x lower than the Decision Tree baseline of 2.68%. While the Decision Tree achieves a higher accuracy of 96.2% and recall of 92.6%, its higher false positive rate makes it less suitable for anti-cheat systems where wrongly penalising an innocent player carries significant consequences. The complete failure of all models on Dataset 6 (1-tick window) further confirms that without sufficient temporal context, even complex architectures cannot distinguish cheating behaviour from legitimate gameplay. Future work could explore attention-based architectures such as Transformers, or hybrid models that retain the low false positive rate of LSTM while closing the recall gap against the Decision Tree baseline. Additionally, a sequential ensemble approach - first applying the Decision Tree for its high recall of 92.6% to flag potential cheaters, followed by the LSTM model to filter out false accusations with its lower FPR of 0.97% could offer the best of both models, maintaining strong cheat detection while minimising wrongful penalties.

References↩︎