TIL: Learn to Code in C++ by Developing Your First Game (Section 3, Lectures 89-93)

Alright! This marks the end of me working through Section 3 of this tutorial series. I feel like I’m learning a good deal going through this course. It’s certainly helping me feel more comfortable with UE as I peek under the hood. Looking forward to the next section. I would have liked to have seen a little more effort on optimization in this section, but I imagine Ben needs to leave something to teach in the next section ๐Ÿ˜‰

Section: 3 – Building Escape – Your First Unreal / C++ Game

Lecture 89: Using Blueprint Timeline

Timeline nodes are special nodes within Blueprints that allow for simple time-based animation to be quickly designed and played back based on in-game events. Timelines are somewhat like simple Matinee sequences in that they allow simple values to be animated and events to be fired off over time. These can be edited directly inside the Blueprint editor by Double-clicking on the Timeline in the Graph tab or in the My Blueprint tab. They are specifically built for handling simple, non-cinematic tasks such as opening doors, altering lights, or performing other time-centric manipulations to Actors within a scene.

I’ve got to admit, I’m not a coding pro. But I’ve heard from multiple sources that Timelines and any ticking behaviour is dangerous to have in blueprints due to the amount of wasted calculation that can happen. If you can do time based stuff in a material vs a blueprint do it as the GPU is faster and often less required than the CPU. I’m also under the impression that matinees are often better than Timelines, particularly with their ability to replicate for multiplayer.

So I go into this hoping to get some information, but also weary about optimization.

Things to be aware of:

    -Make sure that your timelines aren’t unnecessarily long. If your time is only 1 seconds, don’t make the timeline 5 seconds.
    -Use Last Keyframe? can automatically set the timeline to the length of your animation.
    -Plugging into the “Update” output means that it’s going to constantly feed information through the network. Bad.

Right now, it’s going to constantly feed information through, and it doesn’t resolve nicely to play a close animation either. We’ll need an event when we want to close the door to make this work, which gets created in the next video.

Lecture 90: Everything in its Place

It’s important to make sure that information gets kept in just one place for the sake of optimization.

It’s better to have the open angle parameter available on the blueprint so that the user can control the angle in UE4. There’s no point in hard coding it in the .h file as it just adds clutter to the code. While Ben seems content to leave it as an animation with a max value of -90 in his timeline, I prefer to set curves between values of 0 and 1. This lets me multiply against a value later that can be easily tweaked. So I create an editable, float, variable with a value of 90 and then multiply it with the results from the timeline.

Variable

    -Open Angle, Close Delay, and LastDoorOpenTime should be stripped from the code.
    -Since OpenDoor() only did OnOpenRequest.Broadcast(); there’s no point in having an entire method. Just move the broadcast into Tick.
    -If the door isn’t open, it must be closed.
    -ctrl r ctrl r to convert FOnOpenRequest to FDoorEvent
    -ctrl r ctrl r to convert OnOpenRequest to OnOpen
    -Set-up the close the same as the open.

…. and at 10:50 in the video, as Ben says, it’s a little bad that we’re polling every frame for the status of our volume rather than using trigger events… but this is more of a proof of concept than anything else. Just keep in mind that this isn’t a fantastic method of doing things.

Lecture 91: Using Variables in Blueprint

The problem right now, is that we are setting the actor rotations and not making a relative rotation. It would be better to store our starting position and then add to it so that the door will work no matter which wall we put it on.

The set-up I used makes use of some branches and an extra boolean variable to help reduce the amount of data streaming through the blueprint. This is not how I advocate doing it… this if statement should definitely be done inside of the .cpp file so that the events we send are triggers and are not actually polling every frame. But this is at least a start and will reduce the work that the timeline is doing.

DoorOpenBranch

Lecture 92: SFX & Audio Clips

Ben uses audio clips from GamemasterAudio.

Pretty simple lesson, use the actor location combined with a play sound at location, and create an event inside the timeline. There was no sense of directionality coming from the audio, so a quick google search revealed that you need to attach an attenuation file, and your audio also needs to be mono instead of stereo. I can confirm that after making the audio mono, and adding attenuation, the lock both gets louder as you’re closer to the sound, and also will play predominantly from one ear or the other depending on the direction you are facing when the sound happens.

DoorLockAudio

Lecture 93: Section Wrap-Up

Whee! Done! I’ve got a pretty simple level right now. I don’t think what’s been taught so far would be the “right way” to go about it for a game… but it certainly clears up a lot of how the coding structure works. I’m eager to do more!