Digital Worlds - Interactive Media and Game Design

It’s all very well having monsters in a game, providing one of the arbitrary challenges we use to impede the progress of a player character through a game, but sometimes we just want to to retaliate and, in short, just “take them out”.

Killing monsters in games can be achieved by a variety of means - hand-to-hand combat, fireballs, big guns, and so on, but a natural monster killing mechanic for a platform game is to jump on it.

In One, Two, Three, JUMP! we looked at how to make a character jump - now we need to modify the action so that if we jump in such a way that we land on a monster, we kill it… After that, we’ll look at how to shoot a monster from a distance…

Squishing Monsters

We will add the monster killing ability as a series of actions associated with the player character. The even we need to detect is the “collision with monster” event. If the the collision happens whilst the player character is traveling in a sideways direction, the player character loses a life. If the player character collides with the monster by landing on it from above, the monster dies.

Add a new collision event to the player character object that detects a collision with a monster. We now need to detect from which direction the player character collided with the monster.

We do this by testing to see whether the expression vspeed > 0 && y < other.y+8 is true. So what does this expression mean? If vspeed > 0 then we know that the vertical speed of the player character is greater than zero - that is, the player character is moving in the positive y direction - downwards, in other words (remember, the origin x=0, y=0 is in the top left of the room, with positive x to the right, and positive y pointing down.).

The && means ‘logical AND’. That is, both the first part of the expression (vspeed > 0) and the second part of the expression (y < other.y+8) must BOTH be true, at the same time for the whole expression to be true.

So what does y < other.y+8 mean? other corresponds to the other object instance in the collision - that is, a monster. The expression tests that current position of the player character is above the bottom of the monster character. Since we know the player character has collided with the monster, and the other half of the expression (vspeed > 0) is checking that the player character is moving downwards, this means essentially that the player character must have fallen onto the monster character. So it must die…

If the expression has not evaluated true, then the player character collided with the monster from the side, so the player should suffer some penalty, such as going back to the start of the room.

That, in a nutshell, is how to kill the monster by squishing it!

You might of course want to have a rather more elaborate series of actions to manage the death of a monster or the player character. In the official Game Maker platform game tutorial, example game 3 uses the following sequence of actions.

The Start of a block and End of a block statements group sets of action that are to be executed if the condition evaluates true or false. The comment action (the exclamation mark) is just there for our benefit - comments are ignored by Game Maker and are simply used to act as inline documentation for a game programme.

You might also notice that rather than killing the monster immediately, the monster is turned into a ‘dead monster’ object.

On its creation, the dead monster object sets an alarm that raises an alarm event after a short period of time. When the alarm goes off, the Self object is destroyed.

Shooting Monsters

Another popular way of killing monsters is to shoot them. At its simplest, all we need to do is respond to a ’shoot event’ (typically raised by pressing the spacebar on the keyboard) and create a fast moving bullet or missile object. If the bullet or missile hits the monster, the monster dies and the bullet is destroyed. Similarly, if the bullet hits a wall it is destroyed.

Create a new object (obj_bullet) depicted by an appropriate sprite (spr_bullet).

When a bullet is fired, the first thing we need to do is work out which direction to fire it. One way would be to detect the direction the player character is moving. Alternatively, if we are using different sprite images that show the player character looking to the left or to the right, we can detect which sprite is being used and determine the direction from that.

To see which sprite image is currently displayed for the player character, we must write a logical expression to check one of two different variables. If multiple sprites are being used to display the character (e.g. spr_playerLeft and spr_playerRight, as in the official Game Maker platfrom tutorial) we need to check the variable sprite_index; if we are using a single sprite with several subimages, we need to check the variable image_index.

The VAR block (with shaped corners) is another condition testing block. If the condition is true, then the next instruction (or block of instructions) is executed.

So, having detected which way the player character is looking, we create an object that moves in that direction.

We also need an similar action to handle a character facing in the other direction.

If you try to play the game now, you should find that the player character fires bullets in the direction it is facing if you press the space bar.

As it stands, though, the bullet objects don’t actually do anything. At the very least, we want them to be able to kill the monsters…

The first Destroy object action should destroy the “Other” object (that is, the monster), the second action destroys the bullet.

