VACUUM MARAUDERS

V2.0

© 2008 PAUL KNICKERBOCKER FOR LANE COMMUNITY COLLEGE

In this game we will expand on our V1.0 model to include different types of enemies, the

possibility of player demise/victory and score tracking.

This game will focus on:

• Controller Objects

• Score tracking

• Draw Event/Actions

• Inheritance

• Detecting victory conditions

1.THE CONTROLLER OBJECT

One of the most useful objects in any game is also the one never seen. Often called the

Controller object, this object acts as a grand conductor for the game constantly checking

conditions and setting up events. It is always present, never destroyed and invisible to the

player.

Despite all these magical properties, the Controller object is nothing more than an object

without a sprite. It is used to perform actions that apply to the game in general and not

necessarily to specific objects. It can provide shortcut keys that are useful in debugging and is

never purposely destroyed by the game.

To make a controller object all you need to do is create an object named “object_controller”

and not assign it a sprite:

You also want to make sure that Solid is turned off so that there is no chance of getting

caught up in a collision event.

Right now we’ll only add a useful debug sequence, making the <ESC> button quit the game.

Now this works already with simple games, but as the games get more complex this feature

needs to be explicitly added. Add a Key Press <ESC> event to the controller and add in the

End Game action ( , in the main2 tab). This will automatically end the game whenever

the <ESC> key is pressed.

In order to activate the controller it has to be placed in the room – so open up “room_main”

and place “object_controller” in the room (the upper left hand corner is a good place to put

the controller because it is easy to check whether or not it has already been placed in the

room). Objects without sprites will show up as circled question marks ( ) when placed in the

room.

From here we can test to make sure our controller is working properly by starting the game

and making sure <ESC> closes it out.

2.NEW ENEMIES

We will now introduce one of the biggest time savers and important concepts in Game Maker

and Object Oriented Programming in general: Inheritance.

If we lots of different enemies with a lot of the same behaviors, it is redundant to copy those

events and actions from one to the other just to use a different sprite or to change a small

detail about the enemy behavior. For Example: all enemies need the collision event for the

missiles, but if we just want to make a new enemy that moves in a different direction we

have to redo all that code. With Inheritance groups of similar objects can all share events and

actions!

Lets make a new object “object_enemy2” and give it a new enemy sprite from the 3 we

loaded in version 1. The only difference here is that we will set the Parent box with so

that it says “object_enemy”:

Now put a few of these new enemies into the room next to our old enemies:

Then start up the game and we see that the new enemies act EXACTLY like the old enemies.

This is because by setting “object_enemy” as the parent, the new enemy inherits all the

events and actions from its parent. So by setting the parent, we now have an enemy that

collides with missiles, moves and bounces off the edge just like “object_enemy”.

“object_enemy2” is now a child of “object_enemy”.

Now this is good for making duplicate enemies, but the real power of inheritance is that we

can change one aspect of the child object’s behavior but keep all the inherited events of the

parent. If we create a event in the child that is also present in the parent (like Create), Game

Maker will only use the child’s version of the event; this process is called Overriding and

allows us to make new objects that are just minor variations of other objects.

So open “object_enemy2” and make a new Create event, then insert a Move Fixed ( )

with Speed = 4 and the button facing down:

Because there is a Create event in both the “object_enemy2” and the parent

(“object_enemy”), Game Maker will ignore the parent’s Create and only run the actions

defined in “object_enemy2”s Create. As a result, instead of starting movement side to side,

the enemy will start out moving downward:

Let’s go ahead and make another enemy, “object_enemy3” with a new sprite that also uses

“object_enemy” as its parent:

Add a new Create event with its own Move Fixed action that has Speed = 4 and the

downward left and downward right arrows checked:

This will produce an enemy that bounces down the screen diagonally at the player. Put a few

of these new enemies in the room and you should have a variety of enemies coming at you:

OH NO!!! - Even though we can’t see it there is a problem. Now that we have enemies

leaving the screen we have to think about cleaning them up. Just like how we cleaned up the

missiles the player fires by having them delete themselves, we now have to have the enemies

clean themselves up.

Here is another great feature about inheritance – we don’t have to add new events and

actions to ALL the enemies, we just have to add it to “object_enemy”. Because all the other

enemies inherit whatever is in “object_enemy”, if we want to change all the enemies we just

have to add to the parent.

Open “object_enemy” and add a Outside Room event, then put in a Delete Instance ( )

action applied to self. This will make the enemy remove itself when it gets outside the room.

3. PLAYER DEATH

Up to now our player has been invincible, but not any longer. We want to add in a collision

between the enemies and the player that will destroy the player and restart the game.

One problem that arises is that we want to display an explosion when the player gets hit

THEN end the game. If we were to simply make a collision that created an explosion object

and then restarted the game, we would never see the animation because the game wouldn’t

know to wait until the animation was over, it would do it instantaneously. The easiest way to

ensure that the animation completes is to make sure that the restart game only happens at

the end of the animation. To accomplish this we will make a special explosion object.

Right click on “object_exp” in the resources browser and one of the options you have is to

“Duplicate”:

This will give you an exact copy of the object with a generic name, rename the new object

“object_exp_player” and you should have a self deleting animation like “object_exp”:

Now right before the Destroy Instance action, add a Restart Game action ( , found in

main2). Again, order is very important; if the object deletes itself before the game is

restarted, nothing will happen.

Now we have an explosion object that will restart the game when done, all we need now is to

add collision between the enemies and the player. This also demonstrates another great

feature of inheritance: we don’t have to check collision with all the enemies , just

“object_enemy” because collision is inherited too!

Open “object_player” and add a Collision event with “object_enemy”:

Because all the other enemies are “descended” from “object_enemy”, they will also trigger a

collision event as if they were “object_enemy” instances themselves. So this one collision can

handle the main enemy and all of its children.

Within the collision event add a Destroy Instance event ( ) applied to Other (destroy the

enemy) and a Change Instance ( , located in main1 tab) that changes into

“object_exp_player” with Perform Events = yes. Change Events has the same general effect

as a Create Instance action for one object and then a Destroy Instance applied to Self. It

also carries over some object settings which can be helpful, it is introduced here because it

makes for easier to read code.

We should now have a ship that will blow up whenever an enemy hits it.

4. KEEPING SCORE

One of the most important aspects of games is the score. Up to now we have not assigned

scores, but with Game Maker the process is fairly easy. When the game begins the score is

always set to 0, then through the use of Set Score actions ( , in the score tab) the score is

incremented or decremented.

We want to assign 100 points to the score whenever the player hits an enemy, so open to the

Collision event in “object_enemy” (remember, because of inheritance, all the changes we

make here will apply to all the enemies). Before the Create Instance action add in a Set

Score ( ) action with Score = 100 and Relative checked:

In this case the Relative box means that 100 will be added to the current score (i.e. score =

score + 100). To remove 100 points we would put Score = -100. If Relative was not checked

then every time an enemy was hit score would be reset to 100, which means the score would

not be cumulative.

This process alone will track the score but will also want to display it. To display the score we

will use the “object_controler” object, as it is a function related to the game as a whole and

not a specific object.

To draw directly of the screen we will use the event: which is the event

called whenever the screen needs to be updated (which may or may not be every step of the

game). In general, any drawing command should be handled in Draw.

Before we can write to the screen however, we need to load up a Font. This is done just like

sprites, backgrounds and sounds. Use the button to make a new font. Set the font name

to “font_score” then set Font type (Verdana is a good choice), Size = 12 and Bold box

checked. This will set up a font to be used later when we draw text directly to the screen:

To explain how we will draw to the screen let’s look at how Game Maker handles

ordinates. Game Maker uses a Cartesian coordinate system where there are 2 axis, X and Y,

and all the positions on the screen are defined in terms of how far on the X axis an

they are [usually abbreviated to the form (X,Y)]., as seen below:

http://en.wikipedia.org/wiki/File:Cartesian

Game maker uses a non-standard system where the Y axis values are flip

(0,0) [often called the origin] is at the top left hand corner of the screen. This means that

when we look at our screen we have a coordinate system that looks like this (background

removed for clarity):

To explain how we will draw to the screen let’s look at how Game Maker handles

ordinates. Game Maker uses a Cartesian coordinate system where there are 2 axis, X and Y,

and all the positions on the screen are defined in terms of how far on the X axis an

[usually abbreviated to the form (X,Y)]., as seen below:

From Wikipedia - Retrieved Dec 16th 2008

http://en.wikipedia.org/wiki/File:Cartesian-coordinate-system.svg

standard system where the Y axis values are flipped and the point

(0,0) [often called the origin] is at the top left hand corner of the screen. This means that

