I want to learn C++ just for my own purposes but is C++ in UE4 only useful if you’re an advanced user? I’ve found that the only things which it seems to be better for are actually things that you can ONLY do in C++. Self-made plugins, access to the depth buffer (why is it so hard to make things highlight through walls?), and some other stuff that will be passed to Blueprints in time. I personally do enjoy the coding (which is why I’m learning it either way) but once the blueprint to C++ converter gets here will there be a solid reason to learn C++ for UE4 simply for use in a game? I can only think that modifying the source code would be beneficial to some but I’m just talking about the things that you would use blueprints for.
Blueprints can become laggy if you have a decent number of nodes (last I checked).
You know what’s happening in your code. Blueprints… you probable have a very solid guess but without checking the source code you’ll never know.
Takes more time to do (you have to open up V.S. and compile and blah blah blah you’re leaving the engine)
Visual Debugger can only look at the input and output of your code if it’s written as a blueprint node and even then it means that if you have a couple of possible problems you won’t know which one it is unless you broke down your function (which is great practice and should always be done but there are cases where a single function IS the problem. IE Somewhere in your equation something’s gone wrong and you’d like to see an input go through it step by step*)
*This would actually be forced upon you if you did it in blueprints, might take longer depending on if you already know the equation going in, and would simply require that you forcibly gimp yourself in the code “just in case” there’s an error.
I’m sorry if this seems like an opinion posed as a question but I really do want to know when I’d need C++ and whatnot. I’m looking at two learning paths: One with the Unreal Engine and one making basic applications and whatnot. And yes I can do both (and plan to) but I don’t want to spend time on the Unreal Engine side of things if all I’m really doing is getting addicted to an inferior coding method (that is, C++ vs Blueprints).
Said converter will be producing sub-par code. That code will work like blueprints, but I think readability will be bad compared to human-made program.
You don’t EVER use visual debugger in C++ program. It is unnecessary. Also, any decent C++ program will be too complex to display it in such fashion.
You can figure out what is happening by making your program dump large amount of debug information into log file - that will work even if you don’t have access to debugger, and can’t trigger breakpoint from within the program. Debug log beats visual debugger. Because even if the whole program died, log is still here, and you can look through it and see what happened. In addition to that you can insert breakpoint into your program and execute it step by step, checking variables as you go.
You don’t “leave editor”. You start Visual Studio at the first opportunity you get and keep it open alongside with editor.
The main reason to use C++ is that C++ gives you much more power than blueprints. Something that can take entire screen of blueprints normally can be expressed in few lines of C++ code. C++ is very compact and reusing code is very easy. Advanced features like templates are not available in blueprints, and typing is faster dragging things with mouse.
If your goal is to learn C++, and not work with UE4, then you could download Qt 5 and learn that. Qt 5 is closer to usual C++ than unreal, and their codebase is fairly clean. Just DON"T write your own game engine.
If your goal is to make a game in UE4, just use whatever works for you. C++ requires a lot of time to learn it, and a lot of discipline to use it. If you don’t have the time and don’t know it already, but need to ship your game soon, you could use blueprints.
Unfortunately I’m going to state the obvious reason for learning C++, even if only for the Unreal Engine. The most obvious reason is…engine modifications as you stated.
The need for engine modifications is a whole lot more common than you’d think.
My most recent scenario being that I needed to serialize all of the dynamic actors in sublevels of an open world. Some people would notice that right off the bat, the level blueprint of sublevels will fire off the Event EndPlay and that can be hooked up to. However, in my case, that didn’t work because some actors from the level had moved to other levels. Fortunately, UE4 unloads the unused actors and only keeps the used actors alive. However, the level is never “truly” unloaded and the Event EndPlay doesn’t fire. Knowing C++, I was able to just track down what happens when level streaming begins to unload a level. I haven’t gotten to test the code yet, because the source is currently building, haha.
However, based on your post, you just want to learn C++. I’ve been using C++, non-professionally, for a total of 11 years. The first 9 dabbling on and off and not really “grasping” anything and the past 2 years actually trying to become more professional. I’m going to recommend mainly doing console applications and learning all the tools of the trade (containers, const correctness, rule of 3/5/0, operator overloading, threading, RAII and et-cetera). Why console applications? Well, they’re quick to debug and you can easily see what your program is doing by spitting out several messages to a console window. Another reason is, UE4 has built in garbage collection, serialization and reflection. None of which natively exist in C++ at the moment, but are all being considered in some of the up-coming standards.
I got a chuckle out of that. I’ve been doing Qt for 13 years. I love Qt! Working with Qt is like coming home from a foreign country, and being able to speak your native language again. Having said all that, after trying a dozen or so different approaches to bringing this game of mine to life, you see where I ended up, and it ain’t Qt.
For me I have good reasons to use both C++ and BP. As you say SOME things would be really roundabout if you would be limited to C++, if you have to tweak something and have to recompile to see the result. But these things I expose to blueprint, either making them tweakable by variables or implementing them through blueprint logic.
Reasons to use C++:
Run-time performance (they say BP are up to 10x slower)
Development speed, because typing out algorithms is so much faster than dragging nodes
Having access to all engine functionality as opposed to blueprint
Reasons to use BP:
Easy to tweak component locations/rotations/scales
Easy to hook up visual effects like spawning particle systems, usually I hook these up to delegates or events defined in C++
Easy to experiment with gameplay, for example in my turn based game I have the damage formulas in blueprint
Being able to program in C++ is incredibly liberating, and tbh I can probably do a lot of things faster in C++ than I can in Blueprint now. There is definitely plenty of valid reasoning for learning C++. The debugging options are no different in Visual Studio than they are in Blueprint. In fact VS gives you far more detail when debugging than BP does. Call Stacks and being able to re-execute code in line is insanely useful.
It’s also worth noting that the BP > C++ converter will produce fairly crappy code - there’s no way around that. It’s not something you would use in a real production pipeline.
I’d tend to agree with TheJamsh above. There’s simply no way that a blueprint to C++ converter is going to provide anywhere near the flexibility and ability to performance-tune that C++ can. On top of that, the code I’ve already written in just one 1 month in UE4 C++ would be so huge and complex in a blueprint (even if you could do it that way, which you couldn’t at all…) that you’d never be able to understand or deal with it like that. It’d be much too cumbersome in a blueprint, too slow to create, and too difficult to deal with the result. It’s much (much!) better as an editor full of C++ code. If nothing else, you can see more of it at once, and it’s easier to search around.
For very simple kinds of games, blueprints seem like a good way to get started. Also they seem like a good way to graft together large blocks of code you build in C++. But they don’t seem like a good way to do the heavy lifting you need for a complex game.
That’s a great point, IMHO. I’d say that no matter how proficient you are with blueprints, there’s a fairly low ceiling on how productive you can be with them just due to their nature, where C++ has a dramatically higher ceiling. Of course, that requires being skilled with C++, which itself takes serious time, energy, and effort, but the eventual payback is well worth it. Not only is it pretty much the language for games programming, it has thousands of uses beyond UE4 and beyond games programming at all.
Like any complex skill though, you need to plan on years of learning to become “good”, and probably decades to get to a master level. But I think that’s true of most things that are really worth learning.
It’s faster, it gives me more control, the logic is cleaner than a series of nodes, and its a language that is applicable to other contexts (i.e. getting a job outside of UE4).
And one massive benefit I hardly see mentioned; you can rely on C++ being C++ because it’s not a custom file format being parsed inside of an application that could crash out or corrupt your work at any point. UE4 can’t corrupt your C++ files, but it can totally break your blueprints. C++ is a rock, a foundation
You can already generate C++ code from blueprints, and it produces terrible-to-read code. Your logic is a bit flawed, as we can’t just automatically convert everything to C++ and continue on with perfect performance, as that’s not quite how it works, or at least in my opinion.
But as for your comment I think you misunderstood what I meant (or maybe I’ve woken up too early… xD ) but I was simply saying that the setup process and getting things done in a macro sense was more complicated. Not that complicated = difficult but that complicated means many different steps to achieve the same goal. Once you’ve gotten those steps down it seems like it’s worth it so… time to learn C++ for UE4. Thanks!
Edit: I mean as in having everything prepared for C++ stuff. Not that C++ the language is made up of steps or anything but… yeah. I should just stop talking. D:
Sorry, but i have to comment a few things just for fun
We can already generate C++ from Blueprints? How that, did i miss some experimental feature?
And, generally speaking, i am always having fun when people are saying that you have far better performance with C++. This is true in an ideal world where you write perfect C++ code, but in the end it always depends on the person between keyboard and chair. I’ve already seen code that performs horribly simply because of some, lets call it “misunderstandings” on how to code correctly.
And in fact, when you dont do dumb things like having masses of logic in actor-ticks, you will hardly notice performance drops with blueprints; If these people would do their stuff in C++, the performance would possibly be a bit better, but the concept of packing everything inside a tick is still ****.
I have seen code in my job that was handwritten and made me cry. But generally speaking i think you are right
Usually i see it like this:
With the number of Macros used in UE4-C++ and its memory management/gc its already like its own language (or, custom file format). And while it wont corrupt your C++ files, you will have a similar amount of fun in C++ and Blueprints when upgrading to newer releases of UE4 (sometimes)
Short answer, no, but it really depends what you’re writing.
I would say that if you’re just write “C++ scripts” then there is absolutely very little reason to hand-write it in C++, converting from Blueprint will get you C++ code that’s going to be 99% just as good. But here’s the thing, if you want to control execution down to the register level, say you’re optimizing an algorithm to use AVX or SSE, or AMP or OpenCL, or OpenMP, or you want to link code that hasn’t been interfaced to Blueprint, you’re going to need to hand-write it.
As a general rule, algorithm development should be done in C++ and not the scripting language on top of it, or at least end up there, for “glue code” and such Blueprint is fine, simply because 10x “slower” doesn’t matter if the time involved is insignificant. The difference between simple “code” an an algorithm is really just a matter of perception, a formality. One trick to identifying where the “algorithm’s” are (it’s not always clear-cut), if you’re relying on nested or complicated loops in Blueprint you should think about formalizing them and porting them to C++. You formalize the algorithm simply by thinking of and/or commenting the code as an algorithm (and not simply “code”), after thinking about the problem you can optimize. However if you’re not doing much but moving the execution pointer down to the next iteration or algorithm then blueprint is fine, especially if converted to C++ and compiled to native binary.
That said Blueprint really does push the barrier. With the generic Async and Task Graph libraries, Futures, and a mind to factor your code properly into those paradigms you can get some really efficient Blueprints, especially if you convert them to C++. There is little to no penalty for calling your algorithms from Blueprint either, once the algorithm is called it is executed as C++ not a Blueprint, you just don’t want it itself defined as one.
Keep in mind, there is nothing preventing you from moving pieces of your Blueprint into C++ bit by bit. Say you have a Character Blueprint. You could later subclass the Character class, then change your Character Blueprint’s base class to your C++ Character class, then just port the code over from Blueprint to it’s new base (the C++ class you derived from Character), add the appropriate reflection markup to expose it to Blueprint, and as long as you kept the function’s interface and behavior the same the rest of your Blueprint should work just as it did before. Very useful technique for moving a working Blueprint to C++, because you can do it piece by piece and debug just as granularly.
As far as the converter goes, you guys need to understand one thing about it. It literally copy-pastes the functions from the engine C++ into your own projects - there is no conversion or optimization, it’s pure copy-paste.
There will likely be at least one or two cases per FUNCTION where you don’t need to do a certain something, or some variable can be const and isn’t - or even where things can be passed by reference or cached and they aren’t. It’s not just going to produce ‘bad’ code, it will also be borderline unreadable and incredibly over complicated. Don’t for one second think that you can rely on it in a real production pipeline. Like srsly please forget about it lol.
The thing to understand about C++ being faster is that the optimization isn’t just the fact that it’s written in C++, but it’s also the extra things you can actually DO in C++ that make it faster - but to take advantage of those things you have to be a competent programmer. Things like bitpacking and passing pointers by const reference etc, or using TMap’s instead of TArrays, the list is practically endless. But the point is, just writing the same code you did in blueprint in C++ isn’t the full way to take advantage of using C++ in the first place.
In terms of algorithm development, unless you’re computing the cure to cancer or the physical properties of dark matter, I seriously doubt anybody can write in Assembly better than the compiler can. For 99.999% of all games produced today, the need to write anything in Assembly by hand is practically null and void - UNLESS you’re a graphics programmer, in which case those things do start to matter. Even then though, these modern compilers really know their stuff…