About visual scripting

Although UE4 doesn't seems like it's the only tool offering wide visual scripting capabilities, but it seems it was the first one for many to actually try the subject through Blueprints. Including me.

Initially I took it as a tool to utilize some basic, built-in functionalities without bothering with actual programming. I think I actually saw some tone of other opinions kind of 'well yeah it's great basic-programming-for-dumb tool, even our marketer was able to create something'.

For example, initially there was no possibility to do the math other than through placing tons of 'a + b' nodes for any simple formula. Now, with 4.2 release, they are introducing nodes where you can actually write an entire formula. I wonder if there would be an opportunity to create a custom nodes with a normal code in it. Sure the possibility to make C++ code and Blueprints to interact each other is already there. What I'm talking about is to do the 'raw' coding right there in the Blueprints and immediately make it available to reuse as just another visual node.

Overall, finally I've seen it not like an additional tool alongside with the 'real-man way to code' like traditional IDEs, but as the perspective to replace traditional coding entirely, because it's only a matter of time when things like Blueprints would be as flexible and universal.

But even if it will be as flexible as traditional coding, why would people switch to it? Main reason is the visual way to program potentially a way more efficient than traditional verbal way. The reason why marketers and artists are successfully making their first steps in the programming via Blueprints is not kind of 'Blueprints just simpler for lesser creatures to start'. Visual perception is producing most of information flow in brain, and for hundreds of millions of years brain was developed around it. While speech is just some sort of side capabilities we have recently got. Visualization just involves more of brain into the process. Thus even not experienced people became capable to figure out how to actually program something.

