• 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 —
We're now ready to add in our first monster. To begin with, our monster, a Micro Mouse, will be competely static, not moving or attacking. One could almost consider it a wall. However, we're going to use this opportunity to lay the ground work for fully supporting our monsters fully later down the line.
Extract the archive, run cmake CMakeLists.txt, followed by make, and then use ./rogue02 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. Notice how the mouse blocks not only our movement, but also our line of sight. The mouse's placement is random each time a dungeon is generated. Once you're finished, close the window to exit.
Inspecting the code
Adding our static mouse is quite simple, due to everything we prepared in part one. To begin with, let's update defs.h:
We've added ET_MONSTER to our enums, to represent a monster. Just a one line change. We've also done the same with structs.h:
We've added in a field called `solid` to our Entity struct. This field will be used to specify whether an entity is solid and therefore blocks movement and line of sight. We've also added in a new field to Dungeon:
currentEntity will be used to track the entity that we are currently processing in the dungeon, whether that be the player or a monster.
Now, let's move onto the file we've created to handle our monsters: monsters.c. This is where we'll create our monsters, process them, and all the rest. There are already a number of function here, so we'll work through them one at a time.
The first function is doMonsters:
We'll be using this function to process our monsters when it's their turn. In a roguelike, a player will take their turn and then the monsters will do so. Once all the monsters have taken their turns (moving, attacking, etc), control will return to the player. We're doing just that in this function, albeit without the monsters taking any actions themselves.
We're setting a variable named `processing` to 1 and then setting up a do-loop. We first call a function named nextMonster (more on this in a bit) and then update our `processing` flag. `processing` will be set to 1 if dungeon's currentEntity is not the player. Our do-while loop won't exit until `processing` is 0. In other words, we want to keep calling nextMonster until we reach the player and have been through all the monsters in our dungeon.
If we move onto nextMonster, this will make a bit more sense:
We setup a do-while loop and then move to the next entity in the dungeon, by assigning dungeon's currentEntity to the existing currentEntity's `next`. If our currentEntity is now NULL it means we have reached the end of the list. We therefore want to move back to the top of the list, and so set dungeon's currentEntity to entityHead's `next`, in effect wrapping back around. We'll then test the type of currentEntity and assign the result to a variable called `found`. If `type` is either ET_MONSTER or ET_PLAYER, `found` will become 1. Otherwise, it will be 0. Our while-loop will only exit if `found` is 1 (in other words, we've found a monster or the player).
While right now we only have ET_MONSTER and ET_PLAYER in our dungeon, we'll later on have other types (such as items), and so we're just ensuring now that we only consider these two types to be valid.
So, our doMonsters function will call nextMonster to process all our monsters, stopping when it comes back around to the player. As you can see by now, when it comes to handling the monsters, we're merely looping through all the monsters in the dungeon until we return back to the player. Remember, however, that right now the monsters are doing nothing..!
Our next function is addMonsters. There's not much to it right now:
This function merely adds a single monster to the dungeon, by calling addEntityToDungeon. The addEntityToDungeon function takes just an entity as an argument, in this case, the entity returned by initEntity. We'll see more on addEntityToDungeon in a bit.
This next function is createMonster:
This is just a function to help with setting up common monster attributes. For the entity that has been passed into the function (`e`), we're setting its `type` as ET_MONSTER and its `solid` flag to 1. Later on, this function will do much more!
We call createMonster in our initMicroMouse function:
Being an init function, initMicroMouse takes an entity as an argument (passed across from the entity factory). We first call createMonster, passing the entity over, then set the entity's `name` to "Micro Mouse", and then grab the `texture` that is needed, using getAtlasImage. Quite simple, really.
Now let's look at entities.c. We've made quite a number of additions and updates to this file, so we'll work our way through them from top to bottom. Starting with addEntityToDungeon:
For the given entity (`e`), this function will find a suitable place in the dungeon to insert it. We start with a do-while loop, and then set two variables, `x` and `y`, to a random place in the dungeon (less the edges). We then test whether the tile at this point in the map is a floor tile (> TILE_HOLE and < TILE_WALL) and also whether that square is not already occupied by another entity, by calling isOccupied and passing in the `x` and `y`. We assign the result of this condition check to a variable called `ok`. Our do-while loop will continue until `ok` is 1. With that done, we assign the entity's `x` and `y` as the values of `x` and `y`.
Our isOccupied function is simple enough:
We're iterating through all the entities in the dungeon, to see if there's an entity at the position specified (the entity's `x` and `y` are equal to the `x` and `y` passed into the function). If so, we'll return 1. Otherwise, we'll return 0.
Next, we've made an update to moveEntity:
As well as testing that the location the entity wishes to move is within the map and a ground tile, we're making a call to a function called isBlocked, passing in the entity and the `x` and `y` position we want to move to. isBlocked needs to return 0 (false) in order for us to be able to move.
isBlocked is, for now, a basic function:
Like isOccupied, we're looping through all the entities in our dungeon, assigning them to a variable called `other`, and looking for one in the same square we wish to move to. If `other`'s `x` and `y` is the same as the square we want to move to, we'll test the `type` of `other`. If it's an ET_PLAYER or an ET_MONSTER, we'll return 1 (meaning the square is blocked). If we don't find a match, we'll return 0. This function might look odd right now, but this is because we'll be expanding it in future and reacting more appropriately to the type of entity we've encountered. For example, encountering ET_PLAYER or ET_MONSTER might result in an attack happening, while walking into an item could result in it being picked up, and not blocking movement.
drawEntities is the last function that has been tweaked:
We've made one small change, and are now testing whether the dungeon tile the entity is on (using their `x` and `y`) is `visible`. If so, we'll draw the entity as normal. Otherwise, they'll be hidden. You can see this effect for yourself in some of the dungeons by standing somewhere where the Micro Mouse is in a dark tile. The mouse will vanish from sight until you move into a position where it is visble once more.
Now onto the fogOfWar.c updates. We've changed both function here, to support our solid entities blocking our line of sight. Starting with updateFogOfWar:
We've declared a multi-dimensional array called hasSolid (as static within the file), of size MAP_WIDTH and MAP_HEIGHT. Basically, this array is the same size as our dungeon and will be used to mark squares that contains something solid. Now, as well as marking each square in our map as not being visible, we're also clearing our hasSolid array at the same position. With that done, we're then looping through all the entities in our dungeon and testing their `solid` flag. If the entity is solid (1), we're updating the hasSolid array at the entity's `x` and `y` coordinates, and marking it as 1, to say a solid entity exists at that position. The rest of the function remains the same.
We're making use of this hasSolid array in our hasLOS function:
Before, we would return 0 if the map tile at `x1` and `y1` is a wall tile. Now, we're also return 1 if there is a solid entity at `x1` and `y1`, by testing the value of hasSolid. This is what leads to our Micro Mouse blocking the line of sight and darkening the tiles behind it.
Those are the changes to fogOfWar.c complete, and with it the bulk of our changes. The remaining changes are less significant. We'll start with player.c, and doPlayer:
We've added a call to nextMonster after our updateFogOfWar code. This means that once the player has moved, it will be the turn of the monsters (but as we've already seen, the monsters won't be doing much to begin with).
Moving now to dungeon.c, we've updated createDungeon:
Notice to begin with that we've added in an if-statement around two functions: generateMap and generateEmptyMap. This statement exists to aid with our testing and development. Basically, changing the if from 1 to 0 will call generateEmptyMap instead of generateMap. The latter function creates an empty map that is easier to navigate and test with; it is useful to add in monsters, items, etc. and have them available in a small space, rather than go hunting for them. Flip the value from 1 to 0 as you desire, to create a maze or empty map. We're also making a call to addMonsters, to add in our monsters, and assigning dungeon's currentEntity as the player, so that the player can make their turn first (and also ensuring that our game doesn't crash, due to currentEntity being NULL).
`logic` has been updated next:
We simply test who (or what) dungeon's currentEntity is. If it's the player, we'll call doPlayer. Otherwise, we'll call doMonsters, to drive the monsters.
In case you're wondering what the code for our generateEmptyMap looks like, it can be found in map.c:
As with our other map generation, we're first filling the entire map with wall tiles (TILE_WALL). Next, we're using two for-loops to convert all the tiles of MAP_RENDER_WDITH and MAP_RENDER_HEIGHT (plus 1, to keep the edges walls) to ground tiles (TILE_GROUND). We're also setting the tile's `revealed` flag to 1, so that the map is uncovered. Finally, we're setting the player's position to the middle of the empty map, assigning MAP_RENDER_WIDTH / 2 and MAP_RENDER_HEIGHT / 2 to the player's `x` and `y`, respectively.
To finish off, we turn to entityFactory.c, where we've added in the init function for our Micro Mouse:
All we need to do is add in a call to addInitFunc, passing "Micro Mouse" and initMicroMouse as the arguments. We can now add a Micro Mouse monster to the dungeon by calling initEntity with "Micro Mouse".
So, we now have a dungeon where we can add in a monster. It doesn't do a lot right now, but that will change in a little way down the line. Before that, we're going to make a start on combat. Since our Micro Mouse can't move, it will make an ideal target to practice against ...
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: