Introduction

One of the most important factors in the success of a software project is the software quality. In this essay, we will look at the overall quality process and the key elements of the continuous integration process of Cheat Engine. At the same time, we will cover the rigor of the testing process, the past and present changes in Cheat Engine’s hotspot components, and evaluate its code quality. Finally, the paper will also assess the technical liabilities of the system.

The system’s key quality attributes

As described in earlier essays, we evaluate the key quality attributes of Cheat Engine in terms of Modularity, Maintainability, Extensibility, and Compatibility. This section will further evaluate the current level of completion and satisfaction of these attributes in Cheat Engine.

• Modularity:
  The structure of Cheat Engine does cover modular divisions. It includes functional modules such as RemoteMemoryManage and MemoryRecord, which are used to access memory addresses and modify memory contents. Each module is functionally independent of the other, and together they perform the primary function of changing memory address values. However, each module must interact with the MainUnit, which means that the MainUnit controls all the other modules. The Cheat Engine is modular in structure and suitable for current system operation. However, as new versions and features are added, modularizing the code in a more efficient and detailed manner will be necessary.

• Maintainability:
  Cheat Engine is seriously lacking valuable documentation. The guides published on its website are biased towards guiding users on how to use the software and describing the functionality of the various software parts, which does not contribute significantly to the developers ¹. At the same time, the code in MainUnit is heavily redundant and could probably be maintained by authors who have been working on the project for years. However, it is challenging for coders to maintain and redevelop the code without available documentation. Therefore, it can be concluded that the maintainability of Cheat Engine is lacking and unsatisfactory, mostly because of the lacking documentation.

• Extensibility:
  Cheat Engine is relatively extensible to meet the needs of users. It allows the user to create their own scripts and plugins, ensuring that they can use the software for their own needs. The available information regarding how to use these scripting and plugin capabilities is relatively low, and as such there are multiple issues reflecting problems with user-created scripts. This phenomenon corresponds to maintainability, the system’s lack of stability, and the lack of tutorials for the format needed to introduce scripts. Overall, there is still considerable scope to improve the extensibility of Cheat Engine.

• Compatibility:
  Cheat Engine supports both Windows and Mac OS in terms of completeness, but users have reported that Cheat Engine is more stable on Windows than on Mac OS. The functionality available on the Mac OS version is not comprehensive.

Overall quality process

The biggest issue with the current state of Cheat Engine is that there is only a single quality rule mentioned and enforced: “Lazarus likes to make changes to files when you open them or move something around, so make sure you only stage the changes that are required for what you are trying to accomplish.”². Most other problems stem from this lack of quality assurance. There is also no maintained automated testing or building present in the repository that enforces any changes made to meet any set quality requirements.

Continuous integration and test coverage

In 2017, a community contributor did open a pull request which would add AppVeyor to the project to automate the building process of Cheat Engine³. This was merged nearly two years later, meaning everything that was added was already outdated once it was merged into the master branch. The community contributor mentioned he would make sure to maintain the AppVeyor component, but there still have not been any changes since the original commit from 2017. In 2021, another community contributor opened a pull request which would add GitHub Actions for AppVeyor⁴. Although it had been added two years earlier, there was nothing included which would actually run AppVeyor. Although this pull request would start some automated quality assurance by building the application before any merges are made, there is no indication as to whether this will be merged any time soon.

Even with an automated build, the actual quality of the code would not be checked thoroughly enough. This is because the repository only contains a couple of tests that were shipped with some of the included libraries^{5 6}. If Cheat Engine were to start including tests as well as automatically running them before any pull request can be merged, it would be a lot easier to verify any community contributions. Currently, most changes made are made to the master branch directly by the main developer, “DarkByte”⁷.

Hotspot components

Cheat engine has a lot of different components. Some components are more important than others. Naturally, the code of these components tend to change over time, as improvements are added to the software. These important components can be called “hotspot” components. By looking at the commits of the GitHub page, these components can be identified. In this section, we will discuss these hotspot components and how these will change in the future.

