You Did Not Waste Your Time Learning Blueprints

What Blueprints Have Been Teaching You

Everyone has heard about Epic Games announcing the sunsetting of Blueprints in Unreal Engine 6. I don’t know if this will happen as announced or if it will change over the course of the next 3 years, but I do know that the anxiety around it is real.

For many, the idea that Blueprints are going away is scary and that fear is understandable. When you’ve finally found a system that clicks and that allows you to create what’s in your imagination, it’s hard to accept that it could just be taken away.

I still remember MIT releasing Scratch back in 2007 and watching 7-year-olds go from zero experience to making a narrative game in the course of a 3-hour workshop. That’s not something we could ever achieve in a C++ workshop. That is the power of a programming environment with a visual syntax, it removes friction and makes building systems like playing with toys. However simple and toy-like Scratch may feel, it still teaches real programming concepts.

Scratch logic example

My perspective is that the skills people have built with Blueprints are real, valuable and broadly applicable beyond Unreal Engine. With a little perspective, I think I can show that regardless of what happens in the future, your time spent in Blueprints was worthwhile. You haven’t just been dragging Blueprint nodes around, you’ve been secretly training.

Who Am I

Who is this coming from and why should you believe anything I have to say? There are generally two camps in this discussion:

  1. Experienced programmers. These are generally software engineers that have a CS background, program in multiple languages and are working on projects with multiple contributors. They’ve gone through the experience of shipping a product where Blueprints may have caused team concurrency, optimization and/or maintenance headaches. They’ve cursed in frustration that they have to wait 5 minutes to open the editor just to discover that the latest change in a Blueprint was a node moving 2 cm to the left.
  2. Visual thinkers, artists, designers, solo devs and beginners. These are generally people that want to make cool things, have little to no background in programming and that are delighted by the canvas that Blueprints provides them.

I’m someone with one foot in group #1 that regularly works side-by-side with people in group #2. I use C++. I use Blueprints. My job is often making iteration faster for artists while keeping a project shippable.

Shared Foundation

Were Blueprints a magic key that unlocked everything for you? Does the idea of losing Blueprints feel like someone is taking away your means to create? What if I told you that you are not as stuck as you think?

Blueprints are a programming environment with a unique visual syntax, however, the programming concepts that they use are not new or unique. These same concepts show up again and again across many programming languages.

While using Blueprints, you’ve been practicing Object Oriented Programming (OOP). In addition, you’ve been doing it in the most challenging programming context in the world, which is game development! Some other popular OOP languages you may recognize:

  • C++
  • C#
  • Java

You’ve been learning about data types, classes, inheritance, event handlers, functions, object construction, encapsulation, input handling, UI, the list goes on and on. You may not know the names of some of these, but you will be surprised to learn that you do understand many of the concepts because you’ve been doing them over and over.

Maybe you thought that Blueprints were some kind of programming unicorn, they are not. They are made up of the same 3 basic components that you find in traditional programming languages:

  1. Syntax
  2. Data
  3. Flow control
programming languages puzzle pieces

Painting the Fence

Programming languages are not that mysterious, let’s look at the two components that you’ve had the most exposure to and whose knowledge transfers most visibly: data and flow control.

Data

Basic Types

Question: What data type does this line represent?

Answer: Float

Question: What data type does this line represent?

Answer: Vector

You may know them by their colors, you may know them by name, you may know them by the operators that are regularly used on them. Since first dipping your toe into Blueprints, you’ve been learning the differences between floating point numbers, integers, booleans, and objects (like an Actor or a Player Controller).

Ever had a variable that stores another Blueprint actor? Well then you have been using the practical mental model behind pointers and references: The idea that a variable can store some other object and that this object might not be valid!

Pointers/references are historically a difficult concept to understand for new C and C++ programmers. It can be difficult to understand where and why you’d use a reference or a pointer at first, but you’ve just been, you know, using them for something that you needed to do.

Containers

You’ve no doubt dabbled with containers as well, where you select a float and you hit the dropdown that transforms it from a variable into an Array, Map or Set.

array example

Blueprint vs C++ Comparison

Let’s say you wanted to have a variable that stores the player’s health and you wanted it initialized to 100.0. In blueprints, that might look like this.

Here is what that looks like in C++:

float Health = 100.0f;

If you understand what a float is, the above statement is not that mysterious.

What if we wanted to cause damage and play a sound? Let’s look at the C++ version first this time:

Health = Health - DamageAmount;
UGameplayStatics::PlaySoundAtLocation(this, ImpactSound, GetActorLocation());

