The most common type of error is a syntax error, which is an error that occurs when you fail to follow GML’s syntax requirements. This can happen, for example, when you make typos when keying in code statements or when you fail to provide required arguments when calling on GML functions. Syntax errors in GML scripts prevent your games from running and result in the generation of an error message. For example, suppose you add the following statement to a GML script.

play_soun(snd_help);

This statement was supposed to play a sound file. However, a typo has been made when attempting to reference the PlaySound() function. As a result, an error message like the one shown in Figure 11.2 is displayed if the application containing the script is executed.

Figure 11.2. A syntax error generated because of a typo in a function name.

Game Maker’s error messages provide an explanation of the error and tell you where it was found. This error could have easily been caught prior to running the application by clicking on the Script Editor’s Check the Script for Syntax Errors toolbar button. In response, Game Maker performs a syntax check of your code statement and highlights the error, as demonstrated in Figure 11.3.

Figure 11.3. An example of a syntax error that has been flagged by Game Maker.

Because they generate error messages, syntax errors are relatively easy to deal with. A more sinister type of error to deal with is a logical error. A logical error is one that occurs when you apply faulty logic when performing a task. For example, a logical error occurs if you accidentally add together two numbers that you should have multiplied or divided. As a result, your application runs and does exactly what it was told to do, yielding output that is contrary to your expectations.

The challenge in tracking down logical errors is that they do not generate error messages. The best way of dealing with them is to prevent them in the first place, which you can do through careful planning and testing. If, despite your best efforts, you believe a logical error has made its way into a GML script within an application, you should review your script to see if you can spot the problem. If you are unable to track it down, you can try to track it down using Game Maker’s built-in debugger, which is covered a little later in this chapter.

A third type of error that you need to be on the lookout for is a runtime error. A runtime error is one that occurs when your application tries to perform an illegal action. One of the problems in dealing with runtime errors is that Game Maker cannot detect them when scripts are interpreting for execution. Runtime errors can occur for a number of reasons. For example, a needed file might have been deleted or the drive on which it results might crash. As a simple example of what a runtime error looks like, consider the following script.

{
    number = get_string("enter a number","");
    number = real(number);
    result = 5 / number;
    show_message(string(result));
}

Here, a popup dialog window is displayed that prompts the user to enter a number. Since the get_string() function returns anything it collects as a string, the data that the user enters is converted to a real number using the real() function. This value is then used as the denominator in a mathematic expression, the result of which is then converted back to a string using the string() function and then displayed in a popup dialog using the show_message() function. A runtime error will occur when this script is executed whenever the user enters a non-numeric character or if the user enters a zero, because division by zero is an illegal operation.

Depending on what your application is designed to do, it may not be possible to eliminate every possible runtime error from occurring. However, careful testing and a little data validation may go a long way in helping to reduce their occurrence.

The debugger’s Watch menu provides access to the following commands.

Using these commands, you can enter a list of expressions whose values you want to monitor during your debug session. For example, Figure 11.5 shows how the Debugger Information window looks when monitoring three expressions.

Figure 11.5. Monitoring expressions that you want to keep an eye on during your debug session.

One of the most important features of Game Maker’s debugger is its ability to display and dynamically update both local and global variable values during the debug session. To do so, click on Tools > Show Global Variables or Tools > Show Local Variables. Figure 11.6 shows an example of what you will see when monitoring a game’s global variables.

Figure 11.6. The data that is displayed in the Global Variables window is continuously updated, allowing you to keep an eye on how the data is being collected and managed.

The Local Variable window displays similar data for a local variable that you want to monitor. You can monitor as many different local variables as you want at the same time. The Tools menu also provides commands that let you monitor the status of object instances.

If you want, you can execute a code statement during your debug session and then observe its effect on the application’s execution. One reason for doing this might be to change a variable value to see what impact it has on how the application executed. To do so, click on Tools > Execute Code. This displays the popup dialog window shown in Figure 11.7.

Figure 11.7. You can execute code statements when debugging to see how they impact your application.

All you have to do is enter the desired statement and click on the OK button and then monitor its effect on the application. If you want, you can also change the speed at which the application is executing, by clicking on Tools > Set Speed. This displays the popup dialog window shown in Figure 11.8.

Figure 11.8. Changing an application’s speed can slow down or speed up a debug session.

By changing an application’s speed, you can temporarily slow things down so that you can more closely observe what is going on or you can even speed things up.

Begin the development of the Arachnid Attack! game by adding all the sprites required by the game. Begin by starting Game Maker. If it is already started, click on File > New to begin a new game. The following procedures outline the steps required to create the game’s sprites. Note that the graphic files for all of the game’s sprites are available for download from the book’s companion webpage (www.courseptr.com/downloads).

The Arachnid Attack! game will also include a front end. To support the development of this room, you will need to add five additional sprites to the game as instructed below.

The second step in the development of the Arachnid Attack! game is to add the sounds needed to provide the game’s sound effects. These effects include playing an explosive sound whenever a bug or the player’s jet is shot, playing a sound when the bug army advances down the screen, and playing a sound when the wasps glide across the top of the screen. Sounds are also played when shots are fired. All of the audio files you will need to create these sounds are included with Game Maker. By default, Game Maker places these audio files in C:Program FilesGame Maker7Sounds.

The following procedure outlines the steps required to add and configure all of the game’s sounds.

The game will display the player’s score on the screen during game play. Game Maker’s default font size of 12 is too small to adequately display the player’s score. To address this situation, you must add a font to the game using the following procedure.

