Official Blueprint shortcomings compared to code

Hey guys!
I’m currently in research mode for my Bachelors thesis in Game Design. I am analysing the capabilities and shortcomings of Unreal Blueprints but I haven’t found anything specific enough for me to use.
Is there any official article / blog post / documentation about the shortcomings of Blueprints compared to code and maybe even reasons for these shortcomings?

I know for example that it is not possible to overload functions in Blueprints. Searching the source code or google will tell me that (correct me if I’m wrong here) Blueprint functions are called by name only and thus it is not possible to overload them.

But I can’t find any official statement about it and additionally I can’t search through the whole source code just to try and find possible shortcomings.

If someone knows something or someone that would be greatly appreciated.
Thanks in advance!


I just found this, which is indeed helpful. But I am still missing reasons as to why certain features are not (yet) available which can probably only be answered by Epic developers.

There are two shortcomings that I know of when it comes to Blueprints.

First one is that blueprints runs 60% slower than C++. (Epic has already acknowledged this)

Second one is that your blueprint files are binary files and they can get into a corrupted state if you have a bad design in your code. This won’t happen all the time, but it can happen if you use the Tick event in a bad way. Because they are binary files you can’t manually modify the blueprint files to remove the codes that were recently added that started crashing the UE4 editor. See my question here about my recent blueprint corruption, I also linked to a youtube video that i put together for Sean Flint to explain the issue and how I got around it. Crash :: Access violation - code c0000005 after opening PlayerController - Blueprint - Epic Developer Community Forums

Two of the most annoying things about Blueprint for me next to the corruption that elitereloaded mentioned are its exponential complexity & the dumbed down API. When first starting out with UE4 all I programmed in was Blueprint & I tried to do very intricate stuff with it. Unfortunately if you don’t keep your code branch-free the complexity will raise exponentially & after a short while you won’t find ins & outs to it, even despite breaking everything up using classes, methods & macros.

The latter is the fact that Blueprint hides key functionality like quaternions away by default & they are the only way to do rotations right. You just don’t get Gimbal locks with them & they always behave as expected provided the code is right. Unity does all of its rotations using quaternions now. I guess Epic left rotators in for legacy & simplicity, because they are supposedly easier to understand than quaternions. Honestly, as a programmer all you need to know about the quaternion as a concept is that it’s just an axis of rotation provided with an angle of rotation, that all of it is normalized and that to combine them you need to multiply them. You need not be concerned with all the heavy compex number magic that goes underneath as UE4 does all of it for you anyway.

I’ve since moved onto C++ & only ever looked back at Blueprint for the data driven programming, occasional convenience & when writing plugins, but then again it’s just the functions & methods that I expose myself.

In practice overloading Blueprint functions actually works. Try it out for yourself: create a base class with a method & a bunch of children each with its own overloaded version of that method, create instances & put them in an array, then loop the array calling the functions: you will get a method call that’s own to a child every single time.

EDIT: I’ll add to what Mike Prinke & Jeremy Choo said on Quora.

  • “Ability to hide code you don’t want people messing with.” - BP actually has access specifiers just like C++, so I have no idea what he’s talking about.
  • The supposed absence of TMap, it’s actually present in a very simple form in BP to date & Epic are planning to expand it in the future.
  • “No custom movement components at all.” - again, not sure what he means, I was able to subclass movement component just fine in BP, maybe it’s the latest v4.14 feature?

Epic talk about BP performance here & it’s supposed to be 12x slower than C++ (worst case), that was a year ago though, not sure if they made BP faster in the meanwhile.

Hi. Mike here. Funny the places I end up showing up.

To address the latter two points: those were addressed by versions of Unreal which were released after I’d written this answer. As time goes on I suspect it will become, much to my personal enjoyment, increasingly inaccurate.

To address the point about hiding code: BP has access specifiers, but this doesn’t really hide code from designers. They can totally open up your functions, meddle with them, and change access specifiers if they choose. Creating foundational classes in C++ puts an added layer of distance between programming and design that I’ve found extremely helpful, but your mileage may vary. This is admittedly a stylistic advantage in workflow rather than an intrinsic technical advantage, but one I find to be important.