PC Games
• Orb Tutorials
• 2D shoot 'em up Latest Updates
SDL2 Versus game tutorial
Download keys for SDL2 tutorials on itch.io
The Legend of Edgar 1.37
SDL2 Santa game tutorial 🎅
SDL2 Shooter 3 tutorial
Tags • android (3) • battle-for-the-solar-system (10) • blob-wars (10) • brexit (1) • code (6) • edgar (9) • games (43) • lasagne-monsters (1) • making-of (5) • match3 (1) • numberblocksonline (1) • orb (2) • site (1) • tanx (4) • three-guys (3) • three-guys-apocalypse (3) • tutorials (17) • water-closet (4) Books The Third Side (Battle for the Solar System, #2) The White Knights have had their wings clipped. Shot down and stranded on a planet in independent space, the five pilots find themselves sitting directly in the path of the Pandoran war machine as it prepares to advance The Mission. But if they can somehow survive and find a way home, they might just discover something far more worrisome than that which destroyed an empire. |
— A simple turn-based strategy game — Note: this tutorial assumes knowledge of C, as well as prior tutorials.
Introduction We're going to introduce something new here - an obstacle in the world. These will be slime pools, that will inhibit the movement of the wizards, but not the ghosts. The ghosts will be able to move through (over) slime pools, while the mages can't. The mages will be able to target and destroy them, however, to clear the path (see screenshot). Extract the archive, run cmake CMakeLists.txt, followed by make, and then use ./sdl2TBS16 to run the code. You will see a window open like the one above, showing three wizards in a maze-like map, as well as a number of ghosts. Play the game as normal. When encountering slime pools, notice how the A* pathfinding walks around them (if possible). You you click on slime pools to target them, just like ghosts, and click again to attack. So long as you have a clear line of sight, the slime pools will always be destroyed by your magic attacks. Once you're finished, close the window to exit. Inspecting the code Adding in the pools is a very simple thing, as we'll see. Fun fact: when this tutorial was first being prototyped, it involved tanks and jets. The tanks could move over the land, but were blocked by water. The jets were unaffected by this. I changed it to wizards and ghosts, just because..! Let's start by looking at the update to structs.h:
We've added in a new field to Stage. worldTarget is an Entity that will represent the thing in the world that we're targetting (such as the slime pool). Think of this as a meta entity, that can be moved around. The slime pools are actually MapTiles, so we'll be leveraging this worldTarget to attack them. Moving across to mapGen.c, we've updated generateMap:
We've added in a call to growSlime. We'll come to this in a bit. For now, we've made a change to verifyCapacity:
Once we've found a suitable map to use (via the flood fill validation), we're setting our ground and wall tiles. When setting a ground tile (TILE_GROUND), there is a one in 256 chance that the tile will actually be slime (TILE_SLIME). We can get more slime on the map by lowering this value, and less of it by raising the value. 256 is a good value, I've found. Now we come to the growSlime function:
What this function will do is loop through all our MapTiles, looking for a slime tile. Upon finding one, we'll call a function named growSlimePoint, passing across the `x` and `y` coordinates of the slime tile. We're going to go over our map 15 times. Once again, increasing this value will result in larger slime pools, while lowering it will create smaller ones. growSlimePoint follows:
The idea behind this function is to randomly expand a slime tile into a neighbouring ground tile. We start by setting two variables `mx` and `my` to the same values as the `x` and `y` passed into the function. Next, we select a random of 3. If it's 0, we'll update `mx` by between -1 and 1, meaning we'll expand the slime on the horizontal. If our random is 1, we'll randomly update `dy` by between -1 and 1, meaning we'll expand the slime on the vertical. By default, we'll do nothing. Next, we'll test if we're actually expanding our slime point by checking that `mx` is not the same as `x`, or that `my` is not the same as `y`, ensure the point of expansion is inside the map, and then test that the new point is a ground tile. If all of these checks are true, we'll flip the ground tile to be a slime tile. That's all we need to do to create our slime pools! Easy as pie! Now, let's look at how we can go about attacking and destroying them. Turning to player.c, we've updated doSelecteUnit:
Once we've checked to to see if we're not targetting a solid entity, we're testing if the MapTile we've selected is a slime tile (with a call to a new function called isSlime). If so, we'll target it. We're setting Stage's worldTarget's (our meta entity) `type` to ET_WORLD, its `name` to "Slime", and then assigning its takeDamage function pointer to a function called worldTargetTakeDamage. We'll come to this in a bit. Next, we're testing if we've not previously selected this tile. If we've not, we'll set Stage's worldTarget's `x` and `y` to the selectedTile's `x` and `y`, and then assign Stage's targetEntity as Stage's worldTarget. So, in short, we're creating a fake entity that we can attack, and setting some attributes. If we've previously selected this tile as our target, we'll simply call attackTarget, as usual. Finally, if we assess that the map tile we've clicked on isn't an entity or a slime tile, we'll NULL Stage's targetEntity to deselect our target. So, again, as you can see, when attacking a slime tile we're preparing a fake target to act as the entity. Next, we come to worldTargetTakeDamage:
A simple function this, working just like the other takeDamage functions. We first ensure that the MapTile being occupied is a slime tile, and we're then reverting it to being a ground tile. We're then clearing Stage's targetEntity, so that the tile doesn't remain targetted. Let's take a look the isSlime function now, found in map.c: int isSlime(int x, int y) { return isInsideMap(x, y) && stage.map[x][y].tile >= TILE_SLIME; } Easy enough. We're test if the map point at x and y is inside the map and also if the value of the MapTile is TILE_SMILE or greater. Testing this way both ensures we don't index outside of our array, and gives us scope to have different slime images, if we so desire. Jumping over next to bullets.c, we've updated applyDamage:
When targetting slime tiles (entities with a type of ET_WORLD, as assigned in player.c), a bullet will never miss. We therefore test to see if Stage's targetEntity `type` is ET_WORLD, and always call the targetEntity's takeDamge function if so. And since we can always hit the world, we should reflect this on the HUD. Moving over to hud.c, we've updated drawTopBar:
Now, when working out the accuracy to display, we're testing if the targetEntity's `type` is ET_WORLD. If so, `accuracy` will be 100 (so long as it is inside our attack range). Otherwise, we'll be calling getAttackAccuracy as normal, to work out the real accuracy value. Almost done! Just one thing left to update and our slime is all done. Heading over to units.c, we've made a tweak to resetUnits:
Now, alongside the NULLing of Stage's currentEntity and targetEntity, we're memsetting Stage's worldTarget. We're doing so to ensure that the `name` and takeDamage function pointer are cleared, as the AI will also be making use of this entity in a later part! There we go! Our map now has slime pools that can hinder the wizards in their quest to do away with the rogue ghosts. Speaking of the ghosts, it's about time we expanded to roster a bit. So, in the coming parts we'll be adding in all the various other AI types, including ghosts that run away from the mages and ones that blow up when destroyed..! Purchase The source code for all parts of this tutorial (including assets) is available for purchase: From itch.io It is also available as part of the SDL2 tutorial bundle: |