To round off the tidying up of the maze game, it’s probably worth revisiting the aural dimension. Sound design is a major factor in the early success or otherwise of many computer games (none more so than audiosurf – fancy riding Song 2? Woo hoo…;-) and one that we have only paid passing reference to in the design of the maze game so far.

There are three main components to the sound design of a game.

Firstly, there is the background musical soundtrack. In many driving games, this may be contextualised by an in-car radio player (the Grand Theft Auto series has a prime example of this), but often the soundtrack has more in common with the background music of a film. The way that the background music can be used to set the emotional tone of a scene and its potential effect on setting the mood of the player should not be underestimated.

The second component relates to sound corresponding to foreground events. The player character saying “ouch” if attacked by a monster, or an audible reward to complement the collection of a treasure item.

These sounds are typically triggered by actions performed in response to a particular event being raised by object interactions within the game, in contrast to the background music which plays ‘just anyway’.

The third component is incidental background noise. This corresponds to the everyday background noise that ‘thickens’ a scene and adds depth and character to it.

Hopefully, you have already added some sounds to your game, for example to reinforce the collection of a diamond, the capture of the player character by a monster, the unlocking of a door, or the completion of a room by reaching the door.

(As well as the sound files in the game Maker maze tutorial folder, you can find additional sounds on the Game Maker site: Game Maker resources: sounds.)

Adding background music

To complete the game, we are going to add some background music.

There are two ways of doing this: use a MIDI file, or use an audio file.

• MIDI background track: MIDI (”Musical Instrument Digital Interface”) is a protocol (that is, a conventional language) that was originally used to connect physical music synthesizers (that is, digital music keyboards!) together. MIDI is increasingly used to ‘program’ music that is played by an audio synthesiser to create a musical background track. A MIDI file essentially instructs a synthesizer (sound generator) what sound to play, when, and for how long. Most computers today have a sound card that is capable of generating sounds from a MIDI file.
• audio background track: an audio file is just a recording of a sound. Game maker can play two different sorts of audio file: WAV files (simple digital recordings of of sound); and MP3 files (compressed audio files; that is, audio files that have been digitally manipulated so as to take up less memory space in a computer.)

Audio files are best used for foreground sounds – sounds used to denote a collision event within the game for example. WAV files, whilst being larger than MP3 files, can be played directly. In comparison, MP3 files must be uncompressed before they are played, which takes up computer processor time (time which may be better spent actually managing the computer game, looking for collision events and keyboard button presses, for example).

The smaller MIDI files are better suited to ongoing background music. Often, a computer’s audio card will manage the playback of the sound from the MIDI file.

To load music in to the game, select Create Sound from the Resources menu.

To use a MIDI file for the background music, select ‘Background music’; to play an MP3 or WAV music file, select the ‘Use multimedia player’ option.

The background music should be started from the Create event of a spriteless controller object added to the room, and set to loop.

If you do use a music file that his played via a multimedia player, you should preload it so that loading it does not slow the game down as once it is being played. However, for large audio files, the memory requirements of preloading the audio file may affect the performance of the game.

When using audio files you should take care that copyright licenses are not being infringed, particularly if you intend to distribute the game or even share it with other people.

Visually, our simple maze game leaves a lot to be desired. The design of the walls is not particularly appealing, for example, or realistic in anything but the most stylised of senses.

In this post, I’ll look at how to add a bit of visual flair to the maze, giving the walls a mock 3D look (actually, an isometric view).

To do this, we’re going to use a tileset. Tiles are small, regularly sized images, such as we have used in our sprites so far; (each image in a sprite might be considered a tile, for example).

A tileset is a single bitmap image that contains a mosaic of several separate, similarly sized tiles, each designed in accordance with a particular theme and with the intention that they are used in association with each other. Tiles are organised in rows within the single bitmap image.

The tileset thus provides a convenient way of packaging several images in a single file and reusing them within an environment such as Game Maker.

To create the (hopefully) good looking version of the maze, you will make all the walls invisible, and add in a background image layer to the game. The background image is drawn in such a way that things that look like walls are placed on the background image underneath the actual, invisible (and ’solid’) wall objects.

It may feel as if there is some trickery going on here – and indeed there is! The background image, which will depict the walls, plays no tangible part on the execution of the game. When the player character ‘collides’ with the background drawn wall image, no event will be raised. Instead, solid, invisible wall objects placed ‘on top of’ the background drawn walls will provide an obstacle to the player character, will raise an appropriate event and may execute appropriate actions.

