Up until now, you have learned how to make games. You now know how to use Construct 2's interfaces and how to work with them, and you also know how to use the event system to write your code and expressions. Moreover, you know how to use behaviors in objects.
However, we most likely won't write the correct code on the first try. In fact, in all the previous chapters, I corrected the code first before presenting it to you so that you only saw the good code. But now, we will write code a bit differently. I will show you the kind of situations that cause bugs to appear and how to handle them.
In this chapter, you will:
- Learn how to use the debugging function of Construct 2
- Find out what situations usually cause bugs
- Understand more about how Construct 2 picks objects
There are actually two kinds of bugs that appear in a game: the compile time bug and the runtime bug. The compile time bug is the bug that is detected by Construct 2 (or any other programming tools) when the code is being translated into a game or when it is being compiled. On the other hand, the runtime bug is the bug that is not detected when compiled, but comes up while the game is played.
The compile time bug usually appears because there's some code that's not written correctly, or, maybe, we're trying to access a variable that has not been created yet. Usually, there's no compile time bug in Construct 2, because it is designed to be beginner-friendly, and you can't do something impossible such as accessing a variable that doesn't exist.
Alright, so what usually causes runtime bugs to appear in Construct 2? Bugs appear when we do not write code clear enough for Construct 2 to understand. Let's say you're writing the code that runs at the beginning of the level, and, at that time, you want to show a pop up that says something like Level 1 begins!. You want that pop up to show and then disappear at the beginning of a level.
To make something like this, you'd add a Text object to the game and then give it a Fade behavior so that it'll fade over time. Then, you'll add the code to run at the start of the layout to show the text in the middle of the screen. You don't need to do anything to the text after it's created, because the behavior will destroy it. Let's add this Text object to the tank game project from Chapter 7, Making a Battle Tank Game, put the text somewhere off the screen, and use the following code to show the text at the start of the layout:
Let's assume that all other gameplay code is completed, and the game can be played. In this case, the players can play right when the layout starts, which also includes the time when txtDisplayLevel was still shown on the screen. This is usually not what we want because we want the pop-up text to disappear first, and then, the players can do something to the game.
We can call this a bug because players can do something they shouldn't be able to. To fix this, we need to be sure that players can only interact with the level after the pop up is destroyed. To do this, we need to add a global variable. Let's call it gameStart and keep the initial value as zero.
What we want to do is simple; when the pop up is destroyed, we will change the value of the gameStart global variable to 1, and in the gameplay code, we can make it such that the player can't do anything to the game until then:
Can you modify the code so that the game won't play if the gameStart value is not 1? You only need to modify the condition of the events that start the game. When solving a runtime bug, we must closely examine what is wrong, what is not working exactly like we want it to. Then, we'll look at that part of the code and figure out how to make it clearer for Construct 2 to understand.
The other reason that causes bugs to appear is picking the wrong object in our code. Let me remind you what picking is: it is the process of selecting objects in the event system. If you don't fully understand how picking works, you can write an event that does something to another object, other than the one you want.
Construct 2 picks objects based on the condition of the event; if all the conditions are met, then the actions are executed. Consider the following event from Chapter 6, Creating a Space-shooter Game when playerBullet collides with an enemy, then the condition is met, and the actions can be run. When running the action, we manipulate two objects: playerBullet and the enemy. Construct 2 only picked the instances of these two objects that fulfilled the condition, instead of manipulating all objects.
You could pick the wrong object because you tried to do something to an object that's not in the event's conditions; doing so will manipulate all the instances of the object instead of a specific one. For example, if, on the event shown in the preceding screenshot, you tried to destroy a star object, it would destroy all the stars.
Sub-events are events inside another event; the picking process in the sub-events follows after the ones in the event. This means the objects checked in the conditions of the sub-events are the ones that met the event above them. Consider the next event which is from Chapter 5, Making a Platformer Game, when the alien hits the floating coin box from below one of the conditions for the event is that the alien should collide with the box coin. The sub-event checks whether or not the instance variable for the box coin is true; the box coin checked here is the one that met the condition on the event:
One more situation where you'll write the event is where you try to manipulate an object that is not in the event's conditions. One example of this is in Chapter 5, Making a Platformer Game, where we want to play the alien's animation. Here, the event's condition only checks for what arrow key is currently being pressed, and the action is playing the walking animation. The only object in the condition of this event is a Keyboard object, not an alien object. In the case where the conditions don't pick an object that's being manipulated by the action, the action will affect all instances of that object.
This is one of the places where you should be careful, because if there is more than one alien object instance, then all of them would be affected. To prevent this from happening, you must do one of two things:
- Make sure that there's only one alien instance being played in the layout
- Add a condition to the event so that only one alien instance is picked
You can use unreferenced objects like this when you want to create an event that affects all instances at once; for example, you can create a bomb object that destroys all enemies when activated.