So I’m kinda frustrated here because I don’t consider blueprints valuable to me as a C++ programmer who 's learning UE4 and just wants to get experiences in programming, and not just coding simple behaviors. But a lot of times, tutorials online, even UE docs just supports blueprints not c++. So I’m forced to go deep in the engine’s code to find out how to get the same behavior of a blueprint function via code, or how to simply reference something inside the engine. And let me tell you, this is just no fun. What do you think? Does Epic games favor and support visual scripting over actual programming?
2 Likes
I apologize in advance if you know all this already but I find people often don’t.
If you build the engine from source you can usually right click a blueprint node and be taken straight to the code (Alt-g?) for the node in Visual Studio. Eventually you will get used to digging through the code when you have errors or want to replicate something that the engine already does. If you are really green you can look through a book like this:
It hits a lot of topics and you can just jump to the sections you want info on after you get started with the beginning. It covers a lot.
Also when you get build errors you don’t understand, check the output tab and start reading backwards for errors. There’s a lot of weird things you can do to make errors that simply show as the build fails but then you’ll have real messages in the output like you tried to make a function visible to blueprints but the class isn’t or other oddities. Also use the link in the crash window to go to the logs, as well as looking at the engine code reported in the error and if all else fails close the built editor and run the project from Visual Studio to debug and work backward.
Theres also lots of stuff you can search online for once you know what to look for but getting used to finding your answers in the code really speeds up development. I wrote a custom thumbnail renderer yesterday for some of my assets and my Google fu failed me but after looking through the source code for the classes and references I found the links in the baseengine.ini and was able to add new ones in my editor module and project defaultengine.ini. I also had to make my editor module load sooner to be found by the code that goes and looks for packages. This is pretty much how all my c++ development works with UE4.
The sooner you get comfortable digging through the code the sooner you will be able to answer your own questions quickly and not fall into out of date info or hard to find topics online. Learning how to dig into the engine is an amazing skill that you should really continue doing.
For me digging into the engine is fun because I have done it enough to not be intimidated and I can easily learn stuff myself and not be frustrated trying to find info online. It can be frustrating for a while when you aren’t used to it. And Of course anytime you have large amounts of indirection for something it can be a lot trickier to figure out =)
Good luck!
I was just like you about 2 weeks ago when I started learning, so I get where you’re coming from.
That’s kind of the idea of game engines though, favouring everything that’s faster and less error prone. I was very reluctant about blueprints when I started learning and I did everything with cpp code, surfing through the engine with right click->go to definition/declaration.
Right now I can’t imagine not having blueprints, the way you can setup cpp to blueprint communication makes game making incredibly fast, coding in cpp alone cannot even compare. And the UMG widget system, it would be kind of ridiculous to create widgets without blueprints.
Besides, I don’t think using blueprints where it’s faster is making your programming experience any worse or less educational, since you have to get a good understanding of macros and the way objects communicate in the engine.
Epic definitely encourages people to use blueprints where it’s possible. We’re currently in a time where game making is becoming more and more comfortable for game designers and I believe that to be an absolute success of the gaming industry. People who are enthusiastic about creating “the best game ever” can now make games out of little building blocks without being bothered with syntax and constant crashes. Well sort of, because there’s a lot of things you can’t do without cpp.
Being a programmer for over 30 years, I tend to dislike programming in blueprints. However, when I view blueprints as a tool for power users or as a tool for when I am assembling the behavior of my games it really shines through. Being able to change a parameter in the blueprint (inheriting from my C++ classes) and then just clicking Play is powerful iteration.
If you’re making a game you’ll learn to appreciate both.
to second MarkcusD… I use both, but tbh i only go into blueprints for things like triggering animations (timelines) and audio; expose a function in c++ and call it. That is not that i don’t like the visual coding, i just find that a spaghetti of blueprints equals a few lines of c++. Both are tools, so use each as you need.
I use both BP and C++, but mostly C++. Here are some of my reasons I don’t use BP that much, though :
-
Work Safety : I had too many non-programmers coming to me and say “Hey man, what are you doing ? You broke the game !!”. All of it only to find out that THEY accidentally broke my work into pieces and submit to Perforce. That’s when you realize you should have done this in C++, since no one except programmers will ever access those. Better be safe than sorry.
-
Git/Perforce conflict : C++ uses .h and .cpp files, which no one except you will use. When you submit them, all the others have to do is click on “Compile” and voilà. BP, on the other hand, uses .uassets, a file artists can happen to use at the same time. This means if that happens, you have a risk of disrupting someone’s work. Since an .uasset is considered a binary file, good luck resolving the file conflict.
-
Spaghetti : A personal choice, but I prefer debugging in a wall of text than in a giant spaghetti.
1 Like
Shipped three UE4 products at work from 4.9 to 4.22 (working on 4th and 5th now). Blueprints are forbidden to use in any project except for the HUD layout blueprint. So far we haven’t been forced to use them for anything else (yet). 
In the absence of support for XML or HTML5 wrapping, I tend to use blueprints for creating the UI, because I have found Slate unnecessarily esoteric. Every other aspect of game programming, on the other hand, I definitely prefer to do with C++.
To be frank, I can appreciate the intentions Epic Games had when instituting Blueprints, i.e. “artists can now program.” However, using BP still requires some programming sensibility, so I suppose the purpose is lost.
Now, if you don’t mind me being really pedantic, the C++ in Unreal Engine 4 is not actually C++. The constructor (both the starterwire as well as the carburettor of the engine, so to speak) of most applications made with the help of Unreal Engine 4, UnrealBuildTool, is made with C#. This is actually not a bad design decision, since you can still get reasonably low-level to optimalise your game thanks to the C++ part, yet the C# core rids you of all the ******** around with memory issues.
UnrealBuildTool / UnrealHeaderTool are just parsers. It doesn’t handle actual objects. UE4 is very much C++, albeit with some macro magic to paste in some boiler plate.
So which ones handle that?
Might be worth discussion in a separate thread.
It generates C++ files, that’s what you get in Intermediate folders and that’s why you have to include yourheader.generated.h when the header contains UCLASS() objects.
Those C# applications don’t exist in the running built game / application.
For me is very difficult to find good tutorials about c++… and I prefer expend my time in learning c++ in UE4 than blueprints, because I know a little bit of c#. I have to trust in some tutorials without beeing sure that are the best ones to learn (well, sometimes I see that are not the best ones because they are not using the coding and naming rules of UE4) I think it would be a really good investment from Epic to create some tutorials of all levels for the ones that wanted to learn to code c++ in UE4.
Epic is always investing in training, but it’s a naturally slow process.
1 Like
Sadly, we are living at times where everything is valued just by how easy and fast to learn it is… There is no deeper thought going on. Can’t blame Epic that they put so much PR on blueprints, since this is just how the market works. UE4 is trying to become the dominant graphic toolset (not even just for games), and making trivial tasks easy is their primary goal. BP have a lot of issues for non trivial tasks, but they are easy to begin with, and many people do not get the future implications. For example dynamic languages became super popular years ago. I admit that I got really hooked with Lua. And, sure, it’s great language… util you scale up your project, until few more people start working on the same stuff, until you start changing code and break things… Then you understand why C++/C#/Java are real programming languages, and everything else is for minimal scripting. And many people start to get it, which is why we have TypeScript for example. BP itself is mainly a scripting interface. Learning it will allow you to use other scripting languages to interface with C++, so it’s not a waste of time.