I guess I am late to this engine, but I finally decided to check out UE4. Was watching the Intro to Level Design, and I see that they have a really polished Visual Scripting system.

They say it can do everything you can do from the textual scripting. A while ago I posted about node-based programming:

http://www.gamedev.net/topic/650883-examples-of-node-based-programming/

This must be the finest example of it, fully implemented.

Anyone think this is a good case for the future of programming?

If not, explain.

overall, no. visual/node based programming is just very slow compared to regular programming. also larger and complex systems become very overwhelming to maintain. Blueprints is fine for doing quick and easy things, but once you start getting into complex objects, it's better imo to use an IDE over visual programming.

also larger and complex systems become very overwhelming to maintain

A couple of million lines of text spread across a thousand or so files, organised in hundreds of directories isn't overwhelming to maintain?

I think the concept that is generally missing from Node-based languages is a robust way to handle level-of-detail. When I zoom out, I should see the just high-level flow of data through the system. When I zoom all the way in, I should see the individual lines of code (can be text at this LOD, for quick editing). At intermediate levels, I should see the data flow of individual sub-systems...

Until we get fluid node-based IDEs like that, I think visual scripting will continue to be the domain of non-technical scripting tasks.

also larger and complex systems become very overwhelming to maintain

A couple of million lines of text spread across a thousand or so files, organised in hundreds of directories isn't overwhelming to maintain?

Relatively I'd say it's far easier to maintain then a visual language with an equivalent size code base.

Relatively I'd say it's far easier to maintain then a visual language with an equivalent size code base.

That's pure speculation, because nobody (to the best of my knowledge) has ever attempted visual programming at scale.

Whereas we have 30 years worth of tools and programming paradigms designed to make the problem of manipulating text-based languages tractable. Until we sink time and resources into visual programming tools and paradigms, we just don't have enough data to make that assertion.

Recent forays into visual programming such as UE4's Blueprints, or NoFlo, have met with surprisingly good reviews. Perhaps people are starting to overcome their ingrained bias towards doing everything textually?

"Visual scripting" tends to be good at letting non-coders whip up simple logic like "when this button is pressed, open this door".

I would not want to program a game with it.

Part of that may be me being used to working with a text editor, but I think the main problem (touched on by swiftcoder) is a lack of good tools.

Epic has done a ton of work to make Blueprints a viable way to do simple logic, but it's taken them a long time to do it, and they've had to "reinvent the wheel" in a few places. For example, they've had to write a bunch of code to be able to "diff" blueprints in source control - something you get "for free" with a text based language (and which we have a glut of options).

At the most basic level, if I want to edit a text-based script, I have a huge number of possible editors. From heavyweight IDEs like Visual Studio and Eclipse, to tiny little programs like Notepad. If I don't have a tool to do what I want with the script, I can probably write one pretty easily, because "text" is a well-understood data format, with lots of libraries and tools to manipulate it.

On the flipside, the only way I can even view Blueprints (let alone edit them) is in the Unreal editor, which is a pretty heavy application. And if I wanted to write some quick tools or batch scripts to process some blueprints - how do I do that? I'm going to have to go figure out Unreal's format, parse it, make my changes, and then write it back. Not impossible, but I won't really have the libraries or tools without bringing in at least a subset of the Unreal engine into my codebase.

But let's say Blueprints really take off, and people start writing a bunch of tools to work with them, modify them, and do other cool stuff outside of the editor. Then what happens with Crytek adds visual scripting? Or maybe MS comes up with their own? They'll have different goals and different systems and all the tools will have to be rewritten again.

TLDR: Visual scripting is nice - but it doesn't have the tooling that text has, and tends to be too domain-specific for widespread use or standardization.

I have been prototyping games with a visual scripting system called Gamepress, now known as Hyperpad, and I have come to see where textual programming shines. I can also see where visual scripting shines. A merger of these two would be awesome, and so nothing prevents a node from being a piece of textual code, having inputs and outputs. In this way, that code snippet is a node, and code flows through that node.

This would make the two types of programming seamless. All the rage would be these nodes, which are (at the end of the day) textual.

I will see if I can make a mockup of the idea in my head. I still have yet to play with the Level Blueprint thing, but from the commentary in the video, it seems it is very capable.

Mainly the Blueprint Classes:

https://docs.unrealengine.com/latest/INT/Engine/Blueprints/UserGuide/Types/ClassBlueprint/index.html

Here are the types of blueprints:

https://docs.unrealengine.com/latest/INT/Engine/Blueprints/UserGuide/Types/index.html

I've been used to working in C++ for some years now, and scriped in Ruby, Python and a little C#. Even as a programmer with some background, I prefer visual scripting where applicable every day. Its not just for non-programmers - the main points I like about Unreals blueprints that quickly come to mind are:

- Being able to select assets by drop down (with textual search so it is pretty much like having auto-completion for assets)

- Default-parameters for all command nodes (every attribute will have an initial value). This is a pretty huge point - in almost all textual programming languages if I have a function with 10 parameters, I have to fill out all of them with some value (unless there is like 20 overloads). In visual scripting, you create the node, and only need to alter those values you really make use of

- Better "autocompletion". Usually in C++ etc.. we have tools like intellisense which are helping us to figure out which functions/classe could make sense at the current point in code. With visual scripts, this is taken to another level, where I can drag a line from a boolean-return value and have it just show me possible functions that take a bool variable. Also its much easier to "search" for a function to call since when you are placing commands there is not 10000s global defines/enums/classes that you are being shown, but just the functions. When dealing with child types, it will show you a full dropdown list of all possible childs to select from, etc... this is all really awesome stuff that makes people like me who have a memory span of a worm and heavily rely on auto-completion happy.

Of course, there are downsides.

- Scripts can get very large and hard to view if you don't organize them properly (though this holds true to textual programming too).

- Everything math (especially vectors) gets complicated very quickly. Where you would normally write a "-" in front of variable, you now have to place a full-fledged node. This I belive is the main reason of people arguing about the complexity of visual scripts. I do think there are solutions - I'm currently in the planning process of developing a quick math expression language which would allow me to write complex mathematical expressions in text inside a special node. So yeah, this is a point where I currently don't see any solution in purely node-based systems, but we can always tie in text where necessary (like unreals material system also allowing you to write HLSL-code in a special type of node).

- You have to take care of positioning the nodes. Though you also have to format the text, I'd say that this is still a quite significant nuisance. I quess this could be solved by making the language order the nodes by themselves in a few years.

I think there is a lot of potential to be explored, after all visual programming in such a scale is not that new. For now, I'd say that visual scripting is really nothing for developing a full game/engine with, though I'd really prefer it over regular scripting languages every day. Who knows, with better tools and people getting used to them (even and especially programmers) one day they will be used for lower-level stuff.

On the flipside, the only way I can even view Blueprints (let alone edit them) is in the Unreal editor, which is a pretty heavy application. And if I wanted to write some quick tools or batch scripts to process some blueprints - how do I do that? I'm going to have to go figure out Unreal's format, parse it, make my changes, and then write it back. Not impossible, but I won't really have the libraries or tools without bringing in at least a subset of the Unreal engine into my codebase.

Thats more an issue of how Unreal handles its assets. It has binary format for everything including stuff like textures, etc... unlike Unity which I belive stores textures in a separate file (this makes working with unreal partially really annoying once you want to modify a texture in an external application). Visual scripting on the core is not very different than regular scripts. I have my own visual scripts represented as XML, other might do JSON, or you could even potentially have the script as just a plain-text script file, depending on how you load and compile your visual scripts. Only difference is that you have to store the position of the nodes (and possibly some side-attributes like count of output-nodes for a sequence-command), but other than that there is nothing that hinders you from storing a visual script in a text file and processing it with external tools (which also gives you merging abilities back).

"Node Based Programming" ( as described ) has existed for a LONG time - it hasn't 'caught on' mainly due to how inflexable it actually is.

I've been used to working in C++ for some years now, and scriped in Ruby, Python and a little C#. Even as a programmer with some background, I prefer visual scripting where applicable every day. Its not just for non-programmers - the main points I like about Unreals blueprints that quickly come to mind are:

- Being able to select assets by drop down (with textual search so it is pretty much like having auto-completion for assets)
- Default-parameters for all command nodes (every attribute will have an initial value). This is a pretty huge point - in almost all textual programming languages if I have a function with 10 parameters, I have to fill out all of them with some value (unless there is like 20 overloads). In visual scripting, you create the node, and only need to alter those values you really make use of
- Better "autocompletion". Usually in C++ etc.. we have tools like intellisense which are helping us to figure out which functions/classe could make sense at the current point in code. With visual scripts, this is taken to another level, where I can drag a line from a boolean-return value and have it just show me possible functions that take a bool variable.

These upsides all sound like tool/language features, not features inherent to visual scripting in general. There's nothing stopping anyone from coming up with a programming language that allows you to use arbitrary non-default function parameters (in fact, C# supports named parameter syntax which could easily turn into something like this). Having a textual programming language intellisense that only shows functions that return a value of a given type doesn't seem too far-fetched, either.