The "Play (by name)" action takes several parameters: the name of the file (as a text field in which you can add variables and expressions), the folder the file is supposed to be in (either "Sounds" or "Music"; here it is the "Music" folder) and a tag, as the "regular" "Play" action.
The tag here is still "BackgroundMusic", so the file can be stopped at the next wave's end.
The music files in this project are named "MattOglesby - X" where X is a number from 0 to 2.
The use of the expressions " & floor(random(0,3))" allows to concatenate (add to the string) a random number between 0 and 2 to the string "MattOglesby - " (notice the spaces).
This allows to play a random song each wave, in the limits of the available songs.
..° Sounds on some actions (asteroid hit, asteroid destroyed, asteroid in collision with ship, wave end, ship movement, the player presses "return" in the "menus")
Some of these actions, we've already seen (UI1 being played in the "menus", "NewAchievement1" being played on wave's end).
As mentioned earlier, the process is pretty much the same all the time, in a sub event that checks if the global variable "Sound" is equal to 1 (sound is turned on).
Then the "Audio: Play" action is used with the according sound name.
Check in "esGame" the events 22 and 24 in the "AsteroidHandling" group which correspond to the asteroid hit and asteroid destroyed sounds.
Nothing much to add there in regards to the previous explanations.
Event 14 is the sound played on collision between an "Asteroid" and the player's ship.
Finaly, the sounds on ship movement happens in the group "PlayerMovement".
The same sound is played for thrust and brakes, but is tagged differently.
As you can see event 4, the condition "System: Trigger once" is there again to only play one sound as long as the "UP" key is held down (top event 3).
The sound is "JetLoop1" which is not a short sound. Still no need to loop it.
The sound is tagged "Thrust" as the "UP" key makes the ship moving forward/thrusting.
Event 5 happens when the key "UP" is released.
You can notice the action "Audio: Stop "Thrust"".
The sound is stopped since the ship is thrusting no longer.
The same logic happens in event 7 and 8 but for the tag "Brake".
That's it for the Audio System in this project. In your own projects you can act on the volumes and playrate of your sound, in the same way you stop a sound, by naming its tag.
You can give the same tag to several sounds playing and apply the same volume/action to them all at once by simply naming the tag.
5 - A life bar implementation
It is a subject often asked, and also an interesting feedback for the player.
A lifebar is a visual representation of the health/energy left in some object of the game.
In this project, I chose to only represent the ship's health with a lifebar, as the "Asteroid" are a single hit and their size determines wether they split or get destroyed.
The health itself is handled in the group "PlayerHandling" in "esGame". We've already discussed about it in the Basic Mechanics.
The lifebar is just there to visually represent this health.
The lifebar is in the layout "Game" and is composed by two objects:
+ A sprite "LifeBarBorder", which is the white fixed border.
+ A tiled background "LifeBar", which is the gradient from red to green texture.
The useful difference between a tiledbackground and a sprite there is that when you change the size (width and/or height) of a tiledbackground, it simply displays more or less of the texture, whereas a sprite displays the whole texture and stretch it to its size.
This is why tweaking the width value of "LifeBar" will allow to give the lifebar impression to the player and represent closely the current health status of the ship.
"LifeBar"'s width is 128 (at full, like the max amount of health of "Player").
"LifeBarBorder" is strictly visual and never meant to be modified.
Those two textures I made myself using the GIMP. You can reuse those two assets in your own projects if you feel like it, but to be honest, if I can do such assets, you can yourself too, and possibly do better ones.
From a code's perspective there's only one action required for this implementation.
In event 34 in "esGame", the "Every tick" event :