1 min
The sounds were called by sending two enums. The first was tell the user what sound type it is and the second was to tell which sound needed to be played. The sounds were stored in different vectors depending and type of sound it was. There was a vector a game sounds, a vector for menu sounds etc. So the first enum decided which vector it was going to get and the second enum decide which element in the vector was being called. This system worked but relied on the vector storing the correct sounds and the sound that part of the vector matching the enum.
This was changed to a tag based system where each sound now had a tag and the user would call the play function and give it tag. Instead of there being multiple vectors, there was one that stored all the sounds. The audio manager would then loop through the vector of sounds it stored until the string matched the tag of a sound in the vector. This method was much better as it meant it didn’t rely on the enum matching the correct element in the vector. However it does mean the user has to get the tag absolutely correct in order for the sound otherwise it will do nothing, also the fact it loops through the vector. If this was a large game with massive amount of sounds then it would definitely be inefficient but for the amount of sounds in the game it is fine.
Subscribe to this blog via RSS.
Low level programming dev diary 28
Text based adventure dev diary 6
Level design developer diary 3
Game engine programming dev diary 14
Audio-visual production dev diary 7
Audio-Visual Production: Particle System Mesh Spawning Issues
Posted on 20 Feb 2020Low level programming dev diary (28) Text based adventure dev diary (6) Level design developer diary (3) Post mortem (4) Ex-machina dev diary (11) Game engine programming dev diary (14) Network game dev diary (11) Audio-visual production dev diary (7)