• 2D shoot 'em up
Water Closet ported to PlayStation Vita
The Legend of Edgar 1.35
SDL2 Rogue tutorial
SDL2 Gunner tutorial
— Creating a Run and Gun game —
One major thing we're missing from our game is player death. Right now, nothing happens when the player loses all their health. We've changed that now so that when the player is killed, they will explode, and be reset. We've also thrown in a load of explosions and other little effects for good measure.
Extract the archive, run make, and then use ./gunner12 to run the code. You will see a window open like the one above. The same controls from past tutorials apply. Play the game as normal. Notice how when you are killed, the game pauses for a brief moment before resetting the player to where they were a few moments earlier, while making them invulnerable for a short time. When you're finished, close the window to exit.
Inspecting the code
We've made updates to defs.h and structs.h, to add in our new effects and handle the player death. Starting with defs.h:
EF_BOUNCES is a new flag, to say that an entity bounces when making contact with the map. It's only used by the debris that is thrown when the player, an enemy, a door, or oil drum are destroyed.
Next, let's look at the changes in structs.h:
To handle the player's resetting, we've added in two new fields: `checkpoint` and checkpointTimer. `checkpoint` will act as the location (x and y) of the player when they are reset. checkpointTimer is a counter to say how often the checkpoint should be set.
We've also added in a few struct called Debris:
Debris, as you've no doubt seen, are the pieces of scrap metal that are thrown around when something is destroyed. It only has two fields: `life` and smokeTime. `life` is how long the piece of debris will live for, while smokeTime will be used to handle how often the debris produces smoke.
We've also added in a struct to hold our effects:
Effect has several fields: `x` and `y` are its position, while `dx` and `dy` are its movement values along the x and y axis. `size` is how big it is, while `life` is how long it will live for. `alpha` is used to control the texture's alpha value. We're declaring this here as a double, so we can control it more accurately. `color` is the colour of the Effect. Our Effects form a linked list, hence the `next` field.
Finally, we've added the Effects linked list to our Stage:
effectHead and effectTail form the beginning and end of our linked list for the effects.
We'll look at our effects themselves now. We've seen effects in both SDL2 Shooter and SDL2 Shooter 2, and the code and approach here is much the same, so we won't linger too long on these.
Our effects live in effects.c. Starting with initEffects:
We're loading a texture called gfx/effects/explosion.png, and assigning it to explosionTexture. We're only using one texture for all our effects, so we only change the size, colour, and alpha of, as needed. We're also setting up our effects linked list.
doEffects is where we process the effects themselves:
For each effect in our linked list, we're decreasing both its `life` and `alpha`. We're then moving the effect by adding on their `dx` and `dy` to their `x` and `y`, respectively. If either the effect's life or alpha falls to below 0, we're removing it (an effect with no life is obviously dead, while one with 0 alpha will be invisible).
We're rendering our effects in drawEffects:
When it comes to rendering our effects, we want to do so using additive blending. This will result in colours in our effects being combined, becoming more intense, and shifting towards a brilliant white. Perfect for explosions. We're calling SDL_SetRenderDrawBlendMode and setting SDL_BLENDMODE_ADD, to tell our renderer how to handling the subsequent blitting operations, while also setting the explosion texture's blend mode (actually the texture atlas's blend mode) to SDL_BLENDMODE_ADD, using SDL_SetTextureBlendMode.
We then loop through all our effects in our linked list, calling SDL_SetTextureAlphaMod to set the alpha value of the explosion texture using the `alpha` of the Effect. We're also setting the colour of the texture using SDL_SetTextureColorMod, and feeding in the effect's `color` RGB values.
Next, we're preparing to draw the actual effect. Our effects are drawn centered, so we first assign variables named `x` and `y` the position of the effect, adjusted for the position of our camera, plus half the effect's `size`. We're then calling a new function named blitAtlasImageScaled, to draw the texture using its `size` (note: this function was covered in the Sprite Atlas and SDL2 Adventure tutorials).
When we're done drawing all our effects, we're resetting the texture's colours and alpha to their normal states, and changing the texture and render's blending modes back to SDL_BLENDMODE_BLEND.
That's our processing and rendering of our effects. We can now look at how we add in effects. We've created several functions to help with generating them. Starting with addExplosionEffect:
This function creates an explosion effect, with a random colour of red, orange, yellow, white, or black. The function takes three parameters: `x`, `y`, and `size`. We start by mallocing and memsetting an Effect and adding it to our stage's effect linked list. We then set our Effect's `x` and `y` to the values of the `x` and `y` we passed into the function. We also set the explosion's `size` to the value of `size` we passed in. We want our explosion to last for a little while before vanishing, so we set both its `life` and `alpha` to FPS + (FPS / 4). This will mean the explosion will live for one and a quarter seconds. Finally, we select a random colour for our explosion by performing a switch against a random of 5.
Our next function is addSmokeEffect, that creates a smoke-like effect:
addSmokeEffect takes two parameters, the `x` and `y` position of the effect. Again, we're creating our Effect and adding it to our linked list. We're then assigning the `x` and `y` values. We want our smoke to rise, so we therefore give it a random `dy` value of between 0 and -2.99. Our smoke effects will always be the same size: 32 pixels, and they will also live for just over one second, with `life` and `alpha` values of 64. Finally, we want our smoke effects to be a random grey. We can achieve this by setting the RGB values of its color to the same random of 255.
The last function to look at is addBulletImpactEffect. As the name implies, this function creates an effect for when bullets strike the world or entities:
The function takes the bullet (`b`) the effect is for as a parameter. We're setting up a for-loop to create 8 effects. Each one is centered around the bullet (taking the bullet's `x` and `y` and subtracting half the explosion texture's width and height). We're also setting each effect's `dx` and `dy` to a random value between 0 and 1, to make it slowly drift out from where it was created. We're setting each effect `size` to 8 (so they're small), and setting their `life` to half a second. We want the impacts to be bright, however, so we're setting the `alpha` to 255. This means they'll be quite bright before vanishing. With the base effect setup, we're then checking who owns the bullet, by checking `b->owner`. If it's the player, we'll set the effect to be a light blue. If it belongs to an enemy, we'll set it to be a light red.
Our effects are done. Let's turn now to the new Debris entity, that makes use of some of these effects. All the code for our Debris lives in debris.c. We'll start with the first function, addDebris:
Unlike some of the other entity code, this function takes two parameters - `x` and `y` coordinates, rather than an entity to use. This is because we'll create the entity ourselves in the function.
We start by mallocing and memsetting a Debris struct, then setting its `life` to a random of 2 to 12 seconds. After that, we fetch our textures, if needed. There are four different debris textures to load, which we assign to the indexes of an AtlasImage array. We then create our entity (`e`) by calling spawnEntity. We assign its `x` and `y` fields as the values of the `x` and `y` we passed into the function. We then set its `dx` and `dy` to some random values, with the `dy` being given a negative random value. This will result in the debris being "thrown" when it is created. The entity's texture is set as a random image from the textures array (using NUM_TEXTURES, declared as 4 in debris.h). The Debris struct we created earlier is set as the entity's `data` field, and we set the entity's `flags` as EF_BOUNCES, to make it bounce upon contact with the world. Finally, the `tick` and `draw` functions are assigned.
We'll look at the `tick` function next. It's quite simple:
We're extracting the Debris from the entity's `data` field, then decreasing its `life` and smokeTime values. We're then checking if its `life` is greater than one second (FPS) and its smokeTime is 0 or less. If so, we're going to add a smoke effect. We do this by calling addSmokeEffect and passing in the debris's coordinates, plus half its texture's width and height, so that the smoke is created about the center. We're then setting smokeTime to between 1 and 5. The reason for this is because we don't want to be adding smoke all the time, and so setting smokeTime to a random value creates some variance.
Next, we're testing to see if the debris is on the ground by testing the onGround flag. You'll have noticed that when the debris is on the ground, it slides for a bit before coming to a halt. When the entity's onGround flag is set, we're reducing the entity's `dx` by multiplying it by 0.985. This will cause the debris to act as though friction is being applied to it.
Finally, we're checking if the debris's `life` has fallen to 0 or less, and setting its `dead` flag to 1 if so.
Our draw function is next. There's not much to it:
We're simply drawing the debris's texture, nothing more.
That's our effects and debris code all setup. We can now look at where and how we're using them. There are a number of places in the code where an explosion occurs, such as when an enemy soldier or an oil drum is destroyed. We'll look at the code for how we handle Green Soldiers being destroyed. We do this in greenSoldier.c, in the takeDamage function:
Originally, once the EnemySoldier's `life` fell to 0 or less, we would set their `dead` flag to 1. Now, we're creating two for-loops. The first calls addExplosionEffect 32 times, passing in `x` and `y` values based on a random point about the soldier (using their `x` and `y` coordinates, plus a random of their texture's width and height). We're also telling the explosion effects to be 96 pixels in size, making them quite sizeable. The second for-loop calls addDebris 8 times, passing over the midpoint `x` and `y` of the soldier, so that the debris spawns from its center.
This death code is largely the same for the other soldier type, as well as the weak door, player, and oil drum.
Our bullet effects are handled in bullets.c, whenever a bullet strikes the world or an entity. Each requires just a single line change. Starting with checkWorldCollisions:
When a bullet hits the map (a non-zero tile), we're setting its `life` to 0. In addition, we're calling addBulletImpactEffect and passing over the bullet. This is all that's needed to create our effect.
A similar update is done in checkEntityCollisions:
Once the bullet has hit something solid or something that takes damage, we're calling addBulletImpactEffect before setting the bullet's `life` to 0. Again, just a one line addition.
You will remember that our debris bounces when it hits the world. This is, again, a very simple change to apply. Turning to entities.c, we've updated both moveToWorldX and moveToWorldY. Starting with moveToWorldX:
Before, we were immediately setting the entity's `dx` to 0 once it hit a solid map tile. Now, we're testing to see if it has the EF_BONUCES flag set. If so, we're going to invert the entity's `dx` and multiply the result by 0.75. This will mean that if move left, the entity will instead begin moving right. Multiplying the result by 0.75 will make it move slower than it was before, making it appear as though it has lost energy in the impact.
We do a similar thing in moveToWorldY:
Instead of changing the entity's `dx`, however, we're changing the entity's `dy`.
Now, let's look at what happens when the player is killed. Again, the player used to be impervious to death. Now they actually explode. Turning to player.c, we've made some changes to `tick`:
We're now decreasing the Gunner's checkpointTimer, limiting it to 0. Once it hits 0, we're checking if the player is also on the ground, and then setting the Gunner's checkpoint's `x` and `y` to the player's own `x` and `y`. We're then setting checkpointTimer to CHECKPOINT_TIMER_TIME (defined as 10 seconds in player.c). In effect, we're recording the player's position every 10 seconds, so that we can reset them if they die. Something that's important to do is ensure the player is on the ground before we do so. If we don't, the player could be in midair and this could lead to all kinds of problems (and could also be disorientating for the user).
As already mentioned, the takeDamage function was also updated:
Before, only the immune timer would be set. Now, we're adding in a similar explosion effect seen for the soldier. We've also added in a new function to player.c, to help with resetting the player, named resetPlayer:
The function basically returns the player to their last checkpoint and makes them immune for a number of seconds. We start by extracting the Gunner from the player. We're then setting the player's `x` and `y` to the Gunner's checkpoint `x` and `y`, resetting their `dead` flag, setting their onGround flag to 1, and changing their texture back to the standTexture. We're then adding the player back into the stage's entity linked list. Like other entities, the player is removed from the stage once they are killed. We'll see more on this in a bit. With the player restored, we're resetting their life back to MAX_PLAYER_LIFE, resetting their weapon back to their default gun, and also making them immune for 3 seconds.
We've also made some changes to doEntities in entities.c to handle the player death:
Most entities are moved to the dead list when they are killed. In the case of the player, we're not doing this; we've already got a reference to the player in Stage, so we can access them that way. We also don't want to add the player to the dead list more than once, as this will break our list and make our game lock up. Therefore, we're testing to see if the entity to remove (`e`) is not the player (`stage.player`) before removing them.
We're almost done! Let's finally look at stage.c, where we're processing everything. Starting with initStage:
We're now calling initEffects, along with all our other init functions. We're also setting a variable named playerRespawnTimer to RESPAWN_TIMER_TIME (defined as 3 seconds in stage.h). This variable is used to control the time between the player being killed and them being reset. We don't want the player to be reset instantly upon death, so we pause for a brief period.
Turning now to logic, we can see a few new additions:
As expected, we're calling doEffects, to process our effects. We're now also testing to see if the player is dead. If they are, we're decreasing playerRespawnTimer. Once this hits 0 or less, we calling resetPlayer (in player.c) and resetting playerRespawnTimer to RESPAWN_TIMER_TIME. This is how we prevent the player from being returned to the game immediately upon death. Remember that the player entity has been removed from the game at this point, so attempting to fire, move, etc. will do nothing (no `tick` function is called for the player).
The `draw` function is the last thing we need to look at:
Our `draw` function has now wrapped all the other function calls in an if-statement, testing whether playerRespawnTimer is greater than half a second. If so, we're drawing everything as normal. What this means is that there will be half a second when the screen goes blank before the player is returned to game. This is help with respawning the player, in case they are a long way from where they died. It would be jarring for the screen to suddenly flip. Making it go blank for a moment helps to overcome this.
Additionally, we're calling drawEffects. We're doing this after drawing everything else and before the hud. We want our smoke and explosions to be drawn on top of our entities, bullets, and map, so they need to be rendered last.
Those were the last major things we needed to add in, meaning we're very nearly done with our game! We'll be popping in some enemies in the next part, as well as making a much larger map to explore.
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:
If you do not wish to create an itch.io account, you can also purchase the tutorial bundle using PayPal, and then download the tutorials directly from the main tutorials page.
Share your comments and thoughts below. All comments are anonymous and cannot be edited.