Unity is really missing a native Visual Scripting Tool

What might be nice, (I don't know if Unity has the already), is just a node GUI, that you could use for whatever purpose you wanted. Just like it has text boxes and drop down menus that you can use in your game. (I don't know if you can already use the node GUI from the animator window?)

And then for a particular feature of your game that you particularly felt would benefit from a node system, you could hook it up to some code.

One example might be for a level designer, you could just link up some boxes with nodes to specify a series of caves and the links between them. Or maybe specifying the links between stations on the London Underground.

As well as a node GUI, you might also want a grid GUI. Useful for making games like Tetris to specify the shapes.

Some sort of general graph based GUI might have all kinds of uses, if the graph could be read into the code as a Graph object. You might even use it to draw neural networks.

Then you could say "these bits of my game would be best specified by a graph" and these bits by code. Yeah, you could use a 3rd party graph editor and load it in as XML or something. But built in would be nice too. Especially if the graph could be displayed in

 

The one used for Mecanim is (was?) exposed, but undocumented and unsupported. So you can muddle your way through and make stuff with it, but anything and everything could explode next time you update Unity.

 

https://forum.unity.com/threads/simple-node-editor.189230/

 

Okay guy F**K NODE SYSTEM seriously, you get hung up on that too much.

Visual coding don't mean:
- spaghetti monster node base system
- drawing

It mean going to a new metaphor from text based input. The desktop is a visual metaphor representation of file system and replace MS DOS or CP/M for the hold 80s kids

Here is an event based metaphor for game in construct:


Here is Rpg maker, I have made an action platformer and a pathfinding algorithm with this in the 2k3 edition without modifying the soft:


The result looks like regular code but nothing is actually type as far as code go. You can't make any syntax error only logic error.

I'm not saying it's good or representative, just that we have option to explore, and maybe that hasn't been done yet! That's what I'm trying to figure out. SO stop complaining about the spaghetti monster. Also text code is equally ugly, see the drama in the unityscript replacement thread
https://forum.unity.com/threads/unityscript-2-csharp-conversion-tool.487753/page-2#post-3288679

 

I have proposed earlier an extension of IDE with progressive itemization of the code (because code is strongly structured and can be parse easily), with floating declaration like desktop windows. What I was proposing is simply to get current IDE idea up to their final conclusion but was originally imagined as an extension of the rpgmaker way with some sugar for efficiency.
See here: https://forum.unity.com/threads/uni...ual-scripting-tool.414353/page-7#post-3284361

Well I'm discussing it informally here to sharpen the thoughts, but I would like to do something about it, but I still have a backlog of task to do lol. This discussion is a way to work on it without really working on it. I think that once I understand more clearly the problem I could make a crude mock up.

Well I have been making game since I'm 16, that's 20 years ago lol I started on venerable graphic casio, I made a pong and then a tron like game that was the first and only game on the platform playable by two people in real time at the same time lol.

But I'm a designer first, text is just hard to parse to me, especially when I go beyond simple features and start plugging them together and having to deal with interruption, transition, save and reload, switching, memory and process management. And the game I want to make are heavy on this, I'm sure all advence programmer can solve case like I'm going to present but for me, rotating implementation easily overwhelm me.

