Devlog #4: The Finale

It is now the final week. We are now doing final touches, crossing the t’s and dotting the i’s. The game, after being uncooperative and stubborn for a while has finally been built and I am now just making sure I have all the required documentation for submission. 

Overall, I am pleased with how the game turned out and how I have developed as a games programmer during this term. Working cooperatively was challenging but enjoyable. It’s a double-edged sword when you have to rely on others and vice versa, but when it works out and everyone is doing their part, it is very effective. 

The save system was implemented well. To create it, firstly a blueprint was created simply to store an array of variables. Then, in the game instance, a ‘SaveGame’ event was added to check if there is a save game object in the slot, that we are presently in, if not, a new one is created. In the player blueprint, a function was then added to overwrite the variables in the instance and is called whenever the game is saved. Next in a macro, a plethora of variables is set (current health, ammo, player position, etc) and is saved to the game slot. 

The next event was ‘LoadGame’ which loaded the game from the slot name, which was akin to the save game event, but instead of writing to the save file, it reads the date from it and sets the data to each of the variables. Another similar event was added to load the player data, which is used when the level changes, to ensure it is not trying to read the level at the same time, to prevent a loop and an inevitable crash. Finally, a widget was created from the main menu which contained a new game or a continue game button. The load game button was linked to an ‘on clicked’ event and the ‘LoadGame’ method is called.

For procedural generation, we added two different systems. The first was a randomisation of footstep sounds. Essentially, an array of sixteen footsteps sounds were connected to a randomiser node which randomised the output. Next, was the implementation of rocky terrain through procedural generation, where we used a variety of rock assets from quixel bridge and generated them randomly in Unreal’s PCG volume. 

With the amount of voxels and cubes to render, we used Nanite to alleviate some of the stress on the GPU.  Nanite uses Cluster-Culling, which divides the mesh into clusters. This makes it so that only what is visible on the screen is rendered. It also integrates Level of Detail which changes the detail of the mesh depending on camera distance. 

There are, however, some things that could be improved on for the next term. For one, time management. Until around the 10th week, I thought I was doing pretty well. But then I realised that there were many small things here and there that I hadn’t done yet (death screen, arrow count, etc) Furthermore, on two occasions I started duplicating the base enemy blueprint too early before it was done. The first time I ended up deleting all the new enemies I had created because I had forgotten to add a major function or system in the base enemy blueprint. The second time, I started duplicating the base enemy before I had a functioning ‘death’ sequence. This time around, I just manually added it to each enemy type. 

I also realised after the game was built that I had a massive oversight. I forgot to make a condition to check if the enemy is even close enough to attack the player, so the player will take damage out of nowhere sometimes. These problems definitely could’ve been mitigated with some more planning before I started. 

Overall, I am content with how the game turned out. We have the required systems, it has a beginning and an end, and boy does it look nice.