Home > SoulHow > SoulHow to actually do stuff with GML (Game Maker): Part 1

SoulHow to actually do stuff with GML (Game Maker): Part 1

June 7, 2008

NOTE: Comments are locked. I no longer answer questions about the Game Maker tutorials on this blog; I suggest you take any questions to the Game Maker Community. For more info, view the FAQ page.

Skill Level: Novice user (4)

Yet another SoulHow.  This time, instead of doing the cliche “introduce programming with some code that doesn’t really do anything useful” thing, I’m going to discuss some kinds of things that you can actually do using GML in Game Maker.

This is a follow-up article to SoulHow to code with GML; I won’t cover the basics again in this article, so if you don’t yet understand GML, I suggest you shimmy on down to that one. Also refer to that article if you happen to be reading this one and don’t understand something.

Well, well, well. You’ve finally figured out what a variable is, and scripts are not necessarily a foreign language any more.  But what good is making variables and showing them on the screen?  What kind of game just says, “UR VARIABLE IS 9!!!”

We’ve got to actually do something with GML!  In parts 1 and 2 of this tutorial, I’m going to cover a lot, but by using these techniques, your games are going to get a lot better. Just read carefully and it won’t be very difficult. In this guide, we’re going to make a game which has a cannon and a target. You must use the cannon to shoot the target.

I’m going to only cover the coding stuff, so I will say this all now: there is a little preparatory work necessary on your part before we can continue on this tutorial. So before going on, I need you to open a new file in Game Maker, and make three sprites. One, is a cannon pointing right, another, a bullet, and the third, a target. These sprites do not influence the tutorial in any way; they’re just to make it easier for you to understand what’s going on. Therefore, you can draw them however you want. Finally, center each sprite’s origin (click the “center” button on the sprite box) and close out of them. Now make three objects, name them objCannon, objBullet, and objTarget, and give them the corresponding sprites. Finally, make a new room, and put the cannon on the left side of the room, and the target on the right side of the room. Okay, preparatory work, done.

Now we can get down to business. Open up the cannon object. We’re going to start programming there. Don’t run away yet!

First, we want the cannon to move up and down when you press those buttons. Let’s start with down. Add a keyboard down arrow event. We could do this very easily with actions, but we’re taking the difficult path, so code it is. Add an “execute code” action (on the control tab), and inside the window place this code:


Hmm? What is this? Well let’s break it down.

If you recall from the SoulHow to code with GML article, the “+=” means we add the value on the right to the variable on the left. But what’s this “y” thing? We didn’t make that. And if you type it into GM, it even colors it blue.

Well y is what’s called a coordinate. There’s an x coordinate, too. Coordinates start at x=0, y=0, at the top left of the screen. As you increase the value of x, you move right, and as you increase the value of y, you move down. So position x=100, y=300, is 100 pixels right from the left side of the screen, and 300 pixels beneath the top of the screen.

Every object has its own pair of these coordinates. When you put an object in a room, it gets whatever coordinates correspond to where you put it. If you place it 50 pixels right of the left side of the room, and 200 pixels down from the top of the room, its coordinates are x=50, y=200. We can use these coordinates, stored in two variables (“x” and “y“), to move the object. By adding 4 to y, as we’ve done in the above code, we’re moving the object downwards, just like we want to happen when we press the down arrow.

Now, in the up arrow, we want to do the exact opposite. Since the opposite of + is -, it makes sense that we’d use this code in the keyboard up arrow event:


Now we’re subtracting from the y coordinate variable. Because the object moves down as the y variable gets higher, it follows that deducting from the y value will cause the object to move upwards. Run the game now and see that this is true (press up and down and watch the cannon move correctly).

Before closing the game, continue holding the up arrow key and watch what happens. The object goes right off the screen. We don’t want that, so let’s fix it.

Close out and go back into the up arrow key event. When we press the up arrow key, we want the cannon to move up unless we hit the top of the screen. So…if the object is lower than the top of the screen, move up. Otherwise, do nothing. Well lucky for you, there’s another part of GML that can help us out here. It’s called the if statement; and it lets us set up certain bits of code to only be read by GM when certain conditions are correct, or “true“. Let’s look at an example.

if (y>0) y-=4;

This looks like our old up arrow key code, but with an addition – the if statement. An if statement is made up of “if” and then what’s called an expression inside parenthesis. As you can see above, we have “if“, and that means that our expression must be “y>0″.  All the term “expression” refers to, is something that is either true or false.

Let’s read this line aloud. “If y is greater than 0, subtract 4 from y.” (“>” is read as “is greater than”). That expression, y>0, “returns” either true or false. If y was -10, and I said that y was greater than 0, would you tell me that what I just said was true, or false? False, because -10 is not greater than 0. And if y was equal to 5 and I said the same thing, you would tell me that what I said was true. When the expression “returns” true, GM reads the code just in front of it.

Recall that the coordinate y=0 is at the top of the screen.  Therefore, the above code only lets us deduct from y when the y value is already greater than 0 (that is, lower than the top of the screen), and that’s exactly what we wanted to do.

As a side note and to increase your knowledge of GML, I’d like to also mention that if you have more than one thing that you want GM to read after testing the expression in an if statement, you use curly braces. { and }. Just like you use the start of a block and end of a block actions when programming in drag&drop. For example,

if (a>5)

(when using curly braces, we usually indent the lines of code to show they are part of what’s called a “block”, which is basically just a set of code lines inside a { and } )

Now, when a is greater than 5 (which it is, if it’s set to 12), we enter the curly braces and do everything inside them. If we had set a to 2, the expression would return false and we would skip over past the closing curly brace (this one: “}” ) Now look what happens if we don’t use the curly braces in that example.

if (a>5)

a is set to 12, then we test if a is greater than 5. It is, so we move on. This time we don’t have curly braces, so GM doesn’t realize we actually want it to read the next two lines. It just thinks we want to read the next one line, so that’s what it does. If we set a to 2 this time, the expression would return false and the line immediately following the expression would be skipped, but the line after that one (“c=8”) will always be read, no matter what the expression returns. That’s because GM didn’t realize you wanted to group the last two lines together.

Okay, back on track. We want to do the same thing with moving downwards, but this time we have to check if we’ve hit the bottom of the screen. How high is the screen? Well we could always check in the room editor, but what if you decide to change the room’s height later? Then you’d have to go back in every piece of code in which you used the old room height, and change it to the new one. Instead, we’re going to use another variable that GM sets up for us just like it did with x and y. It’s called room_height. (Yes, there is also a room_width, but we don’t need to use it in this tutorial)

So open up the code inside the down arrow key event, and change it to this:

if (y<room_height) y+=4;

If y is less than the room height, add 4 to y.” That’s how GM reads it, and that’s how I read it too. Pretty straightforward; the only real difference from the up arrow key event code aside from the room_height is the “<“. < is just “smaller than” instead of “greater than”, because we want to check if the object’s y coordinate is smaller than (higher up than) the room’s height.

Great, now run the game again and hold up. Watch as the cannon moves up and finally stops dead just before going off the screen. Try it down and watch as the same thing happens at the bottom of the screen. Success!

Okay, now we have to make the cannon shoot. This is pretty easy, so I’ll just cover it quickly. Add a key press spacebar event (NOT a keyboard spacebar event; key press event means that the player will keep having to press the spacebar to shoot whereas keyboard event will let the player hold down the spacebar to constantly shoot a stream of bullets) in the cannon object. Put an execute code action in the event, and now we’re going to use the code equivalent of the ‘create an instance’ action. Most thrillingly, the function we use to do this is called “instance_create“. It needs you to give it three arguments: 1st, the x coordinate to create the object at; 2nd, the y coordinate; and 3rd, the object to create (you do remember about arguments from SoulHow to code with GML…right?). So in the code box, type the following:


As you can see, we use the x and y variables to tell GM to create an objBullet at the coordinates of the cannon. That’s all for this object, because we need the bullet to move. So close out of this object and open up objBullet. We want the bullet to start moving on creation, so add a create event and again place an execute code action. We’re going to use another built-in variable to get our bullet going. This is called hspeed. It stands for horizontal speed. When you put a number other than 0 into hspeed, the object starts moving with that speed to the right. If you put a negative number, it goes to the left. (just like x coordinates move right as they get bigger) Add this code to the bullet:


Now we have a horizontal speed of 12, which sends the bullet off to the right. Great. Last thing to do here is destroy this object when it goes out of the screen. Add an “outside room” event, and inside place the code:


A simple function which needs no arguments and destroys the object which it is placed in.

Yay. Close out of this object and go into the final object, objTarget. We will continue this on the second part of this article.

  1. sam
    September 15, 2009 at 5:03 am

    thanks mate for this site this morning i didnt know wat scrip was and know i can actually use it, hope you get more good feed back thanks.

  1. No trackbacks yet.
Comments are closed.
%d bloggers like this: