Sign in to follow this  

Visual scripting vs Coding?

This topic is 675 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

There is a new engine again and I think it has a visual scripting editor same as Unreal. Question though when do you use Visual scripting and when do you do coding? VS is use mainly on gameplay I think and if that's the case then will there be a time that coding will be replace by VS on game engines? Cause Unreal have VS, Cryengine have VS and infact they all encourage people to use VS rather than coding(since most tutorial focus more on VS tbh. For example unreal. There are too many tutorials about blueprints.)

Share this post


Link to post
Share on other sites
Visual scripting is more for people uncomfortable with coding. Coding is more flexible in the long run and a good coder will produce better results in less time.

But many people interested in doing game design are not good enough with coding or aren't able to code at all. These people will love VS, because it will open up new opportunities. Think of the artists who wants to design a game or a game designer who wants to prototype a new game mechnism (thought a game designer should be able to code to some degree :P )

Share this post


Link to post
Share on other sites

I think Visual Scripting is a kind of thing which is wonderful on paper, but most of the implementations are not really working, and it is more hyped, than actually helping...
I still believe, that visual presentation and editing of code can and will work, but most of the current implementations in game engines (Unreals kismet and blue-print, Stingray flow etc...) missed the point a little. I may be wrong though, but the point of visual scripting is to present and to allow editing of code in a "always compiles" syntax correct way (much harder to make mistakes) + to show and present useful information about the "flow" (control structures, scopes, mutability etc...) of certain code parts, and in this regard https://scratch.mit.edu/ seems to be a much much much better implementation than unreal blue-prints, having all these positives and providing a similar experience to text-based coding.

I know blue-prints are really cool looking, and I know it is well engineered, has a fancy merge tool, but using a pre-existing text-based scripting language like javascript (substitute your fav. one here) and using an extra presentation layer/tool on top of to make it easier for non-programmers to edit it and check it's workings is a much more logical route. You immediately have and can leverage all the pre-existing tech and infrastructure, no need for a special diff tool only an extra presentation layer for the pre-existing diff tool, no need for a new debugger (you get the point here), no need for a completely new virtual machine, and all the editors, syntax highlighters, json parsers etc... still work out of the box...

All in all visual scripting is actually a pretty old technology, not a new thing at all, and so far it could not break into and take over the mainstream industry, and I guess this is due to having "much smoke, little fire" smile.png. It is still coding, it is still programming, and it will not magically make you a coder/programmer, it just makes the activity for non-experienced people a bit easier.

Share this post


Link to post
Share on other sites

Well, from my own expierience, visual scripting is just "another language to learn"...

 

It might no scare away coding newbies with ugly ASCII characters, but its still some kind of "Syntax" you have to learn and understand.

From my own expierience with Unreal Blueprint system, it is a Syntax that is not necessarily easier to learn.

 

I found the Node based Shader system of UE4 really easy to get into, and very powerful once you understood all the options. After some months of experimentation, I feel comfortable creating quite complex shaders, and even at the beginning I learned stuff fast. Its just intuitive.

The rest of the blueprint system on the other hand is just a nightmare for me. Complex code turns into a visual mess (which sadly is also true for the Shader editor), if you are trying to look up information online the documentation is lacking, and worst of all, the name of the nodes shown in the node editor doesn't match the name of the nodes in the selection list.

The logic of the different node types and flow is not really tied to the logic that would be used in a C++ script.

 

My guess is, if a Game Designer or artists takes the time to get into Blueprint and really get good at it, he would have learned C# basics by then. Maybe even more than basics, or C++.

 

 

So to me, yes, Visual Scripting really has some merit. It can ease the step from zero to coder, and it can enrich the existing code possibilities of an engine.

It does not do away with the need for a good traditional API though. Unity C# API is really good and well documented. I would say a good coder will be faster writing production ready C# code than trying to bash a visual script into a production ready state. All the while the resulting "code" will be easier to read and maintain in the long run.

 

However, if the visual scripting systems get more intuitive for everyone, they might serve well for quick prototyping. Or as glue code, so that non-coders could combine functions written by the coders into finished game objects, and free the coders to write more important stuff.

Edited by Gian-Reto

Share this post


Link to post
Share on other sites

Visual tools are not scalable and do not produce long-term maintainable programs (although as the tools mature, that last may be remedied a bit -- source control integration for example).

 

There's nothing wrong with them for small simple things that do not need to live very long.  The kinds of games most beginners write will fall in to this category, so I can only see them as a good technology for introducing people into the world of programming.

Edited by Bregma

Share this post


Link to post
Share on other sites

 

There is a new engine again and I think it has a visual scripting editor same as Unreal. Question though when do you use Visual scripting and when do you do coding? VS is use mainly on gameplay I think and if that's the case then will there be a time that coding will be replace by VS on game engines? Cause Unreal have VS, Cryengine have VS and infact they all encourage people to use VS rather than coding(since most tutorial focus more on VS tbh. For example unreal. There are too many tutorials about blueprints.)

 

When to use either is entirely subjective, but in the objective sense of their express purpose, a VSL stops being useful when what you need to do is going to limit your production to a given platform (0 portability) or custom environment that is unsupported.

Their popularity in game engines is reasonable, given that game design in many cases tends to the visual, making coding in the same manner more viable than say... writing a bank's loan and interest processing schedule with them.

We are already seeing instances of Games' creator(s) expressing that they do not know how to 'program' at all, but managed to produce quality results regardless.. so replacing the direct method with a visual tool is clearly viable, but as with all things, they are not universally applicable.
Complete replacement with visual methods is unlikely to happen before we reach the point of being able to create from natural language.. describe what you want and it is created for you.

Going forward, we will certainly see them become more common.  As we did with IDEs, as we did with high level languages, as we did with Assembler over Machine code.
It is just another step in the evolution or programming.

(too many tutorials about blueprints)
I felt the same way when everything turned "Object Oriented."

 

 

Visual tools are not scalable and do not produce long-term maintainable programs (although as the tools mature, that last may be remedied a bit -- source control integration for example).

 

There's nothing wrong with them for small simple things that do not need to live very long.  The kinds of games most beginners write will fall in to this category, so I can only see them as a good technology for introducing people into the world of programming.

I would be curious to know what you see in a VSL as limiting to scalability.

"small simple things" && "most beginners" -
While they do lower the threshold for beginners to enter the field and begin learning, they are not by any means limited to or centered around that.

The most used VSL currently is that in UE4, Kismet.  It has already been central to the development of a number of AAA Titles, and is a key production tool in dozens more currently in production.
From more recognized titles like (Lionhead Studios) Fable; Legends and (namco) Tekken 7, to EA and upcoming games like (wildcard) Ark and inXile's planned rebirth of a franchise with Bard's Tale 4.

VSLs evolved quickly, and in their (general) present state, offer access to all of the portable features of their parent language. And of course, if you want to reach deeper into a given platform at the cost of that portability, you can always write that into the VSL.

Share this post


Link to post
Share on other sites

 

 

Visual tools are not scalable and do not produce long-term maintainable programs (although as the tools mature, that last may be remedied a bit -- source control integration for example).

 

There's nothing wrong with them for small simple things that do not need to live very long.  The kinds of games most beginners write will fall in to this category, so I can only see them as a good technology for introducing people into the world of programming.

I would be curious to know what you see in a VSL as limiting to scalability.

"small simple things" && "most beginners" -
While they do lower the threshold for beginners to enter the field and begin learning, they are not by any means limited to or centered around that.

The most used VSL currently is that in UE4, Kismet.  It has already been central to the development of a number of AAA Titles, and is a key production tool in dozens more currently in production.
From more recognized titles like (Lionhead Studios) Fable; Legends and (namco) Tekken 7, to EA and upcoming games like (wildcard) Ark and inXile's planned rebirth of a franchise with Bard's Tale 4.

VSLs evolved quickly, and in their (general) present state, offer access to all of the portable features of their parent language. And of course, if you want to reach deeper into a given platform at the cost of that portability, you can always write that into the VSL.

 

 

Kismet has been superseeded by blueprint AFAIK... but you most probably already know that and made a typo.

 

I think if you start developing more complex Blueprints, you will see where visual scripting stops making sense. The visual chaos is just not worth it. Of course you can organize the script into smaller parts and use Macros and whatnot to make it visually more managable. Still, harder to read than well organized code in a good IDE for sure.

I second Bregmas concerns about Source control. Given that I don't know really if the blueprints are stored as ASCII or binary, the version control options might be more limited than with C++ code.

 

I would dare to guess that AAA titles using blueprint are not using it as their sole, or even main programming language, with most of the games (more complex) logic still being written in C++.

There is a tangible gain using visual scripting to allow Level Designers to create the small, simple scripts needed to get their levels going (open a door when the player gets near, stuff like that)... or give Game Designers a tool to prove if their newest idea MIGHT be a good addition, without disturbing the coders from working on more important stuff.

I don't think we will see big AAA titles firing their coders anytime soon and shifting their responsibility to the level designers and game designers. And I don't think a programmer will be using visual scripting for anything more than where it actually makes sense (simple quick scripts, prototypes, shaders)... if C++ is the quicker way to do it, and you are fluent in C++, why go through the whole Blueprint hassle?

Share this post


Link to post
Share on other sites

In my continuing study and practice of programming, I have found that the true "skill" of programming is logic and reasoning; problem solving.

 

The best support of my stance is here:

https://www.youtube.com/watch?v=hx_pmZprWSs&index=3&list=LL1m4o4bmZmQbsEusgH5FX4A

 

Whether it be a visual scripting system, Python, or C++, you can't do anything useful without the ability to solve problems using logic and reasoning. 

 

I would use both if I were you. Don't let tradition hinder you. 

Share this post


Link to post
Share on other sites
I am using a node based spell editor for my current project and it is great. I can treat abilities like a resource that can easily be swapped out on different characters. Its also faster to write the abilities using a GUI than by coding, if the GUI based script is ever missing a feature, I can just create a new code to cover that functionality.

Share this post


Link to post
Share on other sites
There are certain things we do in programming where having some quick way to define our own DSL inside our source code itself would be ideal (ideally in a manner cleaner than preprocessor macros or template metaprograming). Visual and Text both have their own strengths and weaknesses, but they're both just different representations of information that could be represented in lots of different ways.

If we could quickly and easily define our own optimal representations ourselves, I think that would give us the most convenience, flexibility, and power. Edited by Nypyren

Share this post


Link to post
Share on other sites

This topic is 675 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this