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:
- Events: This shows how much time is spent running the logic in the event sheet.
- Physics simulation: This shows the time spent running the physics calculation in the game. Since physics can be CPU intensive, it's a good idea to pay attention to this if you use a lot of physics objects.
- Draw calls: This shows how long it takes for the CPU to issue render calls; this does not include the time it takes for the GPU to draw graphics. Sometimes, draw calls can take a long time, especially if you have a lot of objects to be rendered to the screen at once.
- Engine: This is the time spent doing Construct 2 calculations, not including anything that has already been covered earlier. This means taking care of various objects' behaviors and other engine processes in the background.
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:
- The objects count: This is the total number of objects created: try not to have too many objects because this can reduce performance.
- The framerate: This shows how many times per second the game runs; the game should ideally run at 60 fps, but somewhere between 30 and 60 fps is also good.
- The estimated CPU time: This shows an estimate of how much CPU time is being used in the game. This is just an estimate and not always accurate. If you see this number going up, this means that the CPU is allocating a lot of its power to executing your game logic. You can try to do things more efficiently by not doing a lot of things at every tick.
- The estimated image-memory use: This is an estimate of how much space in memory is used by the images in the game; this only shows the memory used by the loaded images, because images use up the most space in a game. Note that this does not show the memory used by music and sound effects. If this number is high, it means you're using too many large images that might be slowing down the game; switching to smaller images would be a good idea.
- The renderer: This tells you what kind of renderer is used by the game. For faster performance, it is advised that you use
webglinstead ofcanvas2d. There is no reason for you to usecanvas2doverwebgl, but if the device or computer on which the game is running doesn't supportwebgl, Construct 2 will fall back oncanvas2d.
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:
- On triggers
- On sub-events of triggers
- On loops
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.