Modify your game so that your player character can shoot the monster, and test it in a simple room. Does it work? Experiment with the speed of the bullet object. What happens if you set it too fast or too slow compared to the speed of the player character and the monster? What happens if there are no monsters in the direction you are firing? Add another collision event to the bullet object that destroys the bullet if it collides with a wall object.

You now have several interesting ingredients that you can add to your platform game (and also reuse in your maze game). Add a few rooms to one or other of the platform or maze games that make use of marked out monster patrol areas or the ability of the player character to kill monsters by jumping on them or firing bullets at them.

By adding the ability to kill monsters by shooting at them “from a distance”, how does this affect the way you can place monsters in a room compared to the case where the monsters are untouchable?

If you had a go at using Game Maker to build the maze game, you may remember monsters were able to kill the player character, but the player character couldn’t retaliate against the monster.

To provide some balance to the game, many games allow the player character to be able to kill the monsters. In the original version of the Pacman maze game, eating a particular piece of ‘fruit’ allowed the Pacman character a period of grace during which it could catch a monster and send it back to the jail in the centre of the room for a short period of time. In a platform game, one common mechanic for attacking a monster is to jump on it…

Making Monsters Look Beautiful

Let’s start by making a monster object. In the simple case, let’s just define a monster type that can patrol a fixed portion of a platform. The monster will wander back and forth along part of the platform, looking in the direction it is traveling in. If it collides with the player character at platform level, the player character loses a life and goes back to the start of the room. However, if the player character can jump so that it lands on top of the monster, the monster will be killed.

How might you define the object and its associated sprite so that the monster can walk from left to right and right to left, looking in the direction it is travelling, and reversing its direction if it collides with a solid wall object?

In the maze game tutorial resources folder, there are three images that show the monster - monsterl, monsterr and monster_flat (for when it has been squished!).

Can you think of a more compact way of packaging the sprite images used to display the monster?

Remember that several ’subimages’ can be combined in a single image loaded in as a tile set. With the different aspects of the monster contained in several separate image files, you will need to load the separate images into a single sprite. Create a new sprite (spr_monster, for example) and click on Edit Sprite.

Using either the ‘Add a sprite from file’ toolbar button, the “Add from File…” option from the file menu, or the keyboard shortcut ctrl-A, add at least the first two monster images into the sprite.

If you only had the left (or right) facing monster, how might you obtain a right (or left) facing monster?

If you are happy for the left and right facing monsters to be exact mirror images of each other, you could simply load in two right facing monsters (for example), then open one of them into the Image editor, select the whole image (ctrl-A usually does the trick, or Select All from the Edit menu) and then Mirror horizontal from the Transform menu.

Moving Monsters

In the post Improving the Visual Design of a Game - Better Sprite Design, I described how to use the Change Sprite action to select a different subimage from a sprite depending on which direction the the player character was moving, as determined by which arrow key was being pressed to control the character’s actions.

We shall use a similar action here to select the relevant sprite image for the monster, depending on which direction it is traveling in.

But first we need to start the monster moving…

We then need to choose the appropriate sprite based on the direction the monster is traveling. To do this, we are going to use a variable that is defined for each object instance within Game Maker that has a value corresponding to the direction the instance is traveling. the direction is specified in degrees, with 0 point to the right, 90 straight up, 270 straight down and so on.

When the monster is traveling to the left (direction will be set to 180), we want to choose subimage 0 of out sprite. When it is moving to the right (direction equals 0), we want to choose subimage 1.

Calculate the value of the expression (180-direction)/180 for a monster when it is traveling: a) to the left; b) to the right. Will the correct sprite image be shown for each direction the monster travels in?

The speed of the sprite is set to 0 so that the sprite does not rotate through each of the subimages contained within it by itself.

Create a simple room with an instance or two of the monster in it and move the room so that it is the first room in the room list. (You can reorder rooms by clicking on them and dragging them to the position in the list you want them to appear. The game will start using the first room in the list.)

Does the sprite image point the correct way? Stop the game, change the original direction of the monster and run it again. Does the sprite point the other direction?

Monsters on Patrol

As it stands, the monsters will move horizontally in the direction it started forever. To make matters a little more realistic, we could define them so that they change direction when they collide with a wall object. But how might we get the monsters to just patrol a limited section of a platform?

Knowing what you already know, can you think of a way you might use a new object to limit the patrol area of a monster in a similar way to the way the wall object currently impedes the monster, but without affecting the player character?

The trick is to create an invisible marker block that causes the monster to reverse direction if ever a monster collides with the marker, whilst not affecting the player character. By placing invisible marker blocks at each end of a platform, we can make sure that the monsters never fall off the platform, or walk over the edge of one. By placing invisible markers at certain points on the floor (base platform), we can limit a monster’s patrol area to a particular part of the ground floor platform.

Create a new object with a basic sprite (so we can see where it is in a room) but do not make it Visible or Solid.

In the monster object, add a collision event that checks for a collision with a marker, and performs a Reverse horizontal direction action in the event of such a collision.

Run the test room. Does the sprite face in the correct direction after the collision?

If subimage 0 is left facing, and the monster starts off moving from left to right (direction 0), then setting the sprite image initially to (180-direction)/180 will set the sprite subimage to (180-0)/180 = 180/180 = 1. When the monster collides, and the direction is reversed (for example to moving left - that is, in direction “180″), the subimage will be set to (180-180)/180 = 0/180 = 0, that is, left facing.

Design one ot two new rooms for your platform game that incorporate monsters that patrol some of the platforms, or different parts of the same, long platform. Test your game - do the monsters patrol just the areas you intended them to? The intention at the moment is just for you to gain familiarity in how to add patrol areas to the game, using the invisible marker blocks. If you feel you need to add a little jeopardy to the game, see if you can find a way of sending the character back to the start of the room if it collides with a monster.

You can use a similar technique to mark out patrol areas for monsters in a maze game. If you have a few minutes spare, why not add a new room to your maze game that incorporates such a feature? Can you also think how you might be able to use a similar technique to mark out an area of the maze game so that the monster patrols a square path? Why would such a path be likely to “make sense” in a maze game, but not in a platform game?

Having introduced the idea of a platform game, your mission, should you care to accept it, is to build a platform game of your own, on your own, using the Game Maker Platform game tutorial, as well as any other resources you happen to find, to guide you…

If you don’t fancy the idea of that, I’ll carry on developing the platform game here in the Digital Worlds uncourse blog, at a slightly gentler pace. I’ll also show how to use some of the new techniques in the context of the maze game world.

So - if the DIY platform game adventure is for you, read on… feel free to blog your progress and link your posts back here, or even set up a page for your game in the Digital Worlds wiki. If not, get a yourself a cup of tea, write down some requirements about how you’d like some monsters to behave in your platform game world, and stay posted…

For those of you who’ve opted for the solo mission, visit the YoYo games website, and download the Platform Game Tutorial (if you haven’t already done so) and use it to guide your exploration of how to develop a simple, arcade style 2D platform game.

We’ve already looked at how to create a simple platform world for your player character to explore, but the Game Maker tutorial goes into more detail. If you work through it, you will learn how to:

• introduce monsters into the game: you already know the basics, but here you’ll find how to ’squish’ monsters by jumping on them, and how to use invisible markers to limit the territory the monsters patrol;
• make the platform look pretty: the tutorial includes a tileset in the Resources folder that is ideal for creating a stylish looking platform game;
• construct - and explore - huge rooms: our games to date have shown the whole extent of a room within the screen view. It is possible to spread a room over several screens however, through the use of views. At any particular time, the player character is kept in focus and a view of a small part of the room around the character is presented. This technique requires the player character to explore several screens worth of room - not all of which can be seen at once - in order to negotiate the level;
• introduce ramps and ladders: as well as jumping to get between levels, it’s sometimes nicer to walk - or climb. The tutorial describes how configure the player character to walk up a ramp, thought you’ll have to do a bit of thinking yourself (or peek at the tutorial programme code!) to work out how to create a ladder with the correct properties!

Feel free to work through the above tutorial as quickly, and as in as much depth, as you like.