For example say I want to make a game like mass effect, but with developing the npc companion bonding gameplay a bit further:
- Character would have their own personality defined by preference (judgement of appearance) and standard (judgement of actions)
- they also have internal mood that change based on a set of occurrence that can originate from 3 sources: story triggered occurrences, random background occurrences (private lifes and concern), world event base occurrences (which depend on player's actions and various other elements).
- the gameplay is simple, it's based on the idea that you must intimately know the npc to adress his feeling, randomness and background occurence make sure you can never assume what's wrong, which mean you have a gameplay of inquiry and response, ie the mood is both a tell and modifier of behavior, how you react to it will define your relation with the npc, so you need to figure out the problem and how to respond to it while balancing your resources relationship with the character and the all others, after all you can use the information in a way that make your relation decrease, but have you some material gain.

Now I can certainly code that in a prototype, not sure it will scale to a full game, nor it will scale to modification if the original gameplay idea need more modification. The thing is that iterating on the gameplay is as further away from iterating on the code maintainability, it add distance (you have to architect the code first, in between forming the idea and executing something, which can be many days for me), you have to stop and fix bugs, many because you did stupid logic leap and it takes a lot of debug boxing to resolve them, adding more time and less thought about how the gameplay actually works. I mean those occurrence who will manage them, are they stored per character or will I need a global drama manager, all those move the dependency quite dramatically and can impact how fast you set up a scene for test case of balancing the gameplay.

A lot of that is slowed down because the code look nothing like the problem space, which is interactions and not procedure. I mean when you want too object to communicate, you have to either do it naively, like explicitly referencing them to each other, or use one level of indirection, like implementing a message system, that only further hide relation objects hide, and since all the gameplay logic is about relations, most of your bugs or leap of logic are hidden into multiple place. If you want to modify relationship between object (that define interaction) or rethink the architecture, now you have to hunt dependency all other the place, and forgetting a single one can create hard to track bug, bug you will feel stupid because you forgot that one change that text obfuscate. Node base are spaghetti but they have one thing, it is that all relations are super clear and jump at your face just by looking at the structure of the graph. The thing is that the little schema I made to keep track of relation in the architecture for the game loosk nothing like the code anyway.

And I kept mentioning excel, while excel isn't generic at all, it doesn't hide relation at all! I mean a lot of so call good practice are useless because they make no sense in this presentation, for ex: no need for scope because scope is a band aid to "variable identifier". And I'm going to say it now, variable identifier is the devil, it's the one thing a lot of "good practice™" try to hold into his hell. What it does it that it makes data hard to track, something node don't have as a problem and which make them palatable to so many non programmer, it can teleport data anywhere, can be easily forgotten, create dependency, require attention just to find the good name (I mean a big part of refactoring is changing the name of variables and moving them around), removing you from the flow of solving the actual problem, similarly named variable can be mistype and flow seamlessly into one another attribution, create war between people around convention, it's the babel tower of programming, they are too implicit. And so many code structure are just not great at being seen in sequences like text impose.

While not visual scripting per see this blog hint at thing that could be done, they are using scriptable object to short circuit modelling all relation with code.

Often I use script attached as component to have just a declared list of gameobject to drag in the inspector. If I could just go on object and add a list without coding it that would a great step (well that's just an example, because once my script is done, I can do just that, I'm asking if it can be generalized).

Attachment in the editor instead of declaring relation in script is way to make the structure a bit more visual, it's not hidden in a variable identifier, it's clearly expose as you can see what data is contained by an objects, just like excel. So looking at the object inspector tell you what code it hold and what relation it has with another objects. That's not programming per see, but it does address a shortcoming of the problem of obfuscation that text code, it make chance easier, if only it was more coupled to the practice of programming, instead of jumping between a ugly text editor and the editor. Which node editor do, you can see the variable data as they mutate.

Now maybe we can it a compromise, "text node block" basically low level sequential expression can be type as usual, but inside visual node, that are link when appropriate to each other in a non linear way, the spaghetti is contained within the text sequence and we only branch to relevant non linear piece of code, exposing hi level structure. Who know?

You were saying it was avisualization problem, I don't wee how it doesn't prove we cannot visualize it, basically a recursion is a loop, it can easily be identified on a graph with a loop that come back to it's node, and we can recognize it's a recursion (by the nature of the node) and simply mark it as such, much node editor can detect loop already, it's a simple graph theory (a descendant loop back to an ancestor or to himself, you basically compare the depth number of the node).

I don't know, as long it's turing complete and has proper I/O access to the relevant elements, it's generic enough!
Anyway given enough boredom, anybody can make game in any turing complete system: https://carywalkin.ca/2013/09/17/vba4play-making-a-maze-part-1-your-first-maze/
Let's not forget about minecraft redstone which are just basic trigger FFS!
Generic enough isn't the problem really, binary is the minimum you need, that's just two number. Complex game where made in assembly, you don't even have all those fancy best practice like encapsulation or named variable.

You don't need spaghetti, code is already unreadable as it is and you still have to pour into the reference to know what to use, and that's UML anyway. But with a proper paragdim, would you need concept like delegate? Node base already do away with variable, you have output and input at the place.



Anyway, I think this post made thing a LOT clearer to me as to where I struggle with code, I apologize for the length lol

 

Those examples were something that I compared to DSL - simplified, non-programmer-friendly representation of programming logic for a specific domain.

The problem we have is that Unity is a much more generic game platform than RPGMaker, for example. Maybe we can create a RPG platform, or a FPS game framework that can mostly let developers create their content without writing any code.

But as soon as we expand our scope to cover everything Unity can do now, from 2D puzzle game to MMO, I bet it has to be some sort of an insanely sophisticated node based system, as any other pure-GUI based approach will most likely fail to meet such requirements.

I admit that recursion wasn't probably a good example that is hard to visualize. But still, visualizing some process and constructing that process visually is quite different things.

There are tons of debugging and reverse engineering tools in the market that can generate visual representation of a codebase or running process, but the real question we should ask is if we reduce all the details of programming language elements into graphical components to compose them visually, would it be more intuitive than the traditional way of coding without losing much flexibility or features.

I agree that you can make great games in many different ways, including those that people consider to be odd. There are many esoteric programming languages, and I could probably open up VB6 or Excel to create a very popular puzzle game, if I have enough motivation (and maby an odd sense of humor too).

But the fact that you can do something in such a way doesn't mean everyone can benefit from doing so. I know some programmers have quite a big ego, but they didn't invent such concepts like encapsulation or polymorphism to simply brag about or out of a whim.

They discovered that the biggest challenge in developing softwares is not memorizing language syntax, but finding a way to keep the codebase maintainable and extendable, and such principles and paradigms are what they came up with as a solution to that specific problem.

And reducing a task to its minimal components doesn't always make it easier. A 3D mesh is just a collection of vertices, but removing all complex functionalities of a modelling software except adding, removing, moving each vertices wouldn't make it any easier to create models using that program.

Likewise, the fact that the final output of any programing language is binary data doesn't mean that it'd be easier to directly manipulate them without using any higer level abstractions.

 

I'll open by saying that I have notice a major and interesting difference between my argument and non programmer with programmer:
- the former seems to insist on viewing the data (the noun?)
- the latter insist on maintaining the command readability (the verb?)

Basically we don't agree whether programming is either:
- modifying data with command or (excel allow me to see data!)
- using command to modify data lol (dude that's not programming, that's debugging)
Which is kind of the two face of the same coin. lol

There is also a lot of confusion from programmer from the language structure, it's interface and it's paradigm, so discussing the interface apparently mean you mess with the structure. That argument don't make sense when we have asset on the store that literally replicate and generate c#, structure, ie aside from spaghetti, inherit all the expressiveness and concept of c#, so it's not a language problem, just a presentation problem (the so called spaghetti monster). Which is the core of what I'm really discussing!

I think you are missing the point, I'm not talking about RPGMK, I'm talking about the interface, rpgmk is limited the same way than the scripting tools of the neverwinter night are limited. RPGMK is indeed a dsl, but it's interface can be generalize, and that's the core of the argument, that to produce similar result, you don't have to type or rely on text interface. The end result is almost indistinguishable from typing in the case of rpgmk, and is just an annotated version of a text input in the case of construct.

Neverwinterlight use C like structure, it has all the basic elements of programming language, but some other are simply omitted, so ity's not generic enough, it's a dsl. If I were to use the same logic than you, I would say that c like text interface are not suitable for complex project because neverwinter night prove that ... that's non sense.

Also why you come back to node base when rpgmk ISN'T!!

The process of doing that platformer was exactly the same as with any language, I put down the variable, use basic mathematics operator to make a collision system and the IO to get input in and visual out. You can't define custom function inside rpgmk but that's what "common event" are in anything but name. That's why I brought it up, it's nearly the same. Given that rpgmk use an object base coding like unity, each object hold its code, it has defacto encapsulation, this hasn't disappeared just because it's visual! Nor does it disappear when you use c# base visual node system. Interface != language.

Anyway that's loki's wager, we are starting to argue semantic and it divert from the main point, how to make better programming interface (ie visual).

I think it would be better if I go in details and in depth in what works what doesn't and why! and where the strength of each interfaces works and how we can mix the best of all worlds.

In fact I have expressed the idea that I'm not satisfied in how most current visual programming are implemented, so just slapping a visual script would be bad for anyone. But because it's bad, doesn't mean it's not an idea that can't work, we need to see why it's bad. So let's look at a single example:


https://forum.unity.com/threads/released-nottorus-unlimited-visual-programming-plugin.395750/page-6

This is ... kind of ... FUGLY, I'll pull my @mysticfall hat here and say yeah, we don't need that! LMAO

But why it is bad?

Well the visual language don't express the nature and concept of the code, I would say it actively obfuscate it, that's bad!
- start is a function that contain a loop
- the loop contain a debug statement
- a debug statement follow the loop.
The node don't convey any of this and makes it like they are linear sequence of command, the next output from the debug statement feels like a nag. That's just bad.

More importantly, when you lean programming you are introduced to code diagram, which is already visual node, so even at it inception code where inherently represented visually:

And those diagram do a WAY better job at communicating the nature of the code than the fugly example above. Also the node are a bit heavy visually, they aren't well design visually period, they are bloaty and don't communicate their intent well.

So the question I'm asking:

1. Is visual programming bad because of ill thought bad implementation rather than bad fundamentally?
2. Maybe the reason so many people recoil at them has nothing to do with the underlying idea?
3. DO we need visual everywhere or DEGREE of "visualness"?

I will try to explore that in the future.

The c# is also fugly as hell, ask any people worry of programmation and the needlessly verbose syntax is one of the concern, compare to python like statement.

Code (CSharp):

1. Using system
2.  
3. class tutorial(UnityEngine.Monobehavior)
4.     start:
5.          do
6.             debug.log "do code"
7.         while True
8.         debug.log "finished"

The point here is not to contrast language features and structure, but visual interface. The choice python make to maintain clear readability of the code are just less cluttered.

 

@neoshaman I think the first third of that is on the English language tense between programming to analyse existing data and programming to deal with data/events that haven't happened yet

Anyway, when it comes to programming languages, they have strict specifications, you can write a preprocessor for C3 that gives you Python-like meaning whitespace so you don't need curcly braces for blocks, but you then are not programming in C# it's a C#-like language at that point. In the same way that writing Unity scripting in C# isn't programming in C++ even if you build using il2cpp which transforms the C# code you wrote into C++ as part of the build process.

Finally, I think while you may like the additional fidelity of the "flow chart" to illustrating flow, I think it's a fairly low level abstraction where the diamond is equivalent to an "if conditional goto label"

 

Most people who are new to the domain of programming gravitate towards trying to solve this problem by visually representing code. It's natural given limited knowledge of the domain, but misguided.

The generally accepted approach is to simply reduce the code footprint,abstracting out parts of the system that can be represented by data. That together with some creative use of domain specific languages, can make complex systems much more accessible to non developers. Not just being able to do more but to understand better how it works.

Why this works is because just being able to visually represent code doesn't address the issue of non developers have no clue about system design, architectures, data structures, etc.. Which is a large complex field that can mostly be reasoned about without code. So even if code was visual, it wouldn't help you create software systems that didn't suck.

FYI while there has been some limited work in data driven design and DSL's in the game industry, most of that has happened in other industries. Mostly because dynamically typed languages offer better tools for this, so it's just much more evolved where those languages are used.

 

Man I get caught on these interesting problem Don't I? lol
people who are bored just skip this, it's like a drug to me LMAO.
I keep digging deeper. YOu have no idea how many thread and article I'm reading to make these post, I'm line on fire

The phrase are just condensed version of the two perspective I'm noticing, I would say it's not just the tense of the language as much as where the concern of each party really is.
Non programmer care about doing the thing they want, what I called the "data", programming (as in the current interface, not the practice) is in the way of doing that. Meanwhile, for programmer doing the "data" is more or less obvious, so they are focusing on the "command" to make it happen, that is the actual practice and ritual of programming.

I mean consider the argument of unityscripts vs c#:
- Non programmer will tell you that it's about not having to care about unnecessary things (to their design) which allow to focus on what matter.
example:

https://forum.unity.com/threads/unityscript-2-csharp-conversion-tool.487753/page-2#post-3286720
vs
- Programmer will tell you about the ethics of language irrespective of the design that is being implemented.

https://forum.unity.com/threads/programming-what-is-better-javascript-or-c.413585/#post-2696350

The actual language doesn't really matter, what matter is how it it present itself and how it interact with people, how it present the data and don't obfuscate itself, aka how good it as an interface.
Similarly, the flowchart isn't an example of what a visual language should be, but an example of what exposing the underlying concept mean, ie readable, just in the case of node base.
Ie the main idea is that the design should reflect important information, just like you must name your variable sensibly for aided readability, ie avoiding single letter, using convention, having variable identifier be noun and function identifier be verb, just like this visual design need care put into what it is represented.
What does visual programming mean: it might mean exposing the structure and and data of the code in a way that is easily readable and expose the logic of the model expressed by the program.

Though that does raise one question, do we need node base code at this level? I don't think so, it's too low. But I would see "node or body block" where you type inside while interfacing with the input/output of the node. Which is basically just another way to present text code in a non sequential way. But that's a maybe, we have to try in a prototype. I'll try that later. I need to focus on my backlog, I guess I got carried away by another interesting discussion™, DANG! lol

The thing is we can deconstruct and analyze what works and what don't work.

But in order to build a solution, understand the actual need of the user is important. I mean this should be part of the programmer practice anyway, to build something the user "need". I don't think visual language will supersede domain expert (the programmer) in the long term, it will just expend who can things. That was the original goal behind the compiler (invented by Grace Hopper). I mean there is a sort of historical irony to repeat the same exact argument than the time. The arguments to defend what was once at the same place than visual programming.

Spoiler: History is a repeat!

One, zero, zero, one, zero, one. Zero, one, one…

That is the language of computers. Every clever thing your computer does - make a call, search a database, play a game - comes down to ones and zeroes.

Actually, it comes down to the presence (one) or absence (zero) of a current in tiny transistors on a semiconductor chip.

Thankfully, we do not have to program computers in zeroes and ones.

[...]

If you wanted it to solve a new equation, you had to work out which switches should be on or off, which wires should be plugged in where.

Then, you had to flip all the switches, plug all the wires, and punch all the holes in the paper tape.

Programming it was not just difficult, but involved tedious, repetitive and error-prone manual labour.

Four decades on from the Harvard Mark 1, more compact and user-friendly machines such as the Commodore 64 found their way into schools.

You may remember the childhood thrill of typing this:

• 10 print "Hello world"
• 20 go to 10

"Hello world" would fill the screen, in chunky, low-resolution text.

You had instructed the computer in words that were recognisably, intuitively human.

It seemed like a minor miracle.

[...]

One reason for computers' astonishing progression since the Mark 1 is certainly ever-tinier components.

But it is also because programmers can write software in human-like language, and have it translated into the ones and zeroes, the currents or not-currents, that ultimately do the work.

The thing that began to make that possible was called a compiler.

And behind the compiler was a woman called Grace Hopper.

[...]

More often than not, the Mark 1 would grind to a halt soon after starting - and there was no user-friendly error message.

Once, it was because a moth had flown into the machine - that gave us the modern term "debugging".

More often, the bug was metaphorical - a wrongly flipped switch, a mispunched hole in the paper tape.

The detective work was laborious and dull.

[...]

Lt Hopper and her colleagues started filling notebooks with bits of tried-and-tested, re-useable code.

By 1951, computers had advanced enough to store these chunks - called "subroutines" - in their own memory systems.

By then, Grace was working for a company called Remington Rand.

She tried to persuade her employers to let programmers call up these subroutines in familiar words - to say things such as: "Subtract income tax from pay."

[...]

But what Grace called a "compiler" did involve a trade-off.

It made programming quicker, but the resulting programmes ran more slowly.

That is why Remington Rand were not interested.

Every customer had their own, bespoke requirements for their shiny new computing machine.

It made sense, the company thought, for its experts to program them as efficiently as they could.

[...]

Open source
Grace was not discouraged: she simply wrote the first compiler in her spare time.

And others loved how it helped them to think more clearly.

Kurt Beyer's book, Grace Hopper and the Invention of the Information Age, relates many tales of impressed users.

One of them was an engineer called Carl Hammer, who used the compiler to attack an equation his colleagues had struggled with for months.

Mr Hammer wrote 20 lines of code, and solved it in a day.

Like-minded programmers all over the US started sending Grace new chunks of code, and she added them to the library for the next release.

In effect, she was single-handedly pioneering open-source software.

Grace's compiler evolved into one of the first programming languages, COBOL.

More fundamentally, it paved the way for the now-familiar distinction between hardware and software.

[...]

With one-of-a-kind machines such as the Harvard Mark 1, software was hardware.

No pattern of switches would also work on another machine, which would be wired completely differently.

But if a computer can run a compiler, it can also run any program that uses it.

Further layers of abstraction have since come to separate human programmers from the nitty-gritty of physical chips.

And each one has taken a further step in the direction Grace realised made sense: freeing up programmer brainpower to think about concepts and algorithms, not switches and wires.

Grace had her own views of why colleagues had been initially resistant: not because they cared about making programs run more quickly, but because they enjoyed the prestige of being the only ones who could communicate with the godlike computer.

The "high priests", Grace called them.

She thought anyone should be able to programme.

Now, anyone can.

http://www.bbc.com/news/business-38677721

 

I would argue that the bolded part is because the representation (sequential text) obfuscate those concept. Consider Excel, it start with a big empty table, before you are explained what it does you laready have an idea, because the visual convey itself. Variable, list, array, etc... are concept that aren't greatly conveyed in text code, but are greatly conveyed in excel because you manipulate them directly. Maybe if we had "objects" to represent concept in a way that is coherent with their nature, things would be simpler. Which is exactly what the inspector do! Once you write the code you can directly manipulate a list or see the instances members, directly assigning them, without having to put "assignment code".

I mean the code is like

Code (CSharp):

1.  
2. Class character : MonoBehavior{
3.    Public string name;
4.    Public int health;
5.    Public List<GO> child
6. }
7.  

And instead of having for each character you put in the scene, like I would do in Blitz3D:

Code (CSharp):

1. void Updates{
2.     name =  "Lonk";
3.     health = 10;
4.     Foreach (GO c in Child){
5.     //initialize stuff
6.     }
7. }

You just open the inspector, define the size of the list and assign each elements directly.




That's order of magnitude faster and more interesting than typing, it allow fast iteration and you don't have to misspell name with another similar variable, and hunt that bug (unlikely to happen in that trivial example but it does happen).

Now what if we had one step further? What if we could declare the variable directly on the component inside unity without opening your notepad IDE?

OF COURSE, this is just an example, and this particular one don't scale that much for a complete program, as you are demanding proof of something that is in dire need of actual design. Which is the point of keeping asking these question, challenging the status quo and investigating problem.

For example let's addressed the issue with node base visual, which might not be a solution for complex program, but we need to know why and how text base dodge some of the bullet.

 

Programming in UnityScript is programming, and much of the arguments in that thread are about people not wanting or feeling comfortable learning something else (for good reason, from their perspective why should they be happy being forced to change?), and having a preference for one programming language over another (which is OK, ofcourse). You'll find similar statements have been made over and over for AS2 to AS3 or VB6 to VB .net or... it's nothing at all to do with visual scripting, I suspect, or different thinking (UnityScript is not inherently more visual than C#) beyond that those that are generally most affected are usually amateurs dabbling in what is likely one of their first computer languages.

I feel continuing to call these programmer's "non-programmers" sells them short and is possibly condescending to some. If you program a computer to manipulate data with Excel you are programming, if you use a visual scripting tool to handle how game objects should react you are programming.

 

I'm really just saying they have different concern than people who cling to the text interface programming. Am I condescending to myself too?

I'm not saying we should stop programming, I'm talking about the interface we use for programming.

 

I think I also start to see where our perspectives differ, since I see programming to be a process of modelling real world concepts into a computer system, which is not just a collection of commands to process bunch of data.

But I'll try to elaborate on this point later.

Another important differences in our respective understanding is the meaning of 'paradigm'. While I think your usage of the word is largely correct, I'm not too sure if we have the same understanding of nature and scope of paradigms of existing languages like C#, like object oriented, or functional paradigms.

I haven't researched on visual scripting options available in Asset Store, however I highly doubt if any of them would allow me to employ the full object oriented paradigm in a similar expressiveness that C# provides. Please let me know if there's one that actually does it, and I'll see if I was mistaken on this point.

The reason I came back to node based concept is because I believe it could be the only practical form (at least among those that we've seen so far) that a visual language can take to be both as generic and as flexible as conventional programming languages. It tends to lose maintainability in the process and suffers from lack of well estabilished design principles like design patterns, but it's another matter to discuss though.

Now, I'll come back to the problem with paradigm as I promised earlier. I have an impression that you are basically seeing a program as a flow of control statements that manipulate data. While this can be true for most rudimentary scripts, or for some limited domains, it's hardly how experienced developers of a major language like C# would understand it.

I said earlier that programming is essentially a process of modelling more than anything else. And 'modelling' is, in other words, a process of generalizing and abstracting real life concepts of a domain into programming language counterparts.

A programming paradigm, as it is generally understood among experienced developers, defines how we approach such a process. In an object-oriented language, we usually see everything as types which have properties and behaviors, and try to model real world concepts into hierarchies of such abstract types. In a functional paradigm, on the otherhand, we try to see everything as mathmatical functions, and we compose them to make data pipelines and manipulate them.

A paradigm is much more than how to assign variables or perform a loop. While beginning level programmers might feel it difficult to get accustomed to language syntax, it's hardly a concern for more experienced ones.

They rarely have diffculties in remembering the correct syntax to write a for-loop, rather they usually spend their time with such a question like, "if both hair and a weapon is both something attachable to a character, how can I generalize that concept as an interface?", or "Should I use ISet instead of IEnumerable here to make my intention clearer?", and so on.

Certainly, you can create great games using only the most basic elements of a programming language, like conditional statement, variables, function calls, and etc. You may argue that we don't need anything like polymorphism, lambdas, more advanced data structures, LINQ, delegates, or whatever you feel unneccessarily difficult to understand.

However, all it does is simply lowering the entrance for non-programmers at the expense of expressiveness and flexibility of the programming language. While it makes it easier for them to jump right in and begin to construct game logic, it will limit how far or complex they can go without making a complete mess that is utterly unmaintainable and extremely hard to understand or extend.

Many video games are not too complex to reach that stage, and they rarely need to be continuously maintained over extended period of time, like business applications do. For that reason, I believe general purpose visual languages can have their own value and place in game development.

But to go beyond that, you either need to limit the scope of the language to a very specific aspect of game development, like constructing dialog trees, or invent a very sophiticated system (like node based ones) which isn't really easier to learn than conventional programming languages.

If you take away such higher level abstraction tools like polymorphism, design patterns, functional APIs, and etc. and force people to use only the basic elements that non-programmers can understand, it's basically abandoning most of what the whole software industry and academia have come up with to make software development maintainable in the past few decades.

You can lower the learning curve, or make a programming language more expressive and flexible. But you can't really achieve both at the same time, because they are essentially in a trade off relationship with each other.

 

This here is the biggest misunderstanding we have in this discussion. You think it's about simplifying the concept of programming, surprise it's not! It's all about reforming the INTERFACE in which we express these concepts!!! I need more exclamation marks here but I'll restrained myself.

I'll give one example and not dwell in wall of text:
- Variables is a programming concept, it's about storing and retrieving mutable data.
- Variables identifier is about expressing that concept, in order to manipulate it into the text format of code typing.

All the example I ever give is about expressing the former in different format, not break programming. Ie how to express all these concept in way that make them more natural and apparent (like how table are naturally represented in excel and obfuscated in text format).

I apologize anyway, My thought kinda evolved during this discussion, so maybe it wasn't that clear in how I put it down, because I was uncovering this myself with words too. lol

 

Then I have to ask, what kind of graphical interface do you propose to represent an Abstract Factory, or SelectMany API in LINQ, for example?

As I explained in my previous post, programming is much more than declaring bunch of variables and loop, branch over them, at least for experienced developers.

If you simply say "we don't need such things", it's just making your new programming language less expressive and less powerful. And there's a vast gap between what a modern major language like C# can do and what you can achieve by combining only variables, loops, branches, and etc.

 

I just had this brilliant idea! Hear me out...

You know how when you create a public variable in your C# script, it shows up in the component...

What if you could do it the other way! Like if you could choose from a drop down to add an int/float/array/Color/Vector3/etc. (it would have to be quite a long menu with a search box!) to your component. Then it would be automatically added to your script.

Now, you might ask, why would you want to do that? Well, I'm not really sure. But maybe these public variables could be get and set with the MecAnim system. And it might be a quicker way of creating public arrays. I don't know. I don't have all the answers!

 

Typically we call this a solution in search of a problem. Fortunately adding this sort of functionality to Unity's inspector is trivial so you could implement it and see how practical it is over a period of time. Just need a text box for entering the variable name, a button for each of the common types, and the necessary code to modify the code file itself.

 

If I recall correctly, many '4GL' and CASE tools from the late 90s and early 2000s tried to implement such an idea, especially for designing GUIs.

With such tools, you could drop a button component into the design view, or add a new property into the class diagram editor, then the platform would automatically add corresponding statements in your source file.

It didn't really take off though, for various reasons. As for GUI building, the problem was mainly that it's not always easy to maintain two-way synchronization between the GUI status and the code. So, some of the tools made such automatically generated code blocks uneditable, which annoyed many programmers who had to use them.

Eventually, they found that it's much better to construct GUIs declaratively, using some sort of a metadata language and provide binding API to manipulate the components, and it became more or less a norm since then.

As for CASE tools that synchronize UML diagrams with source code, they are still used from time to time. But from what I can see, they also never really took off, as they've largely failed to convince programmers that it can be more, or at least as productive to write softwares that way. So their main usage today is largely documentation purposes.

 

You got caught up in example I pick to illustrate the matter because they were obvious.

However it did bring to mind why that stuff, I didn't say, is actually important ... those are the primitive of the language, that's how you "extend it".

Speaking of which:

That feels like a trick question for an interview, not sure if you are genuine.

Be glad I didn' say that! But that's a weird follow up to the previous quote.
That is those concepts, which are for most language agnostic, were implemented using the primitive of the language, ie so called "only variables, loops, branches, and etc". And of course, class, abstract class, etc ...

So to answer the question "what kind of graphical interface do you propose to represent [insert concept here]", well that's what we... I mean I is trying to figures out, and to do that highlighting the limits of current solution is the way to investigate.

I mean the abstract factory pattern already has a visual form in UML. And the primitive are classes, method, inheritance, etc ... which are the thing we must first figure out to represent to allow the language to not be close and allow the creation of new "views" to manipulate, so maybe views are also primitive to consider.

And ultimately, you are dismissive of the problem I have with text format of code, that is the heavy obfuscation it inherently have, just the abstract factory pattern will have you code dispersed in many file with no logical relation between them, totally indistinct from each other, if you don't know the code prior to reading it. It doesn't self document, you need extra documentation to make anyone else up to date to find the file and their relation. I mean don't you think text is not the best for that?

 

One of the weirder features of C# would be helpful here. With partial classes you could keep the actual code necessary for creating the GUI in one file and have the code intended for the programmer to modify stored in another.

https://docs.microsoft.com/en-us/do...asses-and-structs/partial-classes-and-methods

 

Lol you don't have to have all the answer, iterating, investigating and thinking through a problem is how we design thing, we do not impose a solution ready made from nothing.

The way I see this is that there is 2 things here.
1- There is the idea, that is: declare variable of component directly inside the inspector. That's the intention.
2- There is a proposition of implementation of that idea: That is clicking a button with a drop down. Which is an interface and navigation issues

Observation:
- there is two type of things to select:
a. primitive type of the language (such as int, float, array, etc ...)
b. "derived" structures from these primitive: (colors, vector3, internal classes, etc ...)
- There is a finite number of of a but a potentially infinite number of b.

Why text format is generally used here, pro and cons:
- text used a system of identifier (name of primitive and structures) to uniquely select them. Typing allow the fast selection (the length of the identifier word) of the right items, this is an important features.
- the problem is that you have a long phases of learning as you must memorized and learn what they do, you have to use extra sources (documentation) to know what they do and how they are name. Said documentation is generally NOT "on site" (the ide won't tell you anything generally), which mean you have to find it which might not be evident, it also introduce potential typing error.

Why a drop down button might be used here, pro and cons:
- A drop down is simple and self documented, you are instantly greeted with all possibility, which mean it's partially self documented as you can try and experiment with what the items you don't know to see and learn their function. It prevent mistyping and it's as fast as the navigation in the drop down, the shorter the better, the button can be activated through key shortcut to optimize production speed.
- The system might be optimal for a finite list like the primitive list. However the system fail dramatically as the number of items (like the derived structures) grew, this is an important drawback.
- The use of an autocomplete search box has been proposed to accelerate the drawbacks by using a typing shortcut to select the right items. That potentially allow for the best of the two systems, the fast selection of text format, the self documentation and typing error prevention of drop down.

Further issues has to be discovered with prototyping the idea.

@mysticfall
To be frank he is not talking about GUI at all.

And unity have a neat way to interface code and GUI anyway, you just have to drop a GO with a script attach on the event button field, use the drop down to select the right method to call, and hey presto, no coding required to link a button pressed to an action. Action are still coded in plain text though. lol

 

My point is, most visual languages we've seen so far don't really go beyond providing graphical representations of such 'primitives', and the real difficulty lies in exactly how you can 'extend' them to allow them to be as flexible as conventional programming languages without becoming even more complex than them.

Sorry if my question felt that way. But the reason why I chose those two as an example is that, the one (Abstract Factory, or most of the often used OOP design patterns) is often used to make your code flexible/extendable, while the other (LINQ) is one of such features that provides extra expressiveness for the language.

I have a strong suspicion that if a person has an inclination and capability to learn the whole OOP paradigm and UML notations to represent such an idea, then he or she would hardly feel it to be too difficult to memorize a few coding syntax rules, or learn how to use a modern IDE.

I don't think those who can be most benefited from having a visual scripting language in Unity would be interested in learning a UML based CASE tool, but if you truly see those tools as a natural extension from simpler visual editors we have today, then I'd suggest you to try them yourself and see if they are any easier to use or in what areas they could be improved to meet your requirements.

I had used one of such tools about 10 or 15 years ago (I vaguley recall it was Together, before it was purchased by Borland), so I'm positive that we'd have better tools in the market these days.

A good thing about design patterns is that they actually make it much easier to understand the code, if properly used - there's a reason why they are called 'patterns'.

As the name suggests, a design pattern represents a commonly taken approach to solve recurring software problems, so once you get familiar with a certain pattern, you'll be able to identify them in a code and instantly recognize what was the intention of the original author in using them.

If a programmer see such names like 'ISomethingEnumerator', or 'ISomethingFactory', for example, he or she would instantly recognize what role such types would perform, and what sort of methods could be expected in them without even looking at the source code.

If such structures look confusing, or obfuscated as you said, it's not because text based program languages have certain inherent problems but because you are not familiar with commonly used paradigms/patterns/principles that experienced programmers use.

Actually, the problem you described would much more likely result from using a visual language. Unlike such languages like C# or Java, we don't have any visual language with a well established catalog of best practices, design patterns, or design principles, and so on.

It means that if you found, from your experience, that certain combination of shapes, nodes, or whatever graphical configuration that's equivalent to design patterns in a conventaional language would result in best outcome, such a knowledge might not be easily recognizable or transferrable to other people who might read your code later.

If we can't come up with a solution to such a problem, I'm afraid visual scripting languages cannot but remain to be adopted for a limited use.

I believe the point of his idea was generating relevant source code when you do something from a visual representation, not wiring events without scripting or anything like that.

 

Hi everyone

A bit of shameless self-promotion here. I made Bolt, a visual scripting asset that looks and feels like it is native to Unity. I did it because keeping the same engine UX and UI was important to me, and because we don't know how long it will take for Unity to create their own VS system (it's still just at the research stage on the roadmap...).

It has two types of graphs: flow graphs (like Unreal Blueprints) and state graphs (like PlayMaker). Here's a screenshot of each:





Unfortunately I can't afford to give it for free (it took over a year of full time development to make and I have to pay rent!), but next week it'll be 50% off for the mega sale, making it only $35. (Download link)

I've had to solve & implement a lot of the "practical" problems about visual scripting to make Bolt, so I'd be really glad to discuss design issues on a more abstract level here. This thread is really fascinating!

Edit: Caught up on the thread, and here's what I think about VS conceptually. To me, visual scripting is an umbrella term for lot of different UX ideas. My approach is similar (and in some ways inspired) by Bret Victor's design philosophy, namely Learnable Programming (Seriously, read this! It's pure genius.). This summary in particular:

I believe Bolt excels at most of these roles, and brings them together in a coherent package.

For example, on the environment side:

• read the vocabulary: Node titles which are C# identifiers turned into human-readable format, and descriptions pulled straight from the XML documentation tags.
  
  
• follow the flow: Connections-base approach, with color coding and live animation for active paths
  
  
• see the state: In state graphs, the current state is highlighted in blue. Variables always update in real time and react to changes.
  
  
• create by reacting: Contextual unit options (start from a port, then see compatible suggestions) and live editing (edit the graphs while in play mode to experiment)
  
  
• create by abstracting: Macros and nesting, allowing you to reuse the same graph in multiple places with variable parameters

The language side is basically C# made visual, with a few differences. Bolt follows more of an ECS architecture (composition over inheritance) rather than OOP, because this keeps component metaphors and it's more consistent with the "Unity-style" patterns. Macros / nesting offer decomposition and recomposition.

 

Can't wait. Too bad there's no eval version, but after Monday I would be at least able to say "meh - tried them all - they're all useless". Unless ofc yours "the one".

I have pretty much every other Visual Scripting tool and NEVER use them (except Playmaker from time to time when I'm really lazy and only for unimportant stuff like NPC go there --> play anim --> wait --> go back etc.), because there's always something missing or I just end up writing stuff myself.

The biggest problem for me is that none of them can easily interact with my scripts. If Bolt can do (at least) that - I'd be happy.

 

I'd like to add that the idea of 'composition over inheritance' itself is not mutually exclusive with OOP, as it's often thought of as one of the commonly used design patterns for the paradigm.

Certain implementations of the principle (i.e. ECS), however, could be used as an alternative paradigm that replaces OOP, and it seems many people take that approach when they develop games with Unity.

But again, that doesn't mean an ECS implementation is essentially incompatible with OOP, or you cannot take a full OOP approach when developing on Unity.

Hopefully, this wouldn't look like I'm nitpicking, and you probably already know it. I just wanted to make it sure it wouldn't mislead others who are not familiar with the concept, because I've seen such a misconception more than once in this forum.

Anyway, Bolt looks quite cool to me

 

Bolt can very easily do that. Any field, property or method in your scripts is automatically converted into units (nodes). This means you can get / set / invoke anything in your custom classes from your graphs, without any additional coding layer required. This is also why Bolt supports the entire Unity API and every third-party plugin, without integration work.

You're right, I oversimplified. What I meant mostly is that Bolt does not (yet*) support encapsulation: creating "classes" or "types" that contain both data (variables) and behaviour (functions). For example, you'd create a "Class" scriptable object, which defines its own variables and a its own graphs that act as functions, then attach this directly to a "Class Runner" component on the game object. It's one of the big features I'd like to add in the future, but that's still a while from now.

 

I think honestly, if people want to talk about their visual scripting solutions here (ie asset authors) they're welcome to, so long as it's in context and not blatant ads

For example on of the things I'm looking for is the ability for a VS solution to generate clean native C# with no garbage unless I've made the garbage... anyone got one they can send me?

 

I think Nottorus is the best bet for this at the moment. It maps 1-to-1 to C#, so it should not allocate anything unless you tell it to. Bolt runs in memory, which is fast but it has the downside of boxing some values. It's one of these hard design choices I had to make: it's a bit less performant, but it allows for live editing / no compilation / easy conversions (and overall simpler UX, because it's not as programmer-centric as Nottorus, for example). I'm hoping I can have it generate native, 100% garbage free code in the next few months (it's my next "big endeavour" anyway!). I think uScript generates C# too, although I haven't tried it.

 

Even though I have been defending visual programming here, I have been wary of current implementation I tried. You laid out principles that I was beginning to put into words so clearly that Ludiq is definitely now on my radar. Almost an instant buy, I'lll try as soon the credit come back in my bank lol.

Visualizing data behavior is a big thing for me, and being able to create higher level command is also key.

If I had a request it would be to have visual concatenation of sequential node, sequence only add to the visual clutter with no new information, being able to collapse them in a single block would be cool. I still don't know how to deal with visual octopi though lol (nodes with a lot of link coming out).

But if anything, more visual way to concatenate node group into block, especially around similar concept is great. Even for text I'm annoyed and constantly try to find best formatting to avoid the ugly mess of character, adding whitespace and delimiter just to have clear grouping of concept.

Do you have automatique grid alignment?

 

That looks very nice indeed. I have some questions and a few suggestions.

Questions:

1. Is it possible to use keyboard only (without a mouse?) This is very important.

Suggestions:

1. Could not common operations like "And" and mathematical operators like "+" and "-" have a more compact form? The "and" could even be like an AND gate in a circuit.
2. I would make the white flow lines thicker.
3. Is it possible to collapse a bunch of boxes into a single box? Important for big projects.

Other than that it looks really nice.

 

code is great for that.

so like a method or function

 

Yeah, but I want a visual scripting tool that I can operate with a keyboard. As I'll have to enter text in the boxes anyway.

 

Okay I looked a bit more into the Ludiq stuff, it does some part well (highlighting data flow per type is great) but it is doing the same mistake than other visual node system I tried. It goes from keywords to keywords instead of statement to statement or block to block. Ie it makes low level stuff less readable, I have no idea how to solve that yet.

- You say most visual language you used where dsl very narrow dsl anyway, you should go and try some more
- And text format don't do much more either, it's all about the primitive.
- Playmaker, who is just a dsl, have a very simple way to have extension without adding more complexity, by adding more brick.

Given I'm such a person, as the patient zero of the thesis, however you seems to assume that's it's hard to learn those things, it's not the point at all. The point isn't the learning, it's that the process of dealing with text format as a sequential layout representation of non linear logic, its painful, and it is for these reason:

1. - it's error prone,
2. - it's distracting and rigid
3. - it's verbose and cluttered,
4. - it's plain busyworks with arcane convention,
5. - it obfuscate what's really interesting to focus on highlighting unnecessary ritual things.

The problem is that the organic process of making a game, which change other time, is at odd with such a bad format, you don't always know what's best prior because plan will change.

I'm going back to UML latter. Though I used UML as an illustration, not dealing with all its intricacy (I personally find the design of some of the symbol rather disappointing at communicating what they mean).

You only further prove my point while missing it. First you rely a lot of external knowledge, the pattern you cite was introduce by the so called Gang of four, inspired by an architecture books (By base de Christopher Alexander) about design pattern (I knew about the idea in architecture first who led me to their works). They were no so evident that people where using them deliberately until it was popularize by that book and taught in all school. That book that got under philosophical criticism because it kind of didn't really do what the idea express in the architecture book did.


https://fr.wikipedia.org/wiki/A_Pattern_Language

But that's side stepping the point because the point is how the programming language present itself in text, and in text you only have a local view of each file and little information on the dependency web it introduce. Ie text coding hide its spaghetti while not mitigating the effects, like tracing a bug across multiple file. Maybe pattern like factory could be more self evident if they were presented in a visual form that show how file are dependent to each other.

The type of obfuscation I'm taking about is, staying in obvious example, inheritance. You can mostly view only one class at a time (the current opened file) and maybe you have some tab on the ide. When you declare an interface file, it doesn't self document you have to hack the identifier by adding a "I".

IF it was visual, the language would maybe give an icone that signal it's an interface and you would have a more legible identifier, and better scanning through the file because it's faster to decode image and color than text, and when you are noob it's a stronger signifier of difference. Not only that, but you don't know, while in an interface class file, what are the children that derive from that class, as text language only force you to declare parent class, it would be effectively more busywork to do so in text, but with visual it would be automatic.

Pattern are language agnostic, and factory pattern is just one of the commonly taught pattern, there is other pattern you can discover, with a visual language you could store and spawn pattern you have discovered because they will come directly with their relationship. You could also spot relation that are reoccurring and store that in a library to reuse. You would be operating at a higher level instead of having to define relation at lower level.

When declaring the class, you would have a box, then clicking (or using shortcut) on that box you would simply add method and member variable to the definition. Then clicking on the method to open a windows that allow you define it's body, the class bloc acting like a tray, so you could have multiple floating windows open from multiple class that collapse back to their class block, which itself can be minimize, which allow you to contrast and follow bug origin. And since everything is itemized, you would to just click on the function in a the body elsewhere to open the windows of its own declaration, instead of shuffling tab and files. And declaring relation between object would be as simple as linking them together, which self document in both direction unlike text format.

Since it's visual, you can take adventage of the GUI presentation to have actual sensible name for everything, each item being an objects the IDE would assign them an internal separate identifier with a proper icone per tyê. That mean you can change the name, any time anywhere, and it would be reflected everywhere and break nothing, and you won't have to make nonsense like camelcase and various stupid convention made to cope with the limitation of the text identifier. The text identifier was always subject to hack, which lead to culture war about naming convention, to what is essentially a <key> for the code to identify the same set of memory mapping, and the naming had to deal with reducing tedium (having short name and less typing, since you gonna repeat it) and still be readable, which are opposite goals, that's why I call the naming convention hacks. The irony is that a visual GUI would allow to go with DRY principle while text format is actually very WET.

SO the argument is that, because we don't have them, we can't create them? Unlike text who was born with best practice out of the blue and not discovered other time? You are selling people short, we can identify and fix problem given we put our thought on it, in fact that's also the job of the programmer, to find way to represent problem in a format they may haven't been done yet. Just above I have outine a bunch of possibility. THough they might have others.

Why do you think it wouldn't work, when the pattern you describe are almost universally presented in graphic form when taught? Even the concept of class is generally presented as a box to convey the idea of containment, as it is the main innovation of objects to "encapsulate".

He was literally proposing to short circuit having to put text code by declaring variable visually in the inspector (ie through an interface like a button). Which actually a lot of production already do with scriptable object with the concept of scriptableVariable (see the unity blog), basically a scriptable object where you just declare a single variable and then create asset out of it, which mean you just copy, drag and drop, instead of opening a file to type code. Some replaced enum with that because it's infinitely extensible, by duplicating scriptable assets, without generating, maintaining or breaking more code.


EDIT:
Just found that while picking the link of Alexander, I don't think it contribute much about the discussion because I don't have have any criticism of the idea of pattern, but I thought that was interesting in a tangential way lol.

https://en.wikipedia.org/wiki/Design_Patterns

 

@neoshaman I was in the middle of writing another lengthy post to refute your points but decided to delete it, since I realized it would only result in another of yours and it'll go on and on in circles.

With all due respect, I strongly believe that it might be helpful to you if you can actually spend more time to get yourself proficient at designing softwares by a conventional method, or at least at using such tools like modern IDE or CASE tools I mentioned earlier as an example.

As I said, visual languages have their own purpose and utility, but if you intend to go further and make them something as a silver bullet to solve all the problems that text based programming languages supposedly have, you need to learn the nature and extent of the problems first.

And in order to really understand what limitations conventional programming languages or development tools have, there's no other way than becoming proficient with them yourself.

Otherwise, you would probably be struggling to solve imaginary problems for non-existent requirements.

For example, what you have described below is a feature that many IDEs have been providing for many years:

And again, this was one of the major features of the CASE tool that I mentioned in my previous post, which was released more than 10 years ago:

On the other hand, it seems clear to me that you are not familiar with a programming paradigm that experienced C# programmers use for their day-to-day works:

While OOP might not be the silver bullet in programming and it might be less popular among game developers, it's far from being a minor, or experimental paradigm that some academic programmers might use.

Actually, it is THE paradigm that the whole .NET API is written with, and the one that most of seasoned C# programmers would choose, if they are to start any serious project.

The same can be said of such concepts like generics, LINQ, GoF patterns, reactive programming, and more. You can't simply tell those programmers to abandon such tools for your shiny new visual programming language, simply because you argue that they must be hard to understand, verbose, error prone, or whatever as long as they are written in text rather than in graphical shapes.

If you are truly determined to create a next generation visual language that surpasses every existing conventional language in both ease of use and power, you really need to do a proper research first, so you can understand what kind of real problems that experienced programmers of a conventional language usually face. And no, they don't usually pull their hairs out, trying to figure out what those text symbols mean, when they compose simple if or while statements together.

Otherwise, I suppose limiting the scope to a more moderate, and practical problems, like enhancing usability or flexibility of existing visual language solutions without trying to make them solve every programming problems that such languages like C# failed to solve would result in a more productive outcome.

 

It's rather obvious you understood nothing of what I have been saying Or you have been actively and purposefully misread just for spite!

Just right there, all those time I have been saying it's a problem for a specific class of user like me and non programmer, that's no silver bullet, ie a very delimited use case and you still think it's about changing programming for advance user.
Keep your programming, nobody want to steal your toy!

And since you didn't take the hit, scriptable object allowed implementation of the abstract factory pattern in a way that involve moving away IN PART from text based code by using the unity editor.


EDIT:
Case tools is clearly not in unity, which is the point

 

No need to be personal.

So, you are saying that you haven't been arguing that a visual language can be easier to understand than text based languages without losing any of their flexibility or expressiveness? Or that text base languages are inherently difficult to understand, maintain or be error prone than visual languages?

I can quote tons of your own words to prove otherwise, but if you are willing to limit your claims to "visual languages can be useful for those who don't need all the flexibility or power of conventional programming languages" now, then please be my guest.

I willl gladly forget everything you wrote above and accept that actually you and I have nothing to disagree on this matter.

 

For people like me, it is

I mean how do you interpret ME being the patient zero of that thesis or the comparison of non programmer to programmer? I wasn't trying to be personal, it's like you actively avoid the point.

I removed the unnecessary bit

 

Just to be clear everyone is still discussing how long string cheese should be and if string cheese is the correct paradigm for dealing with world hunger, right?

 

I'd blame the language barrier, if we had problems in understanding each other's points clearly. Apparently, you doesn't seem to be a native speaker of English and neither am I.

Anyway, if you say that what you've been trying to say is simply that "visual languages can be useful" then I have nothing to say against such a moderate claim

 

The goal was always how to make them MORE useful and less sucky, to be familiar lol.

 

Not entirely. You'll still need your mouse to determine where you want to place the nodes in the graph.

It could be made a bit more compact (it's already more compact than in the screenshot above in the latest version), but I want to favor legibility over smallness. One big advantage of VS in my opinion is clearness of intent: at a glance, a person who has never worked on your graph should be able to understand what it does. For this reason, I'm probably never going to remove the "And" label on top.[/QUOTE]

Yes! It's called Super Units. I don't want to hijack this thread with explanations, so here's a link to the documentation:
https://support.ludiq.io/forums/4-bolt-manual/topics/154-super-units/

Not sure I understand what you mean by "keywords to keywords".
In flow graphs, every unit (node) is either:

• A statement (an ordered action with control input and output)
• An expression (something that returns a value)
• A control structure (branching, looping, etc.)

It's literally as low level as C# goes!

 

Amen. I too deleted some posts I was about to send for exactly the same reason.
Can't really add more to what you said here, it's the truth and encapsulates the discussion here perfectly.
Now its up to @neoshaman to take your advice or ignore it.

 

I was refering to this example you shared:


Node are thing like:
OnCollisionEnter
string
and
greater and equal
etc...

A statement, like in the wikipedia link you posted, is a group of these that create a unit of command, ie like: vector3 -> greater or equal ->and (can't reproduce the graph easily in flatten text form) which would be equivalent to: "magnitude > Minforce && istag(enemy)" etc ... each node is an almost keyword but in the form of "node_name(input, input, output)", that is like it's a statement as in takes input and output to form a complex unit, but the actual concrete implementation require other nodes to set the input and output to fulfill the full statement status.

Basically a statement (IMO) in text format is a coherent line (sentences) with many keywords that makes an command (unit of programming meaning), node sit in between the statement and the keywords as they have explicit relation to be fulfill (it's implicit with keywords). The graph above would be the equivalent of multiple lines of statements (and compound statement like the if) in text format like this:

pseudo codeish:

Code (CSharp):

1. OnCollisionEnter(Collision collision){
2.     Bool isEnemy = collision.gameObject.compareTag(enemy);
3.     Vector3 magnitude = collision.impulse;
4.  
5.     if (this.minforce > magnitude && isEnemy){
6.         this.Animator.playanimation("");
7.         This.health = this.health - 10;
8.     }
9.     else{
10.         debuglog("Low damage for " + collision.gameobject.getname() )
11.     }
12. }

Except in this format we need to duplicate keywords to express relation in multiple line.

Spoiler: It's more readable than doing this too!

Code (CSharp):

1. OnCollisionEnter(Collision collision){
2.  
3.     if (this.minforce > collision.impulse && collision.gameObject.compareTag(enemy)){
4.         this.Animator.playanimation("");
5.         This.health -= - 10;
6.     }
7.     else{
8.         debuglog("Low damage for " + collision.gameobject.getname() )
9.     }
10. }

Damn I mistype this into This one time , can we kill typing just yet

Statement also have this neat little visual pattern of being organize around a "parse tree" (let's assume it's the name for simplicity), with data as leaf and operator as branch, that converge toward the main instruction. Magnitude, get variable, greater or equal, comparetag and And converge toward branch (and they are expressed as a single line statement in the text form), idem for getname, string, concat that converge toward debug, these should be visually more compact.

As such while the data flow is clear the actual statement is obfuscated, think about what is the trajectory of your eyes, and the effort you must do, to decipher these two statements in the graph! You do a lot of back and forth between the "branch" and the leaf to get it, which would be way worse if the node had a long dependence that was outside of the local view (ie outside of the screen or of the block), scrolling just to read some input would be rage inducing. That wouldn't scale well.

It's just me, as in what I look for in a visual language, but I'm also not fond of the OnCollisionEnter node, OnCollision is a block that "scope" the instructions, and is part of the unity script control flow cycle. Here it is fused with a struct that pass the collision events' data. I feel like it doesn't reflect the nature of the code just like I pointed with the notorrus example I posted earlier.

I mean what are the various link are supposed to mean by themselves? They seem to be organized around two key idea, to either indicate data flow (colored lines) or command flow (the white one), but it doesn't really organize this in a way that make the code more readable, which is the main complaint and idea, I think, people @mysticfall and @dadude123 when they think of visual interface (not language, and they don't think about the inspector, the editor or prefab which are different paradigm of visual declaration).

IMHO there should be a difference in how you organize command flow and data flow. For example the IF branch node should have visual potency (really the whole command flow should be better highlighted), as it inform about the behavior and the other should be more compact to express their relation to the behavior flow (ie how data is transformed by the command). And you have two variables that don't belong to the current scope (out of the block) and it's not made as clear as it should be (minforce and self.health), this mess the conceptual cohesion of the block, it also don't highlight the actual purpose of the block (it affect the data of the main objects relative to collision).

So for this type of graph I agree with the opposition in this thread, in this case the text form is clearly the superior way to read the instruction. HOWEVER this graph does display some data more clearly than the text form so they are in effect complementary.

The truth is that the nature of code is to be a graph anyway, it's a graph all the way down (the compiler create a parse tree and the chip and electronics are a graph too) and up and most text formatting convention are about expressing this graph in a flatten form, which has its drawbacks. The thing with the visual node as a visual language is that you are effectively exposing a type of parse tree, and they also tend to be locally mostly DAG, with loop being contained in structure that allow them to no spread complexity (which is why we banned goto into the nether and only the darkest rogue programmer now rely on it).

And graph can be compute and manipulate in way we can leverage for readability, for example
- Even when the code as a whole is shown to be in spaghetti form, we could use "views" that would self organize around local focus at certain point. For example inspecting a data flow by visually muting all the node that aren't part of the trail (ie iterating ancestry and descendant) which makes it easy to see influence of a single data.

- Since we also know the type of each node, we can collapse statement when we focus on them, by finding the "parse tree". The main node of a statement is on the command sequences, and the node to collapse are on the data flow, (branching node of the tree seems to be always operator?). For example the debug and if are clearly part of the sequence (white line) we can see how their "statement" items fan from them (orange lines).

- We can also eliminate redundancy easily (or at least highlighted them), in the example node graph above, the magnitude is redundant, it's easy to see there because it put a vector 3 into another vector 3 that feed directly into the comparison operator and nowhere else, we can use the original (impulse) directly; note that redundancy are often use in text format too for clarity of local "block" (I mean conceptual unit doing similar task here, not the language's scope mechanism).

- There is certainly more QOL thing to find.

Now that said, is visual node the visual language I'm looking for? I don't know yet, but this discussion did allow me to understand more in depth what I'm looking for, I'll thanks the contradictor, who will never agree, for having pushed myslef to better analyze and express my own perception. I mean it seem there is an idea in the concept of "behavior flow", ie conceptually visualizing the command and data flow together in interaction while keeping the identity of both. Command flow looks like the bone, and data flow like the flesh lol. I need to dig deeper here, I won't say it's well thought out now. But other visual interface like scratch type or text format, highlight the command better, is there a good middle ground with visual node that show data flow better?

 

Ok, before I leave this discussion, I'll share a few of my opinions about the subject without starting another debate on visual vs. textual language.

Even though I've never created a fully featured visual language myself, I wrote smaller graphical UIs that can compose simple programming elements like a condition or loop, and I also made things like a UI designer that automatically generates programmig code before. So I guess I might be able to share a few thoughts about the matter.

1. In general, creating a DSL (visual or not) is a trade off between the ease of use (or readability) and flexibility. You cannot really achieve one without sacrificing the other, or at least it's really difficult to do that.

The reason why many visual languages take a node editor form is it's arguably the best way to preserve the flexibility as much as possible. If you want a general purpose visual language, it's much better to lose some ease of use than to lose flexibility, since the latter means there are things you can't really do with the language.

A good example could be nested logical operators. There are various ways to represent them in a graphical manner, but attempt to do it without using a hierarchical format like a tree or nodes usually result in unreasonable restrictions or something really horrendous as this one.

2. Generally speaking, you'll need to go higher in abstraction level to make it more intuitive (and potentially less flexible), not lower. It's another axis of trade between the ease of use and flexibility like the one mentioned above.

As such, you might easily conceive a more readable version of the above example regarding handling collisions, like creating an inspector like UI that accepts an animation to trigger, or amount of health to detract, and so on.

Needless to say, it's simply giving up some of the flexibility for additional readability, the validity of which must be evaluated in each specific circumstances.

3. Translating programming elements in their graphical counterparts on 1-to-1 basis will never make it easier to read or to use. Again, you'll need to move higher in abstraction level to make it easier, and a parse tree is an even lower level representation of code blocks than the code itself.

Scala language has a nice interactive console like many other modern languages, and it also provides an API to convert an arbitrary statement into a corresponding parse tree, or to construct those nodes back into a statement.

It means you can type in any valid Scala statements in the console to see how they would translated into parse tree nodes. And here's an example of converting a very simple Scala code into its corresponding parse tree:

Code (JavaScript):

1. val data = Seq(1, 4, 9, 8, 12)
2.  
3. data.filter(_ > 5).foreach(println)

All it does is declaring a collection of integer values, and print items that are greater than 5. And this is how the compiler sees such a simple code block:

Code (JavaScript):

1. Expr(Block(List(ValDef(Modifiers(), TermName("data"), TypeTree(),
2. Apply(Select(Ident(scala.collection.Seq), TermName("apply")), List(Literal(Constant(1)),
3. Literal(Constant(4)), Literal(Constant(9)), Literal(Constant(8)), Literal(Constant(12)))))),
4. Apply(Select(Apply(Select(Ident(TermName("data")), TermName("filter")),
5. List(Function(List(ValDef(Modifiers(PARAM | SYNTHETIC), TermName("x$1"),
6. TypeTree(), EmptyTree)), Apply(Select(Ident(TermName("x$1")),
7. TermName("$greater")), List(Literal(Constant(5))))))), TermName("foreach")),
8. List(Block(List(), Function(List(ValDef(Modifiers(PARAM | SYNTHETIC),
9. TermName("x"), TypeTree(), EmptyTree)), Apply(Select(Ident(scala.Predef),
10. TermName("println")), List(Ident(TermName("x"))))))))))

4. On the other hand, I think such ideas like highlighting or temporarily hiding a part of node graphs depending on context might prove to be useful, and there might be other areas of improvements too.

So, if the goal is to create a general purpose visual language, it might be a better idea to try to find such ways to improve usability of the common node editor style interface, than to attempt to go lower into abstraction level and avoid its drawbaks somehow.

 

Some other observation:

It might be cool to have more differentiation between element that reside on the white line (let's call them command, like debug.log, the IF branch, setvalues, etc ..) and those who reside on the colored line (generally the data structure and some operator, maybe differentiate the operator like and, greater or equal, substract and concat too) I mean the icon are fine, but they all have the visual weight and don't highlight the important part of the code to me. I'm not sure why animator is yellow, it doesn't seems to me it says enough information or highlight something that is important to the code.

Just an opinion. EDIT: I have looked and apparently Blueprint does that and it's more pleasing immediately.

Just want to point that the majority of visual code editor in game engine follow the itemization of command (Let's call it that way for simplicity, aka command are drag and drop item) rather than the visual editor.

We have also to assume that it doesn't have to be homogenous in its presentation and that every single things follow the same format. Not everything in a node editor has to be node for example, we can mix and match views on the code. I mean the inspector is literally a visual declaration interface, using a modular spreadsheet visual, where each entry have its own specific visualization (color use a color picker, curve has a curve editor, etc ...).

So now It's not an answer to @mysticfall, but just taking the occasion to present some non code alternative.
Disclaimer: I'm not saying these are good on their own, but they might have interesting concept.

The most major problem they all have, is that generally they don't allow low level access of various function. They also occasionally lacks in some function or data structure, which generally can be circumvented using the generic data they have like in all turing complete language, and is more a design flaws or limitation by design of th eauthorthan something inherent to the type of interface.

RPG maker:
See screenshot in a ealier post.
New versions allow you to do things in Ruby language (on top of the regular event editor), which allow to import stuff and modify the engine itself (it's written in ruby, you are basically using the source code with an idea in the rpgmk editor), but for a long time all you had was a type of behavior editor. This editor was generic enough so that people made all sorts of game, but it was basically a boxed language, you didn't have access to a lot of things unless you hacked the exe. I made a pathfinding algorithm with it ...

The great thing is that the result is basically like real code™ but with a clear syntax, and modifying code was clicking on the keyword to do everything inside a contextual prompt windows. People did a lot of thing with that, like redesigning the interface and menu, doing whole combat engine, doing game that had no business to be done on the engine like platformer or bomberman etc ... because it was generic enough so that we could build entirely new stuff inside it.

If we had access to pixel that would have open the pandora box. It was just an interface to the core engine concepts, no extra i/o stuff, it's a bit like how the blitz3D engine is tied to the directx7 and don't allow access to lower stuff, even with dll. OR how you are tied to some decision unity made in how it handle some aspects (can't stream without a hitch up until now, come on! That's no c# fault).

Some great concept is how it has multiple "tab" of code per entity, having a default general control selection of the tab that you could combine with another concept of general events, and you could do some stuff like fake inheritance or something akin to the strategy pattern. I would like something like that but not hardcoded into the engine library.

Game Maker:

It's so lacking in data structure, and being in direct competition with the GML language that gave access to a bit more useful commands, it never really reach advence usage at all, in my knowledge at least.

Construct, Klick and play and Multimedia fusion:

I was never comfortable with it, it's clunky, take a lot of space and hard to follow. It's basically a grid where you match events to object in a cell, the cells hold the command. It make sense, but it doesn't scale well at all. They need a visual design badly (all of them) on top of that. I think some of them a more regular command flow as an alternate view too, not sure.

Game salad:

Never used at all, but it seems they used a series of command box that can be nested with a separate windows for variable declaration. I may need to look at it more.

Scratch and similar:

Never used at all, but I heard it's popular, basically code where command are drag and drop snapable items. I like how loop really stand up, the visual design is debatable, but at least it tries to convey relevant information at a glance. The color code group instruction in family of control type. Not sure I would use this color coding.

The only engines, I'm aware of, that use node edition is unreal and godot.

EDIT:
Here is game salad in action, that's kinda neat!

The visual weight of the box and button is a bit too heavy though. I'm sure it can be augmented to use shortcut key too.

just a list of engine to look at their editor:
https://alternativeto.net/software/gamesalad/

 

That's the older GameMaker though. GameMaker 2 is node-based like Unreal and Godot.



Here's the trailer they released during the beta days.

 

That's interesting! They still have the itemized ordered command system but presented visually as a node system.

They just don't have data flow like blueprint or godot's, which allow to enforce a strict correspondence with text based format (as seen in the little preview on the left). They are really not alike but may benefit from the "idea" conveyed by node base programming (ie it's accessible). That's kinda smart.

The question I have is if having a strict command ordering like they do but with data flow added on top, if it would works.

 

I found there is another asset out that can make C# code from visual script

https://forum.unity.com/threads/released-unode-visual-scripting-30-off.500676/#post-3304458

 

Surely it would be quite easy (an hours work maybe) to add the functionality to do this by keyboard?

My suggestion would be something like this:

Arrow = Go to next box in given direction.
Control+Arrow = Go to an empty space in given direction to create a box.
Alt+Arrow = Go to next node of box in given direction.
Shift+Arrow = Move box in direction.
Hold down space = Create wire from currently selected node.
Release space = Connect wire to currently selected node.

One of the problems with the visual programming is constantly having to switch between mouse and keyboard. There's really no need for a mouse as the exact positioning of things is not that important.
It only really needed if you are going to drag select a lot of boxes at once. But that is similar with programming when you use the mouse to select a lot of text at once.
With keyboard shortcuts like these I think you could almost do visual programming faster than text programming.

Without these shortcuts its like a text editor where the arrow keys don't work to move the cursor.

Here's some more ideas for keyboard shortcuts:

Alt+Shift+Arrow = Move everything that is in the direction of the arrow further along. This is similar to "insert row" or "insert column" in Excel but really it just creates space in the graph.