Killer in Purple

As you can see, the main improvement here is making 1 base class. The base class just has an integer, which gets added onto the current score, which is now saved as an integer, and not a string. Also the loop that adds to the score is gone, to increase CPU performance.

Every suit is a child class of this main suit class, meaning if there is a bug with the suit, it only takes 1 minute to fix, instead of 30 minutes.

To fix the issue with the CPU bottleneck, I made a separate collision channel in the Project Settings, so that cameras would only check for the Player Collision and for the Children Collision, this was perfect as it would never check useless things like walls, parents and other props.

Also the casting to all the players is gone due to the object oriented Player, instead I only have to cast to the base class (William_BP). When the player enters the camera view, it will continue checking over and over if they are holding the knife, and once they leave the camera view, it will stop.

The solution to this problem is simple, we just want to check if the player interacts with the elevator, a keypress with F is definitely possible, but this is 1 of the only places in the game using F as an interaction key. So I switched the system out with Interaction by Left Mouse button. This solves all the issues the Elevator had with being active when the player is not around.

To solve the music issue, it's quite simple, since I do not want bloated code for this, all I have to do is remove the code, and just simply leave only the audio. With a simple Audio visualizer I coded, I was able to only put sound in the level. This works extremely well, and even has smooth transitions between levels.

The entire Load function is now replaced with this small load function, that returns the Save Object instead of all the data in it, meaning I can re-use it. Also the game doesn't load at runtime anymore. It now loads once from the save file, and stores it in the Game Instance. Once the player beats this play-session, their score is then updated in the Game Instance.

Once the player quits the entire game in the mainmenu, the Game Instance data is then saved in the Save File.

However there is a slight issue still with this system. Currently the data is still split up, so the Save function is still massive just like the old system. To reduce this size, it would be better to use a Struct and save that. That way you don't have to update the save function every time you add a variable to the save.

Now as you can see, the code of v3.0 is MUCH bigger than v2.0.4, but that is only cause I added more stuff like VR Support, and I also implemented some code into the Player that was in random places it shouldn't be before.

But overall, now all the code for all the players is in 1 class (William_BP), and all the players that are not William, are just subclasses of him, with the same code. This means I can always just cast only to William_BP.

For a comparison, when adding Burntrap to the game, it took me 2 days to implement him fully with all the other Blueprints, and I still forgot things, which had to be patched later.

The new system costs me a maximum of 1 hour to implement a new character, this mostly due to the ability, model and sounds, but code wise it is quite easy.