Blueprints are intended to solve a common problem:
- I have a C++ object (a dog, a door, a vehicle, a lamp, …)
- I need to re-use this object with small changes in various parts of the game
- I may want to change the mesh or animations for the dog
- I may want to change how injured a dog needs to be to attack, or run away
- I may need to change how fast a door opens
- I may need to change what triggers the door to open
- I may need to change the color of the lamp
- I may need to wire up an on/off switch for the lamp
- and so forth
You can make blueprints without any execution code in them; just override the base object with new meshes, new colors, new tuning values. This is a common and legitimate thing to do.
But, it turns out, some customizations like this really do want a bit of code. “Is the player strong enough to open this door?” “Does the lamp ramp up and flicker when turned on when power isn’t strong in the building?” “Does this car play occasional backfire particle and sound systems?”
For these simple behavioral configurations, we have Blueprint Scripting. As long as you don’t do scary math or iterate over many sub-objects, perhaps every tick, then Blueprint Scripting won’t show up in your performance profile, but it still provides a lot of value to AAA, C+±based developers.
When you get started with Unreal Engine, you may write a lot of “code” in Blueprint. That’s fine – it’s a great way to learn the engine. As long as you don’t try to push the limits, or ship on restricted systems (like the Nintendo Switch,) then your game will probably be just fine, even though Blueprints aren’t CPU speed demons. Only if your game starts bogging down, would you need to move the heavy bits to C++. And, for most indie development, that point never comes. Or, if it comes, it would bog down in C++, too, because the problem is algorithmic, not CPU cycle performance.
Experienced developers know what parts will need the performance, and go to C++ early. For the cases where you chose wrong, the good news is that converting a blueprint function or even full class to C++ is much easier than writing that C++ class from scratch – you already did all the hard work (figure out how it should work,) and now you just need to write out some properties and functions / methods. That’s almost mechanical, and shouldn’t take very much time.
So, no, Blueprints aren’t dead, and blueprints don’t require nativization to be quite valuable in game development.