Aevee Bee

having very little first-hand experience with blueprints, I suspect much of the value of them materializes when you're on a larger team, and part of the team can build higher-level, idiomatic abstractions over the auto-generated primitives instead of having to stack a billion atoms together by hand. if you're on your own, and blueprints don't feel natural to you, they're probably not gonna feel any more natural after you have to laboriously build an entire set of coping methods for yourself.

is it realistic for me to be able to touch the C++ side of Unreal given my experience with C# and GDscript?

yeah, the only thing that really makes C++ more difficult than C# is that its syntax has some truly wretched sharp edges on it, stemming purely from:

1. it's a descendant of a programming language that is now 50 years old;
2. bjarne stroustrup made some bad decisions in the '90s that can now never be taken back.

conceptually, it's not really that much more complex, but C# has the advantage of being actively maintained by a company that is happy to make breaking changes to the language syntax when it has to.

I would say, have something specific you want to make with Blueprint, and try to make that, and if the experience starts to suck then maybe you'll have more specific avenues of advice to seek out. I would say don't bother with Unreal C++ unless you specifically want to learn Unreal C++ and see higher value in that than BP. The thing about BP is that lots of programmers look down their noses at it as an Inherently Inferior (cough "for non-coders" cough) and many of them end up writing some of the shittiest BP and/or making architecture decisions that make life extra painful for their teammates who have to write BP. When the truth is that you can pretty much make entire games with it, from a game logic standpoint there is not really much that is out of reach if you're working exclusively in BP, and it is built deeply into every major paradigm Unreal offers.

Re: "non coders", I think your situation is very common and obviously valid because there are many different kinds of non-coders! Some of whom think entirely in terms of language (I'm more this way than others, I think; I can't really listen to music with lyrics while I'm writing code), some of whom think in terms of abstract logic, and some of whom think most comfortably in terms of the visual diagrammatic stuff. I think it's reasonable to come away from giving learning BP a good honest try and concluding that the paradigm doesn't work for you. Hopefully either way you'll emerge with clearer, stronger opinions about what does work for you.

I'd been text-programming for many years before I used BP, so I think for the first few years my process for writing it was still "think of a good text-based program and then find the most concise way to express that in BP", where each node is a statement or a control flow expression etc. The loose "row of script actions" -> "sentence" analogy lets me lean on the patterns I'm more familiar with to answer questions about structure. And at some point I'd learned it well enough to just "think in blueprints" like I would any text-based programming language. They don't feel particularly different in the ol' brain, for me. (My dream, of course, would be if BP had an underlying text-based representation that you could switch back and forth between, but that's a massive technical + design challenge for the future.)

Unfortunately UEd really just kind of shrugs at the question of how to best organize BP visually (ie it's not like Scratch or something whose format dictates a much more rigid structure for you), which is partly why there aren't as much in the way of official standards docs. Some people stumble in that lack of guidance and you get the stuff like the tumblr full of bad BP screenshots that the "code chauvinists" like to hold up as examples of their superiority. But as visual scripting systems go it's undoubtedly one of the best implemented and most fully realized out there.

When I first started getting interested in making games I thought visual scripting would help me out a lot as a beginner. Instead I spent hours trying to make sense of it and then just started learning C# lol I had some simple working systems the same night I started learning and I still can't make sense of visual scripting.
That's not very helpful to your questions but I figured I'd share that others are in a similar boat. Good luck getting a handle on it though 👍

Got a few disparate thoughts:

First, I just wanna reassure you that Unreal C++ is a lot closer to C# and is nothing to be afraid of. It sands a lot of the edges of regular C++ off.
If you're used to looking up "how do I add force to an object in unity" and then typing object.addforce(whatever), it's like the same process in unreal. Accessing components is different, the .h/.cpp thing is different, but if you dive in it'll make sense and the finer points will come up naturally.

In terms of process, I usually fuck around in blueprints and at some point go "ok this is messy" and rewrite it into c++. This is very easy because you already wrote it in BP, and the names of the special functions will be the same. You can probably get pretty far doing the former before doing the latter, up to and including releasing an entire game. YMMV.

Once you have some experience, the way you're "supposed" to use BPs is making a C++ class for your game thing, write functions for it in code, then make a BP based on that file and call the functions in the BP editor. (Like Bark() is written in C++ and Press Mouse -> Bark() logic is in BP)
Big teams and shit do this to expose complicated C++ methods to designers or other team members who just need to call the functions in blueprints. As a solo developer it's just a nice way to have one object that you can both quickly write code or quickly modify BP stuff on at the same time.