Code Magic

Share this post:

Quick Overview

Added enemy spellcasting
Created new spell that is lobbed instead fired in a straight line
Continued sound work

Enemy Spellcasting

The major focus for this week was coding in enemy spells. I spent a long time working the angles/radians in order to make the spell travel on the x/y axis correctly as well as face the correct direction (had to dig back into my trig knowledge/guess and check a lot). I ended up using atan2 from the math python module to calculate the spell speeds and the angle that it would be fired at. This enabled me to have an enemy that fires spells in a straight line towards the player, which works but is not terribly interesting, so I created a new enemy to accommodate a differing style and add some variety.

The new enemy fires off lobbing spells at the player. To make it work, I had the enemy calculate the x-axis distance to the player and divide that result by 2 to determine a mid point. The enemy has a distance value that is shared between the x-axis and the y-axis, so whatever the x-axis doesn't claim the y-axis does. So the farther away the player is, the lower the spell will fly; while the player being near will cause the spell to move a greater distance in the y-axis.

In this example the shared distance value is Z. The game calculates right triangles using the formula shown. This guides the lobbed spell to its final destination.

Although this method currently works fine, when it reaches the peak and begins to angle back towards the ground it feels pretty abrupt. I had written code to make the spell slow as it reaches the peak but this has not appeared to help at all. Will definitely need to put more work into this to clean it up, but for it is functional and gives me the option to make a spell feel a gravitational force.

While working on the enemy, I experimented with a further polishing spell objects so they perform actions upon being initialized. I ended up liking this a lot more than the current system where the game calls on a spell's cast method which creates the spell and then performs the actions. The new system would require the spell instance to just be created and the spell would handle everything else itself. I will switch the player's spell system over to match the new enemy spell system in order to streamline spell object creation and remove the need to call on the cast method. Part of the revamp also includes taking checks that are performed during the main loop and moving it onto the individual spells that use those checks. This will simplify the main loop and should help improve the performance of the game.

Sound Design

I continued working on the game soundscape. I realized that the ambient sounds from the level would continue playing with no way to stop it. I found this out when doing random bug checks related to character death and found the ambiance continues to play on the gameover screen. I decided that it was a nice touch but still had to be stopped when reentering the main menu. So I coded in another media handler specifically for ambient sounds. The advantage to this is that I can use this to perform checks when entering a new room to see if we need to change the ambiance to match the new room. I also modified a music asset and added it to the game to serve as gameover music.

Added updating each enemy’s volume parameter to the update volume function I made so now when the window volumes get updated so does each enemy. Before they received volume information only upon being spawned in which means if the player changed the effects volume after walking into a room, then all enemies in the room would maintain the old level instead of using the new one so the player would have to leave and reenter the room to update the effect volumes of enemies.

Lastly, I copied the random step sound generator to produce climbing sounds, they ended up overlapping a lot so I immensely increased the number of ticks (there’s 60 per second) between sounds to create a short pause before another one plays.