Home > SoulHow > SoulHow to make a boss in Game Maker (using actions)

SoulHow to make a boss in Game Maker (using actions)

June 2, 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: Rookie (3)

I have written an article about ways to improve your currently made bosses, but I seem to have omitted an article about how to actually create a boss in Game Maker. You’re in luck, because that’s what I will explain in this SoulHow guide. In fact, I’ll show you how to do it with actions! If you’re a code-person, fear not, because, it shouldn’t be too difficult to convert the actions to GML code.

So how exactly do you make a boss? Honestly, the answer is, there is no answer. All bosses are different, so instead of giving you an example for a complete boss, I will give you an example of how to make each part of a boss, from health, to health bars, to attacks.

Health:
Of course, every boss needs health. No boss is any good unless you have to hit it a bunch of times before it dies. To do this, we need to use what’s called a variable. To understand variables, you can read SoulHow to code in GML if you want, but all you really need to know at this point is that variables are like containers that you put numbers into. To make a variable, you use this action, called “set variable”:

It can be found on the control tab. Inside this action, you specify the variable’s name and the number it should hold (the “value”). We want to use a variable to give the boss some health, so place this action in the create event of your boss. Call the variable “bosshealth” and give it a value of 10. Your boss now has 10 “hp”. Note, that because the boss object made this variable, it will normally only work inside the boss object.

Of course, we want the hp to drop every time the boss is hit. So in the event where your boss “gets hit” (perhaps in a collision event with the player’s bullet object? when the player jumps on top of the boss? when the boss runs into a wall? etc.), we should subtract 1 from bosshealth.

Go to that event, whatever it may be, and in it once again place the “set variable” action. Type in “bosshealth” for the name, but this time, put -1 for the value and check the “relative” box. Checking the relative box tells GM to add the number you typed to whatever is already inside the variable. So if bosshealth already has 10 inside it, and you add -1, you get 9 (one less than ten, which is exactly what you want).  Make sure that if the event does not belong to the boss, then you set the “applies to” field to either other (for other objects’ collision events) or object (for some other event; make sure you select the boss object).

As a side note, if a specific object damages the boss, make sure you destroy it after it touches the boss so the boss doesn’t get hit continuously. For example, if a bullet hits the boss, deduct from the boss’s hp, and then destroy the bullet object. Like this:

Set variable ‘bosshealth’ relative to -1
For other object: destroy instance

Now, we want the boss to die when it runs out of health. We should test whether the boss is dead all the time, so we’re going to do this in the boss’s step event of your boss. Note from here on out, I’m going to call the boss object “objBoss”.

We have to check if health is gone and if so kill the boss. Go to objBoss’s step event; here, we’re going to use a new action, called “test variable”. This action tests whether the number inside a variable is higher than another number, lower than another number, or exactly equal to another number.

So in that step event, place the test variable action (shown below), type “bosshealth” for the variable name, and type “1” for the value. Choose “less than” in the drop down box labeled “operation”. This is because we want to test whether the boss’s health contains anything less than 1; which would be either 0 or a negative value like -1 just in case something unexpected happens during the game causing the boss’s health to go below 0.

Then, we want to destroy the boss and, possibly, do something else as well. Because we want to perform multiple actions after testing the variable, we need to use start-of- and end-of-block markers (also shown below) to surround every action that is tied to testing the bosshealth variable. That way, when bosshealth is less than 1, all the actions between the block markers are merged into a single “block” which is executed as if it were a single huge action.

The step event of your boss should look something like this:

Test variable “bosshealth” to be less than 1
Start of a block marker
Destroy this instance [the boss]
For all door: destroy instance
End of a block marker

Now, when bosshealth gets to 0, the boss will destroy itself and a door that’s blocking your way. That’s just an example that I came up with in thirty seconds; maybe you want it to do something else.  But whatever you want it to do, remember to put those actions between the and .

Health bar:
Sometimes we want the player to know how much health a boss has left. That’s what a healthbar is for. Assuming we’re still using “objBoss” and the variable “bosshealth” from the “health” section of this article, here’s how we do it:

It’s quite easy, actually. Create a new object, and call it “objBossController”. This object will be used to draw objBoss’s healthbar. Create it when objBoss is created, starts attacking, or comes onscreen, etc.  The choice is yours; just make sure it’s only created when the boss object is already in the room. (explained below)

Now because we’re drawing something, we want to use the draw event. In the draw event, we want to use the objBoss’s “bosshealth” variable to draw a corresponding health bar. How do we get this variable all the way from another object? After all, variables are tucked away deep inside whatever object you use them in. Well to do this, you type the name of the object you want to search in, then put a period (.) which in GML is called the “dot operator”, and finally type the variable’s name.  Be careful, though!  If you use the dot operator to try to get a variable from another object which doesn’t exist in the room yet, Game Maker will throw an error!

Okay, in the draw event of this objBossController, we want to use the draw rectangle action. That’s all a health bar really is, after all: a rectangle that shrinks when the boss gets hurt. Place that action in the draw event now.

We have to specify how the box should be drawn. Let’s draw it so it stays in the view. That way, no matter where the view/character goes, it’ll always be in that same spot on the screen. To do this, we use two variables that Game Maker makes for us: “view_xview[0]” and “view_yview[0]”. They tell Game Maker where the left side and the top of the view are, and we can use those variables to tell Game Maker to put our healthbar in the view. Also, let’s give the health bar a little border; maybe draw it 16 pixels below the top and 16 pixels off from the left side. Here’s how to do it:

Note: there may be some things you don’t understand in this following example action, but don’t worry; I’ll explain it afterwards.  NOTE: This is NOT GML code!  What I wrote below refers to what you should type in each field of the window that pops up after adding the draw rectangle action to the draw event of objBossController.  If you copy+paste what I typed below into code, Game Maker will become sad for not listening to good ol’ SoulRed’s advice and it’ll give you an error.

Draw rectangle
x1: view_xview[0]+16
y1: view_yview[0]+16
x2: view_xview[0]+16+objBoss.bosshealth*10
y2: view_yview[0]+16+32

So what’s up with that “objBoss.bosshealth*10” thing? Well, in order to make a health bar that shrinks every time the boss loses hp, we have to call upon the variable we made which holds the boss’s hp. Recall that to get a number from inside a variable that another object made, we need to type the other object’s name, then a dot operator, and then the variable’s name. That’s how we got “objBoss.bosshealth”.

We are using this variable because then, as the boss’s hp shrinks, so does the width of the health bar. Imagine this: the boss’s hp (which is the number inside the bosshealth variable) is 10. So bosshealth*10 = 100 pixels of width for your health bar (note that * is the computer symbol for multiplication). But then, imagine that the boss suddenly gets hit, and his hp drops to 9. Now, bosshealth*10 = 90 pixels of width for your health bar. It just shrunk!

We could have left out the “*10”, but it’d look silly to have a health bar that was only 10 pixels wide. Finally, the reason I add 32 to y2, is because we want the health bar to have a height of 32 pixels. The height doesn’t shrink (only the width), so we don’t need to use bosshealth for that.

Mmkay, now there’s one more thing I want to bring up. As I already mentioned, if you use the “object name then a dot operator then the variable name” trick when the object which you name doesn’t exist, GM will yell at you with an error even if you did everything else right. So, before we run our draw rectangle action, which uses the “object name then a dot then the variable name” trick, we want to test if the boss object exists. To do this, we’re going to use a “test the number of instances” action. Change the draw event to look like this:

If the number of objBoss is greater than 0
Draw rectangle [keep this the same as above]

Because it’s only one action, we don’t need the start of a block or end of a block actions. Placing this new action there causes the draw rectangle action to only be run if objBoss currently exists, thereby eliminating the need to wait to create objBossController until objBoss already exists.

Attacks:
We definitely want our boss to fight back. Sometimes, though, that’s easier said than done. In reality, boss attacks are generally done with some sort of timer. Luckily for you, GM has a system called alarms, which is basically a bunch of easy-to-use timers. Imagine we have three types of bullets we want the boss to fire, one after another. To do this, we use alarms.

In the create event of objBoss, place the fancy little “set alarm” action.

In the “alarm number” part, don’t change it from alarm 0. I’ll explain why a little further down.

Keep in mind that the number you set the alarm to is not seconds. It is in steps, which is basically 1/30 of a second if you haven’t changed your room speed. If you don’t know what room speed is, then a step is 1/30 of a second. (that’s what game maker puts it to.) Thus, if you want the timer to go off in one second, you’d type 30. If you want it to go off in 5 seconds, you’d type 30 x 5, which is 150. For now, just type 30.

How do we tell GM what to do when this timer goes off? We use the alarm event. Click add event-> alarm -> alarm 0. Yes, alarms start at zero, instead of one. Kind of weird, but as you continue learning you’ll see that a lot of things in Game Maker start at 0 and eventually you’ll get used to it.  Anyways, now any actions that you put in this new event get executed when alarm #0 “goes off”. So because we want the boss to shoot when that alarm goes off, let’s put an instance create action and create our bullet (I’m going to assume I don’t need to explain how to create a bullet object).