If you would like to explore the construction of platform games in a slightly more theoretical, formal academic sense, try working through the Game Maker platform game lecture notes from the UCSC Foundations of Interactive Game Design course: Creating a Platformer using Game Maker (collision detection, undesirable collision detection cases, creating simple state machines, jumping mechanic) [(PDF) (iPaper)], Creating a Platformer using Game Maker, Part 2 (advanced collision detection, all-in-one collision handler for platformers, jumping onto a moving platform) [ (PDF) (iPaper)]. Audio versions of the lectures are also available from the actual course site.

Remember, if you don’t fancy the idea of working through the YoYo Games Game Maker tutorial at your own hectic rate, I’ll carry on at a gentler pace, over the next week or two, here in the Digital Worlds uncourse blog…

As well as fixed platforms that are somehow suspended in the game world sky, and player characters that are subject to gravity (and are hence capable off falling of the edge of a suspended platform!), another defining characteristic of many arcade style platform games is the ability of a player character to jump.

Jumping is a core mechanic of many platform games, because it provides an easily understood way of helping a player character get from one platform level onto a higher one.

Before we look at jumping, however, let’s revisit how we go about making our player character move… To give it somewhere to explore, create a simple, platform filled room using instances of a solid, visible wall/platform object, configured with an appropriate sprite, but no event handlers. Also create a player object and give it a sensible sprite.

Moving the player character from side to side…

In a platform game, the player character typically moves only when an appropriate key is pressed - otherwise, it can be difficult to stop close to the edge of a particular platform.

One way of achieving this mechanic is to configure the player object so that it reacts to the keyboard arrow controls in the following way. When the appropriate keyboard event is raised, check to see if there is anything in the blocking the sprite’s movement in the desired direction:

Remember, the Game Maker co-ordinate system is defined with absolute co-ordinates (x, y) set to (0,0) in the top-left hand corner of the screen, increasing x from left to right, and increasing y from top to bottom. So to check the player character can move to the left, we need to check there’s nothing at the x coordinate location several pixels to the left of the character’s current position (that is, a negative x direction). Ticking the Relative box ensures that we are ticking 4 pixels to the left of the actual location of the player character, rather than the location at x=4.

If the path is clear, we want to move the sprite in the appropriate direction - use the Jump to Position action to achieve this:

For the right arrow, the x value should be set to 4 in each case (that is, a positive x-direction, i.e. to the right). To get a less jerky movement, you might check closer distances/use a smaller jump distance in the arrow key actions.

Try your game out just to check that the player moves correctly in response to your keyboard commands.

In the official Game Maker platform game tutorial, it is suggested that gravity should only be “switched on” when an object is in mid-air - that is, when it unsupported by a solid platform block.

To test whether or not there is anything below an instance of an object, we will use a Step event to repeatedly check whether there is anything immediately below the player character sprite:

If the player character is in mid-air, turn gravity on:

(The direction - 270 - is 270 degrees, measured in anti-clockwise direction from an origin of 0 degrees that points to the right. So 90 is straight up, and 180 is directed to the left…)

Otherwise, turn gravity off, by setting it to 0.

As the setup currently stands, there is no reason for the player character to stop moving through any platforms beneath it once it starts to fall. To stop the player falling through a platform, we need to set its vertical speed to zero when it collides with a platform block.

…then JUMP

When we press the up arrow key, we want the player character to jump up. Can you work out how we might achieve this?

First of all, we need to ensure that the player is stood on something, so that they can generate the necessary force to lift itself off the ground… (physics again! Remember that ‘equal and opposite force’ law…?!). Check that there is something immediately below the layer sprite:

That is, we check that the there is NOT an empty space immediately below the player character (that is, at a y co-ordinate +1 relative to the current location of the bottom edge of the player character).

If the player character is a underneath a platform when it jumps, what happens? Can you explain why? Can you also explain why, when the player character jumps, it does not keep floatng up the room?

Experiment with various settings for the gravity in the room, the speed with which the player character jumps upwards, and the height and spacing between platforms). Can your player make it onto every platform? Try building a tall, vertical wall in the middle of the room and place platforms in such a way that the player character must bounce from one platform to the next to get over the dividing wall, and so cross the room.

Many games utilise a common sense notion of gravity as part of the overall game mechanics. In Line Rider, the sledge rides the line under the force of gravity, for example; in Launchball, the ball is affected by gravity; and in the Newtoon physics game, gravity (as well as electrostatic forces) can be modeled within the game.