look at our screen we have a coordinate system that looks like this (background

To explain how we will draw to the screen let’s look at how Game Maker handles co-

ordinates. Game Maker uses a Cartesian coordinate system where there are 2 axis, X and Y,

and all the positions on the screen are defined in terms of how far on the X axis and Y axis

ped and the point

(0,0) [often called the origin] is at the top left hand corner of the screen. This means that

look at our screen we have a coordinate system that looks like this (background

We can see this is a little different than the normal setup but has some advantages when

working with coordinates. This fixed grid of co-ordinates is what we are dealing with when we

are dealing with coordinates and DO NOT have the Relative box checked. It is worth noting

that even when Relative is checked, the reverse of the Y axis from normal is still in effect.

We want to draw the score near the top of the screen and roughly halfway across. We’ll use

the point (200,30). The two actions we put in Draw will set up the environment for what we

(0,0)

(0,640) (480,640)

(480,0) +X -X

+Y

-Y

will actually write later. The first is the Set Color action ( , in the draw tab), in this you

simply use the selection box to choose a color. Choose a bright red. Then add a Set Font

action ( , in the draw tab) and select the font we made earlier, “font_score”. These two

actions have set up the color we will draw in and what font we will use when writing letters

(respectively).

Now we add the action that actually does the drawing: the Draw Score action ( , in score

tab). This action defines where to draw the score and what words will precede it. Put in X =

200 and Y = 30 with Relative off. Caption should be “Score:”

Because Relative is off it will write on location (200,30) as defined by the room’s coordinate

system (as opposed to the location of “object_controller” which the action is in). This will

automatically update with the score and give the end result that looks like:

There are quite a few Draw actions and they can be identified by the light yellow

background. Almost without exception these should only be used in the Draw event.

The last part of the score display and tracking that we need is a High Score tracking system.

Again, Game Maker provides us with a simple solution: open “object_exp_player” and enter in

a Show Highscore action ( , in score tab) right before the Restart Game action in the

Animation End event. This action pauses the game and provides a form to enter and track

high scores. There are lots of customizations this action will let you make to the look of the

Highscore table, but none of them change the basic functioning.

5.CHECKING PLAYER VICTORY

Our final addition to this version is a mechanism for checking to see if the player has won

(i.e. destroyed all the enemies). Because this is checking a game-wide condition and not the

condition of a single object, we will be doing the check in the controller object. In order to

check whether or not all the enemies are gone we will introduce two very important concepts

in game maker: Steps and Conditionals.

Each game, though it may seem seamless, is processed as a set of discrete Steps. Like a flip

book animation, a Step is a snapshot in time of the current state of the game. At each step

the game makes whatever changes are needed to create the next step. For example: at each

step the game has to move the image of all the enemies to their next location, process any

keyboard input from the user and check to see if any missiles have hit the enemies. We can

insert our own actions in at every step by using the event.

Conditionals are at the core of all advanced functionality in Game Maker and programming in

general. Conditionals are basically questions you can ask Game Maker so that you can make

decisions, they are easy to spot among the actions because they have an octagon shape like

(which is the Check Lives conditional). You use a conditional if you only want to do a

set of actions if the game is in a certain state; in our case we want to restart the game if

there are no enemies left in the room. The controller object usually contains a lot of

conditionals, as it is always checking for victory and defeat conditions.

To check to see if the player has won, we need to ask at each step: Are there no more

enemies on the screen? If that question is true we will want to restart the room. Open up

“object_controller” and add a Step event:

You will also have the option of Begin Step and End Step. These are sometimes useful for

complex games as they allow you to perform actions before and after Game Maker does all of

its standard step processing.

Inside of the step event add a Test Instance Count ( , in the control tab). This

conditional will count the number of instances of an object are active in the game; this is

good for checking if the enemies (or the player) have been destroyed. Make the Object =

“object_enemy” (again, because of inheritance this will check ALL enemies), Number = 0,

Operation = Equal to and the NOT box unchecked:

What this says is that the actions under this conditional will be run ONLY if the number of

“object_enemy” = 0. The NOT box will reverse the condition, in this case it would execute its

action as long as there were some enemies left.

After you place a conditional, ALWAYS add in the Start/End Block tags ( , in control tab)

under the conditional like so:

The block tags define the beginning and end of the actions that are executed if the

conditional is true. While it is possible to execute a single action under the conditional

without the blocks, it is a bad programming practice and leads to a lot of bugs. Remember:

Anything not inside the blocks is not connected to the conditional and will ALWAYS execute

when the event happens.

Now, insert a Restart Room action ( , in the main1 tab) in between the start and end

blocks:

We use Restart Room rather than Restart Game here because it does not reset the Score

counter, allowing the player’s score over several waves to be cumulative. You can give the

Reset Room a fancy transition but it is not necessary.

Test the game by destroying all the enemies and make sure the room resets.

FINISHING UP

Now we should have the following new features implemented:

• Multiple moving enemies that collide with the player

• A player destruction event

• Score counters, high score tables and score display on the screen

• A controller object that checks to see of the player has won