Maybe I’m crazy, but in this picture what’s being provided other than flow or directionality? Is that really what trips people up with coding?
You’re quoting the wrong person.
Agree, both sides seem to get frustrated. Truthfully, visual scripting is a tool that makes for an easier introduction to programming, but has limitations. I’m not against it, but I don’t use it.
One could maybe be developed, but they probably never are around long enough to reach maturity.
The limitations
- Tons of tools already exist for text (lexers, parsers, formatters, IDE’s, unit tests, etc.), so it is easier to take advantage of these things in text. Granted visual tools could probably use these things, but it would probably be a lot of work.
- Source control makes it easier to see changes. I can easily see changes between lines of text. Would be harder to write a diff tool for visual scripting (not saying it’s not possible).
- Unit tests. I can easily write test cases for text code. Again not saying it’s not possible for visual scripting, but tooling would have to support it.
- Find. I can easily do a grep (search for text) in file. Could be implemented in visual tool, but in text I can easily jump from one place to another to see different uses, harder for visual tool.
- Refactor. I can easily copy and paste text out of a method into another file when refactoring code, as general code progression is write, refactor, test, repeat. Additionally I can easily change the name of a method/class/variable and an IDE will replace every known occurrence. A visual tool could probably do this, but again it would be hard to move nodes from one place to another easily and it would be harder to review changes.
That’s just off the top of my head. There are probably more.
Probably could be done, but it wouldn’t be as efficient and would take up a lot of time to engineer. So why take the time to build it. Most people that need that functionality know how to code in text, and it’s more efficient. I’m not saying visual scripting isn’t useful to some people. It would also depend on how complex the scripting language is. Take C#, how would you handle Attributes? Or handle out or ref in a method call? Not saying it can’t be done, but is it worth the effort.
Could probably be done, but it’s not as efficient. Using visual tools is nice when you’re learning a system, but when you know a system text based processes are so much easier, quicker and more adaptable.
Probably not impossible, but is it worth it? Maybe for some? There are cool visual tools for SQL, but every time I always end up going to a text editor because I can do it faster and easier (the tool gets in my way). Text to me isn’t archaic, it’s efficient. Just like the language I’m writing in now. 
I’m not saying visual tools aren’t good or shouldn’t be built. They have uses and people can get things done. But visual tools are always inefficient compared to the language itself.
3 Likes
It’s more like a hack than loop 
Actually try loop nested inside of a loop (even using proper ForLoop macro), that’s where the current setup becomes inconvenient. And no local params per loop (you can only have local variables for function. There’s certainly room for improvement here.
Or implementing scripting language designed to integrate small scripts into graphs. Skookum Script is a very interesting thing, I wonder if Skookum guys actually working on something even better after being purchased by Epic. Many people are curious about that
This is why I don’t like VS as currently implemented. Little work, much entangled mess. And this is someone who is closely familiar with the engine and the internals of it and with BP. Imagine how it would look when those people do it who have no clue how it works? For example those designers and artists, who don’t care.
ps: I have no problem providing this tool to anyone, who needs it as long as I don’t have to work with it or with the people who only wants to use these.
I have a couple things where I see real value in node-based visual scripting: setting up state-machines, application flow-control (which is more or less the same as state machine). But pretty much it.
psps: starts around 3:50 if YT doesn’t jump there.
Unreal BP doesn’t allow time based operations like delays in its flowcontrol nodes like forloops etc
I wasn’t arguing that this was perfect, just that at a glance you can see that this is a loop, and this was all I was able to find through google images.
Edit: misread your post, thought you were saying readability of visual scripting as a whole was rock bottom
Im not sure what it is, but writing shader code is a nightmare to me. All the various concepts within an a typical shader language file is often very confusing.
I’ve written many fancy shaders in Unity using hlsl, shaderlab, and surface shader but just nothing beats a good visual editor for me. Making fancy shaders in UDK, UE4, Amplify, and now Shader Graph is so much more a breeze compared to doing it in code
This is not to say im more efficient than some engineer who’s spent their time making visual treats in shadertoy, but I - personally - am able to work more efficiently and understand shader concept easier when presented in a graph. Especially so because graphs tend to intelligently encapsulate a lot of complexity in easily accessible and searchable boxes and criteria.
that is because some facets of game dev lend itself very nicely to visual aids, shader code is one such example i feel.
I agree, and i must admit I am new to C# and working in a bubble so a lot of my perspective is skewed from the frustrations of not knowing higher end code. But I really do think that the potential to marry the existing standardized IDE environment with some new higher end modern conventions wouldn’t JUST aide people into getting into coding, I think it would have tangible benefits for seasoned coders too like reducing user error and better scaling up and down of how you want to view your code.
This is all hypothetical though, none of this functionality currently exists, visual code in all modern aspects are bare bones versions of other code and very hard to modify by the end user which very much leads to the stigma that visual code is training wheel trash because as it stands, it is.
One of the greatest benefits if there were a feature rich visual environment is people would be able to learn much faster in that environment. And if the nuts and bolts were exposed it could evolve into something better organically by the user base.
Knowing “it is a loop” is not good enough, it is important to know at a glance, what the loop condition and body is.
I think it is bad because it deceptive.
It is not a loop, it is a loop spread across multiple frames, apparently with 1 second(?) delay between iterations. And that detail is something you can only notice when you squint at a tiny little number.
Not quite.
All imperative programming languages have same basic building blocks.
Those are variable, function, class, closure (aka block), loop, branch. (… statement, expression). There is also syntaxic sugar for more complex concepts.
To get rough idea of what is going on in any language, you only need to learn which syntax is used to denote which element which is very quick. The time I spent looking at your example, is on par of what could take for, say, Pascal programmer to figure out whats’ goign on in Javascript code after seeing it for the first time.
There are outliers, of course, for example, Common Lisp, APL, and non-imperative languages follow different paradigms (for example, there’s ML family of languages for functional programming).
This does not apply to visual scripting. Because there is no indication of which node corresponds to which imperative block, and where lies distinction between data and statement, and no common paradigms. There’s “node”, but no agreement of what “node” is, conventions are not standard and vary across software.
The closest paradigm to visual scripting is electronic circuit schematic. And when Visual tools follow that idea, they become far more usable. In circuitry, there’s only signal which flows in parallel through the whole diagram at once. This concept is applicable for signal processing and highly parallel processes.
However, Unreal Blueprints mix two different paradigms, and in addition to signal/data, there’s also “execution point”, which throws the wrench into readability.
In your example. I have to stop multiple times to investigate SMALL details to make sure it does what I think it does. And in the end, it turns out it does not what I expect, because rather than immediately performing in a single frame, the diagram appears to pause execution for 1 second upon hitting the delay node.
By the way, neither behavior trees nor material editor have this issue.
I used it developing materials for unreal tools. However, compared to standard programming, I believe the loop in your example is rock bottom.
This is better:
This is also better:
4 Likes
Well, code in shaders allow you to do something like this:
https://www.shadertoy.com/view/4dGBRy
I have VERY hard imagining implementation of this in nodes.
Yeah. I only bring it up because even though actual code might be more efficient or easy for some, so others its a very hard a tedious path.
This, to me, is just like people who just have a hard time with scripting in code. In a lot of cases, if they have access to a visual editor, they’re able to breeze thru concepts that would have taken them forever to understand/google their way through. This allows them to personally be waaay more efficient with their time.
Though, while i say that, I’d hate to be limited to one or the other. I love the fact that its pretty easy to get to the hlsl code from Shader Graph incase there’s something i want to add that i can’t from SG. And it seems like Unity will probably go that direction with their dots visual script as well, which is great. I like options.
As far as i can tell, it seems like UE4 is pretty reliant on Blueprints, which to me is a downside because i much prefer scripting in code over a visual editor for 99% of things. I know that games can be made mostly in bp, but thats not a workflow i think i’d enjoy much
Again, like i said, I understand some engineer is able to make magic in shadertoy. They might not even be able to do some of their magic in any version of a shader graph to come. But /for me/ a shader graph helps me to understand many concepts that would illude me otherwise. That, and i work much faster in a shader graph than i do punching out code. Mainly because a lot of the concepts and methods are well organized in a shader graph for me.
But to an engineer that has been writing shaders most of their career? Probably not a necessary tool
Exactly the point I was making. Why then if they have better things to worry about, insist on alwasy telling non typists that something like blueprints “is wrong”. I don’t get the feeling that it’s becasue they are bleeding hearts tryign to help the begginer.
Using code is better …for those us who liks typing stuff into an editor. Realising that people learn differently is where the rest of the argument falls appart. Not that hard to learn for you and me maybe, but perhaps not for someone else. Not to mention that code reuse is a lot easier to copy and paste and then modify.
However, whenever some Indie developer/hobbiest comes and says that the fact that Blueprints allows him or her to actually make a game,in a fast and fun way, there is a traditional programmer who in fact doesnt have anything better to do it seems, than to tell that indie dev they are wrong…passionately so in most cases.
I think arguing about it is losing focus. Why are the begginers using VS instead of choosing to code? What can we do in the tool to make it better, easier to use, more approachable?
The only reason I can see for so feverishly being against Visual Scripting is that the programmers that has better things to do, see the better things they have to do as putting every Visual Programmer on “the right path”…their path. That to me seems like the more cultist behavior.
Someone else made the argument as well…if coding traditionally is the be all and end all, then why use a game engine like Unity at all? Why not just code it all from scrath and then the coder can do whatever they want?
Just to be clear…I’m not arguing why traditional proggraming or Visual coding is better. People seem to use Unreal for a lot of reasons - one of a multitude of reasons being Blueprints - they are making successful games.
Then you get the traditionalists, that are saying they are wrong for doing so.
I don’t get that logic. If that Indie has no delusions of having a career as a coder why argue the point constantly? Perhaps this is another reason people are actually going to Unreal. The fact that visual coding is an acceptable way to make games ‘over there’. Whereas here, perhaps they are told “just learn code” if they ask a question relating to Visual Coding.
Anyway, I am not the torch bearer for visual coding or traditional coding - as you say, better stuff to do. However, I have taken a look at Unreal and I like what I see. It is very foreign coming from Unity though so I suspect for those that want to jump ship there will be a steepish learning curve.
It does seem that their VR implementations are less hacky than currently in Unity.
3 Likes
You don’t have to know git to use it. I’ve been using SourceTree past 4 years and almost never manually typed any git command. GitLab has 10GB limit per repo, in most cases that’s enough as project can be split to submodules but in your case you’d have to make 30+ repos. GitHub 300gb would cost 30$/month.
In your case I’d use GitLab, ignore one folder, put all big files there and keep making backup of it yourself on separate disks.
1 Like
And these also get the visual coder closer to true programming. So I agree with you here.
Construct 3
Yeah look, I wasnt arguing that the way Unity are doing it was a good way, just that there is an obvious need and want for Visual Programing tools (natively or otherwise). I fully agree with your assemsment in how it is delivered.
Boy this thread really has its twists, turns and forks, and then a full circle with the visual scripting arguments(pretty sure this ones been beaten to death though hasn’t it?).
Anyone see source 2’s hammer’s features? Also pretty game changing if we were to get a bit back on topic
4 Likes
im pretty surprised UE’s shader editor doesnt have portal nodes…
@negfinity
It seems I should be your antithesis to a T:
- I have been using text programming for 20 years at least
- I have programmed in basics, python, hlsl, microcontroller assembly, c#, javascript, and read in many more language like lisp, c and c++, etc …
- I like to toss myself in problem that are above my skills level, math or otherwise, without training, I put no limit on my self
I still feel hella limited by text based programming, so much I find the format downright insulting. And if it takes 30s to decipher that blueprint, and you did know and use about blueprint, it only took me half a second, and I have very little experience with it, to see the same thing at you. MOSTLY and precisely because I can see the big picture at a glance before homing on relevant details, I discard information so much more efficiently with node flow it’s not even a contest.
Meanwhile I still have to write down text code on actual paper to make annotation so I can use that as a support, even for my own code. And I try to pack thing in ridiculous one use function to compress the information density, and I have to deal with stupid useless syntax like brackets. I DO have a sort of mental impairment, I have a smaller working memory, so I cannot hold as much data without forgetting some bit, it’s only be a real problem with programming, as soon as a code is bigger that one screen, that’s a problem, and it’s already a pain before that.
In fact let me tell you about how I first learn to code, I did it on old scientific graphic casio, it was the slowest machine in the school, everyone had fancy hp48 and ti 8x, faster in many magnitude, I couldn’t even understand the long ass complex program they were doing in it at the time. I was already making game back then, but by my third, I completely ditch the stupid command line by switching to “matrix” coding (array basically). I wrote a state machine, that you call from a main program, then it read the matrix where there were number, and that number call a sub program by passing data in reserved letters (variable where only one letter long so you were limited to alphabet + theta), these subprogram do computation, change the matrix state, change the cursor that pointed to matrix data or return some values. Now my programming was basically filling tile data, as I had a visualizer that turn number into symbol, it was super efficient because I broke free from linear reading, as it could flow in the matrix in 2d, I broke the variable limit to any number above the alphabetic number, and program run faster, because it also maximize the traversal length, and I could see the shape of the code in an instant, better code was data, and data was code, so I start doing thing people told me would be impossible.
It taught me to not get marry to the text paradigm by breaking free from it, all in my first year learning programming.
7 Likes
It also lets you have a go at making potentially catastrophic changes with zero risk, because that “revert” button is right there. Even better if you also get comfortable with branches.
That’s not quite fair, though, since your code and the Editor aren’t the only things which can change. Windows Update is one culprit for making changes transparently under your feet.
Without details of your exact setup we can’t tell what specific thing might have lead to that, user error or otherwise. Same deal with the issue where a bunch of performance was lost. Getting VC set up and working nicely the first few times definitely is a pain, and - when it comes to Git in particular - the fragmentation makes Unity’s current state look like the Promised Land.
For the busted material, for me that kind of thing usually happens when I forget to select the relevant file while making commits. One of the pains of working with Unity is that certain files you’re not working on tend to get small changes applied to them*. They don’t tend to make any difference to the project, but they do clutter workflow for the version control process, which has contributed to my making mistakes like that in the past.
- It looks to me like these are runtime values getting mistakenly serialised, possibly because they’re also used by Editor scripts. Almost certainly avoidable, and something I should look into at some point.