AGK Studio 2 – Refactoring the code

I’m back with the next installment of the tasks to be completed before creating the new version of my game. In the previous article, I described all the aspects that need to be changed before starting work on the new version of the game. The first adjustment is the refactoring of the code.

What is this all about?

I will reorganize, standardize, and correct the source code to address everything I mentioned in the previous post. The ultimate test will be to ensure that the game functions exactly the same as it did before this task. We’ll start with variables, constants, and data types.

Global constants declaration

There was already a file named constants.agc dedicated to declaring global constants. This time, I went through all the code, searching for constants that were declared in the wrong places, and moved them to the aforementioned source file. During the same process, I took the opportunity to standardize the naming convention, defined as follows: Constants will be declared in uppercase letters, as is customary in most programming languages I’m familiar with (C, C++, C#, PHP, Java). The name of the constant will be preceded by the letter G, indicating that it is global (it’s worth distinguishing between global and local constants here), and a letter that indicates its data type:

• I for an integer constant.
• S for a string constant.
• D for a decimal constant.

Thus, the name of a global constant will be: Without further ado, I decided to use the English language in the code, as I’d like to share it at some point, and this language will give it greater reach. Here’s what the code looks like:

Global variables declaration

Global-scope variables will be declared in the globals.agc file. Regarding the naming convention, these must be written in lowercase letters, starting with a g (to indicate that they are global) and following the current standard: separating name particles with underscores and ending with the $ character for strings or # for decimals. For instance: In the case of matrices or arrays, this will be indicated by an a after the initial g, while continuing with the same standard: For global variables of custom data types, only the letter g will be used, followed by the name of the variable. For example: The adjusted global variables file now looks like this:

Custom data type declaration

The BASIC language that powers AGK Studio is a procedural programming language, meaning it is not object-oriented. Therefore, in order to create “encapsulated” units of information, the closest thing we have are custom data types. If we compare it to the C programming language, we are basically talking about structures or records. The syntax for declaring them is as follows: As a naming convention, and to avoid confusing a custom data type declaration with a variable, I will use CamelCase for the type name definition and the fields, following the same standard for declaring variables. The final character indicating the data type will be omitted since it’s declared with the as clause. For example, the record that stores the general game configuration is GameConfig:

Once the adjustments were made to the reorganization of variables, constants, and data types, I made the changes to the corresponding references in the program because, basically, if I had skipped this, the program wouldn’t compile.

Summary

Regarding the debugging, sorting, and renaming of global constants and variables, as well as custom data types, here’s what I did:

• Go through each source code file and, if global variables or constants are found, move them to their corresponding files.
• Check that each variable or constant found is being used. I took the opportunity to remove duplicate ones, with similar names but serving the same purpose, and those that were declared but not used.
• The variables that belonged to the same category were grouped into a data type, like the variables used to track the game’s configuration. Previously, there were four global variables; today, it is a single global variable, but of type GameConfig.

Having made these changes, in addition to updating their declarations, I had to go through each file to make the necessary adjustments, referencing the new variables, replacing the old ones, and removing references to the ones I had deleted. And well, that will be it for this stage. The next step will be to organize the program’s events: where it starts, where the configuration is read, where it is applied, and where each screen is displayed. There’s a lot of material and experiences to share. See you soon!