General time to learn C#?

Learning the language itself (assuming you would transition to C# in both cases which you would not) is the same difficulty but you're not just using the language. You need to learn the APIs that you use to interact with the engine on a daily basis.

I don't know that much about Bolt aside from what has been discussed in this thread but Blueprint is definitely a higher level language than scripting in the sense that it is designed to get you further with fewer instructions and that will make life more difficult for a beginner.

Of course like I mentioned in the first sentence you wouldn't just switch from Blueprint to C# but rather Blueprint to C++ and that adds even more problems on top of the fact that Blueprint isn't one-to-one with the actual APIs.

 

Program's appearance is syntaxic sugar. Whether it is text or nodes, it is the same thing.

However, Unreal Blueprint API does not match Unreal C++ API. While Bolt API seems to be very closely following unity API. As a result transitioning in case of unity is going to be easier than in case of unreal.

Because programs mainly consists of API calls, in case of Blueprints-->C++ change, you'll be looking for things that aren't there. And that is going to slow you down.

 

The OP is asking a very common Q. They know the Unity Editor, have a little programming (through Bolt) and want to learn more about the coding part. Before LEARN, Unity recommended a generic C# college textbook (the "Yellow Book"). Some people here recommend the microsoft site, or to just browse for any good generic programming book. Those are all just text without any pictures of Unity.

Coding in Unity is a big hole and a big problem. New users just naturally assume "scripting" is a simple Unity thing to learn. It's tough to convince them that it's computer programming and they can step away from Unity for a few months to learn it. I realize you're not purposely doing this, but complaining a C# book is no good since it needs to cover the Unity editor more -- that's the opposite of what we're trying to tell new users.

 

My advice to beginners is to learn as you go. Practically speaking, you don't want to study C# from a book for 6 months and then say "Ok, now I'm ready to start!" What you want to do is to learn a little, then do a little, then learn some more, then do some more. Start with the simplest possible project and work your way up. It will take you a long time before you can do everything, but there are also some things you can do right away. You might be surprised what you can do in a short amount of time.

I've been learning to program for my entire life and I'm still going. On the other hand, I had only been learning for a day or two before I programmed my first game (Not in Unity, though).

When will we finally be finished learning C#? The Unity API? Probably never, but it doesn't matter. The important thing is whether you can do what you need to do.

 

It turns out you do!

I wouldn't bother looking up some random Unity add-on either. But the thing is, Bolt's title is "Bolt visual scripting". If one looks up visual scripting the search page lights up with hits. "game engine visual scripting" gave me "11 best game engines with visual scripting" (Unity is one) at www.slant.co/topics/8237/~game-engine-with-visual-scripting. Searchign just "visual scripting" lead me to wikipedia's "visual programming" entry, with a huge list, including Unity's Bolt. So Bolt isn't some random package, it's a common game engine feature.

The first discussion of coding vs. visual scripting was a 2-year-old thread on some crazy site: forum.unity.com/threads/coding-vs-visual-scripting-which-has-the-faster-workflow.997676/ . A person with username Ryiah and a Kim Possible headshot posted there to give an opinion: "Visual scripting allows the artists and level designers to implement functionality in the game while taking some of the burden off of the programmer". Well put.

 

The best thing I ever did when learning programming was look up a glossary as the vocabulary and understanding what all the bizarre symbols etc. actually meant was my biggest struggle, it will vary from person to person though. I feel like this is something a lot of veteran programmers forget as a suggestion because sometimes it can come very naturally to people and they don't understand what it's like to come at a programming language with literally nothing.

 

This is still true. Doesn't mean this approach teach you coding.

The best person here to comment about VS experience in practical way, is @BIGTIMEMASTER.

I have learned C# from reverse engineering, while started molding games. However I had already prior experience in other languages. Unity learning was hands on. Started Unity, and asked myself, how to move and rotate cube. Sent queries to the Internet and start searching for an answers. Then replicated results and start messing with variations of setup on my own. Then went from there, repeating process.

Resources I was reading/watch in was anything. Snippets, doc, vids, forums etc. If I failed to understand one way, I kept searching and experimenting other way.
But always hands on.

Reading prior tons of pages of gibberish, would be massive turn off. Now once I know more about techniques, I can read more about approaches. Compare with what I know. How to improve.

The point is, to having reference point. Reading random book for starter, gives no practical reference point, to start understanding a problem, if never had chance to practically experience anything similar. All will be at best a theory.

Having simple 'hello world', surely don't want to read tons of books, just to learn basics syntax of printing text on the screen.

Anyway, that's me.

 

well i haven't messed with unity's visual scripting, but for me it is simple: visual scripting means I piggy-back more on the expertise of experts and face less caveats that must be fumbled over in order to make the ball roll.

Big geniuses can tell me that it's not so hard to learn blah blah blah. I am not measuring my e-peen here though, only my time. Trying to get from zero to published game on the path of least resistance.

If I hit a problem and learning to write the text which makes my eyes hurt to look at is the only solution, then I do that. But so far, I haven't come to that. And if I did come to that, I'd seriously consider the scope of what I'm trying to do before I jumped into the trenches.

I can only offer advice for people who are 10% behind me. To them I say, if you are trying to make those most common games solo developers are usually trying to make - you know, walking sims, really simple games that focus on story or decision-making gameplay - i honestly see the amount of time to learn traditional code as time wasted. Given that there is faster options.

But that doesnnt mean visual scripting is easy or you dont got to do some maths or get used to thinking the dumb logical way a computer does. It's still a royal PITA - you just have 99 problems to solve rather than 110. Plus, for a person who didn't take to math in school, it's much easier to visualize logic on a flow chart than just looking at text. So you can apply yours smarts faster, further.

OF course if you have more complex goals in mind or trying to get a job you probably have to learn how to write code. You got to do what you got to do, just make sure you have a real reason to do so - if you are doing things this way or that way because of ego reasons, well that is stupid because really nobody but you will ever care and some day down the line, maybe 10-15 years if you aren't very observant - you'll realize you've been doing things a harder way than was needed and you got nothing to show for it and nobody cares.

 

It might not in Unreal's case, I don't know, but Unity Visual Scripting (aka Bolt) auto-generates nearly all of its nodes from Unity's C# scripting API and right now it doesn't have any artist or level designer oriented high-level nodes (Unity are working on them, however).

People working in UnityVS graphs right now are using the exact same API as C# coders use, so they're more or less doing the same thing, just with different user interfaces.

Visual Scripting is a lot slower to work in, of course, but it also removes a lot of the complexity - no classes, namespaces, inheritance or advanced composition or the need to know syntax.

It lets users focus 100% on the design and displays how the graph logic flows in real time, which is really helpful for beginners to see how their logic executes and where it fails. And graphs can be edited, and the changes tested in Play mode without ever having to exit it so there's 0 friction when you're rapidly experimenting.

UnityVS unlike IDEs also assumes the user doesn't know what to write so there's a fuzzy finder that categorizes most commonly used Unity API. Users can browse around and understand how Unity is structured just from that. There are many user-friendly features like that. It's really intuitive.

You can't equate UnityVS with Blueprints (or with Scratch lol), they do different things.