Save a copy of your game as it currently stands, for reference purposes, and then save it again using a new name – this will be your new working copy of the game. In the wall object, change the sprite to . You should still be able to see where the wall objects are in your room(s) because they will be depicted by question marks.

Now you need to draw in the walls using tiles from an appropriate tile set shown – like this:

Save the tileset file to your desktop or Game Maker folder from the following link: Walls Tileset (right click, Save As…)

To load the tileset in to Game Maker, select Create background from the Resources menu, select Load Background and load in the tileset image file that you saved to your computer.

In order to actually use the image as a tileset select ‘Use as Tileset’ in the Background properties dialogue. The tile width and
the tile height should both be set to 32. The image should also be set to Transparent.

Using Game Maker in Advanced Mode (set via the File menu – remember to save your game and reload it if you need to change to
Advanced mode from Simple Mode), open up a room and select the Tiles tab from within the Room Properties window. You can
now select any of the tiles and add them to the room.

Using the ‘invisible’ wall objects as a guide, add appropriate wall-image blocks from the tileset (just select the image you want from the Tiles tab and then click in the room where you want that image to appear. Only add wall images at this point (don’t bother with any grass!)

By carefully changing the view properties of the room, you can toggle between the background view and the view of the room containing the wall objects:

From the images shown above, you will see that as well as the walls, I have added a grass background to the room. This part ofd the background actually sits on a lower ‘layer’ than the wall images. (Think back to how traditional cel animation works – frames are built up by drawing a background image and detail that increasingly lies in the foreground is drawn on to transparent acetate sheets that are placed on top of the background and each other).

If you “deselect” the view of the Tiles, you can look at each layer separately:

Add additional layers by clicking on the Add button. You can change the layer number by clicking Change. The higher the layer number, the further into the background it is. (If you find that you have your layers the wrong way round, just change the layer number).

For the grass layer, you can cover the whole room – the wall images will sit above the grass. If the background/tile set is set to transparent, then the grass will show through at the ends and corners of the wall.

Even though we no longer want to see the wall sprite when we are playing the game, we still need to use that sprite within the wall object, albeit making it invisible (untick the Visible checkbox).

There are two reasons for this: firstly, the boundary of the sprite identifies the collision area that is used to detect a collision and raise a collision event; secondly, it means we can see where we’ve drawn the wall when we are editing the room!

So – get to it ;-) See much better room looks once it has real walls?!

You can find more information about using tiles from the Game Maker Help file (hint: search for ‘adding tiles’). Being able to locate and learn from sources of instruction – such as Help files – is an important skill, and one that will enable you to get started with a wide variety of content generation tools that are available on the web.

If you want to explore the world of tilesets more fully, you can find more example tilesets on the Game Maker website: Tileset downloads.

If you want to create and manage your own tilesets, download and install this Tileset Maker for Game Maker (that’s where the tileset image I used in this post actually came from…)

To recap: a tileset is a single image that contains a mosaic of regular, smaller images that have been designed to complement each other. When a tileset is loaded as such, the single tileset image is essentially ‘cut’ into a multitude of separate images that can each be used separately.

So far, we have been using single image sprites in our games. However, sprites offer much more potential than this. In particular, sprites typically contain several images that can be used to animate the motion of a character. Each ‘frame’ in the sprite animation is displayed in turn to give the appearance of motion (similar to the way an animated gif actually ‘contains’ several images that are displayed in sequence). However, it is also possible to select and display just a single frame image from within the sprite at any particular time, as you will discover…

In particular, you are going to animate your player character so that as it moves, it appears to be looking in the direction it is traveling.

Save your game, and then save it again with a new name to create a new version of it. Click on the player sprite and load in the new sprite playerNice.gif from the maze game resources folder.

In the Sprite Properties window, you should see that the sprite contains several image frames that you can click through.

Opening the Image Editor makes the compound, packaging nature of the sprite even more evident.

The separate frames may be used to animate a character so that it appears to move (for example, animating a character’s legs so that it appears to be walking or running, or animating a fire so that it appears to be burning) or simply be used as separate, static images to change the (fixed) view of a character depending on what it is doing at any particular time.

The player sprite you have just loaded will be used to animate the player character in this second sense. That is, rather than animating the character so that it appears to move, we shall animate it so that the view we have of it is depnedent on what it is doing.

As the game originally stood, even though the player character could move in one of four different directions, it always looked the same. that is, it never ‘really’ looked where it was going. If you clicked through the sprite images, you should have seen that the sprite depicts four faces of the player character – left facing , forward facing, right facing and backward facing.

To set the subimage that is displayed when the player character changes direction, you will need to add and a Change Sprite action from the Sprite panel on the main1 actions tab to each of the keyboard events associated with the player object.

By way of example, for the left arrow, add the Change Sprite action and configure it as follows: select the player sprite, select the appropriate subimage (click through the subimages with the Sprite Editor menu to identify the correct one) and set the speed to 0. (The speed here corresponds to the speed at which each of the images contained within the sprite are cycled through; because we are not using the sprite images as ‘free running’ animation frames, we don’t want Game Maker to cycle through them for us each time the character is redrawn, so we set the speed to zero.)

Run your game. How much more ‘realistic’ is the behaviour of the player character now?

If you are feeling particularly creative, have a go at editing the player sprite, for example by changing the colour – or “cut” – of its clothes. Sprite design is just one of the many tasks required of graphic artists in the games industry. Would you have what it takes to become a sprite designer? What skills do you think are required?.

If you are using the movement scheme in which the player character only moves whilst a key is being pressed, which sprite subimage works best when no key is pressed? What happens if you do not use the Set Sprite action at all in this case?

If you did not set the sprite subimage for the event, you may have found that the sprite appears to spin round when you are not pressing any keys. To keep the sprite facing the direction it was facing in previously in this case, you should set the sprite within the person create event to an appropriate subimage of the person sprite and with speed zero. The speed setting here is crucial. Setting the sprite’s image changing speed to zero here means that the sprite image will be essentially fixed, unless the speed is set to a non-zero positive value elsewhere.

With a little imagination, sprites can be used to provide a ‘context sensitive’ view of a character. If you think back to the original Pacman game, the view of the player character depending on which direction it was facing, and the colour of the ghosts changed depending on whether they were in “fight” mode – when they could kill the player character – or “flight” mode – when, after eating a particular piece of fruit, the player character had a period of grace in which it could attack the ghosts and send them back to the pen in the centre of the room.

Many maze games involve the collection of point scoring treasure. In our maze, we shall require the player character to collect diamonds, and receive points in exchange for them.

Create a diamond sprite (use the diamond.gif image in the Resources folder) and use it to depict a diamond object (obj_diamond).

Now think about what you want to happen when the player collides with the diamond. I can think of two essential actions and at least one nice-to-have.

What actions do you think are required? [Think about it... ;-)]

When the player character collides with a diamond, we need to increment the player’s score, and make the diamond disappear. I think it would also be nice to provide an audible reward when a diamond is collected, by playing a sound.

The simplest way of adding these actions is to create a collision event for the diamond object that detects a collision by the player object, and then:

• increments the score;
• plays a sound (remember – you’ll need to add one to the library first!)
• and then destroys the current (self) diamond object instance (so we can’t keep collecting the same diamond again and again, ad infinitum, and racking up a very high, if tediously achieved, high score!).

Alternatively, you could set a single action for the collision event that destroys the diamond object instance, and then use a Destroy event within the diamond object to trigger the score and sound actions.

Try adding some instances of diamonds to at least one of the rooms. Does the opportunity to collect treasure affect the way that you guide your player character through the room?

If you have any monsters in the room, try to arrange the position of some of them so that they guard a particular diamond. Is it possible to position the monsters in such a way that it makes it impossible for the player character to acquire a particular diamond? If so, how do you think this will make the player feel?

Can you position the monsters so that some diamonds are more difficult to reach than others?

If some diamonds are guarded by monsters in such a way that the player character feels that there are quite likely to risk losing a life collecting a particular diamond, they may decide to forgo it and not even attempt to collect it. How could you motivate – or even compel – the player to try to collect all the treasure items in the room, or at least a certain minimum number of them?

Blocking progress to the next level until a challenge is completed

A common theme in many early maze games was to block the player from exiting the room and moving onto the next one until all the treasure items had been collected. One widely used metaphor was to provide a “locked door” that barred the way to the next level and that could only be opened by the player collecting all the treasure items. (Alternatively, the player might have to collect a single magic key from somewhere within the level in order to open the door.)

