On the other hand, UE4 has also been somewhat stripped of “default” content in order to emphasize the user-generated content located on Epic’s new marketplace. This tutorial series is designed to bring you up to speed on UE4 level-design by showing you how blueprints work and how you can create your very own blueprint building-blocks.
The Blueprint system is a visual scripting language central to all game interaction in UE4.
Blueprints come in two flavors: Level blueprints and Class blueprints. Level blueprints are attached to your level, whereas Class blueprints are self-contained templates for a single type of object in your level (a “class”) only. Anything you do in a Level blueprint can also be done in a Class blueprint, but Level blueprints additionally enable you to set up communication between multiple Class blueprints.
Let’s take a look at what actually goes on inside these blueprints.
Let’s start with the two basic blueprint nodes: Functions and Variables. Variables can be explained as containers of object data, while functions essentially perform game logic upon variables.
The next section will cover these nodes in more detail.
A Player variable with a Jump function. As illustrated, executing the function (f) causes the player to jump
Object Data (Actors and Variables)
Although they are very versatile, variables are most commonly used to control actors, objects that exist inside the game world. Characters, weapons, doors, switches are all examples of actors. Additionally, every actor’s variables can potentially be manipulated by functions, for example the health of a character stored as an integer value.
A actor variable (player) with health and position stored as an integer variable (green) and a 3D-vector variable (yellow), respectively
Actors can also contain components: other actors incorporated inside the main actor. This enables static meshes to have component collision boxes, or to be paired with component particle effects, among other things.
The components of this door object are two meshes (a door and a doorframe) and a collision box that helps control the door’s physics behavior
Functions are nodes of logic which can be executed (called) to perform a certain task. If something needs to take place in-game, such as a player picking up a weapon, functions can enable as well as add additional consequences to that action.
A function execution string (the white line)
Functions present and modify variable information. For example, a function which acts upon information gathered by a variable could teleport players to specific game-world coordinates. A ‘getter’ or ‘pure’ function, on the other hand, merely relays information for use elsewhere, such as reporting a player’s current coordinates in the game world.
A ‘pure’ function (green). Notice that ‘pure’ functions do not have independent execution, only when linked with a regular function (blue) does this particular function have effect
So, we’ve covered Variables and Functions. But how does the Blueprint system know how and when to react to incidents inside the game world?
Events allow different actors to communicate with each other. For instance, an event controls when an actor collides with another actor, or what an actor should do if a collision actually occurs. More examples of an event are a door opening as a character nears it, a switch being thrown, or a barrel exploding after it has taken sufficient damage. An example of an event could even be as fundamental as a player using controls to move their character model. Customized events can be called much in the same way a function would be.
Event (red) called if an actor is hit. The event triggers a function linked to taking damage. This example is intended for learning purposes, not for practical use
Quick aside: In general, as a good practice, variables, functions and events should be named for their exact purpose. This helps both you and others read what’s going on in your blueprints. An actor named “player”, or an integer named “health” is easier to understand than one named “asdhjkashdj”!
For more information on variables, functions and events, please refer to Epic Games’ own documentation, which provides encyclopedic knowledge about the topic.
Now that we understand the building blocks of UE4’s Blueprint system, let’s look at a practical example: the Class blueprint of a sliding door (If you want to create your own sliding door, I recommend taking a close look at Epic’s in-depth guide.
When a player gets close to it, the door opens. When a player leaves the door’s vicinity, it closes. Let’s examine the door’s blueprinting:
You can see that the door actor is composed of several components: a frame object, a door object and a triggering box
In this image, we can clearly see the nodes used to trigger the door’s opening and closing. For example, the event OnComponentBeginOverlap triggers once a player steps into the Box component actor listed. That triggered event starts executing anything along the execution logic path, such as the Timeline function and the Set Relative Location function.
The Timeline function changes an integer with decimals - the Driver float variable – between 0.0 and 1.0 over time, and sends execution updates every time the float changes. The float variable is called Driver in this case, because it drives the door to either open or close. The Lerp function’s Alpha parameter then uses this float value to determine the exact position of the door between being open (float value of 1.0) and closed (float value of 0.0). The Vector variables Door Closed Position and Door Open Position are end points for Alpha to blend between. This is to ensure that the door opens and closes smoothly over time rather than instantly.
Set Relative Location then executes the data received from the Lerp at intervals put forward by the Timeline’s update execution for the door that we use. The result is a door which slides opens when players are nearby.
Lastly, our OnEndComponentOverlap event triggers the closing of the door by reversing its operation when players leave the triggering box.
Here you can see our moving door in action:
To be fair, this case study is a bit over-simplified in order to provide an example that can be easily understood. The real version of this door (which will be shown in the next part of this series) is a bit more advanced, but its core principles are exactly the same.
So far, we’ve covered the structure of variables, functions, events, as well as a common gameplay element like a sliding door. In the part two of this tutorial series, we’ll learn some more advanced blueprint features, such as class recognition, level blueprints and blueprint communication.
Thanks for reading!