• 2D shoot 'em up
SDL2 Santa game tutorial 🎅
SDL2 Shooter 3 tutorial
The Legend of Edgar 1.36
SDL2 map editor tutorial [UPDATED]
TBFTSS: The Pandoran War - Amiga OS4 Port
— Creating a simple roguelike —
Up until now, the monsters have been static, not moving or attacking. We're going to change this, and have the monsters move towards us and also attack. This is going to be a short part, to demonstrate how the enemies can attack us.
Extract the archive, run cmake CMakeLists.txt, followed by make, and then use ./rogue05 to run the code. You will see a window open like the one above, showing our main character in a dungeon environment. Use the same controls as before to move around. Battle the Micro Mice when you find them. There are three in total. They will hit you back and can harm you, but cannot kill you. Once you're finished, close the window to exit.
Inspecting the code
We're going to start by updating monsters.c. doMonsters is up first:
Before calling nextMonster, we're making a call to a new function named moveToPlayer. We'll see this fully in a moment. For now, we'll cover off a tweak to nextMonster:
Where before our `found` variable was being set to 1 (true) when finding an entity type of ET_MONSTER or ET_PLAYER, we're now also requiring that the entity's `dead` flag is set to 0 (false). This is to handle a race condition where, following the player's turn, the enemies go next (due to the nextMonster call). It is likely that the player might have just killed a monster, but owing to our processing the dead monster is able to act and strike us. By checking if the monster is not dead first, we eliminate this bug.
Now we come to moveToPlayer:
The idea behind this function is that the enemy will simply attempt to move towards the player, one square at a time. We start by subtracting dungeon's currentEntity's `x` and `y` (the Monster) from the player's `x` and `y`, assigning the results to `dx` and `dy`. This will give us the direction the monster needs to move to reach the player. Because our monsters can only one square at a time, we need to limit the values of `dx` and `dy` to between -1 and 1. We do this by calling our MIN and MAX macros for `dx` and `dy`, passing in -1 to MAX and -1 to MIN.
Finally, we check to see if the square the monster wants to move into is empty or is occupied by the player. We do this by calling getEntityAt, passing over the currentEntity's `x` and `y`, plus the calculated `dx` and `dy` values, assigning the result to an Entity variable named `e`. We then test the value of `e` to see that it's either NULL or is the player. If so, we'll call moveEntity, passing over currentEntity and our calculated `dx` and `dy`. Remember that according to moveEntity this will result in the monster attacking the player, should the player be in the square the monster is attempting to move into.
Next, we've made a tweak to addMonsters:
We've just added a for-loop here, to create 3 Micro Mouse monsters, instead of just 1. They'll be added into the dungeon at random places.
We've also tweaked the Micro Mouse itself:
We've increased its maxAttack from 2 to 3. This is because it would otherwise always fail to cause damage to the player, being too weak to harm them. These sorts of tweaks will likely continue to happen during our development and game testing, especially when weapons and armour are added.
Finally, we've made an update to player.c, in doPlayer:
Since we now have mouse support, we've added in the ability for the player to move the character around by highlighting a square and holding the left mouse button. It's not the best method of navigation, but does sometimes help with fighting monsters, especially when attacking along the diagonals.
We first test to see if App's mouse's left button is pressed, then calculate the distance between dungeon's selectedTile and the player, assigning the results to `dx` and `dy`. As with the monsters, we're limiting the values of `dx` and `dy` to between -1 and 1. The rest of the function continues as normal.
That's all we needed to do to add in basic monster movement and attacking. While this works, it's very crude and there are many flaws. To begin with, the monsters are always moving towards the player, regardless of how far away they are and whether they are in the line of sight. The other issue is that the movement is so basic that the monsters can get stuck behind walls, etc. The way to solve this is to use a better navigation method, such as A*.
In our next part, we'll introduce A* pathfinding to replace the movement we've demo'd here.
The source code for all parts of this tutorial (including assets) is available for purchase:
It is also available as part of the SDL2 tutorial bundle: