You can access the full course here: INTERMEDIATE GAMEMAKER – TOP-DOWN DUNGEON CRAWLER
Introduction
Delve into the depths of game development with our epic GameMaker dungeon crawler tutorial!
Dungeon crawlers originated in the 1970s and 1980s with games such as Rogue and Ultima – and have since become a popular genre known for their emphasis on exploration and combat. In this GameMaker dungeon crawler tutorial, we’ll explore the fundamental concepts of creating a player character with movement, animation, and attack capabilities. By the end of this guide, you will have implemented the foundational features needed for just about any dungeon crawler and be ready to expand into your own projects.
This tutorial assumes you have intermediate familiarity with GameMaker, including experience working with GML. You can also review our full course, Intermediate GameMaker – Top-Down Dungeon Crawler, which covers these concepts in-depth.
Let’s get started!
Project Files
To help you follow along, we’ve included all the necessary assets used in this tutorial. Feel free to download and use them for your project: GameMaker Dungeon Crawler Assets
Player Movement
In this first section of our GameMaker dungeon crawler tutorial, we will be creating our player and setting up his movement. We will do that by creating the player’s sprite, then importing his animation. Then we will be creating an object that uses that sprite. After that, we will dive into the code to change his x and y coordinates based on the keyboard inputs. So, let’s start by creating a sprite.
Creating the Player Sprite
Go ahead and click Create Sprite and we will name it s_player_walkdown. Included with this course files, you will find the downloadable zip file which contains the assets that we’re going to be using for our course. Download that zip and extract it to your computer. Then click Import and navigate to your assets folder and choose player_walkdown_step_4. As you probably noticed, the image name ends with step_4. Which means once we import it, we will have an animation that’s composed of 4 frames.
Creating the Player Object
The next thing to do is create our player object. So head over to Objects, right-click, choose Create, then Object and let’s name our object o_player. And then let’s add our sprite into it.
Placing the Player Object in the Room
Now that we have our player object ready, let’s place it inside our room. Select our player object and place it inside our room. Now let’s go ahead and click play to see how our game looks at the moment. And as you can see, our game looks fuzzy at the moment, so let’s go ahead and fix that.
Fixing the Game’s Appearance
Click the Options button, this gear icon, then choose your operating system. Click your operating system and then click Graphics and make sure to disable Interpolate colors between pixels. Then click Apply – and if we click play at the moment you’ll notice that our game looks much better.
Creating Player Movement
The next thing to do is create our player movement. In our player object, click Add Event and we will add a Step event. You’ll see this window asking if we’re going to be using GameMaker code or GameMaker visual scripting. Select GameMaker code and make sure to select Don’t ask again for this project and then click OK.
Registering Player Input
The first thing we’re doing is registering the player input, which basically means we’re going to detect what key the player is pressing on the keyboard.We will start by deleting those comments and make a new one for our input.
// Player Input
We will begin by having a variable called _right which is going to be the keyboard check for the right arrow key.
var _right = keyboard_check(vk_right);
This variable will register if the player is clicking the right keyboard arrow. ss you can see our variable starts with an underscore. This is because it’s a local variable, meaning we can only use it locally; we cannot use it in another event or in another object.
Let’s do the same thing with the other keyboard buttons. Make four variables for our four arrow buttons:
var _right = keyboard_check(vk_right); var _left = keyboard_check(vk_left); var _up = keyboard_check(vk_up); var _down = keyboard_check(vk_down);
Implementing Player Movement
Let’s use this input to have our player movement. To move our player, we will simply add to our X position so we will add our right variable minus our left variable.
x += _right - _left;
To figure out the logic behind this line, let’s think of the possible scenarios:
- If the player is clicking the right button, we will have 1 on the right and 0 on the left. That’s 1 minus 0 which equals 1, so our player will move by 1 pixel each step or frame to the right.
- If the player is clicking the left button, then we will have 0 minus 1 which equals minus one, so our player will move by negative one pixel each frame which means our player will move to the left.
If we click play to test that, you will see that our player can move right and left.
Vertical Movement
To implement vertical movement, we need to copy the line above and change it for our Y position. So for our Y position, we will have our down button minus our up button.
y += _down - _up;
If we test that, we will notice that our player can move right and left as well as up and down.
Missing some of the basics? Check out Zenva’s GameMaker Academy which provides a curated learning pathway to help you learn from scratch!
Player Animation
For the next part of our GameMaker dungeon crawler tutorial, we will focus on creating and implementing player animations in our game. We will start by creating different sprites for each animation, then assign these animations based on the player’s movement direction. Additionally, we will ensure that the animations stop playing when the player is not moving and adjust the player’s speed to match the animation speed.
Creating Sprites for Animations
First, we need to create sprites for each animation. Let’s create a new sprite and name it s_player_walk_right. Import the corresponding animation for the right movement. Repeat this process for the left, up, and down animations, naming them s_player_walk_left, s_player_walk_up, and s_player_walk_down respectively.
Assigning Animations Based on Movement
Next, we will assign these animations based on the player’s movement direction. Open the player object and go to the Step event. Add the following code to specify the animations:
// Input
var _right = keyboard_check(vk_right);
var _left = keyboard_check(vk_left);
var _up = keyboard_check(vk_up);
var _down = keyboard_check(vk_down);
// Animation
if(_right)
{
sprite_index = s_player_walk_right;
image_speed = 1;
}
if(_left)
{
sprite_index = s_player_walk_left;
image_speed = 1;
}
if(_up)
{
sprite_index = s_player_walk_up;
image_speed = 1;
}
if(_down)
{
sprite_index = s_player_walk_down;
image_speed = 1;
}
This code checks which keyboard button is pressed and assigns the corresponding sprite to the player object. The image_speed is set to 1 to play the animation at normal speed.
Stopping Animations When Not Moving
To stop the animations when the player is not moving, we will use the image_speed function. Modify the code as follows:
// Animation
image_speed = 0;
if(_right)
{
sprite_index = s_player_walk_right;
image_speed = 1;
}
else if(_left)
{
sprite_index = s_player_walk_left;
image_speed = 1;
}
else if(_up)
{
sprite_index = s_player_walk_up;
image_speed = 1;
}
else if(_down)
{
sprite_index = s_player_walk_down;
image_speed = 1;
}
This code ensures that the animation speed is set to 0 when no keyboard button is pressed, effectively stopping the animation.
Adjusting Player Speed
Finally, we will adjust the player’s speed to match the animation speed. Add an event for the player object, such as the Create event, and initialize a variable for movement speed:
move_speed = 1.5;
Then, in the Step event, multiply the movement by the move_speed variable before adding it to the player’s position:
// Movement x+= (_right - _left) * move_speed y+= (_down - _up) * move_speed
This code ensures that the player’s movement speed matches the animation speed, providing a smoother and more cohesive gameplay experience.
That’s it! You have successfully created and implemented player animations, adjusted the player’s speed, and ensured that the animations stop when the player is not moving.
Player Sword Attack
Moving on with our GameMaker dungeon crawler tutorial, we will be making our player attack. We will start by importing our attack sprites, then we will head over to the code and make a direction and a state variable that will determine if we are moving or attacking. After that, we will start working on our attacking logic, where we will determine which attacking animation will be played based on our direction. Lastly, we will use a new event called animation end to get back to our working animation once our attack is finished.
Importing Attack Sprites
Let’s start by creating our attack sprites. We will name this sprite s_player_attack_down. Import and choose player_attack_down.
Repeat the same process for the other three directions: s_player_attack_up, s_player_attack_right, and s_player_attack_left.
Adding Variables in the Create Event
Next, let’s head over to our player object. In the create event, we will add two variables:
player_direction: This will be set to “down” at the start of the game.state: This will be our player state, meaning if he’s walking or attacking or doing something else. We will set it to “idle” at the beginning of the game.
player_direction = "down"; state = "idle";
Updating the Step Event
Now, let’s head back to our step event. Since we will work with states, let’s make sure that our player moves only when he’s at the idle state.
//Movement
if(state = "idle")
{
move_and_collide((_right - _left) * move_speed,(_down - _up) * move_speed,o_wall)
}
In our animation logic, we will also ensure that the animation only plays when the state is idle: Additionally, we will set our player direction based on the movement:
//Animation
if(state = "idle")
{
image_speed = 0;
if(_right)
{
sprite_index = s_player_walk_right;
image_speed = 1;
player_direction = "right";
}
if(_left)
{
sprite_index = s_player_walk_left;
image_speed = 1;
player_direction = "left"
}
if(_up)
{
sprite_index = s_player_walk_up;
image_speed = 1;
player_direction = "up"
}
if(_down)
{
sprite_index = s_player_walk_down;
image_speed = 1;
player_direction = "down"
}
}
Implementing the Attack Logic
Let’s start working on our attack. First, in our input, let’s add an attack button. We will use the space button for this:
var _attack = keyboard_check_released(vk_space);
Now, let’s start working on our attack code. We will check if we click the attack button. In that case, we will reset the image index for the animation and update the state:
if (_attack) {
image_index = 0; // Reset the image index to start the attack animation from the beginning
state = "attack"; // Change the state to attack
}
Next, we will check if we are in the attack state and use a switch condition to change the sprite based on the player direction:
if (state == "attack") {
switch (player_direction) {
case "down":
sprite_index = s_player_attack_down;
image_speed = 1;
break;
case "up":
sprite_index = s_player_attack_up;
image_speed = 1;
break;
case "right":
sprite_index = s_player_attack_right;
image_speed = 1;
break;
case "left":
sprite_index = s_player_attack_left;
image_speed = 1;
break;
}
}
Handling Animation End
To ensure our player gets back to the idle state after the attack animation ends, we will create a new event called “Animation End”. This event will get executed every time our player finishes one of his animations.
In this event, we will check if we are in the attack state and use a switch statement to change the sprite back to the walking animation based on the player direction:
if (state == "attack") {
switch (player_direction) {
case "down":
sprite_index = s_player_walk_down;
break;
case "up":
sprite_index = s_player_walk_up;
break;
case "right":
sprite_index = s_player_walk_right;
break;
case "left":
sprite_index = s_player_walk_left;
break;
}
state = "idle"; // Set the state back to idle
}
That’s it! You have successfully implemented the player attack logic.
Looking to expand your skills further? GameMaker Academy has you covered with real-world game projects in popular genres with instruction from industry professionals!
Player Hit Box – Part 1
In this next part of our GameMaker dungeon crawler tutorial, we will start creating our player hitbox and define its sides. We will then spawn this hitbox based on the player’s direction and draw it into our game. Let’s get started.
Creating the Hitbox Object
First, we need to create an object for our hitbox. Let’s name it o_hit_box. In its create event, we will initialize four variables corresponding to the hitbox edges or sides. These variables will be set to zero initially.
// Create event for o_hit_box top = 0; bottom = 0; right = 0; left = 0;
Spawning the Hitbox in the Player Object
Next, we will return to our player object and modify its step event. If the player is in the attacking state, we will create a new variable for our hitbox. We will then instantiate our hitbox and assign it to this variable using the instance_create_layer function. This function takes three arguments: the x position, the y position, and the layer at which we want our object to be created.
// Step event for player object
if (state == "attack") {
var hit_box = instance_create_layer(x, y, "Instances", o_hit_box);
}
Setting the Hitbox Sides Based on Player Direction
Now, we will set the hitbox sides based on the player’s direction. For example, if the player is facing down, we will set the hitbox sides as follows:
if (player_direction == "down") {
hit_box.left = x - 10;
hit_box.top = y + 20;
hit_box.right = x + 10;
hit_box.bottom = y + 10;
}
We will repeat this process for the other directions (up, right, and left). Here is the complete code for setting the hitbox sides:
if (player_direction == "down") {
hit_box.left = x - 10;
hit_box.top = y + 20;
hit_box.right = x + 10;
hit_box.bottom = y + 10;
}
if (player_direction == "up") {
hit_box.left = x - 10;
hit_box.top = y - 20;
hit_box.right = x + 10;
hit_box.bottom = y - 10;
}
if (player_direction == "right") {
hit_box.left = x + 8;
hit_box.top = y + 4;
hit_box.right = x + 24;
hit_box.bottom = y - 4;
}
if (player_direction == "left") {
hit_box.left = x - 8;
hit_box.top = y + 4;
hit_box.right = x - 24;
hit_box.bottom = y - 4;
}
Drawing the Hitbox
Since our hitbox object is empty and doesn’t have sprites, we need to draw it manually. We will add a draw event to our hitbox object and use the draw_rectangle function to draw the hitbox. This function takes five parameters: the left, top, right, and bottom sides of the rectangle, and a boolean indicating whether to draw only the outline of the rectangle or fill it completely.
// Draw event for o_hit_box draw_rectangle(left, top, right, bottom, true);
Now, when you test your game, you should be able to see the hitbox when the player is in the attacking state and facing different directions.
Summary
In so far in our GameMaker dungeon crawler tutorial, we created a hitbox object, spawned it based on the player’s direction, and drew it into our game. This hitbox will be used to detect collisions with enemies during the player’s attack.
Player Hit Box – Part 2
In this final part of our GameMaker dungeon crawler tutorial, we will address two issues with our hitbox: it stays active indefinitely, and it does not affect the enemy when it collides with it. We will solve these problems by creating an alarm to destroy the hitbox after a certain amount of time and by detecting collisions with the enemy to destroy it.
Creating an Alarm to Destroy the Hitbox
First, let’s create an alarm that will destroy the hitbox after a certain number of frames. Follow these steps:
- Go to the hitbox object.
- Add an event: Alarm -> Alarm[0].
- In the Create event, trigger the alarm by writing the following code:
alarm[0] = 20;
This code sets the alarm to go off after 20 frames. After 20 frames, any code in the Alarm[0] event will be executed. We want to destroy the hitbox, so add the following code to the Alarm[0] event:
instance_destroy();
Now, the hitbox will be destroyed after 20 frames.
Destroying the Enemy upon Collision
Next, let’s make the hitbox destroy the enemy when it collides with it. Follow these steps:
- Add a Step event to the hitbox object.
- In the Step event, create a variable to check for collision with the enemy:
var collisionEnemy = collision_rectangle(left, top, right, bottom, o_enemy, false, false);
This code checks if the rectangle defined by the hitbox’s left, top, right, and bottom coordinates collides with an instance of the enemy object (o_enemy). The last two arguments determine the precision of the collision and whether to include the hitbox itself in the collision check.
- If a collision is detected, destroy the enemy instance:
if (collisionEnemy) {
instance_destroy(collisionEnemy);
}
Finally, don’t forget to delete the Draw event from the hitbox object, as we only used it for testing and don’t want the hitbox to be visible in the game.
Now, when you test the game, you should see that the hitbox disappears after 20 frames, and if it collides with the enemy, the enemy will be destroyed.
GameMaker Dungeon Crawler Wrap-Up
Congratulations on completing this GameMaker dungeon crawler tutorial! You’ve successfully implemented player movement, animations, and attack mechanics, laying the foundation for an engaging and interactive dungeon crawler game. From responsive controls to dynamic animations, your player character is now ready to explore a vibrant game world.
But why stop here? Consider enhancing this project by adding more animations, improving attack mechanics, or introducing enemies and NPCs. You could also experiment with additional gameplay features like inventory systems, quests, or multiplayer functionality!
To further expand your skills, check out Zenva’s GameMaker Academy. This curated learning pathway will help you learn GameMaker from scratch – while letting you practice with hands-on, real-world game projects in popular genres. Whether you’re building 2D platformers or RPG adventures, we’ve got you covered.
We hope this guide has inspired and empowered you to create amazing games. Best of luck with your future game development endeavors!
Did you come across any errors in this tutorial? Please let us know by completing this form and we’ll look into it! FINAL DAYS: Unlock coding courses in Unity, Godot, Unreal, Python and more.
Transcript – Player Movement
Welcome back. In this lesson, we will be creating our player and setting up his movement. We will do that by creating the player’s sprite, then importing his animation. Then we will be creating an object that uses that sprite. After that, we will dive into the code to change his x and y coordinates based on the keyboard inputs.
So, let’s start by creating a sprite. Go ahead and click “Create Sprite” and name it s_player_workdown. Included with this course’s files, you will find a downloadable zip file containing the assets we will use for our course. Download that zip file and extract it to your computer. Then click “Import,” navigate to your assets folder, and choose player_workdown_step. As you probably noticed, the image name ends with “step 4,” which means once we import it, we will have an animation composed of four frames. Click “Open,” and as you can see, our sprite now has an animation composed of four frames.
The next thing to do is create our player object. Head over to “Objects,” right-click, choose “Create,” then “Object,” and name it o_player. Then, let’s add our sprite to it. Now that we have our player object ready, let’s place it inside our room. Select the player object and place it in the room. Next, click “Play” to see how our game looks at the moment.
As you can see, our game looks fuzzy. To fix that, click the “Options” button (the gear icon), then choose your operating system. Whether you’re on Mac or Windows, the steps are the same. Click your operating system, then click “Graphics,” and disable “Interpolate colors between pixels.” Click “Apply,” and when you click “Play” again, you’ll notice that the game looks much better.
The next step is creating our player movement. Head back to the player object, click “Add Event,” and select “Step Event.” You’ll see a window asking if you’re using GameMaker code or visual scripting. Select “GameMaker Code,” check “Don’t ask again for this project,” and click “OK.”
The first thing we’ll do is register the player input, which detects what key the player is pressing. Start by deleting the comments and adding a new one for the input. Create a variable called _right which will check if the right arrow key is pressed. Similarly, create variables for _left, _down, and _up to detect the corresponding arrow key presses. These variables are local, meaning they can only be used within this event.
Now, use these inputs to move the player. Add a new comment for the movement logic, and update the player’s x-position by adding _right minus _left. This logic ensures that pressing the right arrow key moves the player one pixel to the right, while pressing the left arrow key moves the player one pixel to the left.
Click “Play” to test it. You’ll see the player can now move right and left. As a challenge, try figuring out the vertical movement so the player can move up and down. Pause the video, complete the challenge, and come back.
Welcome back! To implement vertical movement, copy the x-position code and adapt it for the y-position. Use _down minus _up for the y-position logic. Test it, and you’ll see the player can now move right, left, up, and down.
That’s it for this video. See you in the next one!
Transcript – Player Animation
Welcome back.
In this lecture, we’re focusing on making our player animations. So we’ll start by creating different sprites, each corresponding to a specific animation. Then we will jump into the code to assign those animations based on our player’s movement direction. After that, we will make the animations stop playing if the player is not moving. Finally, we will make our player move faster to match our animation speed by creating a variable that controls our player’s speed.
Let’s start by creating our sprite. We will make a new sprite and name it s_player_work_app. Let’s import the corresponding animation and do the same thing for the right and left animations.
Now, let’s head over to our player object. In the step event, let’s add a new command to specify that this is going to be our animations code. We’ll create an if statement to test if the right keyboard button is pressed. If _right is pressed, we will change our animation to sPlayerWorkHideSprite. The sprite_index is a built-in function that assigns a sprite to our object, and we will assign it the s_player_work_hide sprite.
If we click the hide button, we want our player to have the s_player_work_hide sprite. As you can see, if I hit play and move to the right, our player changes its animation to s_player_work_hide.
Now, let’s do the same thing for the other animations. Duplicate this code for the left, up, and down animations. If I click the left button, I want my sprite to be s_player_work_left. Similarly, we’ll set the sprites for the up and down directions. Let’s test that again.
As you can see, our player changes its animation based on the direction. The only problem is that if we are not pressing any keyboard button and are not moving at all, our player keeps animating. Let’s change that.
To do this, we will use another built-in function called imageSpeed. This function controls the speed of our animation. If we’re not pressing any button, we want our animation speed to be zero. If we’re pressing the right button, we want imageSpeed to be one. We will do the same for the left, up, and down buttons.
If we are not pressing any button, our animation will stop (speed set to zero). But if we are pressing any button, the animation will play at its normal speed. Let’s test this.
As you can see, if we are not pressing any button, the animation is frozen. If we start moving, the animation resumes at normal speed.
Currently, our player is too slow and does not match the speed of the animation. To fix this, we’ll start by adding a variable named movementSpeed in the create event and give it a value. You can use a bigger number for faster movement or a smaller number for slower movement.
We will use this variable to control our movement by multiplying it with the movement value before adding it to the x or y position. Let’s test it out.
Now, our player moves faster and matches the speed of the animation.
That’s it for this lecture. I’ll see you in the next one.
Transcript – Player Sword Attack
Welcome back. In this video, we will be making our player attack. We will start by importing our attack sprites. Then, we will head over to the code and create a direction and a state variable that will determine if we are moving or attacking. After that, we will begin working on our attacking logic, where we will determine which attacking animation will be played based on our direction. Lastly, we will use a new event called “animation end” to return to our working animation once the attack is finished.
Let’s start by creating our attack sprites. I’m going to name this sprite s_player_attack_down. Import and choose player attack down. Step 4, let’s do the same thing for the three other sprites. Now, let’s head over to our player object. In the create event, let’s add two variables. The first one is player_direction, and let’s set that to be down at the start of the game. The second variable is state, which will represent our player’s state, such as walking, attacking, or idle. Let’s set it to idle at the beginning of the game.
Now, let’s head back to our step event. In our movement code, since we will work with states, let’s ensure that our player moves only when in the idle state. If state equals idle, then we will move and collide. The same applies to our animation logic. If state equals idle, then we will execute the animation logic. Also, let’s set our player direction: if we move to the right, player_direction will be right; if we move to the left, player_direction will be left. Similarly, moving up sets player_direction to up, and moving down sets player_direction to down.
Now let’s start working on our attack. First, in our input, let’s add an attack button. Create a variable called attack, and use keyboard_check_released so that the attack happens on button release, not on hold. I’m going to use the space button, but you can choose any button you like. Now, let’s add the attack code. First, we will check if the attack button is pressed. If attack is true, we will set our image index to 0 so that the attack animation always starts at the beginning. Then, we will change the state to the attack state.
Next, we’ll check if we are in the attack state. If state equals attack, we will use a switch condition to handle the player’s direction. This is similar to using multiple if statements but more streamlined. For example, if player_direction is down, we will set sprite_index to s_player_attack_down and adjust the animation speed, then break out of the switch statement. Repeat this for the other directions: up, right, and left, assigning the corresponding attack sprites.
If we test the game now, you’ll notice that the player gets stuck in the attack animation. To fix this, we’ll create a new event. Add an “animation end” event, which triggers every time the player finishes an animation. In this event, check if state equals attack. If true, use another switch statement based on the player’s direction. For example, if the direction is down, set sprite_index to s_player_walk_down. Repeat this for up, right, and left, assigning the corresponding walking sprites. Lastly, set state back to idle.
Let’s test the game again. Now, the player finishes the attack animation and returns to the idle state. That’s it for this video. I’ll see you in the next one.
Transcript – Player Hit Box – Part 1
Welcome back. In this video, we will be making our player attack. We will start by importing our attack sprites. Then, we will head over to the code and create a direction and a state variable that will determine if we are moving or attacking. After that, we will begin working on our attacking logic, where we will determine which attacking animation will be played based on our direction. Lastly, we will use a new event called “animation end” to return to our working animation once the attack is finished.
Let’s start by creating our attack sprites. I’m going to name this sprite s_player_attack_down. Import and choose player attack down. Step 4, let’s do the same thing for the three other sprites. Now, let’s head over to our player object. In the create event, let’s add two variables. The first one is player_direction, and let’s set that to be down at the start of the game. The second variable is state, which will represent our player’s state, such as walking, attacking, or idle. Let’s set it to idle at the beginning of the game.
Now, let’s head back to our step event. In our movement code, since we will work with states, let’s ensure that our player moves only when in the idle state. If state equals idle, then we will move and collide. The same applies to our animation logic. If state equals idle, then we will execute the animation logic. Also, let’s set our player direction: if we move to the right, player_direction will be right; if we move to the left, player_direction will be left. Similarly, moving up sets player_direction to up, and moving down sets player_direction to down.
Now let’s start working on our attack. First, in our input, let’s add an attack button. Create a variable called attack, and use keyboard_check_released so that the attack happens on button release, not on hold. I’m going to use the space button, but you can choose any button you like. Now, let’s add the attack code. First, we will check if the attack button is pressed. If attack is true, we will set our image index to 0 so that the attack animation always starts at the beginning. Then, we will change the state to the attack state.
Next, we’ll check if we are in the attack state. If state equals attack, we will use a switch condition to handle the player’s direction. This is similar to using multiple if statements but more streamlined. For example, if player_direction is down, we will set sprite_index to s_player_attack_down and adjust the animation speed, then break out of the switch statement. Repeat this for the other directions: up, right, and left, assigning the corresponding attack sprites.
If we test the game now, you’ll notice that the player gets stuck in the attack animation. To fix this, we’ll create a new event. Add an “animation end” event, which triggers every time the player finishes an animation. In this event, check if state equals attack. If true, use another switch statement based on the player’s direction. For example, if the direction is down, set sprite_index to s_player_walk_down. Repeat this for up, right, and left, assigning the corresponding walking sprites. Lastly, set state back to idle.
Let’s test the game again. Now, the player finishes the attack animation and returns to the idle state. That’s it for this video. I’ll see you in the next one.
Transcript – Player Hit Box – Part 2
Welcome back. As you can see, right now our hitbox gets spawned and stays active as long as the game is open. Also, if we hit our enemy, nothing happens. So in this video, we’re going to fix those problems. We will do that by first creating an alarm that destroys our hitbox after a certain time, and then we will detect if our hitbox collided with our enemy. If so, we will destroy our enemy. So let’s do that.
We’ll go to our hitbox object and then add an event. Choose alarm and select alarm zero. This is simply a timer that counts down from a given value to zero. Now, in the create event, let’s trigger our alarm. We do this by writing alarm0, which is the name of our alarm, and then setting it to 20. This is the number of frames before our alarm gets called or executed. So after 20 frames, any code that’s in our alarm event will get executed.
After 20 frames, we want our hitbox to get destroyed. To do this, we use a predefined function called instanceDestroy. If we test our game right now, you can see that our hitbox stays for 20 frames and then gets destroyed.
The next step is to make our hitbox destroy our enemy if it collides with it. To do this, let’s add a step event to our hitbox. In the step event, we will create a new variable that will verify if we collided with our enemy. We’ll call this variable collisionEnemy and use a function called collisionRectangle. This function checks if the rectangle defined by the first four arguments has collided with the object given as the fifth argument. In our case, the rectangle’s sides are left, top, right, and bottom, in that order. The object we want to check collision with is O_enemy.
The next argument determines if the collision is precise. We don’t want precision here, so we set it to false. We also want this object to be included in the function, so for the last parameter, known as the “not me” parameter, we also set it to false.
If the variable collisionEnemy has any value, meaning it’s not empty, we will destroy that object using the instanceDestroy function. This time, we pass the object we want to destroy as an argument, which is collisionEnemy.
One last thing before testing our game is to delete the draw event since we only used it for testing, and we don’t want to see our hitbox in the game. Now, let’s hit play. You can see that if our hitbox hits our enemy, the enemy will get destroyed.
And that’s it for this video. I will see you in the next one.
Interested in continuing? Check out our all-access plan which includes 300+ courses, guided learning pathways, new courses monthly, and more!