Archive for the 'Game Maker' Category

Scripting With the Game Maker Language

Although Game Maker’s visual environment provide a friendly interface to many users, some people (particularly experienced programmers) may find it more natural to construct programmes using the text based Game Maker Language (GML).

In this short series of posts, I’ll repeat some of the other Game Maker tutorials using GML. So if you’ve ever fancied trying your hand at writing actual programme code, why not give this a try…?:-) Note that this series assumes some familiarity with writing games the visual way in Game Maker.

To start with, I’m going to replicate the “Catch a Clown” game described the introductory Game Maker tutorial.

The approach I’ll take is to write a series of series of GML scripts that can be attached to events associated with game objects, Setting up the game objects and events needs to be done using the visual editor (at least until I can figure out how, or if, we can write scripts to set up objects and rooms directly!)

To use Game Maker Language scripts, you’ll need to run Game Maker in its Advanced mode (set it from the File menu). Scripts can then be created from the toolbar, or from contextual menu raised by right clicking on the scripts folder in the left hand sidebar palette.

To begin with, we’re going to recreate the a single room game, with wall elements round the edges, and a clown that bounces around inside the room. The aim of the game is to splat the clown by clicking on it.

As I’m teaching myself GML too, will start by learning how to attach scripted events to the game objects. TO start with, you’ll need to:

– create a room;
– create a wall object with a solid wall sprite;
– create a clown object with a transparent clown sprite;
– put wall objects round the edge of the room;
– pop a clown object somewhere in the middle of the room.

To get things moving, we’re going to create a script that will set an instance of the clown object moving when it is created with speed 4 in a random direction.

Create a new script from the toolbar or scripts resource folder; double click on the new script to raise the script editor. In the Name textbox in the status bar at the top of the script editor, give your script a name. For convenience, you might prfix it with scr_. I’m going to call my first script scr_moveAny.

When writing a script, there are certain syntactic conventions we need to be aware of. Firstly, programme code nees to be contained within curly braces: { }

Secondly, separate lines of code need to end with a semicolon – ;

So how do we go about writing a GML programme. GML has a wealth of predefined functions, which are all described in the Game Maker Help menu. But as novices, we donlt know what any of those functions are, or what they do. So let’s start to build up our knowledge somehow.

Before we get into the code, remember this: writing programming code is not what programming is about. Progrtamming is working out the things you need to tell the computer to do so that the programme does what you want. Writing the code is just that – taking the programme, an coding it in a particular way. You can write your programme – the list of things you want the computer to do – anywhere. I often doodle outlines for the programmes I want to write on scraps of paper. Having worked out the programme, we can then write the code.

So what programme are we going to write for starters? Well, when the clown object is created, we need it to start moving in a random direction with a specified speed.

Looking through the GML help file manual, in the Moving Around section, I noticed a function called motion_set(dir,speed) which Sets the motion with the given speed in direction dir.

Hmm… okay, so my programme code might look something like:


So if I attach this script to the clown’s Create event, it should start to move in direction dir with speed 4. But what’s dir? Digging around a little bit more, it’s a direction given in degrees. So to move randomly, I need to set dir to a random number between 0 and 359). I know a bit about other programming languages, so I guess there’s a probably a “random” function… and there is: random(N) which returns a random real number (i.e. it might have lots of bits after the decimal point) between 0 and N.

To get a whole number (known as an integer) we can put the random() function inside another function, called floor(M), which rounds the number, M, contained in the brackets down to the nearest whole number. That is, if we write:


the random(360) function will return a random number between 0 and 360 (such as 124.9734), and the floor function will round it down to the nearest whole number (in this example, 124).

Great – so we can get a direction angle for our motion_set() command. We could just replace the dir term in the motion_set function with the floor(random(360)) expression, or we could use a variable. A variable is like a container we can use to represent a (possibly changing) value. In GML, we need to declare a variable before we use it with as follows:

var dir;

var is a special reserved word that tells Game Maker the next word is the name of a variable, in the above case, dir. We can then set the dir variable to a numerical value:
var dir;

The whole script looks like this:

var dir;

You can check that the code is “correct” in a syntactical sense (i.e. you can check you’ve got the brackets and punctuation right, if not the logic) by clicking on the 1010 button (“check the script for syntax errors”).

