Moving on With Game Maker – A Maze Game

The first game we looked at using Game Maker (“Catch a Clown”) was based very strongly on the First Game tutorial that can be found on the YoYo Games/Game Maker website.

The second game we shall look at is also inspired by an “official” Game Maker tutorial, although we’ll work through it in a slightly different way.

The original maze game tutorial assumes that there will be multiple rooms. I’ll start with a single room game and then show how to add additional rooms, as well as several other gameplay features that you may be familiar with if you have ever played classic arcade maze games such as Pacman.

To set the scene, you may wish to to relive old memories (if you’re as old as I am) or find out what the heck I’m talking about if you’re a member of the Google generation!

Play a quick game of Pacman (try the arrow keys!) Can you work out how the controls affect the direction of the player character? How are points scored in the game? What about bonus points and penalties? How many ‘modes of behaviour’ do the ghost characters have, and what happens in each mode?

If you aren’t into arcade games, at least watch a quick run through of the game:

In the Catch a Clown game, the clown sprites moved around the room of their own accord, changing direction whenever they bumped into a wall. In many games, the real player will control the movement of a player character within the game, either using keyboard commands or another physical input device such as a joystick or gamepad controller, (or if you have a bluetooth computer, maybe even a wiimote… but that‘s for another day ;-)

Danger Maze

In this bundle of Game Maker activities, I’ll show you how to build a maze type game that is spread over several rooms, each of which may be populated by angry monsters or prizweworthy jewels! By taking control of the player character, the real player will have to find their way through each of the rooms, avoiding any monsters that may cross their path and collecting treasure wherever they can.

The audio and image assets used in the game can be found in the Maze Games Tutorial which can be found on the Yoyo Games tutorial page. (Download the tutorial directly from here).

To start with, we will construct a single room game, where the object is for the player to reach a special goal square, at which point a congratulatory message will pop up and the game will end.

Create three sprites (spr_player, spr_wall and spr_goal), and three objects corresponding to those sprites (obj_player, obj_wall and obj_goal) and configure them as follows:

• The wall object is empty of actions.
• The goal object has collision event with player that raises a display message action: “Game Over” before ending the game after a short delay.

In this first pass at our maze game, the player object is – if you will forgive the pun – where all the action is.

Let us think first of all what we want our player character to do. In response to particular key presses, we want the player character to move. But how?

There are two main ways of controlling the movement of the player character:

1. the character can move while an appropriate key is pressed, or
2. a key press may change the direction of a continuously moving player character.

In the latter case, you may also want to specify the original moving direction of the player character when it is created, so that is starts moving as soon as you enter the room. To prevent the character from moving too far before the player gets a chance to decide for themself which direction they want the character to move in, you may wish to ‘trap’ it so that it bounces between two wall blocks that are one or two squares apart.

You will also need to check the alignment of the player sprite with the grid before changing direction.

The original Game Maker tutorial describes the situation as follows:

[The player character] must react to input from the user and it should not collide with a wall. We will use the arrow keys for movement. (This is natural, so easy for the player.) There are different ways in which we can make a person move. The easiest way is to move the player one cell in the indicated direction when the player pushed the arrow key. A second way … is that the person moves in a direction as long as the key is pressed. Another approach is to keep the player moving until another key is pressed (like in PacMan).

[First of all, let’s consider the second way – the player character moves in an appropriate direction whilst a key is pressed, unless blocked by a wall.]

We need actions for all for arrow keys. The actions are rather trivial. They simply set the right direction of motion. (As speed we use 4.)

To stop when the player releases the key we use the keyboard event for. Here we stop the motion. There is one complication though. We really want to keep the person aligned with the cells of the grid that forms the maze. Otherwise motion becomes rather difficult. E.g. you would have to stop at exactly the right position to move into a corridor.

This can be achieved as follows. In the control tab there is an action to test whether the object instance is aligned with a grid. Only if this is the case the next action is executed. We add it to each arrow key event and set the parameters to 32 because that is the grid size in our maze.

Moving the player critter – if you want to align the player critter with the grid, you will need to add the check grid action to each keyboard event before you change direction.

Clearly we also need to stop the motion when we hit a wall. So in the collision event for the person with the wall we put an action that stops the motion.

