So as far as I understand blueprints are easier to use than actual C++ coding, but what are the real limitations of blueprints vs actual coding? What are examples of game mechanics that you could only create in C++ but not with blueprints? I understand that one of the arguments against blueprints is that complex code can become difficult to read compared to conventional code, but that’s a matter of visibility/readability rather than actual functionality. At what point do blueprints become insufficient? Can they only be used to create very basic game mechanics/logic or can they work most of the time unless you have something very specific or gimmicky in mind?
If you want to develop prototype projects, Blueprint can be enough (even if you won’t be able to access some specific features without C++).
If you want to become a full fledged programmer, C++ is the way to go. Especially since it will necessarily involve doing Blueprint along the road (to speed up your iteration process).
You can also develop large scale projects with blueprint only… but there are many limitations in terms of performances and accessibility to all Unreal features. I wouldn’t advise it if you don’t have a solid programmer background.
I have some basic understanding of coding from my days as a Doom and Quake modder. But not as deep as C++ or even C#, though I am slowly learning.
If your game is relatively complex and you have a framerate budget you can’t rely on Blueprints.
For example anim graphs and AI are often moved to C++ to save on milliseconds eaten there.
That is because Blueprints are executed on a virtual machine, somewhat slower than native code.
1 Like
Would this be a problem for a turn based game where having a very smooth framerate isn’t required for the gameplay to work as intended?
No, one of reasons why Blizzard used Unity (old version) for Hearthstone was because turn-based games don’t require a steady framerate.
- Although modern Unity isn’t that slow anymore.
On the other hand when you have one single frame freeze in game like Fortnite during a shotgun fight you’re pretty much dead because of that.
Fortnite is very heavy on amount of UObjects and Blueprint nodes, platforms such as Nintendo Switch and Mobile have a very hard time to keep smooth framerate.
And players complain, a lot.
If you like blueprints just keep going with them. You could even put stuff in C++ later or tinker around with the BP to C++ compiler. If you wanna be a member of programmers that all code in C++ and sync their work via SVN/GIT you have to use C++ of course. But you would not ask that question in that case. If you wanna develop a full game alone you would most likely go blueprints as coding is only one part of creating a game and you would prototype a lot. Code execution would be slower but usually you would be faster. Try to add a single actor in BP and compare your time to do the same in C++. Add/remove few parts to that actor and try to run/test your project with both. If you start UE4 and put all your anim logic in C++ you probably never finish the game so execution time does not matter. Even if it might save some msecs I would not be the poor guy that have to set C++ breakpoints to debug some unexpected anim-behaviour.
1 Like
Here are a couple of examples :-
- I wanted an actor (not pawn or character) to receive keyboard input. Not possible with blueprints but with C++ I could add an input component to the actor.
- I wanted to write to serial ports on the computer. So I wrote a plugin - The code calls windows serial functions. Had to be C++.
But,
I am creating a physics driven helicopter with my own external controls that mimic real helicopter controls. All the code in the unreal project is in blueprints and it runs nicely on a low spec machine even in multiplayer. Adding more helicopters and more multiplayer logins is starting to slow things down now so I am at the point where I am looking at optimising code. But for a couple of users the blueprints have worked fine and my helicopter is computationally pretty complicated. Some people scoff at blueprints and say you have to go C++ but I think that they are wrong.
Besides, you will be learning a lot about C++ and structure of the engine and game using blueprints even though you might not realise it. Blueprint nodes often translate directly into C++ function calls. You can also package using blueprint nativization which will convert the blueprints to native C++ code (though not very nice for humans to read).
Just crack on making something using blueprints. You will find out as you go whether a lack of C++ is a problem. Very often is is not a problem.
More functionality is being exposed as blueprints as time goes by and I imagine that in the future C++ will become less relevant. It reminds me of when C was created. People used to program in assembly language to optimise but now the C/C++ compilers are so good that they will beat a human trying to optimise code. (yes, I am that old).
cheers
Podge
1 Like
That’s quite possible with BP. It’s just a dropdown list choice. The feature even comes with priority settings and you get to choose whether input gets consumed or passed through.
I agree. Usually in most coding languages if is an if and a loop is a loop and as a coder you know when you wanna choose what. If is called branch here but the idea is the same. UE4 blueprints are heavily object and event oriented (which is good). The resulting coding style is usually clean. Wanna get that green eye at public variables instead that yellow? Enter the tooltip. I like that. I saw lots of C++ that just used the “++” to get access to include <string> and left everything else spagetti code with tons of globals and functions > 2000 lines (which is a nightmare).
Don’t get me wrong. I like C++. I earn my money as C++ coder in a team with of other C++ developers in the (not so exiting) non-gaming industry. Unfortunately my job does not require any art so I searched a game engine for my freetime to create my idea of a world at home few years ago. I thought UE4 is the best choice because of good support of C++ without requiremend to pay extra for that (I’m no big fan of C# or Java in games). UE4 was the right choice but I turned back C++ soon as I experienced with BPs and found out that I have to invest a lot of time in 3D programs creating meshes and animations and PBR painting, … and I feel myself a lot faster using BPs to finally put all those parts together. Even all those upgrades from UE 4.7 up to 4.22 went without issues using BPs the last years. It just takes seconds to upgrade. It saved me a lot of time.
Everynone, I stand corrected. To be honest I cannot remember why exactly I wrote the code - there was something that I wanted to achieve 2 years ago that the blueprints wouldn’t let me do but I am buggered if I can remember what it was. Maybe I was wasting my time!
I think the main issue with Blueprint is that if you have it done not very structured (thinking ahead), refactor it, enhance it, it is a pain, more the pain as the bigger is the amount of blueprints or coding inside it. Now to restructure a C++ code, refactor some things is several times faster even if the code is huge already. Sometimes debugging certain issues while in C++ is way easier. Overall you need to experiment mixing both and moving stuff from BP to C++ as you see performance becomes an issue.
Too true… https://blueprintsfromhell.tumblr.com/
Not saying you can’t write awful impossible-to-maintain C++ code, but poorly-designed BP systems are a special kind of awful in my opinion 
yeah, some serious rat nests there >.<