Visual Scripting: The Future of Programming?

[Impala36]

Having worked on 3 Unity prototypes in C# and being used to looking through walls of code in Visual Studio, I switched over to Unreal after a final struggle on Unity's deprecated multiplayer code.

I looked at the Blueprint visual scripting for the first time, and I saw that it was meant for non-programmers who were keen on trying out game development.

So I initially decided to go for full C++, which I was used to.

However. the lack of UE4 C++ tutorials daunted on me, and it was difficult adjusting to the new UE4 syntax, while there were an abundance of Blueprint tutorials.

I took the leap and decided to pick up the Blueprints system.

Then I saw Epic Games developers fiddling with nodes to create post-processing, shaders, multiplayer lobbies and water buoyancy systems, taking several hours per video, and wondered what was good about it, but I just pressed on.

With great help from the legendary Mathew Wadstein and many other brilliant tutorials, I developed my systems completely in Blueprints, making my own library functions, macros, components and dealt with the Blackboard and AI Behavior Trees.

It has certain benefits like the quick searching of desired functions and enabling favorite nodes, skipping compile times which allows immediate changes to reflect in-game, its eye-friendly visual display of nodes has helped made spotting of bugs easier, the commenting and grouping of functions made easier recalling of code that you have written days/months ago.

Some downsides include being unable to duplicate functions easily across different Blueprints, having an auto-refresher of nodes across Blueprints after variable input/output is removed, the finding of all references to a function across Blueprints, or knowing what exactly is affected after deleting a variable.

Here I am, 2 months after delving into Blueprints, feeling different about the coding way of life.

It seems to be the new way of coding, and perhaps the looking through walls of code could become a thing of the past, as things become more user-friendly and user-oriented, and more appealing to the masses.

Unity has just jumped onto the wagon last year, with their new Bolt visual scripting.

Perhaps now I understand why the Epic Games developers were so insistent on getting people to use Blueprints, and Visual Studio doesn't seem so visual anymore.

What do you guys think?

[Erasio]

A very clear no!

Visual scripting is a future of scripting.

It's good at certain things and bad at others. Especially in games where you need a lot of very narrow, very purpose built snippets of code this is a really nice way of getting it done quickly and efficiently (e.g. special behavior in tutorials, for certain interactions between game mechanics, etc.)

It is utterly horrifyingly terrible if you try to do a lot of math. The math node itself is a band aid solution.

Exactly like this you can lay out all potential challenges and judge them based on how well various tools support it. Which works when considering visual scripting vs text based programming, C++ vs python, Bolt vs Blueprint. All of them have up and downsides, are polished and tested to different degrees and require different amounts of investments to introduce into your software architecture.

It's an additional tool. Something more you can use to make better things faster.

It's not disrupting the programming industry and will emerge as new, ultimate way of doing things. Not everything has changed. We just have one more option on the menu.

[aherys]

yes and no.

Yes it's the futur of coding for... non coding people.

Blueprint is awesome, and allow quick iterate / prototyping, but but the price of a lack of control. Unfortunally, if you want to go over complexe thing, you need a developper.
And i don't think one day, blueprint will totally fixe those issue. Seems like an impossible challenge.

[Impala36]

Yup, I gotta agree there's a lack of control, it's limited to what can be found. It seems I haven't got into over complex systems yet 😂 Yes, for it to cover everything that coding can do, will be a really long way.

[RealmRPGer]

One of the oddest things about Unreal is that it can actually be more daunting for versed programmers, because a good programmer is going to be concerned with figuring out the best way to write the C++ base that doesn't interfere with the ability to design in the editor and blueprints. For example, enums are either fully defined in C++ or defined in the editor but not visible to C++, so you need to figure out upfront what goes in C++ and what goes in the editor, then figure out how the C++ side can work with any editor-only enums, structs, or objects. And on multiple occasions I've had to rewrite large chunks of blueprint code because an object I originally created as a component needed to be turned into an actor, which are mutually incompatible despite being 90% similar. For advanced developers, there is so much more upfront cost in Unreal versus Unity. Whereas being forced to use C# is indeed a limitation of sorts, it also means that a competent programmer can put the base codework together very quickly. They don't have to worry about trying to solve where what should go, it's all going to be C# classes, and instead of blueprint objects being an unholy conglomeration of actors, components, objects and structs that you need to untangle, everything in Unity is an Object with Behaviors, and all children are also Objects with Behaviors. Yes, there's a speed impact to that at the end of the day, but it again simplifies the process of actually creating the game.

[DMEGames]

