My name is Yifu.
I have started learning UE4 2 days ago, and I would say I am really impressed. The flow is much better compared to UE3, and being able to code in C++ is always nice. I hate unreal scripting with a passion and that was the reason I stopped learning UE3 a few years ago.
I come from c++, OpenGL, Unity3D, C#, and I think I am pretty good with those. And since I have been using those technologies for years now, there are something in UE4 I found hard to get used to.
When I was doing the battery man collecting tutorial, I noticed the teacher in the video uses a lot UFunction and upropery macros to set up stuff in blue print.
I am just wondering, as an UE4 programmer, what kind of mentality do you have when writing c++ code? Do you always think about how to hook your code to blueprint event graph? Do you expose your gameplay functionality as much as possible? Or do you just write you code like standard c++ game engine and only hook them up to blue print event graph when a designer asked you to do so? Or is it just purely based preference? If I am just a hater of blueprint, can I get away with pure C++?
I personally don’t like visual scripting and I found it a bit tidius. For example, simple changing a material color takes more than 10 nodes in blueprint, but I believe it would be about 2 lines of code to achieve the same thing in c++.
But I understand that blueprint is core part of the engine, I feel like I am missing out if I don’t use it smartly. if it is a good practice to have, then I will force myself to use it more and get used to it.
Can anyone with a lot experience give me some advices on a high level? I really appreciate any input.
I don’t have loads of experience, but I can give you my opinion at least.
I love Blueprints. I think they’re an amazing tool, and extremely underrated by programmers. It’s about finding where to utilize them.
Although I do 90% of my work purely in C++. I can open up the variables I want to Blueprints, and I use them as a top level layer to tie all functionality together. The second you’re working with a team of non-programmers, Blueprints are extra awesome. They tell you what they want, you can easily prepare something for them in a way they can use it themselves.
Also, we recently wrote an AI system, where the workload eventually became 50/50 between C++ and Blueprints, simply because using Blueprints was more powerful in many aspects.
It’s not about Blueprints OR C++, more like understanding how they can be utilized together.
Just a quick response to this first; the UFUNCTION() and UPROPERTY() macros are often indeed used to set up blueprint, but they can also be important when you’re not working with Blueprint. For instance, I believe the C++ delegates system that UE4 has requires functions to be marked with a UFUNCTION() macro, and UFUNCTION(exec) can also be useful to expose functions as console commands. The UPROPERTY() macro too when not working with Blueprint. For instance, if you have a pointer to a UObject (or class derived from UObject, which is the majority of all classes in UE4) somewhere as a member variable, you’ll likely want to mark it with a UPROPERTY() macro to prevent it from getting garbage collected (or use a TWeakObjectPtr instead if it’s fine if the object does get garbage collected from the point of view of that class).
The way I like to this about this is as follows; when writing functions, think about whether it could be useful for a designer or someone writing a quick, small script, to be able to call that function. If yes, expose it to Blueprint, otherwise, don’t. For example, imagine you’re writing a function to add an item to a character’s inventory in a Role-Playing Game (RPG). I think it is very likely that a designer may want to have access to such an AddItem() function in blueprint. For instance, he might be implementing some functionality for a small Quest in blueprint, and in that particular quest an NPC needs to give an item to the Player (a key for a locked door or a quest reward or something like that). So, it’s very useful if AddItem() can be called from Blueprint.
More complex functions that implement core gameplay functionality or helper functions that never need to be called directly but are called sometimes from within the implementation of another function should probably not be accessible from Blueprint. For instance, there may be a function that checks if a Character still has enough space in his inventory for a new item to be added to it. This function is probably always called by AddItem() to check if it really should add the item or if it should simply fail, but a designer should never have to manually perform this check in Blueprint. The designer should simply call AddItem() and the C++ implementation of AddItem() will do all the required checking.
I agree that Blueprint can get annoying and turn into a big mess of spaghetti if you’re trying to do anything even slightly complex. But, it can be useful for cases like my example above, implementing a simple quest. Such an implementation likely only requires a few function calls (so a small number of nodes, and therefore no spaghetti). It is often also highly specific (it is the implementation of one particular Quest, not of the complete Quest system in general for the entire game), and therefore nice if a designer with little or no programming experience can still implement it so that the experienced programmers can work on the core gameplay systems. Finally, Blueprint is very useful for quick prototyping, because compiling a Blueprint script is MUCH faster than (re-)compiling C++ code.
Yes, you can do anything in C++. More, actually, because not everything is exposed to Blueprint, but mostly the same stuff. I only use Blueprints as object templates. Prefabs that inherit from a C++ class I wrote, basically.
On the other hand, it can be efficient to use Blueprint. if you’ve got weapons in your game and one of those weapons has a unique special effect that you’ll never use on another weapon, you can write your generic weapon in C++ and add the secret sauce in Blueprint later, just for that one weapon. It’s probably much quicker than creating a child class in C++.
I use the same approach as Gwenn, but for AI development and fine tweaking Behaviour Tree is a really cool tool, what you can visually debug runtime. When the tree is working you can convert it to C++ if more performance is needed, or at least you can create C++ nodes instead of the most heavy parts…
I asked all the game industry ppl I know, and none of them could give me a good answer.
I guess UE4 is still relatively new(compared to UE3), so maybe no one around has enough experience to answer me.
After exploring this engine for about 40 hours, I managed to make my own game and the more I used this engine, the more awesome I think blueprint is.
It was a bit learning curve at first, but after a few tries, it actually make sense now.
I could do everything in c++, but I found that simply build basic functionality and then expand it with blueprint is even much cooler and fun!
After some more exploration, I think C++ and blueprint are NOT mutually exclusive(which was my original impression). Blueprints expands c++ functionalities beautifully and impressively!
It all makes perfect sense now.
I can’t believe I found visual scripting is actually addicting!
Btw, here is the game I just made after 4 days of learning.
I am impressed by how easy it is to get my hands on this engine compared to UE3.
Thanks again for everyone’s input.
I hope this thread helps other new comers in the future.