Hey dudes! So I’m aware that Blueprint is quite powerful and a few folks have actually created entire games using blueprint exclusively. However, if C++ can do everything Blueprint can, but with more control and performance, then why would someone well-learned in C++ ever utilize Blueprint?
One can say using Unreal’s C++ can take an exhausting amount of function calls just to perform simple tasks, but Blueprint can get pretty tedious as well.
To me, Blueprint is just catered for the artist who doesn’t have extensive programming experience. Is that it?
Well, while this is true in most cases, there are some circumstances where you would prefer using BP over C++ (for example, if you want to use Behaviour Tree, Animation Blueprints, etc.).
As @ already said, for me Blueprints just fit into the common workflow between Actors, Materials, Behaviour, Animation and so on. If I’m going to implement a simple logic, like a button which toggles a light, I don’t want to leave the editor and switch into VS. I’m just doing in inside my Actor I’ve just created. But if you personal workflow looks different, you don’t need to use them.
I see Blueprints as a great level of abstraction for C++. Basically you are building the same logic and structures as you would in C++ but with a graphical representation, which makes it easier to understand for non-programmers. To transfer your logic and ideas from a blueprint to a C++ class is more or less easy.
BP shows me that everyone is capable of programming. Even a designer can get into the basic levels of coding in a playful way, which is great.
I don’t code that much of c++ but so far I see that re-usable code and components are better fitting for c++ and BP can be efficiently used to glue components together. Code which takes a lot of iterations to build like character or vehicle controls is really fast and easy to build using BP. Whatever you have in BP can be always ported to c++ if necessary. In principal they are just different tools to solve the same problem. I would heavily advice to learn and use both as BP is much more forgiving and can be used for fast debugging when something doesn’t work using c++ code.
Best practice in a C++ project is to abstract your C++ classes with blueprint then set default properties on them. All Epic’s C++ learning templates use this workflow.
Some Blueprint tools however are much easier to use than their C++ counterparts. Animation in Slate (C++ UI) is very difficult as is iteration, so UMG is often used instead now unless you have a tight UI budget. Additionally, the behaviour tree and animation graphs are much easier to edit in BP as well. You can always transfer the assets to C++ later if you need to claw some performance back.
C++ can do much more than Blueprint can, and typically is much faster. Personally I write code faster than I can Blueprint, so I prefer to do that where possible, and I’m a tad OCD
Is it really true, that you can do anything in C++, what you can do in Blueprint?
I thought Epic favours Blueprints and not all functionality has C++ interfaces.
For example creating and modifying landscapes in C++ or building materials by connecting
input slots and compile material chains within code seems not to be possible.
Maybe it is, but the main problem with C++ is the documentation, all systems are “listed”, but not explained.
Level designers, designers in general, need blueprints; a team can’t simply wait for the framework programmers to code everything while others just sit there because the C++ code isn’t ready yet.
The other thing to remember is that making full games with Blueprint happened by accident, it wasn’t what they were originally designed for - they’ve just ended up that way (but that’s no bad thing).
Even with the converter there are often cases where a good C++ programmer will be able to write something that runs faster and/or uses less memory. There are for example lots of types that aren’t exposed to BP at all, you can only use int32, no doubles, no quaternions, no Matrices etc, no real concept of ‘const’ either (which I use wherever possible). The Blueprint converter essentially does a lot of copy-pasta - which can result in lots of unnecessary function calls too. Not something you’d notice until you start doing lots of things over and over, but it’s still there!
C++ can also me considerably faster and more convenient for things like UI too, even if you’re not using slate. Regardless of how good Blueprint gets, it’s still always going to be worth learning C++.
For me, the best way its to do it mixed. Create the core functionality and architecture it on C++, expose it to blueprints, and use blueprints to define the basic functionality in subclasses. For example, in my game deathwave, i have a Spell class, that just defines events like OnActivated, OnUpdated, OnDeactivated, etc. From C++, i handle selecting them, activating them, using timers to deactivate them later, things like that. From blueprints i just use those events, alongside a few helper functions, to build the functionality for each spell.
Well Blueprints are made of C++, so i think u can do much more in C++ than in Blueprints
Try to take a blueprint node for example and RightClick–> GoToCodeDefinition. The Definition of this Blueprint will show and so u can use every Blueprint node as a c++ function.
As others already menthioned… I personal also love to BlockIn and try things out with Blueprints before i convert them to C++. And I’m doing this mainly to keep my things organized and untouchable for the designers. (Oh that doesn’t work hmm better fix it myself… Hmm now the whole code doesn’t work any longer HELP! )
We really need a stickied post that goes into the “why use blueprints” question as it seems to get endlessly necroed. This thread is full of wrong ideas - it’d be better to explain the workflow than leave people guessing.