Now here’s the real trick: we’re going to set a second alarm. Add a set alarm action in the alarm 0 event, and this time click the dropdown box and choose “alarm 1” (which, due to the starts-at-zero-thing, is technically the second alarm). Set it to 30 (1 second). Click add event and add the alarm 1 event in the same way you added the alarm 0 event, and in it, put another instance create action so the boss shoots the bullet a second time. And yes, use the set alarm action again and this time choose alarm 2. Set the timer again to 30, and add the alarm 2 event. In the alarm 2 event, use instance create once more to create your third bullet.

Well, we’ve created all three bullets. However, we want the boss to keep shooting. There are about 12 alarms for each object, but when we get to the twelfth one, we’ll be out of alarms and the boss will stop. So instead, we’re going to use the second real trick, and reset the first timer. After the instance create action in the alarm 2 event, use the set alarm action one more time. This time, choose alarm 0, and set it to something like 90 (equal to 3 seconds, because we want the boss to “rest” a little after the third shot).

Now, what will happen, is alarm 0 will be set, and it will go off, setting alarm 1, which will go off and set alarm 2, which will go off and set alarm 0 again. When that goes off, alarm 1 will be set which sets alarm 2 again which sets alarm 0 again…etc., etc.

There you go. A boss attack sequence.  Note that this is incredibly simplistic and you’re going to want your bosses to do a lot more than just shoot, shoot, shoot, rest, shoot, shoot, shoot, rest, etc.  However, you could easily use alarms to give the boss other types of attacks; maybe alarm 0 makes the boss move up and alarm 1 makes the boss move down, and in alarm 1 you could set alarm 0 again; and in alarm 2 you could have the boss shoot and set alarm 2 again so he keeps shooting. All kinds of things are possible, so be creative and see what you can come up with!

Pitch has brought up a good point.  The attack pattern above describes predictable behavior, that is, behavior that never changes; however, I’d like to mention that if you’d like more random patterns, throw in an “if the dice lands on one” action, and perform a different action depending on what happens.  For example, you may want to set a random alarm so that the boss performs a random action.

If a dice with 3 sides lands on one
Set alarm 1 to 30
Else
Start of a block
If a dice with 2 sides lands on one
Set alarm 2 to 40
Else
Set alarm 3 to 30
End of a block

If you check the math on this, you’ll see that this gives an equal random chance of setting alarm 1, 2, or 3. Random attacks/moves! In each alarm you could call this set of actions again after doing whatever else the boss needs to do, causing it to perform yet another random attack.

Thanks again to pitch for giving me the idea to write the last section of the guide.

If you enjoyed this article, please consider checking out the rest of the blog.

If you have a technical question, such as “How do I do this” or “this is not working right” (relative to something with your Game Maker game after reading this tutorial), please head over to the Game Maker Community and ask there.  I can’t answer any such questions in this blog and the members at the GMC will be more than capable to help you.  For more info, go to this blog’s FAQ page.

Advertisements
Categories: SoulHow Tags: , , ,
  1. Dan205
    October 18, 2009 at 9:05 am

    WOW!!!! Amazing!!!! I was really stuck because my game was really boring, but this has helped me loads!!! THANKS!!!!

  2. Max
    October 13, 2009 at 12:26 pm

    Very nice!
    This was perfect for my “asteroids” game!

  3. Rudy
    July 30, 2009 at 1:46 am

    Hola, dejame decirte k me encanto este tutorial, muy importante a la hora de crear un juego y lo busque como loco. pero grax a ti lo encontre.
    Lo malo es que esta en Ingles y tube k traducir algunas cositas, pero mil veces grax.

  4. redefinekeys
    June 14, 2009 at 4:41 pm

    Cool cool cool :)

  5. Hi
    November 26, 2008 at 5:40 pm

    Thanks, I made a ton of successful bosses using this!

  6. GrygrFlzr
    August 22, 2008 at 7:40 pm

    Tanx a lot! Now I could make a timed game with a random transformation!!!!

  7. July 15, 2008 at 5:54 pm

    event>step>execute piece of code
    your object name here. x = mouse_x
    your object name here. y = mouse_x

  8. soulred12
    June 14, 2008 at 3:51 am

    @pitch: You’re right, it is pretty basic. But you can get further if you use the principles and get a little creative. For example, you could throw in a call to random() (or an “if a dice lands on one” action) to choose which alarm to set. In fact, I will add that to the tutorial. Thanks!

  9. Pitch
    June 14, 2008 at 12:35 am

    A nice tutorial if you’re going for bosses with fairly predictable patterns (Ala Megaman), but this doesn’t really detail how to make a boss that doesn’t (or at least is misleading enough to look like it doesn’t) follow a set pattern. Of course, if you could use a bit of coding common sense you could figure it out on your own. But it’s a very nice outline tutorial for getting into more advanced boss developement. Good job.

  10. Westly123
    June 7, 2008 at 11:34 pm

    Nice tut I made my games boss with dis and it works great!

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