Write down a brief specification of what objects, sprites, events and actions actions you think you need in order to implement a locked door that blocks access to the way out of a room, and that can only be opened (destroyed?) once you have collected all the diamonds in the room.

Here’s one way of approaching the problem: “every time the player collides with a diamond, after destroying the diamond object (an action that is executed when the ‘Collide with player’ event is within the diamond object) test to see whether the count the of the number of instances of the diamond object is zero; if it is, destroy the door”.

• create a new door sprite (spr_door) by copying the wall sprite, and changing the colour (refer back to Editing a Sprite if you can’t remember how to do this); add the door to the maze so that it blocks access to the exit;

  

• copy the wall object to create a new door object (obj_door) and use the door sprite to represent it;

  

• add a Test Instance Count action from the Questions panel of the control tab, and configure its properties so that it will test whether the number of instances of the diamond object is equal to zero; as the very next action (the action that will be performed if the diamond instance count is zero) use a Destroy event from the Objects panel of the main1 tab configured to destroy instances of the object obj_door.

  

The first Destroy action should destroy the “self” diamond object instance. The second Destroy action – which is executed if the previous conditional statement evaluates as true (that is, if there are zero instances of the diamond object) should apply to the door object:

You might also find that the experience of the game is improved if you give an audible signal to the player when the goal of unlocking the door has been achieved.

Try running your program. Does the door disappear when you have collected all the diamond objects? What would happen if you had several door instances in the room?

How do you think you might extend the game further so that a locked iron door barring the way out of the room can only be unlocked by collecting a rare ‘red diamond’ placed somewhere within the room? Suppose further that access to the red diamond is blocked by a different sort of door that can only be opened by collecting at least three ‘ordinary’ diamonds.

Achieving the same thing, but differently…

One of the attractive features of Game Maker (depending on your point of view!) is that there are often several ways of achieving the same thing. In the previous section, we used the player collision event within the diamond object to open the door when the diamond count in the room hit zero. Alternatively, we could have used an action within the door object to achieve the same thing. In this case however, we would apply the destroy action to the self object if the diamond count equalled zero. In order to test the diamond count regularly, we would need to place it within a Step event in the door object.

To understand how the Step event works, you need to understand a little about how Game Maker operates when a game is played. Essentially, many times a second, Game Maker looks in turn at each instance of each object within the current room, testing each event as it does so. If the event is true, then the actions for that event are performed.

The Step event is simply an event that says ‘each time you test me, then perform the actions associated with me’. In this way, every time Game Maker ‘looks’ at the state of the door object, it will run the actions performed with the step event, and test how many instances there are of the diamiond object in the room…

If you were unfortunate enough to be caught by one of the monsters in the game, you may have found it rather unsatisfying to have the game immediately end – you may have had the feeling that a slip of the keys was to game, or a miscalculation about the speed of the monster that you won’t fall for again.

The majority of arcade style games in which the player character can be “killed” offer the player the chance to play again. So common is the idea of “three lives then you’re out” that it could almost be described as a convention – and something that players will expect the game to offer.

So how can we introduce the notion of lives into our maze game?

As in Who’s Best? Keeping Track of High Scores and Upping the Stakes – Bonus Points, we will call on a controller object to manage the lives of our player character. Create a new controller object (controller_lives, for example; no sprite required) and add the following events:

- from the Event Selector, choose Other and then Draw Lives. You will need to add two actions to this event: Display a message (”You lost *all* your lives!”,maybe?!), which can be found in the Info panel of the main2 actions tab; and an End Game action, from the Game panel of the same tab;

- again from the Event Selector, choose Draw, and add the Draw the lives as image action from the score actions tab. Double click on the Draw the lives as image action to raise it properties dialogue, and put in the co-ordinates of where you would like the lives counter to appear on the screen. Select an appropriate image for the life counter (for 3 lives, 3 images will show…)

Now add the controller object to the room (it doesn’t really matter where). The controller object will manage what happens when you lose a life, or when your lives run out. But how do we get our lives in the first place? And how do we lose them?

In the player object (obj_player), add a Create event, containing the Set lives action from the score tab; set the number of lives to 3. When an instance of the player object is created, it will now be initialised with three lives.

To lose a life, we need to revise what happens when a monster collides with the player character. Still referring to the player object, select the appropriate Collision Event, remove the End Game action (this is now being managed by the controller object), and add the following actions: Set Lives (from the score tab, and with the properties “relative to -1″); and Jump to Start (from the move tab).

Run your game. Hopefully, you should find that you now get three chances to cross the room. If a monster catches you, your player character is returned to the point at which it entered the room.

Does the addition of multiple lives improve the playability of the game. I certainly found it less frustrating when I got caught, knowing that I’d be able to have another go (having possibly worked out how to get round a particularly trickily placed monster!)

How important is the number of lives that a player is given? Why do you think the game might be less satisfying if the player had four or five lives, for example?

As well as losing something – lives in this case! – we also want our player character to be rewarded in some way as they progress through a room, so that the player can gain some sort of points scoring reward even if they don’t manage to cross the room completely.

In the next post, I’ll show how to add some ‘treasure’ to the room that will reward the player with points as they collect the treasure items.

In the meantime, what do you think should happen when a player collects (i.e. collides with) a treasure object? What objects, sprites, events and actions will we need to add to the game in order to implement “treasure”? ;-)

[Screenshots missing - I will add them by first thing tomorrow morning...]

When you created added several monsters to the maze game that moved in different directions (Adding Monsters to the Maze Game), you may have found that you forgot to add an event to the player object that checked for a collision with am instance of a “vertical monster” object as well as an instance of the “horizontal monster” object. (If that is the case, the player would not have suffered any ill consequence of colliding with a vertically moving monster; to remedy this oversight (?!), you need to check for a collision with an obj_verMonster in the player object, and add a similar set of actions as used in the collision with an obj_horMonster event.)

If you have lots of objects that are ‘variations on a theme’ – such as the monster objects – it can become quite confusing trying to maintain separate collision detection events for each of them.

However, there is a technique we can use whereby objects can ‘inherit’ certain properties from other ‘parent’ objects, in such a way that allows them to be treated as those parent objects in certain respects.

(Objects, instances and inheritance are all ideas taken from computing/software engineering – in particular, the object oriented programming model. I’ll cover some of the basic nitty gritty in another post, but if you’re already familiar with the basic idea, and are feeling up to a challenge, you can maybe learn a bit more from this OpenLearn unit on Modelling object-oriented software – an introduction .)

To make use of these ‘object inheritance’ properties, you will need to run Gamemaker in Advanced mode. If you are not already in Advanced Mode (?!), save your current game, go to the File menu and select ‘Advanced Mode’. Gamemaker will close and open again with a new game, so you will need to open the game you just saved back in.

Delete the vertical monster object and the corresponding collision event from the player object and create a new ‘vertical monster’ object. Give it an appropriate sprite. You should see that there are now several more options in the object editor now that we are in advanced mode. The one we are interested in at the moment is the parent property.

Set the parent of the vertical monster to be the horizontal monster.

If you were now to add the vertical monster to the game, it would behave in exactly the same way as the horizontal monster – it has inherited all its behavioural properties.

However, we can override some of those properties by explicitly defining them within the vertical monster object. In this case, the property we want to override the direction the monster moves in, so add a Create event that sets the movement direction to be up or down, with a speed greater than that of the player object.

We do not need to explicitly define the collision event between either the vertical monster and the wall, or the player object and the monster because the player essentially sees the vertical monster as a horizontal monster type and reacts to it as such.

With multiple monsters in your game, it is possible to set up many situations that may prove increasingly challenging for your player to negotiate. For example, see if you can set up a couple of rooms that are empty except for five or six monsters that just move up or down, either all in a line, or maybe out of sequence with each other (start some of them at the top of the screen, others at the bottom, and so on). The challenge here is simply to cross the room… Are there any particular configurations of monsters that make this especially difficult to achieve? To what extent does increasing the speed of the monsters make it a more or less difficult task to cross the room?

Finding your way through a maze is a simple form of puzzle. In the previous post (”A Two Room Maze Game“) we looked at adding extra rooms to a maze game to provide a variety of different challenges to the player. In this post, we shall see how the introduction of an element of danger – in the form of “monsters” that can kill your player character – can spice up your game.

To begin with, we shall create a monster that just moves horizontally, from side to side, so that it can patrol a particular area of the the maze.

Create a new sprite – spr_horMonster for example – and load it with an appropriate image. Use this sprite with a new object – obj_horMonster, for example.

Configure the object as follows:

• Add a Create event to the monster object that triggers a Move action, choosing either left or right directions (or both!) and setting the speed slightly faster than that of the player character.

  

