Now, we know enough to be careful when writing our code so that we can evade the runtime bug. However, sometimes, there are bugs that we didn't anticipate, no matter how careful we are in writing our code. In times like these, we need to be able to see how Construct 2 runs our game behind the curtains. This is where we need the debugging tool.
You can use the debugging tool primarily by debugging each layout. To do this, just click on the Debug layout button right beside the Run layout button at the top of Construct 2:
Clicking on it will start the game as usual, except that you'll also see the debug tool (called the Inspector tab) below the game. On the left-hand side of the debugging tool, you'll see a list of all the objects in your project. The number in the brackets indicates how many instances of that object exist on the layout; the ones with 0 instance means that they're not created yet. On the right-hand side, you can see the properties of the object that was selected on the left-hand side.
If you try to run the debug tool on your game from Chapter 6, Creating a Space-shooter Game, you'll get an Inspector tab, like the one shown in the following screenshot:
It might look confusing at first, but don't worry, because I'll guide you in how to use the debugging tool. If you click on an object in the objects list, the list will automatically expand and show the list of instances of this object, by their order of creation. The first instance created will be listed as 0, the second one as 1, and so on. Clicking on the index number will show the properties specific to that instance, such as their position and instance variables, if it has any.
However, it would be hard to inspect the inspector while the game is running, because the value of properties you're looking at might change, or the game can end because an enemy killed the player.
This is why the inspector has the button to pause/resume the game in the top-right corner. The Restart button is used to restart the layout, just in case you want to go back from the start to check on something. The Save button creates a temporary save file that you can load using the Load button; this is useful if you want to repeat a part of the gameplay, but not from the beginning of the game.
Try to run the debugger with our other previous games and see the changes in each object's properties. You can also check the changes in the value of global variables, which you can use to check whether the value of a global variable you write on a Text object is correct or not.
Besides only viewing the properties' values, we can also edit them from the inspector. Not all values can be changed, only the ones with the white background. The gray ones are read only and can't be changed. This is a good feature if you want to experiment.
As you can see, we can check so many properties of all the objects in the layout; while it is good as you only want to check a property of one object, it can be troublesome to select different objects if you want to check their properties. Fortunately, you can "watch" selected properties easily using the Watch tab.
To use the Watch tab, you must first select which properties you want to look at. You can do this by clicking on the eye icon beside each property.
Then, you can look at all the watched properties in the Watch tab:
After that, you can see all the properties you've watched, categorized by which object contains the property. When the game is resumed, you can see the changes in these values happen in real time; this is a good way to examine if you think that more than one property's value need to be checked. You can delete a property from the Watch tab by clicking on the cross icon in the right-hand side of the property.
The third tab on the debugging tool is the Profile tab; it gives a more detailed explanation of the CPU's performance. The game must be running continuously for the profiler to be able to collect data. It then shows the estimate of how much CPU time is used in each process. The profiler updates the data it shows once every second, and the values shown are for the previous second.
Remember that the CPU usage is only an estimate, and, therefore, the values shown in the profiler are not always accurate. The details shown here are only about the JavaScript-related processes, while the CPU might be working on other tasks, such as audio processing. Also, the profiler doesn't calculate the time it takes for the GPU to render the game to the screen.
Despite its drawback, the profiler can be used to identify the places where it needs to be optimized if there's performance trouble. We will discuss optimization in more detail later.
Okay, I think it'd be hard to know what the profiler shows only by looking at the previous screenshot, so I'll tell you how to read the profiler. The profiler is divided into several parts that show where your game process is focusing on. These parts are as follows:
In the top left-hand side of the debugging tool, you can see a summary of the game's performance. You can use this to measure how fast your game is running. The values are as follows:
webgl
instead of canvas2d
. There is no reason for you to use canvas2d
over webgl
, but if the device or computer on which the game is running doesn't support webgl
, Construct 2 will fall back on canvas2d
.Construct 2 has a debugging tool that traditional programming languages have: breakpoints. Breakpoints are an advanced feature that can greatly help in debugging your game. Breakpoints pause the running of the game right before the event marked with it is executed, and they allow you to carefully inspect the game objects' properties before continuing.
To use a breakpoint, you need to right-click on an event, on a condition in an event, or on an action you want to examine. A pop up will show and select the Toggle breakpoint option. You can also erase a breakpoint that was applied earlier in the manner specified in the following screenshot:
You can apply breakpoints on any event or actions except:
You can still apply it on any sub-events that are not under a trigger. When you apply a breakpoint to an event, the breakpoint symbol is shown right beside it:
The breakpoints won't work if you just run the layout normally; they will only work if you debug the layout. I did say that breakpoints pause the game before the event marked with it is run; in the case of events, this means that the game is paused before the conditions are evaluated. This means that the debugger doesn't know whether or not the conditions are met and the event is run; you must resume execution to be able to know.
When the debugger encounters a breakpoint, the Pause and Step buttons change to Continue and Next. The Continue button makes the game run again until it comes across another breakpoint, while the Next button advances the execution one step at a time to the next event, condition, or action. This can be really useful when you want to examine the changes that take place in the Inspector tab step by step.
When the game is paused on encountering a breakpoint, the corresponding event will be outlined in a red dotted square to indicate that it is the breakpoint that is tested.
If you apply breakpoints on an event's condition, then the game will pause before the event is checked, and Construct 2 won't know whether or not the condition is met. If you have an event with more than one condition and you put a breakpoint in the second condition, it will be evaluated after the first condition is checked. If the first condition is not met, the breakpoint in the second condition won't be checked, and Construct 2 will just continue to the next event.
If you put a breakpoint on an action, the game will pause after the event is evaluated, and all conditions are met before the first action is executed. Placing a breakpoint on the first action in an event is a good thing, because it ensures that all the conditions are met before pausing the game on a breakpoint.
The last place you can apply breakpoints is in the sub-events. Similar to when breakpoints are applied to actions, putting breakpoints in sub-events only pauses the game after the event is evaluated and all the conditions are met. If the conditions aren't met, Construct 2 will continue on to the next event.