Title: Debugging your Games
Course: RITA MC - GAME DESIGN > Section: Module 3

By now you have lost some points in at least one of your Game submissions for having “bugs” or a glitch. A hiccup, an error, an anomaly, something is "wonkie" with your game. How do you fix these issues?

Sometimes you just have to simply start again. This is why it is so important to save multiple versions of your Game. Start again at a point in your saved game where you KNOW the bug does not exist. The process of debugging is a soft skill, one that you will need and use over and over and over again. Even a Pro has to debug his code. It comes with the territory. It is an occupational hazard. A common rookie mistake is for a novice to ask someone to debug their code or their game for them. YOU are the best one to begin that process.

Here are a few simple methods to employ when debugging your Game Maker game.

Begin with common errors. This would be an object that does not exist or a variable that has not been declared. Any of those states causes an error. You must learn to read your errors so that you can determine a cause and a solution. It’s all very logical.

Note that the line of hashtags is your border or a line break that separates your error and makes it easier to read. The first few lines generally tell you where the error occurred. It might tell you that the error is associated with a specific object.

So start checking your code right there.

If you see a line of code that states Variable Get – then you have been warned exactly what is going on and what the problem is. These two words mean that the variable the program is trying to use is not there, or at least it cannot be found for some reason. It might be a spelling issue, or a syntax error.

Look again at the code and see if it provides additional Line numbers that need to be reviewed.

Common causes for missing variables are:

- Typing errors, misspelled variable
- Variable was never ‘declared’ (create event, global variable in another object, etc.)
- The variable is being declared out of sequence – after that line of code. Declaration often happens in another object.

Keep in mind when you fix one error, you may create others. This is why it is so important to play your games and run your code frequently during creation. This is also another reason to organize files by name and save multiple versions – until you complete the game.

Other tricks to help with debugging are TOGGLES. It is useful to be able to enable and disable things by pressing a key. Lasers, turrets, pauses, all can be disabled with a single line of code.

Use the not statement. (Represented by the special character, exclamation point >>> !)

The not statement is often used in an if statement to check whether something is false. The way it works, is to multiply the returned result by -1, making it negative if the number was positive or positive if the number was negative.

This creates a basic toggle swith.

Sample code:

If (keyboard_check_released(vk_pace)){

On= !on;

}

See what we did there?

The preceding code checks to see whether the player has released the spacebar key and if they have it will set the on variable to be the opposite of what it was before. This works by setting on to !on. In other words, it works by multiplying on with -1.

This code will work the exact same way:

if (keyboard_check_released(vk_space)) {

on*=-1;

}

These toggles can be applied to anything that needs a variable to turn on and off. They become useful when debugging a game as they will allow the programmer to enable and disable parts of the game at any time and see exactly where the issues are taking place.

You can also use comments and remarks to stop a piece of code from working temporarily while you try to determine the source of an issue.

Using the Debugger in Game Maker Studio

To run a game in debug mode, click on the red test play button instead of the green one.

Using this debugger, we see what the game is doing. And we can see the source code of the game when it runs and add break points on the fly.

A break point is a point where the game will pause on a certain line.

We can have the game step through its code, and watch as each line of code is executed. If the source code is not already evident, click on the greay close button at the top right corner of the current form to close it

Then right click anywhere on the blank screen and choose Source form the drop down list that appears. With the source form open, you should now see some source code from the game that is running.

If you want to see a different section of the code, use the tree structure on the left side of the debugger window to select objects, events or scripts you wish to view.

To add a break point, double-click on the line. A red dot will appear to the left of the line when a break point is active. To remove a break point, double-click on the same line again.

At the end of the code, the game should pause.

You can also step through the code using the step controls at the tope of the debugger window. The first button is the step in button. It steps into a block of code, the middle button is the step over button that steps over a code block and skips it, and the last button is the step out button that steps out of a block of code and ends it.

The Game Maker debug tool is designed to be a watching tool and provides info on your game. The game cannot actually be edited in real time as it runs, so all actual changes would have to be made in GameMaker.