Quake III Arena is a multiplayer-focused first-person shooter video game released in December 1999. The game was developed by id Software. Quake III was a very popular game and even now it’s still popular and many gamers enjoy with it.
The original source code of Quake3 can be found here .
Artem Kharytoniuk decide to create it’s own version and his goal is described in it’s repo:
This repository contains updated version of the original Q3 codebase with reorganized code structure, compatibility fixes, build setup for the latest Visual Studio and modifications that update the core tech but preserve original gameplay, look and feel.
Let’s compare the source code of the two projects and discover what improvements were down in the Kenny edition version.
The whole picture
Here’s a summary of some metrics of the original code
And here’s the summary of the modified version
Here are some remarks after comparing their summaries:
- Less code in the modified version.
- Less types, methods and variables.
- Rating and debt very similar for the whole solution.
- Similar method complexity.
Let’s discover these metrics for each project:
The original code
And for the modified code
Let’s go further and compare deeply the differences between the two versions.
Modularity is a software design technique that increases the extent to which software is composed from separate parts , you can manage and maintain modular code easily.
For procedural language like C where no logical artifacts like namespace, component or class does not exist, we can modularize by using directories and files.
In the modified version, there are some refactoring concerning the folders structure. here’s an example of the refactoring where the folders related to the engine are isolated in the engine directory.
Encapsulation is the hiding of functions and data which are internal to an implementation. In C, encapsulation is performed by using the keyword static . These entities are called file-scope functions and variables.
Let’s search for all static functions for the original code:
Many methods are declared as static to enforce the encapsulation. However there are many other ones not declared as static.
We can use the Metric view to have a good idea how many functions are static. In the Metric View, the code base is represented through a Treemap. Treemapping is a method for displaying tree-structured data by using nested rectangles. The tree structure used in a CppDepend treemap is the usual code hierarchy:
- Projects contains directories.
- Directories contains files.
- Files contains struects, functions and variables.
The treemap view provides a useful way to represent the result of a CQLinq request, so we can visually see the types concerned by the request.
As we can observe almost all the functions from renderer and cgame projects are declared as static, which is not the case for the other projects where only few functions are declared as static.
Did the modified version enforce the encapsulation?
Here’s the CQLinq result of the static functions query:
There are less static functions than the original code, mainly because many functions were removed due to the refactoring, and this new version does not enforce more than the original one the encapsulation.
Usage of structs to store the data model
In C programing the functions uses variables to acheive their treatments, theses variables could be:
- Static variables.
- Global variables.
- Local variables
- Variables from structs.
Each project has it’s data model which could be used by many source files, using global variables is a solution but not the good one, using structs to group data is more recommended.
Only 166 variables from 9084 fields could be refactored to make them const, static or embed them in a struct.
And here’s the same quey for the modified code
few new global variables candidate to be refactored are added to the new code. For that we can search for the primitive global variables , not static , not const and not changed in the source code:
some of them like multi_texture_add_frag_spv_size or multi_texture_clipping_plane_vert_spv_size added in the code could be declared as const.
Code Smells in two projects
Types with too many fields
Let’s search for structs with more than 30 fields:
And here’s the result for the modified version
Some big structs were refactored, for example the number of fields of cgMedia_t passed 258 from to 199 fields.
Too big functions
Here’s from the linux coding style web page, an advice about the length of functions:
Functions should be short and sweet, and do just one thing. They should fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24, as we all know), and do one thing and do that well. The maximum length of a function is inversely proportional to the complexity and indentation level of that function. So, if you have a conceptually simple function that is just one long (but simple) case-statement, where you have to do lots of small things for a lot of different cases, it's OK to have a longer function.
And here’s the same result for the modified version:
Many big functions are gone, some of them are completly removed and the other ones are refactored.
Functions with too many parameters
Here are the functions concerned for the original code
And here’s the result for the modified version:
only very few functions has more than 8 parameters in both versions.
Functions with too many local variables
Methods where NbVariables is higher than 8 are hard to understand and maintain. Methods where NbVariables is higher than 15 are extremely complex and should be split in smaller methods (except if they are automatically generated by a tool)
Here’s the result for the original code:
And the result for the modified one
Some added functions in the new modified version have more thann 15 variables, vk_initialize() is an added function with 73 ariables.
Functions too complex
Many metrics exist to detect complex functions, NBLinesOfCode,Number of parameters and number of local variables are the basic ones.
There are other interesting metrics to detect complex functions:
- Cyclomatic complexity is a popular procedural software metric equal to the number of decisions that can be taken in a procedure.
- Nesting Depth is a metric defined on methods that is relative to the maximum depth of the more nested scope in a method body.
- Max Nested loop is equals the maximum level of loop nesting in a function.
The max value tolerated for these metrics depends more on the team choices, there’s no standard values.
And the modified one:
We can observe that many complex functions are removed or refactored.
The original source code of Quake III is well implemented, few code smells are detected. However a big clean was introduced in the modified version where many functions and variables were removed, some structs are refactored and the physical structure a little changed.