The most important components of Cheat Engine is the MainUnit ⁸. This component has a lot of GUI functions build in. So it is by no surprise that this component has a lot of commits, as every change in the GUI is directly made from the MainUnit component. By looking at the past commits from this component, we can see that most commits are small GUI improvements, or bug fixes. These commits go all the way back to 11 years ago ⁹. This component might even be older, as Cheat Engine was released in 2001 ¹⁰. Unfortunately, the GitHub page does not show anything older than 2011, because of a repository migration. But it can be assumed that this component was made at the very beginning of the implementation of Cheat Engine. This component will still be important in future versions, as the GUI of Cheat Engine keeps improving and bug fixes get added.

Another hotspot component is the MemScan unit. This component is responsible for the scanning function of Cheat Engine. This component also gets a lot of commits as multiple issues are found over time, which must be resolved so it can function well. By looking at the commits, most of them are for fixing issues and adding additional support. It can be speculated that this hotspot component will still be improved in the future, as additional support and bug fixes will be added in future versions to improve the use of Cheat Engine.

The code quality

Code quality is an important specification in software, as it determines the understanding of the code. This also plays a big role in the maintainability of the software. A well-organised and structured file with good documentation can easily be maintained. This is especially important for files with a lot of lines of code, as one can simply get lost. Open-source software like Cheat Engine should be well documented and easily maintainable, so programming hobbyist can make improvements without a lot of effort needed for understanding the code.

Unfortunately, documentation is not a strong point in the GitHub repository of Cheat Engine ¹¹. There are plenty of tutorials on how to use the software, but not on how to contribute and how the code is structured. Documentation about functions and variables is often missing and some placed comments are redundant. For example, in the MainUnit file ⁸, many functions are missing essential explanations and snarky comment about loving long variable names makes it unorganised. Valuable comments in the code are often one-liners and kept short. In a file that is 11000 lines of code, contributors will have a hard time understanding the code.

There are some good qualities in the code. Variables names stick to their purpose, which makes them often long but recognisable. In newer files, more comments are added for better documentation. Although many improvements can be made for the code quality, these small steps of adding extra comments can lead to a better organised and structured code in future versions.

The quality culture

Cheat Engine has a variety of people in the community. Most of them are regular users and this can be seen on the issue tab of the GitHub repository. Cheat Engine has accumulated 1618 issues, where 591 are still open ¹². If we look at the issues, most of them are complaints about Cheat Engine itself. A few examples are trouble with installing the software ¹³ and questioning the safety of the software by asking about viruses ¹⁴. We can see in these issues that the community tries to help those in trouble, as well as clarifying any doubts of security and safety of the software ¹³.

A small amount of the Cheat Engine community are contributors. There are 45 contributors to the Cheat Engine GitHub repository ¹⁵. These contributors try to improve the software of Cheat Engine by fixing issues and making pull requests. There are currently many open pull requests with little to no discussion, one of which is currently over 2 years old ¹⁶. If we look at these pull request, they typically range over different aspects. Most of them try to fix issues and add support by updating specific files, while others fix grammar mistakes in the code. Pull requests are the main source of interaction and contact with the developers of Cheat Engine, as the developers can comment and discuss these fixes in the pull requests. However, as seen in the pull request discussions ¹⁷, the developers don’t tend to interact much with the community and often ignore them.

Technical debt

Cheat Engine has a considerable amount of technical debt. Analysis of its version update reports shows that a relatively small percentage of new features are released in each version. Most of the updates cover fixes for various bugs that prevent the system from running stably.

The reason for this technical debt is the UI-driven development. In terms of Cheat Engine’s software architecture and implementation code, in each release of Cheat Engine, new features are added to MainUnit or other modules based on what part of the UI is responsible for interaction with those feature. This has caused too much functionality to be covered in the MainUnit file. At the same time, there was no clear documentation to explain the code and processes, which makes the overall codebase confusing and challenging to maintain directly.

References