Building A Note Reading System In Unreal Engine 4 (Part 2)

Hello and welcome back to my journey in creating a note reading system in Unreal Engine 4. This is the second part to the first blog post, if you haven’t read the first you should do that to get the full picture.

In the first part of this post, I covered how I went about making a system where the player would get prompted to read a note when they were close to it, how hitting the E key would bring it up to the players screen, how hitting the E key again would remove the note from the screen and how it would be automatically removed from the screen if the player went too far. I had also stated that I had trouble making a functioning prompt message. My issue was that the prompt message would not go away even after we specifically added the “Remove From Parent” node on the widget when the player overlap ended with the note’s box collision. In this blog post, I will go through how I was able to solve the prompt not disappearing, as well as how I went about creating multiple notes that display different things. For latter topic, we will be discussing parent and child blueprint classes.

The solution to the prompt problem is actually simple, but not the best solution. The node I am using is the Remove All Widgets node instead of the Remove From Parent node. When ever the player leaves the box collision that is on the note, all widgets from the screen get removed.

How the Remove All Widgets node is implemented in the Note blueprint

This isn’t a great solution because obviously, if you are making a game with more than just the note widget on screen, the Remove From Parent node will also remove those widgets and not just the note. I will be looking into finding a better way but for now, this is how it’s implemented.

Now onto parent and child blueprints. If you know anything about Object-Oriented Programming, you know about parent and child classes. A parent class could be a vehicle, and a child class could be a car, truck or motorcycle. These child classes all inherit things from the parents, they have wheels, engines, steering wheels and more. They also have attributes that are special to them. Parent classes can provide a base for the child classes, this helps in reusing code and organization. In my case, I used parent and child classes for the notes in my project. The parent note has the all of the collision events set, the only difference in the child classes is that they add different widgets to the viewport because they are different notes. Different notes have different information that they provide. So for example note #1 will add widget #1 to the view port, note #2 will add widget #2 to the viewport and so on.

With child classes, you can also change how it looks in the viewport, without re building the entire thing. For example, I have 3 notes in my project so far, and they all have an outer glow. In this case, I also had to create material instances of my initial glow material to create different coloured glows. Material instances are similar to having a parent material, and a child material which is the instance. This helps us reuse “code” and help improve engine performance.

The parent material and it’s instances. In this case the parent material is mistakenly named “BlueGlow”.

The parent note class and it’s children. You can see how notes 2 and 3 have a different coloured glow to them thanks for parent and child classes, as well as material instances.

That’s it from me this week. I am going to be tackling a projectile based first person shooting system next. My plan is to combine my note reading system with the shooting system I will make and create my first project/demo. Thanks for reading.

Saarim