Are Unreal Engine blueprints no-code?

Be warned: “visual scripting” is about “visual” AND “scripting”!

This article is also available on Medium.

Everyone can cook!

That’s what chef Gusteau says in the famous Pixar movie Ratatouille to remind the other characters that a legend can rise from anywhere.

Nowadays, we seem to be in the “Everyone can code!” mantra. The trend for no-code tools keeps on growing and we are seeing the birth of new automation solutions in all industries. It’s all about giving a way to citizen developers to make their ideas a reality, even if they’re not expert coders.

Unreal Engine’s logo

But what about tools that look like no-code but aren’t? In my opinion, a great example in that category is Unreal Engine’s blueprint system. At first glance (and if you look at some Youtube tutorial titles…), you might get the impression that these blueprints are a way to create a game without coding:

Screenshot from a DevSquad’s tutorial on Unreal Engine 4 Blueprints (https://www.youtube.com/watch?v=BVpy7kvz_yg)

That sounds amazing right? Think of the thousands of people that grew up with video games and dreamt of one day creating one with their bare hands — now they can, no matter their background in dev! All they have to do is plug in connectors into nodes and that will eventually create a full-fledged game with physics, AI, UI, etc.

Hum — wait. Is that really true? Is it actually possible? Can you create a game without coding?

Epic themselves don’t pretend to provide a “no-code tool”: in the Unreal Engine docs, they talk about “visual scripting” and “gameplay scripting […] using a node-based interface”. Scripting, meaning coding. Basically, the team offers us another way of producing code, except that you don’t write it but you drag-and-drop it. And it’s worth noting that they consider that blueprints may be for designers but are still mainly for programmers.

Big disclaimer: for game dev, I have way less experience using Unreal Engine than Unity. So if I make some accusations that are completely obsolete or overthrown by a feature I’m not aware of, feel free to tell me in the comments! 😉

Visual scripting, what’s that?

The most common way to develop a program is to open up some code editor and to write a bunch of lines of code in a given programming language. Then, depending on the language, you’ll either compile your code to binary and run it, or directly give it to an interpreter.

All that is to say — programming is, in the head of most devs (myself included), about writing.

UE blueprints put a different spin on this. Rather than writing lines of code, you connect together nodes in an event graph that each represent a little bit of logic; and the entire graph is roughly equivalent to a C++/C# class. You pick those nodes from a list of nodes that have been prepared beforehand by Epic’s team. They’re like LEGO bricks: you have a bag with red 2×2, blue 4×1, yellow 4×8… and with all of this, you should be able to build some evolved logic that is complex enough to power an actual video game or simulation.

Here is an example of a little graph that moves a cube forward on the x-axis continuously, every time the update loop (aka the “tick event” in UE) is called:

A simple UE blueprint event graph to move a cube along the x-axis at every update loop call. (Image by the author)

As you can see, the logic is pretty human-readable — we see, from left to right that:

  • the event tick is the root trigger
  • at the bottom left, we get the mass of our cube
  • then we have our speed value that is multiplied by the “delta seconds” to normalize the results across computers
  • we multiply the mass with this new float value
  • and the final computation result is passed to the impulse node along with the cube actor: this node will ultimately use UE physics engine to move the cube

The advantage of this representation is that node names are pretty straight-forward and the node-based visualization is intuitive to most people. Moreover, the power of UE blueprints comes from all the logic that is shipped in the ready-made nodes: you can easily access some 3D object position, teleport it somewhere else, make a camera follow a target with a bit of delay, take some user input and pass it to your physics force system…

The visualization tools (like variable type-dependent colors, auto-alignment, snapping, etc.) help with actually managing all those nodes, since a complex mechanism might result in quite a lot of nodes on your screen.

Because of this somewhat intuitive access to various parameters of your game, visual scripting is often presented as a better alternative to hand-writing code when you want efficient and beneficial interactions between the programmers and the designers or artists in your team.

Bonus: it’s pretty in a tutorial! This might seem like a silly thing to say, but attractiveness and shiny looks can be a selling point for some undecided people that don’t know how to choose between Unreal Engine and, say, it’s competitor Unity.

But is it really coding?

When I first took a look at some tutorials on the Internet, my dev brain had some of a dismissive snort — come on, this is not coding! This is just playing around!

And then, I actually sat down and tried it for an afternoon. Truth is, I was pretty surprised with my conclusions at the end of the day. I did confirm some of my expectations, but I also discovered a few things. In particular, I realized that blueprints are clearly not for non-programmers. Or more precisely, I strongly believe non-programmers will struggle with and perhaps even mislearn from this system.

Please, all UE fans, wait for a second before reacting in the comments! Let me explain…

I am not saying that only expert programmers with 12 years of experience should use UE blueprints. I am not saying that amateurs won’t make anything good — with all the resources on the Internet (tutorials, docs, etc.) you have plenty of pointers to help you create a completely valid and robust project.

My grudge here is against presenting people these blueprints as a replacement to coding altogether. Before I said that coding was about writing lines of code. That’s only half the truth… because coding is a mindset. That’s why even non-professional developers can be regarded as “real coders” if they’ve spent time learning the fundamentals and understanding the mental frameworks.

From my point of view, UE blueprints require you to have this mindset and, in fact, to already have some programming reflexes. Think of my previous graph example: could you intuitively create this from scratch, or even understand someone showing it to you, if you had no idea what a variable was? Or how 3D positions are represented via Vector3 with an x, y and z components? Or that we have things called events that can trigger actions in a code?

My personal experience with blueprints is that to understand what you’re doing you need to have done some programming before. Creating a blueprint is about sketching up the entire logic of a script and, at the very end, replacing the “writing characters to make words” part by a “dragging nodes to make graphs”. Yet this ability to conceive an architecture, to design the logic and the interconnections between your game components, is the true skill of programmers.

So yeah — UE blueprints are “real code”!

Some no-code issues

However I think that, despite how powerful this system can be when used right, UE blueprints still suffer from some flaws that are also present in no-code tools.

Black box issues

For example, you sort of have the “black box issue” that is well-known in AI and is also a big deal-breaker for many devs when they’re presented automation software. It happens whenever you’re using a system as a blind consumer: you enter the data you want in the expected format in the input, you watch the box rumble for a while and you get your result at the other end with no idea whatsoever how it was computed.

The black box issue is closely tied to control and regulation: if you can’t tell how something work, you can’t insure it works properly. It might completely fail in a rare case that hasn’t been cared for, or simply behave a bit differently from the initial specifications, without no one being able to notice.

In UE, when you do your blueprints, you import the nodes that have been prepared by the Epic team. The problem is that we don’t know precisely how the whole system works under the hood, and more importantly we don’t have any say in it. We play with the neatly prepared LEGO bricks, we plug things in and spit things out, but we don’t see the inner workings of the bricks themselves. Although we have access to UE’s source code, the project is not open-source — the UE community is not taking part in the development of the engine and there is a complete centralization of decisions and roadmaps at Epic.

Note: also, as a UE beginner, you’re going to have to swift through pages and pages of docs, and you’ll need to learn a lot of node names before you can actually do something interesting. Because plenty of things are ready-made, you did not pick the name, thus you don’t know it initially… For example, the first time I tried blueprints, I spent a while searching for an if/else before eventually finding it’s called “Branch”. This is valid from a computer science point of view, but not very intuitive with my background as a programmer!

We are therefore depending fully on Epic to write satisfying functional nodes. (You can of course switch to C++ and create custom nodes but, then, you’re out of the “blueprint scope”.) And Epic is expecting the users to “guess” and “learn by themselves” how things work because, sadly, UE docs aren’t always up to speed or readable enough.

One solution to rule them all

Also, because of this centralization, the black box problem is actually combined with the “one-way-is-enough” philosophy. Like in most no-code tools, UE blueprints don’t let you choose how nodes behave. I think that’s the limit with my LEGO analogy: here, you are given a box of LEGO bricks that are meant to be used in a particular way, and this way only, and you have to adapt your project to their behavior. Now, to be honest, having a hundred possible manners of writing the exact same snippet of code can be a pain to, and I’ll just quote The Zen of Python, for its 13th rule:

There should be one– and preferably only one –obvious way to do it.

Note: by the way, did you know that the reverse philosophy also exists: “There’s more than one way to do it”? 😉

Still, I feel like no-code solutions (and UE blueprints) are going at the far end of the spectrum by offering a universal but highly constrained workflow. You either play along and follow the rules of the engine creators, or you won’t be able to do anything with the blueprints.

I like to organize code in my own way and to decide what my functions takes as an input and produces as an output; perhaps because of my experience on Unity, I prefer building everything (almost) from scratch so I know how it ticks and I can more easily debug it when it goes wrong.

Node-based visualization is pretty… but slow to use!

My final critic to UE blueprints is very subjective — but as a developer, I usually find that graphical interfaces are way slower to use than pure text writing. As an example, just look at this graph:

(Image by the author)

Can you tell what it does? It’s a for-loop. It simply iterates over an array of string, Names(making sure to break if it’s reached the end) and looks for a specific value, stored in a variable called MyName. In the end, depending on whether it found the string or not, it prints something different in the console. True, I’m not the most proficient UE blueprinter around; but I spent over 3 minutes building this.

Now, I know I am biased after years of programming in various languages. But isn’t it just faster (and actually more readable) to have some C# code saying that?

for (int i = 0; i < Names.Length; i++) {
  if (Names[i] == MyName) {
    Debug.Log("Found my name!");
    break;
  }
  if (i == Names.Length - 1) {
    Debug.Log("Reached the end :(");
  }
}

And even in C++ (which UE uses for its “classic” coding) a for-loop is, in my opinion, written quicker than this graph is made. It took me roughly 30 seconds to write this snippet of code (mostly because I’m not used to PascalCas ing variables but wanted to match my blueprint conventions).

One might say that, at first, this piece of code is frightening because you have all those weird words: for , break , Debug.Log() … But it’s just as true with the graph. If you don’t know what a “For Each Loop with Break” is, or that you should use the “Print String” node to debug, you won’t get far. So this makes the case for my previous affirmation that blueprints are made for programmers (or programmer-like-thinkers).

Note: to some extent, I think the blueprint is even more complicated than the code snippet here because the “break” is an event that you have to define yourself, call when needed and pass to the for-each node, whereas most programming languages have some sort of break statement natively that is automatically linked to the current scope. On the other hand, this setup lets you break out of nested loops, which is always a pain in “normal” code…

Conclusion

First of all, this article is by no means a critic of Unreal Engine and its blueprints system — I think it’s a great tool that probably helped lots of people enter the world of game dev, which is great!

But I believe its “user-friendliness” and “ease-of-use” should be taken with a grain of salt: yes, it’s quite easy to use the given nodes to interact with the input system and the physics engine, but it’s very easy to create convoluted and unoptimized logic too! My guess is programmers are the kind of people who’ll make the most of this tool… although they might get frustrated by the constraints, the imposed codebase organization, the necessity to know node names by heart or the slow drag-and-dropping.

I’ve tried it and it’s not a tool for me, partly for those reasons. My personal belief is that your tools should adapt to you, not the other way around. In that sense, UE blueprints show some similarities with no-code tools. However, taking a step back, we clearly see that blueprints are another way of programming and they require you to have, at least, the mindset of a coder.

There is a lot more to say about UE blueprints and I could go on for hours neat-picking about differences between Unity and Unreal Engine.

But I wanted to talk about this because Unity is now also offering a visual scripting feature in its 2021.1 version — only this time, it’s specifically branded as a tool for “non-programmers”, which I find this “risky”, in terms of public communication and awareness. As I’ve mentioned in other articles, more and more people are getting involved in the world of tech and software is now a powerful tool in our modern societies. And as a broader audience wants to enter the community of coding, they shouldn’t be fed a false image of what it is. I’m wondering whether this plug-and-play approach of development is not abstracting away too much — will the devs who learnt solely with these visual scripting tools internalize all the underlying logic and mental frameworks that are essential to creating robust and optimized architectures?

Time will tell…

Leave a Reply

Your email address will not be published. Required fields are marked *