This is a well-thought-out, reasonable comment. I held pretty much this exact opinion earlier in my career, and I still agree with a lot of your points today, so my response is "here's some additional food for thought" rather than "go to hell you're wrong." First, just to get the obligatory cranky-old-man, you-don't-know-how-bad-we-had-it talk out of my system: Blueprints have come a long way since their initial launch, and they're remarkably stable these days. Don't believe me? Go back to Unreal 4.1 and try working with Blueprint interop! Back then, the editor crashed if you looked at it sideways! You don't know how bad we had it! ...OK, sorry about that. On to some real points. Anyone who's ever made C++ changes only to have the editor crash when loading a Blueprint can understand what you're talking about re: Blueprints feeling unstable. If you're one of those people, and you only take one thing away from this comment, make it this: Core Redirects. docs.unrealengine.com/en-US/ProgrammingAndScripting/ProgrammingWithCPP/Assets/CoreRedirects/index.html If you refactor something in C++ that has downstream dependencies in Blueprints, then you just slap a line or two into the [CoreRedirects] section of DefaultEngine.ini to record the old and new paths/names for the classes/properties/functions/etc. that you've renamed or moved. The Engine takes care of the rest: all references (including references from Blueprints to native types) go through this automatic translation process and will be seamlessly fixed up. That's a very simple, straightforward fix that applies to the majority of cases where you need to preserve Blueprint compatibility in response to C++ changes. If you find working in C++ to be fun and carefree and light-as-a-feather, only to be crushed by the sudden thought of "oh god, but what's going to break in Blueprints if I make this change," then you need CoreRedirects in your life. There *are* other cases besides simple renaming/moving, where you might have to do something slightly more involved, like deprecating old properties and patching their values into new properties on PostLoad, or, in rare cases, attaching a debugger to figure out why something's crashing on load. These are costs of a workflow that supports Blueprints. These are also important skills to have. You just have to weigh those costs honestly, and you have to appreciate and learn those skills. After that, the decisions are yours to make. I've seen people who are weirdly, counterproductively resistant to Blueprints because they got frustrated with these sorts of issues and just decided "I know C++; I don't need to bother with Blueprints ever again." I nearly fell into that trap earlier in my career. The problem with that line of thinking is that it stops you from learning *why* those issues are happening and learning *how* to anticipate and avoid them, and it biases what should be an objective decisionmaking process. You're not doing anything wrong by choosing to use C++ for most things, as long as you're not insisting on using C++ for things that it's objectively ill-suited for (direct asset references, scripted sequences, etc.), and as long as you're not hamstringing Blueprint-savvy people on your team by yanking tools out of their hands. The workflow you're describing (i.e. a thin layer of Blueprints on top of mostly C++, where Blueprints handle asset references and visual details but have minimal gameplay-relevant logic) sounds pretty much like the workflow that traditionally-organized gamedev studios tend to use. There are plenty of good reasons why that's a common approach. Based on your comment, it sounds like your reasoning isn't "Blueprints are terrible," it's just "I have weighed the costs and this is the workflow that makes the most sense for what I'm doing." More power to you - my only advice is to make sure you're keeping an open mind and reevaluating based on your continually evolving understanding of how things work *now*, not based purely on past experiences.

@@AlexForsythe I truly appreciate the information and thanks for the answer! Going into the future, I will keep your valuable advices in mind and I agree that I shouldn't just ditch blueprints because I had bad experience with them but instead try to learn and understand root of these issues so that I can become a better engineer.

​@@SomeKindOfMattias As of C++17/20, how much easier is it to write higher-level expressive code in C++?

​@@DefinitelyNotAMachineCultist I'm far from an expert in C++, coming from C# fairly recently. That being said, you can use things like templates, but not expose to blueprints (I think they're working on better template support). Subsystems are great for abstraction out aspects of a system. Gameplay Tags are awesome for a host of things. n general though it's more about knowing a and implementing design patterns, and that doesn't requite much from the actual language

@@AlexForsythe I'd have to back up OP here. Extending Blueprints in C++ seems really interesting, and is something I plan to support in my own engine. Well, something like it, not Unreal's Blueprints, but a visual scripting compiler that you can hack at in C. Something for UI specifically. It would be nice to have a more powerful scripting language to handle asset references and gameplay code like you mention. The only problem I've heard of wrt Blueprints is performance at scale. Doing *everything* in Blueprints has a performance cost, but most may not see it AFAIK.

second that

Everything about this video is a masterpiece! The voice, the video animations, and obviously this immense knowledge about Unreal Engine. Thank you.

Couldn't have put it any better... Well besides for him not saying, 'Happy lil rockets' or whatever

@@-abs- it feels like Bruce Wayne is giving you a lesson on business.

nailed it

I would prefer C++ a lot more if not super long compile times. Until I buy better CPU at least even then still blueprints would be faster to compile. But lot of node spaghetti can be fixed with C++ too. So best is use both.

totally agree

Have you tried using c++ with UI vs the UMG editor?

@@chancylvania UI with UMG seems waaaay bad-optimized, but I don't care too much about the overall performance impact. In fact, I prefer to use both C++ and BP when I'm working with UI.

@@morderus0033 why does it seem badly optimized? I’m talking about the widget UI bp object you can create. Maybe the UMG editor is something different

@@chancylvania maybe I am not the best programmer, neither have the best practices, but doing a Main Menu using only blueprints causes the game to crash or just bug, if I try to do something more complex