Meet the project

Cheat Engine is a tool for memory analysis and manipulation, for the purpose of modding and reverse engineering processes. It operates on one of the lowest possible levels of abstraction and gives a real insight into the inner workings of other processes. Directly observing the behaviour of processes also allows for reverse engineering of secondary artefacts, such as encryption keys, file formats, and communication protocols. This gives the user back the freedom to control the processes on their machine in the way they want.

Our view on scalability

Essay four was supposed to be focused on an analysis of the scalability of Cheat Engine. However, as we have mentioned in our previous essays, the current state of Cheat Engine is not suitable for scalability at all. This is why we decided to focus this essay more on the current technical debt and issues within the current workflow and to propose solutions to make Cheat Engine a healthy software project again. In order to do so, we start off by analyzing the issues we deemed most important, like issue workflow in the repository and the file hierarchy. Then we combine these analyses to state the current state of the system. Finally, we pose several recommendations to fix the causes of the analyzed issues.

Analysis of the system

The first part of the essay is an analysis of the issues we deemed to be most critical. These issues were encountered when writing the first three essays and are related to both the codebase and the workflow in the repository. Examples of these issues are the lack of documentation, unorganized files, GitHub repository issues, and more.

File hierarchy

The project mostly consists of GUI elements directly containing relevant variables, complex object definitions, and event handlers, there is little to no importance on where some code is located. The code is altered through an editor called Lazarus, so there is also barely any direct interaction with the files. These two properties of the project have led to the current file hierarchy; an enormous amount of separate files, non-obviously interconnected. The main Cheat Engine folder contains 701 files ¹.

The main folder contains 403 .pas Pascal Code files ². These contain Pascal code responsible for most of the functionality. Most of the code is spread out over a large number of small files, but there are also very large files that have formed around a singular purpose or UI element. The biggest code files are the integrated assembler and disassembler, the Lua handler, and the MainUnit.pas mentioned in earlier essays. While the larger, self-contained code files such as the disassembler are bound to be some of the largest code files in the project, the files correlating to the UI elements mostly contain event handlers.

The main folder also contains 145 .lfm Lazarus Form files ². These define the placements and event handlers of the UI, so the biggest files are for the most complex elements; the MemoryBrowserFormUnit and the MainUnit.

Issues

The project has changed its preferred method of communication multiple times over the course of its existence. It initially lived on a now-defunct message board ³, until it moved to its own forum in 2003. Starting in 2007, the mantis bug tracker ⁴ was used for a while, even after the move to Github in 2011. Because of the low interaction with these issues, the amount of meaningful issues for any external developer is quite low.

The GitHub page of Cheat Engine has a lot of open issues. Some of these issues are still open from 2017 ⁵. We analyzed the number of issues and the duration these issues stay open. We can conclude that the maintainers of Cheat Engine do not pay much attention to the issue page, as there are a lot of issues open which are not applicable anymore. A more serious problem is that some of the older open issues discuss rather important problems, such as issue 60 ⁶, which discusses the open source license. Another issue is the rather low quality on incoming issues, as a lot of issues are opened regarding problems with installing or running the program. If this continues, the issue page will only get more unorganized.

State of the system

This analysis confirms our assumption that Cheat Engine is not in a proper state to discuss the scalability of the application. The analyses clearly show that the mess in the system has grown exponentially over the last few years and the issues that create this mess should be resolved as soon as possible to prevent it from growing.

Recommendations

In order to prevent this mess from growing, we will be looking at some potential solutions for the biggest issues. The solutions will be in the form of recommendations. We believe that these recommendations can make the workflow of Cheat Engine more healthy.

File hierarchy

One issue Cheat Engine has, is the file hierarchy. All the main components are all put in the same file, which is not organized and could be improved ². This also hurts maintainability as Cheat Engine has a lot of different files with different functionality and searching for the correct file to change could waste a lot of time.

