Quoting Donald Knuth: “Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%”. (See source at Donald Knuth - Wikiquote)
I’ll paraphrase: It’s a mistake to worry about performance until you know which code is actually slowing you down. Attempting to optimize too early leads to code that’s more complex, less readable, and harder to debug.
tl;dr: I recommend using blueprints first as a general rule, then convert to C++ as necessary to obtain speed improvements. ( A good exception would be when writing some behavior in C++ actually makes it more readable/maintainable. )
Since the topic already has been resurrected, I’ve got to raise an objection.
There are other disadvantages to Blueprints, especially if you’re working in a team because Blueprints are stored as binary assets, which turns version control into a nightmare.
Also, there are some aspects of a game where you know in advance that a factor of 10 will make a huge difference. (For example, we’re currently using a custom pathfinding algorithm, which is executed by all actors, not all the time but often enough to be a performance problem. We did end up implementing that in Blueprint just to see if we could, but we knew all along that we were going to use C++ for that in the end.)
What we did at work was set aside 3 weeks for our coders to build a prototype entirely in Blueprints to see how Blueprints compared to C++ not just in performance but also in workflow. This was a great decision because we learnt a lot. A large part of that was the decision to build most of the game in C++, after all, but our own experience with Blueprints will come in handy when supporting the designers who will be making adjustments using Blueprints.
So I’d recommend that: build a bare-bones prototype of your game in Blueprints (in full awareness that you might have to redo it in C++). It’ll help you to decide which parts work better in C++, and for which Blueprints are sufficient.
An important note about that factor of 10 thing though:
I think one has ´to be more accurate
here, to not give people the same
heart attack the I got when I first
read this - after building my project
months over months with blueprints
instead of C++.
Really only the calls to the engines
are 10x slower! And that is not the
fps bottleneck for 99% of the games
anyway. The render Speed of the GPU
and engine calculations done with CPU
(physics, AI, etc…) is not affected
by this, if I am right.
There is this nice console command
stat unit that shows how long gpu
needs for each frame and cpu and so
on. At least in my game it is the gpu
on my laptop every time, which is kind
of expected in foliage heavy Levels.
Draw call time and CPU time is
completely irrelevant, at least for my
frame rate drops.
Lot’s have people have said a lot good stuff. I’ll try not to repeat anything, and just add that Unreal Engine is VAST. There is so much functionality and utility built in. For me right now, I’m just trying to wrap my head around everything that’s available. Coming from an experienced C++ coder: learn blueprints first for the sole reason that there’s so much rich functionality in UE4 and its just way easier to find the feature you’re looking for from the blueprint editor. The best part about blueprints is that it all mirrors C++ functionality, so at any time you can decide to take any piece and move it into code, either in part or in whole. So from a purely educational perspective, blueprints first approach will help you learn UE4 as a whole.
please note though that different C++ codes can have an infinite difference in performance, therefore even if BP are translated into C++, this code will probably be slower than optimized hand-written C++. my advice is using C++ in bottlenecks or extended functionality that can’t be done in BP. BP for everything else