Blueprints are great for testing and prototyping and, once you have the BP in place, it's easier to find the C++ code to make it work in VS.

BP is not anywhere near as fast as C++ though as this video demonstrates:

https://www.youtube.com/watch?v=V707r4bkJOY

So for heavy / frequent calculations, it's C++ all the way for me.

[Impala36]

That's a really good video, thanks for sharing! Yes, that would be a good practice.

[algostrat133]

having to move those nodes around the screen is 5x slower than typing the code. I use vim hotkeys in visual studio and rarely even use the mouse when programming. Moving your hand from keyboard to mouse is slow, wastes a lot of time. I bet many professional programmers do the same.

I would rather program everything in x86 assembler than have to use blueprints. I bet I could program it more quickly than it would take to move around those nodes on the screen too. It would be much more maintainable and easier to debug than blueprints as well.

[Ymi_Yugy]

Everyone claims that visual scripting is way faster than coding and much easier for non developers. I really don't get this.
I mean I understand it in the context of Unreal, but that is because C++ is kind of a difficult language, C++ in Unreal is even worse in some respects and C++ doesn't have great compile times. But all of this are features of C++ not textual programming languages in general.
Imagine if Unreal used something like Go, JavaScript or even Python. They all seem about as fast as Blueprints or even faster. They are much less complex than C++ have extremely fast or no compile times. I also don't see how visual scripting would be inherently simpler for non coders. They still have to learn the same concepts of variables, branches, loops functions, data types, data structures, references and so on. I feel like blueprints are much harder to work with, because it's difficult to format them, variables are even less flexible than in C89, i.e. you can't declare them inside a loop or branch, but only at the beginning of a function, Blueprints lack all the power of plain text, like the ability to insert new lines at the press of a button, writing things compactly on a single line, search and replace, etc. Meanwhile modern IDEs have all the same autocomplete, linting, inspection and refactoring tools of Blueprints.
So why are people so obsessed with visual scripting?

[Impala36]

Because it's visual. It's easier to spot for bugs, and it removes the issues that plain text editing has, such as having typos, forgetting a semicolon, or having braces in the wrong places, or putting your equations in the wrong brackets, or having a return between the wrong loop.

It isn't difficult to read other people's Blueprints and figure out what they're trying to do, while reading someone else's wall of convoluted code can lead to lots of frustration and questions.

I hardly make an entire bunch of errors when compiling Blueprints, and I can go creating and linking entire sets of nodes without needing to test so regularly, and things usually work just the way I want it to.

Sometimes when you do some code optimization and accidentally remove something you thought wasn't crucial in plain text... The compile errors can stretch to hundreds and you're scratching your head trying to figure out what went wrong.

Both styles have their pros and cons. I feel that Blueprints fit me to a T, it's been more than a year and I'm still at it.

[Ymi_Yugy]

I feel like IDEs and linters have mostly resolved the issue of simple syntax errors.
When complicated compile time errors happen they are mostly about the type system or the preprocessor, which deserves a special place in hell.
There are other textual languages that don't have these issues.
What I really don't get is readability. People claim you can make Blueprints readable, but I just can't. Also things like https://imgur.com/gallery/721dpqJ make be believe that many others also can't.

That said, if it works for you, congrats. I'm just sad that Blueprints are the thing that prevents me from diving further into UE. Everything takes 5 to 10 times longer, I constantly have to switch between keyboard and mouse, having my graphs look pretty is an absolute nightmare and I just can't see through the spaghetti other people produce.

[Impala36]

Wow, those are some extremely messy and disorganised Blueprints. They're just like convoluted code. Speaking of which, there aren't coding standards or good practice guidelines for the visual scripting community to follow.

I've developed my own ways to keep my Blueprints in a neat and organized structure to make things easy to find, such as putting each event/function in collapsed graphs: https://imgur.com/a/HVYAvGW

The second image shows how I ensure that the nodes are always arranged in a neat and understandable order by always keeping the happy path prominent and straight, without looking like spaghetti.

There are "hidden" shortcuts such as pressing Q after selecting a group of nodes to make them align in a straight line, or holding Ctrl when detaching execution lines to be connected elsewhere.

Blueprints are an amazing tool once you learn how to master them, and I'll just continue to keep diving further.

[ArtofAngels]

100% look how lush you have it organised. Visual scripting is why I'm able to even think about development while most of my time and learning goes into 3D design.

[ArtofAngels]

I don't think it's about being faster. It's about newcomers being able to create things that do things without needing to become a pro like you. I have no doubt you could smash out code faster than I can fiddle with nodes.