Overview Of This Week

This week I maintained the development of my fundamental skills for the unreal engine.

As a minimum, I had to try and implement:
• A new input for the player – such as dashing or crouching
• A new actor that is spawned through the player – such as a fireball

Both these minimum requirements were completed this week with the actor being spawned through the player being completed last week already.

For stretch goals, I had to make:
• Something that overrides the controls from the player – such as a remote-controlled missile or a hot air balloon
• Something that reads an actor’s properties to output different actions – such as a coin sorter
• Something that drops “loot” when it’s destroyed – such as an enemy or a chest

Unluckily I was unable to complete these stretch goals this week but I made a few stretch goals of my own that I completed.

Blueprint Fundamentals

Compared to last week with following strict rules of what to follow, I used a more free flowing approach on what I might add in potential projects in the near future. The most simple features that I ended up adding where movement based mechanics. This included a sprint, crouch, jump and double jump into the movement of the playable character. The double jump was as simple as setting the maximum amount of jumps in the player movement component. Most of the events and functions were simple to find and implement. They will be shown below:

Extra Things I Have Learnt Or Problems I Have Solved This Week

Unreal Blueprints

• Whilst experimenting with different spells, I found out that there could be a parent blueprint class that the other child classes could share the functions and overwrite necessary variables and functions with. All the child classes shared the shooting of the parent class but things such as the look of the magic ball would be different as well as certain properties such as speed and potential damage to the enemy that is hit. The children and parent will be show below with the parent being highlighted in blue:

• Whilst experimenting with the child classes, I found a weird error in the log that would essentially say that there was a null reference to an object when the spell would be shot out. This is when I found out that I put a destroy actor function two times; once in the parent class and the second in the child class. By removing one of these destroy actor functions, the error would disappear in the log. The problem was solved as each spell would have a different amount of time before being destroyed compared to the parent class. Once the child class would be destroyed sooner than the parent class or vice versa, there would be no reference to destroy the spell actor.
• I also made the enemy take damage from the spells and even die if their health goes below a certain threshold. This script is held within the “Spell” parent blueprint. The image will be shown below:

Plans For Next Week

My main plans for next week will be to try to complete the stretch goals which have been set for this fundamentals task which are:

• Something that overrides the controls from the player – such as a remote-controlled missile or a hot air balloon
• Something that reads an actor’s properties to output different actions – such as a coin sorter
• Something that drops “loot” when it’s destroyed – such as an enemy or a chest