So there is at least one truly fundamental reason why visual scripting/coding would eventually compete verbal coding at least in application area (Java, C#, etc).

Conclusion: UT has to jump in this passing train until it passed completely. Visual scripting is not just another fancy tool, but one of most important things to develop. Better if it would be an cooperation with some language developer, for example, why wouldn't Microsoft to make theirs Visual Studio truly visual.

 

That's good that you can write formula in the new BluePrints. I often though combing BluePrints with something like Mathematica would create something very powerful.

It would be great if the formula you write were formatted as standard mathematical expressions. Since that's how our brains process maths the best:

eg.

Instead of "Sqrt(x^2+y^2)/4"
It should be displayed in the node as:



What do you think? Maybe someone should suggest that to the Unreal people.

 

Thats smart, I like it and I approve this message.
Say NO to writing!

 

I think you essentially can do something like that as described here:

https://wiki.unrealengine.com/Custom_Blueprint_Node_Creation

 

A think they aware of what way they could improve Blueprints even more. My suggestion, however, is for UT to take Blueprints seriously and introduce their own ASAP.

 

Hm... I'd definitely try it if Unity released their own. It doesn't seem great to me from the perspective of never having used it before (which means that what I say can be taken with a grain of salt). But it seems like it would get really cluttered and be difficult to organize. And in some situations it may take up a lot of space when there wouldn't be that much writing involved doing it through code?

And can you possibly match the power of programming in an effective way? I am skeptical about it, but willing to try it if Unity would release it without me having to pay a lot of money for it...

 

There is, since 2011 an Antares Univers Vizio plugin for UT, that has also visual debuging tool, and it is 1:1 to UT classes, I made games and multiplayer project using just this plugin, no line of code at all!
The reason that I came form UDK to Unity was this plugin as Kismet was not good enough for me.
I didn't check the blueprint, but it resembles AU Vizio a lot. When I have a time I will work with blueprint, but for now AU Vizio and UT is working perfect.
There you have some links about it:

aplications made with Vizio
Antares Universe Vizio

 

The same, I believe, could be said about OOP compared to old-school functional programming, and any other higher level vs. lower level tool comparison.

Current application languages, like C#, offers huge flexibility to effectively describe any logic you could ever imagine. But visual scripting isn't a language, obviously, but an possible shell over it. You can compare it to the Intellisense. What Intellisense offers? Well, there are code completion, typos detection, assignment of wrong type errors, etc, all performed almost real-time as you are coding. What visual scripting could offer? All of that, at first. And admit it will not even allow you to make an typo (as there is no typewriting) or write an wrong type assignment. Additionally, it could (as Blueprints already do) also organize your code into visual flowchart, show you how process flows right there during debugging, keep you aware of possible, say, 'attachment points' where you can put additional data or logic branches without changing an existing 'code' an so on. Working with text, you must do it on your own right in your head, translating text into some sort of imaginary system, which you will quickly forgot while not working on it.

 

I can see it working. It probably seems strange to me only because I'm so used to the traditional approach and haven't gotten used to that kind of system. I think I'll have to try it out before speaking further about it.

 

The main advantage in an engine like ue4 is that it allows you to rapid prototype and develop the game without the need to compile in visual studio. But in Unity, C#/etc fits that bill perfectly

I still think visual scripting is great for non-programmers. But yeah for full fledged programmers in an engine like Unity the benefit is not as apparent

Pretty interesting post.

 

I also believe VS is the future, and the single most important tool to universalize software making. Now U4 is leading the way, even do Unity as enjoyed access to more mature solutions in the past years.
Many devs want a WYSIWYG solution for Gui, Shades etc but scripting seems to trouble a lot of minds. I fear Unity shares the big programmer "sombrero" that wont let them see past the ground around them. As the subject as never been address in any official capacity that i know off.

 

Yeah well, aren't there user-made "functions" in those visual scripting plugins? As in, code reuse to reduce redundant code? I think the same concept can be applied to a visual scripting environment to reduce visual clutter.

 

Or alternatively go with both. It is trivial to write custom Blueprint nodes and, while solo developers might decide on a single solution, I don't really see the point in having a team stick with one method. This way the level designer, for example, could write basic functionality while the programmer can focus on core logic.

 

I'm looking at all the lines and arrows going all over the place and it seems scary to me. I think that for someone who doesn't have programming experience, then visual scripting will be a lot easier to learn. But if you're an experienced programmer, then you know programming like you know English (or whatever native language). And in that way, your brain is well adapted to writing code out. Would visual scripting be good for a person like you? Maybe, if it's doing a lot of work for you... as in, one node you can quickly place that would otherwise require many, many lines of code. In this way, it's a time saver. But how often is that the case?

 

For those who want to know more about the Blueprint system there are some good video playlists about it here:

http://www.youtube.com/user/UnrealDevelopmentKit/playlists

Or, spend twenty bucks and give it a try yourself.

 

Visual Scripting has been around forever, and it is not "the future". Everyone gets excited about it the first time they try it, but give it a few months, and you will get over it. Just like charades hasn't replaced talking, and pictograms haven't replaced writing, bubbles and arrows won't replace coding. Language is a very compact and inherently understandable way of communicating information. While it's true that some people are visual learners and some information is more easily conveyed through pictures, these are special cases, not universal realities. Communicating with words is here to stay. Anyone who really thinks that visual diagrams will replace language should only reply to this post in hieroglyphs and MS Paint drawings... I guarantee you will start to remember why words are more useful than squares and arrows pretty quickly.

 

My comment is regarding what benefits does Visual Scripting offer a full fledged programmer though over traditional programming within the Unity environment? I know why I would write a blueprint in ue4 (because its so easy to prototype things with it) but in Unity there is C# in which compiles on-the-fly.

I've worked on products where we've had visual scripting available but only our Level designers and scripters used it to good effect. But our coders never did...

 

In other words, any of those data structures we are using in programming just useless, good-ol' serialized data and ASM is always better. LOL.
That is why algorithms often described in a flowcharts first, and then just serialized in languages, sure. Such an example of a programmer who can't figure out concept of interfacing. As verbal language is not more than interface, no matter how flexible it could be, it puts nothing but limitations.

I wonder if you could say something similar about any visual material editor (which is actually one of application areas of visual programming). Sure, real man doesn't need all those squares and arrows, while there is such effective way to do the same in a raw shader code. The only problem is a director doesn't want to hire yet another programmer, when artists could do the same visible (damn, again that 'vis' root) result.

Face it, you have quite a chance soon to be replaced by marketers and artists which will start to program things for themselves without your help.

 

I think that there's a lot more to programming than just 'learning the syntax' and 'knowing what each tool does'. I mean, verbal programming is essentially: you're given a bunch of tools. You're given loops and arrays and lists and functions and interfaces and what have you. You can learn what all of these do and how to write them out verbally, but does that make you a good game developer/general programmer?

Visual scripting is kind of the same thing. You're given all the tools, just in a different way.

But in the end, I think you need to know how to program. You need to know how to actually use the tools to make something. You need to know the logic, how computers work, how all the tools work together, etc.

I still am unsure about whether visual scripting can do all the same things as actual programming. I find it hard to believe. I feel programmers will be needed even if just to make custom nodes for the visual editor. Because I don't think it can have the same power that written programming can.

 

Being trained to think one way, it always hard to make yourself to learn some new way. Although visual scripting is not a language, but more like some sort of Intellisense, without seeing actual code you nonetheless have to actually learn it as a new language to describe logic circuits you are imagining. Being unfamiliar with it, especially when there is the other so familiar way to program, it is natural you feel nothing but limitations. Had you been initially trained to program with Turbo Pascal's functional programming, even then you will think at first that damned OOP and C# limits you (how could one ever survive without global methods and variables?).

Not to mention that today's visual scripting could actually not be as flexible and effective as a raw code it supposed to generate. But it is only a matter of time when it will.

 

Well, if VS will expose all capabilities of its base language to flowcharts, then there will be no reason you will not be able to make a flowchart and then put it in a single node to reuse. Not like it would necessarily be always as effective as normal coding, but not impossible.

 

By the way, how would any of you implement Gandalf's problem solving algorithm?

 

If language is so inflexible compared to squares and arrows, why didn't you take my suggestion and respond to my post with a bunch of boxes and arrows in MS Paint? Why even make the original post with so many words, when you could have just used boxes and arrows to try to describe your intentions?

 

In the future, games will just spring forth from your imagination fully formed and bug free. Until then , I fear we'll be "limited" to writing code by hand. I'm sure to a non-programmer this visual scripting stuff sounds great, but a programmer looks at it and says "wow, that's really limited". Not because we're just unable to see past our mindset, but because programming is all about power and flexibility.

What you're presenting as "the future" is a basic feature of map editors for, say, Starcraft. The ability to create limited scripts to control your game visually. That's fine for altering functionality in basic ways, but kind of sucks if you want to do anything reasonably complex. It's the difference between a paint-by-numbers piece of artwork, and a free-handed masterpiece. Sure, you can create what to the untrained eye looks like art, but anybody who sees it will say "that is definitely paint-by-numbers."

I'll believe that this stuff is even mildly exciting when I see a single game made using these techniques get published and become profitable.

 

I was never a fan of visual scripting before Blueprints. Kismet, PlayMaker, Visio, uScript, were all very underwhelming. They lacked a key feature, which blueprints addresses: It enhances my workflow as a programmer, while the others are merely (poor) alternatives to traditional scripting, which still require some degree of scripting to achieve many things.

I'm definitely a believer now, and I think UT can really do some great things in this area if they see that.

 

Oh I'm quite familiar with Visual scripting since in my ue4 project I have been writing tons of visual scripts (I sort of hinted at this earlier). For a full fledged programmer like myself- I mostly only see visual script being useful to prototype on-the-fly. And it is pretty to look upon- as I arrange my little boxes and organize things. It is fun- but I can't think of one solid advantage of a visual scripting language in Unity- when it can already compile C# on the fly quickly (at least in my projects cant speak for others).

 

Hi Ray, can you give more examples how does it improve your workflow?

My workflow is improved due to the fact in many other case I'd have to shutdown the editor if I add variables, etc to the C++ class. So, for me, the main advantage I am seeing is I am more productive because I can just stay within the editor and quickly tryout ideas.

But if Blueprints were in Unity I am dubious if I would use them *unless* I just wanted to expose some gameplay for a Designer/Non-coder to tweak

Note- all my posts are only discussing what advantages are applicable to programmers. For level designers and non-coders they are great

edit- Okay one other advantage as the original poster has stated- I do massively enjoy the smooth intellisense features! Intellisense in C# (in Visual studio) was quite amazing but I think Blueprint might edge it out. When I am in Unity I need to constantly check the docs (which are very good for me). But while I am in Blueprints it just all flows out naturally. No need to look at additional docs very often at all

 

I read all of those books. I don't remember that.

 

Maybe that would be a good ideal of how to restructure 'Unity Answers' . Certainly like to see a section of Unity Answers restricted to answering in BluePrint VS style.

 

If only Paint-By-Numbers had the same cool as Roy Lichtenstein, or rather the same cool as the people Roy Lichtenstein knew.

 

I think you bring up a good point, because Unity does have the advantage of never having to restart the editor for testing variables. In UE4 blueprints kind act as both the visual scripting language AND the equivalent of Unity's Inspector all in one, so simply adding something like blueprints to Unity wouldn't yield a huge increase in productivity, but that tight integration that blueprints have to other systems (shaders, animation, events) is the golden ticket.

The biggest advantage to a visual scripting system is the easy with which I can prototype. No matter how good I get at writing code, it's hard to beat the speed of simply re-attaching nodes, putting in new ones, copy-pasting parts, etc.

Edit - And yes, contextual nodes are the best!

 

Hello mister My-language-is-the-only-way-human-being-can-think-and-things-can-be-described. Consider to learn something about Chinese or Japanese, they are actually writing their intentions with sequences of little pictures where each denotes a concept. Also consider to learn that any writing is just a representation of a phonetic language, which could be pronounced only linear sequential way, with all its concepts about relations between things that are not linear and not sequential at all.

However, I see a frustration there, because while areas to be programmed are becoming wider and wider, but programming is becoming simpler and more accessible to anyone, not just for programmers. With UE4 artists are already creating shaders without programmer's help, defining level and game logic without programmer's help, creating interactive stuff without programmer's help, and overall creating whole games without a single line of code (as well as with that Unity's visual scripting tool was meant earlier). And if even games could be made that way, nothing to say about more common tasks like taking some data from yet another DB and putting it in yet another textbox. That area is even more standardized and thus even more prone to 'flowchartification'.

 