Instead of having all the important files in one folder, multiple folders can be used. The Cheat Engine repository already has done this for other files, like files used for the tutorial, but not for their main files. The files can be divided into different folders based on their functionality. For example, files that are used for scanning functionality can be found in the scanning folder, or files that support LUA scripts can be found in the LUA folder. This will improve the workspace of Cheat Engine, as the files are more organized.

Documentation

In our previous essay, we mentioned the importance of documentation for maintaining and understanding the code of the software. The documentation of Cheat Engine could use a lot of improvement, as the current state has little to no documentation about important functions and variables. This improvement of the documentation can be done in multiple ways.

The most basic way to improve documentation is to make use of comments in the code. The current state of Cheat Engine does not provide enough comments in the code of the key components. Explaining what certain functions do and what specific variables are used for can clarify what the code does.

Another way to improve the documentation is to make an overview of the interactions of the components. This will give a better understanding of the software without even looking at the code. This way, contributors will have an easier way to make improvements, as they most likely will not have to look at the code of every component, but only at a specific component that matches their improvement.

Furthermore, a small tutorial for contributing could be added to the Readme file of the GitHub repository, as the Readme only explains how to install the software ⁷. Contributors will have it easier because they will have to spend less time understanding the code. This will also attract more contributors and thus will improve the project as a whole.

Split up large files

Splitting large files is an excellent way to improve the safety of software. In case of Cheat Engine, if the MainUnit fails, the whole software will collapse, while if the MainUnit was divided into multiple parts, only certain features would crash, but not the whole software.

An improvement would be to split the MainUnit into different files. This way the software is more failure-proof because if one file of the MainUnit fails, the whole software will not collapse. This will also improve maintainability, as errors that point to a specific file can be easier found if it has fewer lines of code.

Git branches

The branch design of Cheat Engine is not very sensible, and there is only one branch for older versions apart from the master branch ⁸. The existence of only one master branch is bad for contributors. A reasonable suggestion would be to build branches in different functional directions, which would help contributors to optimize a particular part of the functionality. In addition, different branches help the owner of Cheat Engine see which features have been tweaked by others while keeping the master branch in check.

Code of Conduct

The Code of Conduct defines how to participate in the community. It marks an inclusive environment where all contributions are respected. At the same time, the code of conduct should include procedures for dealing with abuse. The above information can be used as a starting point for the Cheat Engine Code of Conduct, which will help contributors to understand which norms to follow when making changes to the project. The Cheat Engine user guide clearly states that users should ensure that they are not violating the EULA/TOS of a particular game/application and that Cheat Engine does not tolerate illegal use. The same information should be reflected to code contributors. As contributors implement new features, they are also required to adhere to the code of conduct to avoid developing features that are not allowed in the specific game.

Issues and pull requests triage

By analyzing the issues on Cheat Engine’s GitHub, we found that Cheat Engine’s Issue and pull requests have the following issues to be improved. 603 issues ⁵ exist for Cheat Engine to be resolved. They are generally related to the system not starting correctly, file scanning does not work, and crashing, etc. At the same time, Cheat Engine issues are not well categorized, resulting in a confusing distribution of issues posted by users. The naming of pull requests is confusing, for example, Update DBKKernel.vcxproj, and the location and function of this file may be easily understood by long-time contributors who maintain the project. However, for beginners trying to contribute to the project, the purpose of this update can be challenging to understand. More importantly, with only one of the 603 issues ⁵ being closed and two years old, the lack of timely feedback on issues is also not conducive to good maintenance of Cheat Engine.

Issues and pull request templates

The information described above suggests that the Cheat Engine project urgently needs a template for issues and pull requests^{9 10}. A possible solution would be to classify issues and pull requests. As described above, issues mainly cover problems such as not starting correctly, flashing and scanning functions not working correctly. Therefore, the issue type and description are needed when the user intends to post an issue. By doing so, issues of the same type can be handled uniformly, and the reasons for many issues of the same type can be analyzed to maintain the software efficiently.

References