Hello lovely wizards-in-training,

Another week of production on Tower Trouble has passed us by. The game now has a working gameloop, and the coming week is the final week in which we add gameplay features.  We've got some final things to discuss in the team for this week, and then we'll move on to polishing what we have.

ART

As for art, we've been busy with the second layer of the towers. This will allow for longer gameplay loops soon.

We've also been busy with making everything pretty, and filling the level.

PROGRAMMING

Here's the sound designer again, giving an update on the programmer side of things. This week we focused on getting the gameloop up and running, meaning implementing all the functionality for the towers - the second layer and the core - re-opening the level. This turned out to be more of a challenge than anticipated. The problem ended up being that local player ID's are managed by the game instance, which persists across the entire runtime of the game - and these weren't being checked for whether they had a controller and pawn already or not. So, the solution was easy: check if a player ID already has a controller and pawn, and if not create and assign one.

SOUND

This week sound design and implementation had to take a back seat for other facets of the project. There was a problem being caused by the audio however, that was causing the game to crash. After a lot of testing, setting breakpoints and staring at loading bars, it became clear what the problem was.

The error was happening on the spell attack audio component in the wizard. To have audio for spatialize correctly, I used the SpawnSoundAttached function, which returns an audio component that I then used to overwrite the existing component with. At some point in the process though, this spawned component can get caught in the garbage collector, returning null and crashing the game.
After figuring this out, I moved the code for the audio in the wizard over to blueprints, removed the audio components from the c++ code altogether and created a scene component to serve as an attachment point for the audio specifically. In the blueprints, I then spawn the attached sound when the appropriate event is triggered, and set a dedicated component in the blueprint to this spawned component. These components are checked on whether they are valid or not before setting any of their triggers.
I could probably create the same construction in C++, but for now the audio no longer seems to be causing any problems and there are other things that require my immediate attention.

For the final week of production, I'm going to make the sounds for the towers - a dedicated hit sound for the core, a big explosion sound for the ending and an ambient loop that starts when the cores become visible - and for when the phase of the game changes. Looking forward to showing off the results next week!