The Phun 2D physics sandbox also provides an environment for creating animations that explore a gravity filled, abstract digital word:

(Unfortunately, phun isn’t released for Macs…. yet…)

At the simplest level, the effect of gravity can be seen in games where things ‘drop’ from higher up in a room to the ‘floor’, and maybe bounce around a little when they land. The speed (or more correctly, velocity) of the item increases as it drops - that is, it accelerates due to the force of gravity. If the item bounces when it hits the ground, the height it bounces up to is related to the height from which it was dropped in the first place - another consequence of the “physical laws” implemented by the game (in this case, a consideration of the kinetic energy of the object as it hits the ground, and the angle at which it does so).

So far, so basic physics…

I bet you always wondered what physics was good for, didn’t you? Well this is it - creating games and game engines! If you would like to learn more about the details, such as how gravity works “in the real world”, and how gravity can be modeled mathematically (so that it can be implemented by a game’s physics engine, for example), try working through the OpenLearn unit Motion under gravity, or the more mathematical Describing motion along a line.

So - how do we add gravity to a Game Maker game? Very easily, in fact.

Create a new game, add a couple of sprites (such as the clown or a simple monster sprite, and a wall sprite), a couple of objects and an empty room.

Configure one object as a wall object (no events or actions required - just a solid object), and add a wall along at least the bottom edge of the room:

Turning now to the ‘dropping object’, configure it with a Create Event that is handled by a Set Gravity action. When you start running the ‘game’, you may wish to experiment with the gravity settings to see what happens… If there’s anything you don’t understand, raise it in a comment…

When the dropping object collides with the floor/wall object, we need it to do two things: firstly, we need it to bounce:

Secondly, we need to model the change in velocity, and in particular lose energy. If the collision was elastic, then no energy would be lost during the collision and the object would bounce back to its original height. In an inelastic collision, however, energy is lost from the dropped object, and it will bounces to a lower height with each bounce.

Place several instances of the dropping object in the room at different heights above the solid floor, and run the game. Does each instance bounce to a different height?

One of the popular exercises in basic animation is to animate a bouncing ball. In Game Maker, the internal ‘physics engine’ handles most of the animation work for us. To make the ball look more realistic, it is often set spinning. See if you can design, or find, a multi-image sprite to simulate a spinning ball.

Experiment with various gravity settings in the initial object creation event. What does the direction setting determine (and how do you know which direction gravity is acting in?) Also experiment with the vert speed setting in the collision action. How significant is that setting in terms of the mechanics of the bounce ‘feeling right’?

Create a room that contains a series of platforms, made out of wall objects. The player character should enter the room at the top!

Configure the player character object so that is can be controlled using the left and right arrow keys. If the player character walks off the edge of wall platform, it should fall under gravity until it lands on a wall object underneath. (In the player object defined below, I have inherited the gravity behaviour form a parent object.)

To add an element of risk to the game, add one or more instances of a poison object to the room that will kill the player and send it back to the start. Experiment with adding one or two more instances of the dropped/player object to the room, all of which will be controlled by the same keyboard commands. The aim of the game now is to get all of the characters out of the room without killing any of them…

Alternatively, you may wish to add some treasure to the room (in which case you’ll also need to keep track of your score!). To add a little bit more tension to the game, how about creating a key object that must be collected from one of the platforms halfway up the room that will unlock a door leading out of the room on the ground floor platform?

What “issues” does your game have in terms of its playabilty? Do the objects bounce appropriately if they hit the wall at an angle? If the door out of the room is not on the lowest platform level, is there any way for that player character to get out of the room?

Hopefully, hopefully, I’ll start looking at the basic design and development issues behind another ‘classic’ arcade game design pattern - platform games - in the next few days…

As with the Catch a Clown and Maze games, I’ll go through how to construct a game of that type in Game Maker, though if you are following along I hope you’ll feel confident enough to use my notes as a starting point for your own creative exploration of that game genre…

In preparation, I thought it might be an idea to flag up some background material to the classic arcade style platform games, and maybe even encourage you to start putting together a concept document for your own platform game. (The game I’ll describe will have a simple linear structure, but you might link to consider how the platform game could work using other narrative structures… ;-)