Here is what that might look like in Blueprints:

The point here is to show that even if you don’t know the syntax for C++, you can still understand the gist of what’s happening when you understand the data types involved.

Flow Control

The other pillar you’ve been learning is how to write logic to control the flow of your game:

Branch, For Each Loop, While Loop

If statements have been around since 1957 and if you’ve used Branch in Blueprints then you fundamentally understand how they work. These flow control primitives are found across all languages, some languages look a little prettier, but they all get the same job done.

if (Health <= 0.f)
{
	Die();
}

If you have used a Branch node then you understand the shape of that logic.

branch

My Worst Interview

My first paid Java gig was working on a cool android app. I was implementing camera SDKs, QR code libraries, and optimizing things in C++ using the NDK. I was a top performer, I was over-delivering, I felt competent and confident. Until… I attended a speed-dating job interview at a conference and the interviewer was all:

This java function has the keywordin front of it, what does that keyword do?

Uhh….. 😦 well now…. hmmm… I see that all the time 🤔 I…. don’t actually know…..😢

The point is that I had seen that keyword hundreds of times in my work and had always glossed over it, my IDE had always written that for me, it always worked, I never needed to change it. Therefore it never felt important to truly understand it.

We all miss things! A good tool sets sane defaults and hides the complexities that we don’t touch as often. There might be a lot of things that Blueprints have been hiding from you that are just a few clicks away, don’t feel bad if you haven’t paid attention to them up until now.

Time To Connect the Dots

The next step in your training is to be curious. Just because you don’t know the formal name for a concept, doesn’t mean that you do not have an understanding of it.

You haven’t been pretending this whole time, you’ve learned real programming concepts in a visual language. This might be a good time to poke around at some of the things in Blueprints that you’ve been accepting on autopilot. Doing so is going to make you a better Blueprint programmer and therefore a better programmer.

Whatever comes next, whether that’s switching engines, using a text-based language or keeping Blueprints alive-and-well with community supported contributions, continuing your learning will only make you more resilient.

With your background in Blueprints, wherever you go, you are bringing more with you than you think.

Call to Action

I wanted to provide a small call to action to help people do a self-audit. This isn’t a pop quiz. This isn’t a comprehensive list. You don’t need to grind through these. You don’t need to know all of the answers right now. These are given in the spirit of solidifying your Blueprint knowledge into generic programming concepts, pick one or two that make you curious.

Data

  • When would you use a Set instead of an Array?
  • What are the 4 primary operations that you can apply on sets? Do those operations exist in Blueprints?
  • Why do we call IsValid on Object types? When should we call this?
  • Why use a struct and what does struct stand for?
  • Why would you use an enum vs an integer?
  • What does passing a function value by reference mean?

Flow Control

  • What is a safe way to iterate through an array and remove entries from the array during the loop?
  • When is a good time to use a switch statement? What types of variables can you switch on?
  • What is the difference between a For Each Loop and a For Each Loop With Break?
  • What does a Flip Flop do?
  • What does a Gate do?

OOP

  • What is a class?
  • If you right-click a Blueprint asset and “create a child-blueprint”, what does this do? What is a child blueprint, who is the parent?
  • What happens when you set a Blueprint variable to private vs public?
  • If you right-click a function like BeginPlay and select “Add Call to Parent Function”, what does this node do? When would you use it?
  • What is Casting (Cast To) and why do you need it?
  • Why would you use a Blueprint interface?
  • What does it mean for a class to have good vs poor encapsulation?
  • What does Separation of Concerns (SoC) mean in the context of OOP?
  • What is loose coupling vs tight coupling?

Concepts

  • Over the lifetime of a project, what percentage of your time will you spend reading your code vs writing it? Should you optimize for readability or writability?
  • How can functions be used to increase the readability of your code?
  • What happens when you tick the const checkbox on a Blueprint function?
  • What is Top Down Stepwise Refinement
  • What is the DRY principle
  • Think about the function naming scheme VerbNoun vs NounVerb for function names. Which makes more sense? Which is easier to parse with your eyes? TakeDamage vs DamageTake SetPosition vs PositionSet
  • Think about the variable naming scheme PropertyThing vs ThingProperty MaximumHealth vs HealthMaximum CurrentHealth vs HealthCurrent
  • Read the Unreal Engine naming standard
  • Boolean math – what are the truth tables for AND, OR, NAND, NOR, NOT, XOR?

Help out! Drop a call to action that you think can help your blueprint friends level up.

Be the first to comment

Leave a Reply