• Add a Collision event to the monster object that will cause the monster to bounce when it collides with a wall object.

  

• When the player bumps into the monster, the player character should scream out loud, the game will display a message, and the game should come to an end.
  
• For the scream, create a new sound, name it appropriately, and load in an appropriate sound file. In the player object, add an event that detects a collision with the monster object. For the first action, play the scream. The second action should display a message – such as “The monster caught you!”.
  
• Finally, add the End Game action to stop the game.

Place one or more monsters in the room and try out your game.

Is it a little bit more exciting now? More challenging, maybe? If necessary, modify the layout of walls within the room to provide runs for your monsters.

Experiment with the placement and speed of the monster(s) and see how it affects the difficulty of the game and your enjoyment of it. Do any particular configurations work particularly well? If you have a blog, why not take a screenshot or two to show the initial set up, and post them to your blog explaining why the configuration is effective.

[I use Jing to capture the screenshots used in this blog - Jing]

Different monsters

Duplicate the monster object and modify it so that it implements a monster type that moves vertically instead of horizontally (so you could maybe call this monster object obj_verMonster. (You will need to modify the start action so the monster starts to move in a vertical, rather than horizontal direction.)

Add one or more of these monsters to your room and try out the game now. How do you need to modify the player object so that the vertically moving monsters (as well as the horizontally moving monsters) are capable of “attacking” the player character? Are there any particular ways of placing the wall objects and monsters to provide challenging situations for your player character to negotiate?

In Moving on With Game Maker – A Maze Game, we looked at a couple of ways of how to get a player character to move under keyboard control.

Now it’s time to actually put a maze game together.

Defining Your Maze

If you played (or watched) the Pacman game, you’ll be familiar with the sort of maze I’m thinking of when I talk of a maze game – a walled area, populated by treasure and monsters; the player character has to get to get the chequered flag, avoiding the monstaers and collecting as much treasure as possible.

We’ll also cover how to improve the aesthetics of the maze, to produce something like this, for example:

(The study of maze and labyrinth design is actually quite involved. For an introduction, see An Introduction to the Typology of Labyrinths and Mazes (5 points for the first person to comment about what distinguishes a maze from a labyrinth;-))

With the room selected, add wall blocks to the room to create your maze. Place an instance of the player object at a start position within the maze and a goal object at the required end point within the maze.

In some games, there is the convention of leaving gaps in the the wall of the maze that correspond to that start and goal squares (that is, the entry to, and exit from points of the maze). We shall see later how a door can be added to the exit that bars further progress until it has been opened by completing a particular task.

Play the game. with the movement style and player speed you have selected, how easy is it to navigaet through the maze and get to the goal?

If you find you can’t get the player character to line up with the grid and get through narrow gaps in the wall, or it keeps getting stuck against the ends of the walls, add a Check Grid Alignment action to the player object before changing direction.

Adding a second room

It is possible to add a large number of rooms to your game and move from one to the next as you complete the challenge offered by each room. To create a second room for your maze game, simply select the Create Room option for a second time from the Game Maker Resources menu. Draw a maze using wall objects, and add the player object where you want it to enter the room, and a goal object where you want the player to leave the room.

One of the simplest ways of implementing the move from one room to another is to specify a particular goal within the first room, such that when the player character reaches it (that is, collides with it), the action moves to the next room.

In the goal object, inspect the collision event that tests for a collision with the player character. In the Main1 actions tab, you should see a set of actions relating to Rooms. Select the Check Next action.

This is a particular sort of action known as a conditional action. The action will test the state of the game world (in this case, to see if there is another room after the current room) and if the test succeeds then the next action will be executed. If the conditional test fails (there are no further rooms, for example, as may be the case when play is in the final room) then the next but one action (if any) will be executed next.

Configure the goal so that if there is another room the player moves to it, otherwise, end the game.

Add an instance of the goal object to the first room. When the player reaches the goal, play should move on to the next room.

Play the game – when you complete the first room, does the the player move to the second room? Does the game end when the goal in the second room is reached?

Without changing any of the objects, you can add as many rooms as you like, each describing a different maze (remember to add the player character where you want it to enter the room and the goal object at the exit). You can reorder the rooms by dragging and dropping them to rearrange them within the Rooms folder in the Game Maker sidebar.

Can you make one room more difficult than another, just by the way the walls are positioned?

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…