What is a Platform Game?

The ‘official’ Game Maker platform game tutorial describes a platform game as follows:

Platform games are very common, in particular on handheld devices. In a platform game you look at the scene from the side. The player normally controls a character that walks around in the world. This world consists of platforms. The player can walk on these platforms, jump or drop from one platform to the other, use ladders or ropes to get to different places, etc. On the platforms there are objects to collect, enemies to avoid or kill (often either by shooting them or by jumping on top of them), switches that can be pressed to open passages, etc. Also the player normally requires skill to jump over dangerous areas. In some platform games you see the whole level at once, but in most you see only a part around the character. In such a case, finding your way around becomes an additional challenge.

A reasonable introduction to platform games can be found here: Platform Game (Wikipedia). (Feel free to use that article as the starting point for a timeline history of platform games… if you do so, please make sure to post a link here if you do so…;-)

The Youtube user retrogamevideos has a wide selection of video examples of classic ‘retro’ arcade games; it’s well worth visiting as an ideas bank for your first Game Maker game in any particular genre (though you would be well advised to turn the sound down on many of the games!).

To get an idea of the mechanics of the classic arcade platform games, here’s part of a run through of one of the first games I remember playing- Jet Set Willy, on the ZX Spectrum, released almost twenty five years ago:

As you watch the movie, note how the opening screens are organised, watch closely for how the rooms are designed and how the player character moves (and how it is visually represented), and listen (if you can bear it!) to see how the sound is designed for the game. Having seen that clip, try to sketch out a simple game concept document for that game, that describes the platform game you’d like to develop (keep it manageable!).

The Game Concept Document

The first stop in the development lifecycle of a computer game is likely to take an original idea for a game and work it up it into a concept proposal that describes in general detail what the game is about. The concept proposal is the document that sells the game idea to a whoever is going to pay for it to be developed into a real game…

The concept proposal should have enough information in it to excite the reader, with enough detail to suggest how the game can actually be realised, without going into too much design or development detail.

The gamasutra article “The Anatomy of a Design Document, Part 1: Documentation Guidelines for the Game Concept and Proposal” by Tim Ryan suggests in the section Guidleines for the Game Concept that the game concept document should include the following:

* Introduction
* Background (optional)
* Description
* Key features
* Genre
* Platform(s)
* Concept art (optional)

Read Guidleines for the Game Concept and create a concept document for a platform game you are familiar with (or failing that, for a game for which you have watched a walkthrough video).

Start to think about the overall concept for a platform game of your own. As we work through how to build a platform game in Game Maker, you will be able to refine this document and use it as a guide for the development of your own unique platform game (hopefully!).

Feel free to join the Digital Worlds wiki on wetpaint, and add page there for your own game concept documents.

I have added a draft Game Concept Document template to the wiki; if you add a new page and select the Game Concept Document template, the page will be prepopulated with several headings that you might find useful for structuring your own concept documents.

(If you would like to take issue with any parts of the template document/suggest changes to it, please post a comment here…)

If you are itching to get ahead with Game Maker, you might like to start thinking about what ’s actually likely to be involved in a technical sense in creating your own platform game… Alternatively, you might like to explore further how to keep the player engaged in a platform game, by considering the management of Difficulty in Dexterity-Based Platform Games, for example…

With the two Game Maker games we have created so far (Catch a Clown and our Maze Game) we have gone straight into the game from a standing start, and come straight out of the game at the end.

How much more professional would it feel if we had a proper start screen and a final closing screen to top and tail our game?

Spend a minute or two thinking how you might go about adding these screens to your game(s). Write down two or three bullet points each about what you want to appear on each screen and what interactions each screen should support. If you think you can see how to add these screens to you game, fire up Game Maker and see if if you’re right…

Here’s the approach I came up with…

The title and game over screens can each be represented by a separate room, possibly containing a background image, with the title/game over words either appearing as part of a background layer, or as an object containing a large sprite. Ideally, there should be a button to start the game on the start page, and buttons on the game over page to either replay the game or quit.

So let’s try it…

