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?