There is one thing you have to be careful about here. If your person’s sprite does not completely fill the cell, which is normally the case, it might happen that your character is not aligned with a grid cell when it collides with the wall. (To be precise, this happens when there is a border of size larger than the speed around the sprite image.) In this case the person will get stuck because it won’t react to the keys (because it is not aligned with the grid) but it can also not move further (because the wall is there). The solution is to either make the sprite larger, or to switch off precise collision checking and as bounding box indicate the full image.

Describing the required key controls in a textual way is not necessarily the clearest way of presenting the information. Can you create a tabular layout that states the actions for each key for both the “move on press” and “Pacman” types of player character motion?

Select one of the movement types and use it to configure your player character. If you want to use the Pacman style of motion, you will need to define the player object as follows (without the ‘no key’ object):

Reporting the Configuration of an object.

The above screenshots showed how the various maze game objects should be configured for this game. If you wanted to document your game by listing the settings of the events and actions associated with each object, it could take a significant amount of time to create that sort of view. Fortunately, the Advanced Mode within Game Maker provides an option to display information about an object in this sort of form:

From the Game maker File menu, see whether the ‘Advanced Mode’ is set. If it isn’t, save you game, then select the Advanced Mode. You will need to close Game Maker and restart it for the change to take effect.

To display the Object information panel, from the Edit menu, select Show Object Information.

Henceforth, I shall try to use this sort of report to summarise the settings of an object so that you can check your
settings against them, rather than providing pages of screenshots showing how to configure a particular object.

Movement Directions in the Show Information Report

Although it may be obvious to some, just how to read statements like:

Keyboard Event for Key:
start moving in directions 000100000 with speed set to 4

may not be obvious to all, so here’s the trick to reading the long string of 1s and 0s.

The movement setting allows you to specify which directions the object might move in, organised on a 3 x 3 grid, giving nine possible grid locations. The string of 1s and 0s is 9 items long (count them!). The top row of the direction setting grid, read from left to right, corresponds to the first three locations, the second row, again read from left to right, the fourth, fifth, and sixth locations; and the bottom row the last three locations.

A ‘1’ in the “string” of digits specifies the corresponding directional element has been selected, and a ‘0’ that is has not.

Creating the Room

Create a new room, and set the grid size to 32 x 32. Select the wall object in object area of the Room Properties dialogue. Draw a wall around the edge of the room to mark out the borders of the maze. Remember that you can ‘paint’ a wall by pressing the Shift key as you click and drag the cursor round the room, rather than just clicking to press each wall brick separately. Right click on a wall brick to delete it.

You may find it convenient to get into the practice of leaving a one or two row border of empty grid squares at the bottom of the room for displaying a running score, and other game related information, although we shall not be calling on this requirement for the moment. For now, do not put any inner walls in the maze – just leave the inner area empty, as it was in the Catch the Clown Game.

In the centre of the room, place a wall block at the corners of a 3 x 3 grid square grid to define a simple crossroads, with an instance of the goal object somewhere else within the room.

Now use this simple room to check the controllability of the player character, by seeing how easily you can navigate through it and turn a corner in the centre of it.

Place an instance of the player character in the centre of the room and run the ‘game’.

Check that the player character behaves as required in response to your key presses, then exit from the ‘game’ by pressing Esc. If the player character did not work as required, check the settings of the player object.

Different Game Mechanics

Duplicate the player object to create a second player object, and configure it so that it uses the other type of movement to the movement type you originally selected. Replace the instance of the first type of player object with one of the second player object type.

Run the game again and see how this second movement type compares to the first.

If you do not enforce grid alignment using the continuous movement mode, it can be rather tricky to control the player accurately.

By using the grid alignment control at the start of each key press action, the controllability of the player character can be improved.

How easy is it to control the movement of the player accurately with and without grid alignment in the continuous movement and ‘move-on-click movement modes?

How does the ease or difficulty of controlling the player character’s movement accurately change with different player movement speeds? What speed provides the best balance of controllability and ‘excitement’?

In the next post, we’ll put together a proper maze and find out how to create a 2 room game, before moving on to add treasure and monsters in later posts…

Advertisement