Killer in Purple 2

Enums are a great tool, but the way it was used here is not good. The main reason for that is that all the levels are combined within 1 level (besides the Pizzeria and some specific levels).

This was done to experiment with Level Streaming. However this just made everything messy and clunky as can be seen.

For v1.4 I completely re-designed this system, now, do note, not all functionalities are implemented yet, but every level is now separated again.

v1.4:

This is still quite temporary, but the system is much smaller, and it is not based on Enums anymore, making the process time, and code mess a lot simpler.

Door Highlight

As the interaction system for v1.3 was based on Enums, I also made the highlight based on Enums.

v1.3:

For v1.4 I also made this a lot cleaner by, again, not using an Enum, but instead just use a Text variable.

v1.4:

v1.4:

There are a couple issues with the v1.3 system which I had to address for v1.4:
- Memory Usage
- Categories
- ShopBase Actor

Memory Usage:

Firstly the Memory Usage. All the Shop Items were stored as hard class references. Then those classes had the Name, Cost, Description and Thumbnail stored for that shop item.

But the shop doesn't need anything besides that, it now also loads in meshes from those shop items, materials, textures, audio, etc.

V1.4 replaces this system with a shop manager, that has a list of structs. Within those structs are a Name, Description, Cost, Thumbnail and a Soft reference to the Actor Class. When you buy one of these items, it will load that class into memory and spawn it. Meaning nothing unnecessary is loaded into Memory when not needed.

Categories:

Categories have been almost the exact same since the Alphas, nothing much changed with them, as they seemed to work, but it used code duplication, where each category would cost more and more work.

v1.3 (Inside Shop):

To make this more reusable, and clean up some code from the Alphas, I decided to make a widget base class which does the exact same as the hard-coded category button.

v1.4 Category Button:

Shop Actors

Shop Actors were probably the biggest issues, cause I have both just props, and Animatronics. Props are a subclass of AActor, and Animatronics are a subclass of ACharacter.

But they still need the same implementation of code. Back when I first made this system (around v0.1) I had no clue how to solve this issue, so I just duplicated the code in the Animatronic Class.

However, this gets out of hand, cause the Shop needs to cast to both the ShopBase actor and the AnimatronicBase actor.

This caused loads of memory issues, flow issues and general code issues with sloppy code.

v1.4 has a simple fix for this... Components!

Instead of having the code in a ShopBase Actor, or an AnimatronicBase Actor, I made use of an ActorComponent, that implements all the code for placement, holograms, etc.

This component can be attached to ANYTHING, it can even be attached to the bird outside, and the behaviour of the Shop Placement and such will be added onto that.

This makes it extremely flexbible, and prevents me from casting to anything (besides the component) inside of the shop, making the shop completely separated from the rest of the game.

v1.4 Shop Component:

These couple small improvements, make a massive difference, going from unstructured code that took a while to maintain, to easily readable code that can be expanded infinitely.

The memory optimization is also crazy. going from 700MB (This was more in-game, as it could lead to GB's of Memory)...

v1.3:

Going to around 17MB, although some things like Goldie's Jumping animation and some optimizations in a Functions Library still need to be addressed.

1.4:

So for my school assignment in my 2nd year, I decided to go on a quest, to try and improve this system.

First things first was Research, so I sat down with a Game-Designer to work out what makes a good character creator.

After that, I also wanted to do some research with the target audience, that being all the players that had played Killer in Purple 2.

With a lot of feedback I was able to create a list of improvements, some positives about the v1.3 creator, and some extra ideas as well.

After a couple months of work, I came up with this system, it's similar to the old system, but it now locks your camera view, you can move around the character with your mouse (full 360 view) and you can easily save, load, or reset your current character.

System 2 (v1.1):

The second system only shows when the pizzeria opens / closes (At night it closes, and at morning it opens again). There is no further interaction to manually Open / Close your Pizzeria.

System 3 (v1.4):

The 3rd and last system that I have designed is a mix of the first two systems. The pizzeria automatically closes at night time, but you can now also manually open / close the pizzeria. If either Manual or Auto is set to closed it will close.

For v1.4 I decided to just completely re-code the Jukebox from scratch, as the code was just not reusable. I started by looking into other options to import audio, and found a Runtime Audio Importer that imports audio into the game. This system works a lot better compared to the old one, and is way more optimized and clean, with much more control and options.

v1.4:

The player has a lot of code in it, and with a lot, I mean too much. The player handles systems that it should not handle.

Let's go through it step by step, as this was a huge improvement from v1.3 to v1.4.

v1.3:

v1.3 (Shop - Collapsed Graph):

v1.3 (Build Menu - Collapsed Graph):

v1.3 (Input - Collapsed Graph):

v1.3 (Customize - Collapsed Graph):

As you can see, this is extremely messy, it handles too much, like Building the Pizzeria, the Shop, Customization, some input that is not needed. You can see the issue with maintaining this.

For v1.4 I started completely from scratch, just like the Jukebox. Currently a lot of old features are added, but not everything yet, so the blueprint is slightly smaller, but the Shop, Build System, Customization and a lot of Input is already coded in v1.4.

v1.4: