Capturing a Vibe

This week, I spent a lot of time messing around with and learning about sound and textures for the game (and definitely was not putting off doing some of the more important and intimidating last few systems that need to be completed). That said, there is 1 major system that has been set up and tested this week at least in a preliminary fashion — health, dying, and spectating.

Newly adjusted player status widget

As you can see, there’s a new element up here by the stamina bar to represent the player’s current health. While there’s nothing in the game yet that does damage to the player, I did make a quick little actor to damage the player to test this and it does indeed track the player’s health properly.

You might notice the player’s health widget doesn’t update on the killing blow for some reason. This is a bug, though I’m not sure it’s really necessary to fix, since the plan is to remove the HUD when the player dies anyways. As you can probably tell, this is still a very early implementation of this system, but the player gets put into a spectator pawn when they die and can click to swap views between players. Right now, the dead player is still a valid target for spectating, since the player pawn is simply unpossessed when they die and rotated to indicate they’re dead. The plan is to replace the player pawn with a physics ragdoll eventually, but I’ve deemed it unimportant for now. The system also doesn’t have any logic for if all players are dead yet. That function is one of the last couple of things that needs to be implemented before the game has a full “loop” — well, that and something to spawn in the floor that can actually kill the players.

Outside of this, the programming front this week was spent hunting down a handful of other bugs I discovered. Most of these were related to floors that have multiple sections, which I’m starting think is going to be a non-stop battle between me and the floor generator. The most interesting of these was related to a system I’ve technically had for a long time now but never realized wasn’t working properly. One of the first things I implemented to try and make the rooms a bit more varied was a system to randomize the light intensities. I only realized recently that this wasn’t replicating properly and even on the server wasn’t totally functioning correctly. The replication problem was fairly easy to hunt down, all things considered. However, the other one was a bit tricky. First, a short explanation of the system.

The random light intensity function node

This is the function I wrote in order to randomize the intensity of the lights in each room. It includes an input for the light in question, minimum and maximum light intensities, an on chance, and 2 new inputs that are related to how I fixed the problem I was finding. The basic idea is the light would first check if it’ll even be on — this is what the On Chance input is doing. The function picks a random number between 0 and 1 and if the number it picked is higher than the On Chance, the light is just off. This part of the function worked just fine. The problem is the random intensity. For some reason that I’m still not certain about, each light in the whole floor would be the same intensity, barring the ones that were turned off. This problem was slightly fixed when I realized that I was calling this on every room at the end of each section, but not entirely. This fix only made it so each section now had the exact same light intensities. The way I ended up fixing this was by feeding in the Random Stream and the current number of rooms left to spawn from the floor generator to the room. This happens when the room is deemed a successful spawn. Using the random stream alone was leading to this weird homogenous lighting problem, so at the beginning of the function, we do this now:

Creating a new random stream for each room

For those unfamiliar with what this means, a seed is essentially just a random number that indicates a particular random generation. This is useful for games like this because it means that if the generator has a problem, a bug report need only contain the seed they were playing on and a few other pieces of information like the game version and floor level for me to go and check out that generation in particular, in order to try and fix the problem. This seed is used to create a “Random Stream”, which is essentially just an object that makes it so the flow of random numbers, while still random, are predictably random, in order to guarantee that same result every time the same seed is used. For some reason I’m not quite sure of, this wasn’t working for the lights, and it’s prompting me to go and double check some things this week, but the solution I came up with here was to break the stream, add the room left number to the seed, and make a new random stream from it. This means that effectively each room spawned has its own unique but still predictable random stream to use to determine the intensity of its own lights.

Now, onto what I did this week while procrastinating other systems.

A few weeks back, I was conducting a sort of impromptu playtest with one of my friends, essentially just sending him a copy of the game so that we could both load it up and make sure things were working properly, because there’s a handful of things in this game that I simply can’t test on my own, like voice chat. After we played for a little bit, one of the things he brought up as something that felt weird about the game was the lack of sounds, and I was inclined to agree. This week, as you may have heard in the clip above, I finally rectified the lack of footsteps in the game. I did this using the new MetaSounds feature in Unreal Engine 5, which seems like a really cool and powerful sound system. I distracted myself further by doing one of the tutorials Epic has on their website for becoming familiar with the system, and it can synthesize sounds without an audio file to work with, which is really cool. I hope to in the future have some really dynamic sound systems in the game that can be used to really vary the ambience, sound effects, and music. Speaking of ambience, I’ve also dipped my toes into making some of my own for the game.

As many reading this already know (hello friends and family), I have a pretty extensive background in music, having been playing instruments for a large majority of my life. I figured, “why not try and put that to work here?”. So I plugged my bass guitar into my audio interface, booted up FL Studio and crushed it with a lot of reverb. Here’s the result:

The reverb is definitely doing a lot of the heavy lifting here, but I think it fits the vibe I’m going for fairly well. I don’t necessarily wanna have a lot of actual music in the level as that might take away from the spooky vibe, but stuff like this is definitely worth looking out for. Right now, this music plays once when the elevator doors open, so it’s not terribly dynamic, but it’s enough to get the idea across while I’m still in this early stage. That along with some of the textures I grabbed off the internet are definitely helping to sell this game as an at least horror-adjacent genre, which is good!

Expect more bug fixes in the next week as well as potentially the completion of the game loop as well as the first versions of an inventory system!