Unreal Blueprints Visual Scripting

Blueprints enable anyone to rapidly prototype and build playable content without touching a line of code. Use Blueprints to author level, object and gameplay behaviors, modify user interface, adjust input controls


Tutorial Videos


I've had the opportunity to use UE-4 for a few months and I can report a little more information:

The Blueprint runtime is currently implemented with an interpreter written in C++ - and so probably 1 or 2 orders of magnitude slower than C++. From what I can tell it wouldn't be too hard to generate C++ source code as an alternative, however, since the type system is essentially a subset of C++.

One-shot continuations, i.e Futures are supported (Unreal calls these "Latent actions"), which however have to be implemented in C++. The overall nomenclature is sadly C-like. They distinguish Blueprint "Functions" and "Macros". It seems Functions are callable from C++ and must return synchronously (can't contain "latent actions"), whereas Macros can only be called from their interpreter.

The Unreal Editor is almost certainly the coolest IDE every created. The blueprint editor itself is pretty cool, and is stable and usable (I haven't lost any work yet). Blueprint debugging, breakpoints, and watchpoints work. Auto-completion works well. Type-checking is decent - errors are placed on nodes in the graph as well as listed. Searching and navigation (find references) and refactoring (renaming) works reasonably well.

Although they don't have first class sum types, they do generate graphical "switch on X" nodes for C++ enumerations (which again have to be defined in C++ and with additional preprocessor boilerplate), which have outputs for each alternative. In addition, they have a "switch on String" node to which you can add cases in the editor. For product types, which are C++ structs that you must annotate with additional preprocessor boilerplate, they generate "break struct" nodes which have outputs for each factor.

Higher-order functions aren't supported. Concurrency aspects seem to be undocumented but the reality is obvious - blueprints aren't thread-safe and everything must occur on the main thread. Generics aren't supported in general in blueprints, however they are supported for arrays - which correspond to the Unreal C++ class template TArray<>.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I'm not sure if there is

I'm not sure if there is anything new here. It is a visual data flow language like Kismet (can we say it is just Kismet with a new name?).

Two things that might be novel:

It has a nice meta-game interface through construction scripts, which runs only during level editing.

It seems to be naturally distributed in client/server settings; blueprints and variables can be replicated on clients to locally handle cosmetic logic; events can be replicated to clients as a form of RPC.

Perhaps the biggest point of the language however, is that it seems pretty full featured.

Its not the novelty

It's not the novelty which is noteworthy, but rather the fact that no traditional textual programming language is provided - only Blueprints. Yes, I know C++ can be used - but Blueprints is expected to be used exclusively instead of higher level languages such as C#, Javascript, Lua, etc offered by other game engines.

I get that, but as you

I get that, but as you probably would agree level designers have been scripting in higher-level languages for awhile now. This language isn't meant for game programmers (as those not designing levels), who are still mostly stuck in C++ land working on components needed by those designers. So I don't see much difference, except the scripting language used by designers is now visual. As far as I can tell, this tool still not meant for programmers, meaning nothing has really changed in the VPL field where VPLs are great for people whose primary job is not to program.

Perhaps Tim Sweeney could chime in; he's been known to drop by occasionally.


My view is that you are a programmer if you write programs. If you can do other things as well such as create art or music, that doesn't make you a non-programmer. I'd rather construe what you refer to above as "programmers" as people who will tolerate low usability in programming languages due to politics and job-security considerations - that normal people would not.

It's interesting that Blueprints is statically typed - contrary to the perception that dynamically typed languages are "easier".

Now, I'd be more impressed if they had created Unreal-ed with itself, however I still find the extent of programming tasks that are being carried out with Blueprints rather remarkable.

Those who program are

Those who program are obviously programmers, but we have to distinguish between those whose primary skill is programming, and those who use programming as a tool. A designer has higher needs for usability because they have other skills they need to focus on (like...design). This is less true with a developer, who wants instead more power and flexibility and is willing to pay for that with more tool investment.

Even this isn't perfect though: programmers specialize also and they are obviously using programming as a tool, just a tool so hard to use that mastering it gives them the title "programmer."

My point about blueprints is that it is seems like it is making the same old trade off between usability and power, which is completely fine...we know this approach can work! So I look at the language features instead and try to find what's new and interesting. The contextual code completion is nice (I didn't see static typing, but they might need it to support that).

Differences between Blueprints and scripting languages?

I decided to revisit this thread after a friend showed me this recent post from Tim Sweeney, which basically argues against "scripting" and in favor of the "pure C++" code-base adopted for Unreal Engine 4 (which, to be clear, includes this Blueprint feature).

Sweeney lists several issues that arise from using embedded scripting languages, and which led them to drop their UnrealScript language. What I am having trouble understanding is why these same concerns don't immediately apply to Blueprint as well.

What might be the differences that make a visual scripting system like this preferable to a textual one, when measured against these concerns?


That was my original point exactly.

Another issue

Why would blueprints not be considered a DSL in itself? Heck, we even know how to encode dataflow languages as text, so is Tim Sweeney basically claiming that...its not worth maintaining a procedural language aside C++, so let's just go higher-level data flow declarative instead as URE's scripting story? He doesn't mention Blueprints at all in his post, so I'm just speculating.

One of the common reasons to support a scripting language in a game engine is to support live programming (or at least hot swapping) to have better turn in applying design...you get that with blueprints I think, and even hot swapping can be really hard to achieve with C++. And these advanced dynamic features are what tend to make interop hard, as you basically have to implement live enabling features (e.g. dynamic dependency tracking) there.

interop and debugging

I'm guessing (but I may have good guesses). When I look at Blueprint examples, the interface resembles a graphical PL I helped develop in '94, with boxes connected by lines, with inputs on the left and outputs on the right. It was dataflow with immutable lazy functional evaluation. Altering an input dirtied the dependents downstream, then recomputed any output value actually shown or consumed. I added oo support in dispatch by letting you graphically declare interfaces and conformance to interfaces, so anything with the same interface could be swapped-in provided covariance and contravariance was correct for types.

Sweeney lists several issues that arise from using embedded scripting languages, and which led them to drop their UnrealScript language. What I am having trouble understanding is why these same concerns don't immediately apply to Blueprint as well.

I noticed Blueprint examples start with an event as first input on the left, which implies immutable message passing is favored. This is important because it can be async. That matters because you are not building recursive call trees of synchronous C++ imperative execution, which would be hell on transitions between C++ and script stacks unless they shared a common runtime for stack representation.

I thought about the following quite a bit about fifteen years ago. Suppose you write a scripting language you call from C++, and you want to support stacks where scripts call C++ and vice versa in arbitrary nesting patterns. (Say you implement map using higher order functions, mixing C++ and scripts every which way.) Furthermore, you want any given script method to be able to execute in several forms, from byte-code to AST to JIT native code. In effect, a function pointer includes manner of execution in its type info. This would be hard unless C++ used the same stack calling conventions as every other variant. But C++ is very unfriendly to any other runtime beyond its own, so boundaries cause grief.

Issues Tim listed boil down to interop and debugging. Those would be made hard by call stack mismatch just noted. And then there's "impedance mismatch" (cf wikipedia on object-relational impedance mismatch), which folks used to say when describing model disagreement causing slow accumulation of conflict. For example, I'd expect very different memory management plans in C++ and a scripting language.



Added some additional information.