💡Visual Scripting
Why text by scripting is easier and faster to learn and do and yields far better results.
Last updated
Why text by scripting is easier and faster to learn and do and yields far better results.
Last updated
Consider supporting us as a GitHub Sponsor and get instant access to all our Unity assets, exclusive tools and assets, escalated support and issue tracking and our gratitude. These articles are made possible by our GitHub Sponsors ... become a sponsor today!
1st let me come right out and say that I am not a fan of visual scripting for general programming, or really any use case.
I understand that some people are intimidated by the prospect of learning general scripting and programming.
I understand that some people think it will take too long to learn scripting and that somehow visual scripting will make it faster, easier or just somehow better.
My goal with this document is to help people see that learning to write the types of scripts you would need in Unity is easier and far far faster than learning to use Bolt, GameMaker or other visual scripting tools.
My main arguments are this:
Scripting is simply typing words. You probably already know how to type, so you already know more about scripting than you likely do about a particular node graph editor (what those visual scripting tools really are).
Second, the "hard part" of creating a script isn't the typing of words. Its the understanding of systems, data structures, how to manipulate all that to get the desired results ... the "Programming" of it. Visual scripting DOES NOT change the programming aspect, in many cases it makes it harder since visual scripting tools are always far more limited than text based scripting so you often have to be more "clever" with how you do things. How can I say they are always more limited? Visual scripting tools write script for you, they are not black magic that is an alternative to code. They simply help you write code, they are thus always behind the current state of text based scripting or at best almost (but never quite) as complete.
Node graph editors (the visual scripting tools) are all proprietary. That is they are made by and maintained by someone. As a result there are fewer resources and less general support for them when compared to standard tools and concepts such as programming languages. This also means that upgrading versions becomes so much more error prone when you use visual scripting tools.
In contrast C#, the primary scripting language used in Unity, is a standard and open language with a truly massive amount of resources available to you. The language does get updates but is extremely stable due to being so wide spread.
Perhaps its the overwhelmingly large number of resources that have put you off learning, so to help you narrow that down to just 1.
This course is free, doesn't take long at all and will take you from "installing Unity" to creating some of the most common scripts you will need in Unity.
This course goes on into more advanced subjects if you would like to carry your knowledge forward.
I can say if you start now with the program I linked you will have your first scripts written and working possibly in minutes maybe as long as a couple hours.
Exactly how long depends on the person but I can say logically it would take less time to learn to do a thing in script than it would to learn to do the same thing in visual scripting.
Why?
The "hard part" to learn is what can be done and how to do it i.e. the "programming" part. You have to learn the programming part, no matter how you program. Whether its dragging blocks or typing words. all visual scripting does is reduce the things you can do and remove the need to type (most) words. it does not remove or even change the process of learning system design, understand data structures, etc.
You already know more than you think you know when it comes to scripting by virtue of already knowing how to type. When it comes to learning a new node graph editor you know nothing, so you already have a head start on learning scripting.
There are far more resources, larger communities and far more mature and developed tools, courses, etc. for text based scripting/coding than there is for any flavour of visual scripting tool.
I can tell you from experience that many things are far more complicated to do in visual scripting nodes than they are in text based script. In some cases its simply not possible to do in visual scripting, or cant be done in a way that is functionally performant. Its very common that the "visual" solution is massively less performant than the text alternative. This is due to many reasons that cannot be compensated for by better node graph editors or better use of them. Its fundamentally an issue with how you're creating the logic.
If you take the time to understand the basics everything else will come faster and easier. The fastest way to reach your goal is to do it the right way, the first time. Just a little quote form James that I find I use a lot.
So start scripting now. The time you spent reading this far in this document, you could have gotten through your first script in the Junior Programmer course I linked above. Assuming you skipped the how to install Unity. I assume you already know how to install Unity.
The thing to understand is that the "hard" part of learning to script is the programming part, that is learning how to design and implement systems that yield the desired results with minimal resource (CPU, RAM , etc) used.
Visual scripting does not make "programming" "easier" you still have to learn how to create those systems, why they work, when to use them, etc.. All visual scripting does for you is makes it so you can drag and drop nodes as opposed to type words. Consequently that also means it makes it so you cannot use the full power of the underlying language and APIs.
I still insist that you already know how to type words faster than you likely know how to drag and connect nodes.
You also already have prebuilt knowledge of written communication, that means you know more about how a script file would be constructed than a node graph.
For general scripting I really struggle to see any use case where working in a node graph would be faster or easier or yield better results than to spend a small amount of time to learn the basics of scripting.