To begin with, I want to create my start screen. One quick way of generating a start screen it to use a photograph. To add a start screen to my Catch a Clown game, I searched on flickr, the photo sharing site, for a clown photo, using the advanced search options to find photos that were licensed with a Creative Commons license (so I am free to use them) and allowed “derivative works’ (so that I can change them - by adding words over the top, for example)).

Having selected an image, I downloaded the large sized version of it to my computer, and then loaded it into Game maker as a new background.

If you open the background file in Game Maker, you can open the background image into an image editor and add some text to it (click on the TT button in the palette on the left hand side; set the font size from the text menu; set the font colour from the palette on the right. If you go wrong, ctrl-z should undo the last action!).

Create a new room (rm_titles, maybe, or rm_start?) and add the background to it. Move the room to the top of the room list so that it is the first room in the game and the one that will be displayed when the game is started.

To start the game, we just want the player to press any key on the keyboard (or maybe click the mouse). Create a new controller object (no sprite required) and configure it so that when any keyboard key is pressed, the game moves on to the next room. (You may also want to handle a key click event with a similar action.)

If you run the game, you should now find that you have a title screen at the start of your game.

See if you can work out how to add some title music to your game that plays whilst the Title screen is displayed. How might you modify the start controller so that the game starts if the player presses the ’s’ key, and displays the game information if they press the ‘h’ or ‘i’ keys? (To help the player out, you would need to change the instruction text on the start screen too, maybe to something like “Press ‘H’ for help, ‘S’ to start”!)

Adding a ‘Game Over’ Screen

Turning now to the maze game, my game currently just fizzles out when I get to the final room. In the Catch a Clown series, we looked at how to display a High Socre table (Who’s Best? Keeping Track of High Scores), which is something that might be good to add to the end of the maze game.

But for now, I just want to add a screen with two buttons on it - one to restart the game, and one to quit. Again, I could add a photo background to the game over room, but I won’t for now, preferring instead just to have a simple coloured background. make sure the room is the last room in the game.

What I do want, though, are a couple of buttons to press (rather than particular key presses) to restart or quick the game.

One easy way of generating the buttons - which are going to be sprite images associated with relatively simple objects that spot when the button instances are clicked on (i.e. “pressed”) - is to use an online button generator, such as buttonator.

Create your button, right-click on it to download it, and save it as a bitmap (.bmp type) image. It then then be loaded into Game maker as a sprite image.

Create two sprites and two objects (one to quit and one to restart, in each case) and add them to the room.

Can you work out what actions to add to the button objects? (How did you configure the clown object so that the programme recognised when a clown instance was clicked on?) Try it and see….

If you have not already done so, add a left button/end game event/action pair to the quit object, and a left button/restart game event/action pair to the restart object.

If you’re feeling really adventurous, you might make two versions of each button - one for when it is unpressed, and one for when it is pressed. (If you do achieve this, feel free to post the method/howto back here as a comment or in a blog post of your own that links back here ;-) Both images should be the same size. If you load both images into the same sprite, you should be able to work out how to show the button being pressed by displaying the second sprite image when the mouse button is pressed (before performing the appropriate action when the mouse button is released, or when the click event is raised…)

So that’s it - you should now be able to add title and end game screens to your game and make them just that little bit more complete….

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.

Tilesets are single images 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 and repeatedly to create a much larger background image.

So for example, using this tileset:

we can easily create this sort of background image:

Tileset design can be a very rewarding, if time consuming, part of the whole game design process. Indeed, it’s almost a puzzle game in its own right, designing tiles so that they ‘plug in’ to each other, even if they are rotated…

To learn more about tileset design, this article from Gamasutra provides a good overview of the complexity involved in designing a tileset that can be used to create background terrain: Tiled Terrain.

For a slightly gentler introduction, try this tutorial on So You Want To Be A Pixel Artist?.

For how to create brickwork, check out Creating a Brickwork Effect; and for grass, here’s a tutorial on creating: The Grass Tile.

I’ll put together another springboard post about how to go about designing the “3D” like tiles when I’ve covered a little bit of the theory behind how it works (if you’re keen to know more now, searching for isometric pixel art should turn up something relevant!)

In the context of Game Maker, the Tileset Maker for Game Maker provides a basic environment for creating your own custom tilesets.

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.