If you save the script, we’re now in a poistion to attach it to the clown object. Open the clown object window, add a Create event, and from the control panel on the right hand side, add the “Execute script” action.

Select the clown object and add a Create event. It would be nice if we could configure Game Maker to easily allow us to attach a script to this element more directly, but in Game Maker 7 at least, we need to do this from the control tab on the right hand sidebar palette in the object editor window. The element we’ll be needing is the Execute Script code element:

Game Maker Exectute script element

Select your script from the list of named scripts that are available from the drop down listbox, and attach the desired script to the object itself:

Now play the game. Hopefully, you should see the clown start to move in a random direction at the required speed when the game is started.

So what’s next? If the clown bumps into a wall, we need it to bounce off. We might also want to play a sound as the clown does so. Create a new script, and call it something like scr_wallBounceSound. The function move_bounce_solid(adv) (“Bounces against solid instances, like the corresponding action. adv indicates whether to use advance bounce, that also takes slanted walls into account.”) looks handy. I’m not sure what adv is, but I’m guessing true or false…

Let’s try this:


Save the script, add a collision event to the clown object that detects a collisions with a wall object, and attach the scr_wallBounceSound script to it. Run the game – hopefully your clown will start to move in a random direction and then bounce off the walls…

Now lets add a sound. Searching for sound in the help file turns up dozens of sound related GML functions, but sound_play(index) looks relevant (“sound_play(index) Plays the indicates sound once. If the sound is background music the current background music is stopped.”). index is the number of the sound file, as ordered in the sounds folder in the resource sidebar, and starting with the index number zero. I have two sounds in ,my game, one for wall bounces, one for when the clown is clicked on, so I choose the approariate one. My script now looks like this:


And finally… In the simplest version of the original game, the idea was to click on the clown to catch it. Catching it has the effect of increasing the score, playing a sound, repositioning the clown to a different location, and setting it moving in a random direction again.

We know how to play the sound and get the character moving, so all we need to figure out is how to increase the score, and move the clown to a new location. In the GML help pages the section on “Score” tells us the name of the variable that is defined by the game to hold the current score: score.

To increase the score by 10, we can write one of two things. Either:
That is, set the new value of the score to equal the current value of the score, plus 10.

Or we can use the shorthand form: score+=10

To reposition the clown, the help file comes to our rescue again. In the Moving Around section, we find the function move_random(hsnap,vsnap) Moves the instance to a free random, snapped position, like the corresponding action. I think we can just set the hsnap and vsnap values to 0.

So here’s the script that we want to attach to the left-click mouse event on the clown object:


Okay, I think that’s enough for now… except to look at how we might save and load scripts. In the scripts menu is an option to Export a selected script. The export looks something like this:

#define scr_clickedClown

It might therefore seem reasonable to suppose we could edit a who range of scripts in a text editor outside of Game Maker and save them in a single text file. Something like this maybe?

#define scr_moveAny
var dir;

#define scr_wallBounceSound

#define scr_clickedClown

And it does indeed seem to work… as long as you save the file as a text file with the suffix .gml

Finally, finally, it’s just worth saying that if you want to leave notes to yourself in a GML programme that are ignored by Game Maker, you can do. They’re called “comments” and you prefix them like this:

// a comment in a programme that is
// ignored by Game Maker;

That is, use double slash… And how are comments typically used? A bit like this:

//script to handle the left-mouseclick event when a clown is clicked on
// this script should be attached to the clown object
#define scr_clickedClown
score+=10; // add 10 to the score
sound_play(1); //play the squished sound
move_random(0,0); //move the clown to a new location
motion_set(floor(random(360)),4); //move in a random direction at speed 4

That is, we can use the comments as programme code documentation…


Killing Monsters in Game Maker

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?

Monsters on Patrol

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?

Growing the Platform Game – You’re On Your Own, Now (If You Want to Be!)

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…

One, Two, Three, JUMP!

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.

Gravity Waves…

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?

Quick – Find Out About Some Platform Games…

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…

Adding Title Pages and Game Over Screens to Game Maker Games

With the Game Maker game(s) we have created so far (Catch a Clown and maybe 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.

May 2011 – Buttonator seems to have moved on… here are a couple of possible alternatives: Glassy Buttons, Cooltext. They seem to work in much the same was as Buttonator did…

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….

Finishing the Maze – Adding Background Music

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.

Springboard – Designing Tilesets

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.