Because all of that kind that were available earlier were actually limited things to expose some built-in functionality to non-programmers.

What is future is visual scripting exposing ALL possible functionality and programming capabilities. So it would be not more limited than programming itself is. Speaking about 'built-in' things, isn't 99% of code just about reusing built-in functions of different APIs?

Yeah, and about published and profitable. Do you think those angry and flappy birds couldn't be created with Blueprints? Actually there is Tappy Chicken, full flappy's clone in terms of functionality. Not to mention there was the 8-bit era and never-dying games and game mechanics which were made with even more limited tools.

 

I can see that visual scripting could work out as well as programming does. I don't really see it being superior, though. I see it more as a preference - some may prefer that, others may prefer writing it out. I see both as different forms of the same tools.

Ultimately, you still have to know how to use the tools to make a game no matter which way you decide to do it. That's what matters.

 

VS can open the gate to a lot of potential app developers. You still need to learn to communicate with a computer just not with the syntax overhead on top.
Software as evolved by getting more visual independently of increased features and complexity. In fact that´s one of Unity´s Flags. I don't see how they can afford not to dab in to VS. Specially since a big contender, Epic, as "legitimated" it.

 

anyone used a VS package from asset store like this one?
https://www.assetstore.unity3d.com/en/#!/content/1808
I`m guessing its fun and all but, will it do for a serious project? Maybe someone can share his experiences with that

 

Well, I stand corrected. Advanced games like flappy birds can be recreated without having to write a single line of code. Amazing. This is most definitely the glorious future of Flappy Bird clones. What am I doing wasting my time programming when I could just be pumping out a clone of a game that already exists? From this day forth, I shall only create clones of popular mobile games. That'll be profitable, right?

 

Well aren't you precious.

 

I think this feature would bring many people who wants to make game but not necessarily have knowledge of "real" coding. Visual game coding has proven successful, for 2D game coding like Clickteam's products, Game Develop, Construct and (*pukes* because it's licensing nightmare) Stencyl.

Though there are beginnings of using visual scripting in 3D game engines, main example I have is CraftStudio, but it's not mature enough to use it for anything serious and dev dismisses any suggestions for improvements that would make it good engine. But it still isn't as good and easy as in those 2D game making tools mentioned in first paragraph.

Anyway I'd certainly would like to see it in Unity without the need of using utils from Asset Store. Or perhaps UT could just buy Playmaker or other good visual scripting solution and develop it in house as part of future releases.

 

I've actually built the majority of my current game's framework (a third-person turn-based shooter) almost entirely in uScript and Playmaker. There's this weird obsession with performance, but I think it stems from how people seem to forget that Unity already handles the bulk of performance critical code in the background.

 

If you're good and lucky at it why wouldn't it be? Certainly most people in the forums here would have scoffed at the original Flappy Birds change to make money before it made money. You scoff at the chance of a new game to make money even when they are complex games made by big companies on large budgets. Flappy Birds plays remarkably like many others games released before it and that had better art work.

You're confusing your desire to make your original game and make money from it, with others desire to make money and games being a resource poor way to do that. People at the App Marketplaces ain't going to come to the Unity Forums and ask for our approval to buy a game.

 

BP serve a larger role in UE4 than they would in Unity to be fair. In Unity if you want to have an object with a mesh as well as some code you just drop the mesh and code components on a game object and you can scale, rotate, adjust the mesh in the editor. For UE4 you put classes in the game view not empty game objects so you either need to handle all the creation, rotation, scaling of the mesh(es) in your c++ class file or(recommended way) extend your c++ class with a blueprint and do all your mesh manipulation in the BP class where it is visual.

BP is not just for "non programmers" in UE4, it is critical to how the system works and even as a coder you will use it.

 

@Murgilod Yeah, premature optimization is bane of programming. You should worry about performance when fps is low (<60fps as human eyes can't really see more) or game freezes every so often. Until then, you should use language/tool/library which you are most comfortable with.

 

Check your windows task manager, you will find that your Unity game only uses a bit over 1 core of processing power*.

* Check the number of physical cores your CPU has = X. Divide 100 by X and you should have a value similar to the cpu % used by your game.

Unity is not multi-threaded so it does not use all of the power available to your CPU, this can be a performance bottleneck.

 

I'm making this with Playmaker.

It's slightly more complicated, and you can certainly do a few cool things. I think it's great what a person or artist can actually do without writing any code whatsoever nowadays. Visual scripting has enabled a lot of people.

This is just my personal work, there are other examples as well.

It's not all garbage. While you can make a flappy clone with visual scripting you could of course do the same thing without it. One thing might be that since less experienced people would be using visual scripting it could be seen that more low quality work is produced from it, but that doesn't stipulate that it is inherently weak or incapable of being used to produce quality game logic and systems.

 

I'm aware of that, but I'm kinda saying that most games are nowhere near as complicated or performance reliant as we think they are. It's only when you get into much MUCH more complicated projects that this becomes a severe issues, and at that point Unity might not even be your best bet for the reasons you just stated and more. I mean hell, my target platform is 60fps on the late 2012 Mac Mini.

 

I have been fortunate enough to work for a couple of blue chip IT companies and the best visual tools I've worked with are cyclical, they produce code and changes to the code are reflected in the visual scripts.

Then you can have the best of both worlds, build scripts visually and tweak and adapt them in code or visa versa.

Blueprint is close to this as it allows developers to write code and then expose blueprint interfaces for adaptation and integration into blueprints.

 

My point is simply that the Unity Engine should be multithreaded, combined with a cyclic visual to code/code to visual IDE it would be an amazing tool for any project.

 

Oh. I completely missed that. It's kinda been a long month.

But yeah, you're absolutely right. I think Unity 5 is coming with multithreading though, so that should be very interesting to see.

 

Ah, I see your point now, Arowx. Yup, that'd be good, but I've worked on porting some single-threaded apps to multithread and it wasn't pretty.