The Arachnid Attack! game is made up of 12 objects plus an additional five objects needed for its front end. The objects include different types of bugs, the player’s jet, player and bug bullets, and the wall objects that are used to build bunkers behind which the player can hide his ship. The game will use a parent object for the ant, spider, and beetle bugs, allowing behavior to be inherited and thus simplifying game development. Likewise, a parent wall object will be created. Finally, there will be a special controller object and a series of objects needed to build the front end. Instructions for creating all of these objects are provided here:

The next step in the development of the Arachnid Attack! game is to add two rooms to it. These rooms represent the game’s front end and the room that the game is played in. Instructions for creating and designing these rooms are provided in the sections that follow.

Adding a Room for the Game’s Front End

To create the game’s front end room, click on Resources > Create Room. The Room Properties window appears. Click on the Settings tab and then name the room room_intro. Change the size of the room, setting width to 514 and its height to 360, and then add a caption of Arachnid Attack! to the Caption for the Room field.

To finish up the development on the room, click on the Objects tab and then add an instance of each of the following objects to the room: obj_intro, obj_ start, obj_scores, obj_help, and obj_quit. Arrange these instances as shown in Figure 11.10.

Figure 11.10. Completing layout and design of the game’s front end room.

Adding a Room in which to Play the Game

Add a second room to the game and click on the Settings tab, naming the room room_level1. Change the size of the room, setting width to 514 and its height to 360 and then add a caption of Arachnid Attack! to the Caption for the Room field. Also, modify the room’s Speed stetting to 55. This will speed up the play of the game within the room to an appropriate level.

To wrap up work on this room, click on the Objects tab and then add the following object instances to it: obj_ant, obj_spider, and obj_beetle; obj_block, obj_half_block, obj_player, and obj_controller. Arrange these instances as shown in Figure 11.11.

Figure 11.11. Creating a room that the game will be played in.

Now it is time to develop the programming logic required to bring the Arachnid Attack! game to life. As previously explained, the game’s programming logic will be developed using a combination of GML scripts and action icons. Let’s begin by developing the three GML scripts that will be used to do the following:

/*This script creates a number of variables for the obj_controller object*/
{
     //Used to set the bug's pace
     game_pace = 20;

     //Used to keep track of when obj_controller should do something
     counter = 0;

     //Specifies the direction the bugs are currently moving
     currentDirection = 9;

     //Specifies the direction the bugs should move (initially to the right)
     targetDirection = 9;

     //When set to true the bugs should move
    timeToMoveBugs = false;

     //When set to true the bugs should move down the screen
     moveBugsDownward = false;

     //Used to set flag indicating when the bugs have been moved downward
     downMoveComplete = false;

     //Capture the initial starting location of the player's ship
     startx = obj_player.x;

     //Capture the initial starting location of the player's ship
     starty = obj_player.y;
}

/*This script is executed by obj_controller at every step that occurs in
the game. */
{
   counter = counter + 1; //Increment the variable by 1

   //When counter equals game_pace it is time to move the bugs
   if (counter == game_pace) {
       timeToMoveBugs = true;       //Set bug movement trigger
       sound_play(snd_bug_move); //Play the sound
   }

   //See if the bugs have already been moved
   if (moveBugsDownward == true) {

       //If downcheck equals true the bugs have already been moved
       if (downMoveComplete == true) {
           moveBugsDownward = false; //No need to move bugs
           downMoveComplete = false; //Turn off variable flag
       }
   }

    //Determine if a new cycle should be started
    if (counter > game_pace) {
        counter = 0;        //Reset counter to zero to
        timeToMoveBugs = false; //Disable bug movement trigger
    }

    //See if the bugs have switched directions
    if (targetDirection != currentDirection) {
        moveBugsDownward = true; //Time to move the bugs downward
        targetDirection = currentDirection; //Update the target direction
    }
    //Check to see if the player has killed all of the bugs
    if (instance_number(obj_bug_parent) == 0) {
        room_restart() //Restart the room if all bugs are destroyed
        sound_stop(snd_wasp) //Disable sound playback
    }

    //Randomly create instances obj_wasp
    if (action_if_dice(2000) == true) {
        //Position it in the upper-left corner
        instance_create(20, 30, obj_wasp)
    }
}

/* This script controls the movement of the bugs*/
{

    //See if it is time to move the bugs
    if (obj_controller.timeToMoveBugs == true) {
        //See if the bugs should be moved to the right
        if (obj_controller.currentDirection == 9) {
             //Make sure the bugs should not be moved downward
             if (obj_controller.moveBugsDownward == false){
                  x=x+9; //Move the bugs 9 pixels to the right
                  y=y+0; //Make no changes downward
             }

        }

        //See if the bugs should be moved to the left
        if (obj_controller.currentDirection == -9) {
             //Make sure the bugs should not be moved downward
             if (obj_controller.moveBugsDownward == false){
                 x=x- 9; //Move the bugs 9 pixels to the left
                 y=y+0; //Make no changes downward
             }
        }

        //See if the bugs should be moved downward
        if (obj_controller.moveBugsDownward == true) {
            x = x + 0; //Make no changes left or right
            y = y + 9; //Move the bugs downward 9 pixels
           //Mark the downward movement as complete
           obj_controller.downMoveComplete = true;
        }
   }  else {
        //Make sure the bugs have not tried to move too far to the right
        if (self.x > 480) {
            obj_controller.currentDirection = -9 //Change the bugs' direction
        }
        //Make sure the bugs have not tried to move too far to the left
        if (self.x < 32) {
            obj_controller.currentDirection = 9 //Change the bugs' direction
        }
   }
}

You are almost done. All that remains is to add a little game information so that the player will know how the game is played and to modify the game resolution, demonstrating how Game Maker manages screen resolution settings on computers with different resolution settings. To create the game’s information page, double-click on the Game Information entry in the resource tree folder, and then enter the text shown below, which describes the game and how it is played.