Unity is really missing a native Visual Scripting Tool

If Visual Scripting was all i could use:

- Flows
-- High level, to get an Overview.

- Sheets
-- Middle level, to see usage of Functions, Actions, Events, ...

- Blocks
-- Low level, to see what those Function look like under the hood.

Thats just my Ideal.

I know this is Way Too Much Work for any developer to implement... so i'm not gonna hold my breath.

 

I get the points people make in support of visual scripting, and the point about how people think differently/learn differently/and so on is a good one.

I hope we won't be considering it the evolution of programming, though. Not only is it vastly more limited than programming in text, but this idea sort of opposes the "different ways of thinking" that was mentioned. Going from assembly to C doesn't - you're doing the same programming, just at a higher level.

Going from text code to visual scripting requires a whole different way of thinking, which may not be a way of thinking that's as compatible with people as text programming is. I would place it on the same level as text programming, as an alternative for people who prefer it. I would definitely not call it an evolutionary step forward.

 

Again, as mentioned, the design across the board, from every developer who implements a blueprint style system - it is not a replacement for programming. That is illogical, it makes no sense and I struggle to see why programmers worry about it.

And I'm not even sure how it would replace programming. Try making an engine with it. I lament daily that Unity doesn't have one built in. I am tired of the asset store random implementations. I have a hugely complex game and I find it hard to have to code every little tiny interactive behaviour.

I likely will have to ram playmaker in at some point as it's the most full featured option but it is massive bloat, and overhead.

In The Other Brothers, I developed a component based task manager that worked well and was able to deliver some interactivity (you could probably make space invaders in it) but it too was a mess I'm not keen to return to.

I'm a programmer - I don't want to use blueprint, but I can't possibly keep up without it. I need non programmers to breathe life into the world because I am busy trying to keep on top of making the actual game, which is job enough.

I may consider piggybacking off Animator and use the mecanim style graphs to create behaviour, we'll see.

 

This is pretty much the way we are doing it in our current project and it works very well except for upgrade/unity release compatibility projects with the increasing size of external plugins we have to use.
If we had a native, performant and logical/complete visual scripting system that was built into Unity we'd probably be using it like ... yesterday. As it is we cannot even change Unity point releases because it would break too much stuff. And the project really isn't an overly large one.

 

I'm a programmer and I do use VS in a hybrid sense with UE, because if it speeds certain workflows up then I don't see a decent enough reason why not to use it? I'd rather focus on the meat and potatoes, the stuff that really matters rather than re-doing the mundane that can be done in six or seven BP's..

Or I can hand off the "mundane" tasks to artists etc. because with a bit of training near enough anyone can do it. I think we need a car analogy, electric cars are becoming a thing. There has been concerns it'll turn cars into mundane souless econobox's. Then supercar manufacturers got a hold of them, used it to increase the power and efficiency of a standard engine setup.. So the electric engine supplements the petrol..!

That's how I see it, as a supplementary service used to make delivery even quicker. Even though the likes of BP's are powerful enough to make entire games, for me it won't be completley replacing progamming any time soon.

Glass half full and all that, I'm not sure right this moment how useful a system like this would be in Unity. There's many other things on the wish list I'd rather have in first..

 

Yeah but you're using it as a designer. You wear many hats. If you had staff, the designer would best do this role. That's animation, particle scripting, anything visual, and general flow.

That's actually the designer's job. See, before now, it was the programmer's job. It shouldn't really be the programmer's job to do anything except low level stuff that doesn't make sense to blueprint.

 

Yeah, I said what I said because I keep reading people claiming that it should be the next step in the evolution of programming and it's annoying. I think the actual programmers should determine the future of programming.

Other than that, I agree with what the others are saying. I fully think that it's a great idea as an alternative tool for designers/artists to implement some types of systems.

 

But they did. Some of the smartest game engine programmers in the world all decided this had to happen, because they were utterly sick of doing every little menial task. It made programmers far more productive having blueprints, because they don't have to sweat the small stuff any more. They, very smart people™ decided on blueprint. Not artists. Not designers.

Right now in Unity, programmers are doing tasks they think they should own, but really it's not even a programmer's job, like anything visually interactive. That is not really a programmer's job. A programmer should be coding systems, while designers do behaviour.

When people realise the split between systems and behaviour, looking at a graph for behaviour makes so much sense.

 

You're right on why they created the visual scripting systems. Not as (I quote myself) "the next step in the evolution of programming" - which is what I was referring to specifically. They created it for non-programmers. Very different thing, and very understandable thing that I support. So I'm unsure why you're arguing with me, since we share the same view on that.

 

I don't think I'm arguing with you, just fleshing out the thing being discussed for general readers.

 

I guess it should be thought of more like the next evolutionary step in accessibility. Programming is not going to be replaced any time soon just like Photoshop isn't replaced by Substance Designer and analog music isn't replaced by synthesizers.

 

Well if you know I wear many "hats" you should also know I have staff, either that or I have a pretty severe case of split personality disorder. I'm not sure what your point is, it doesn't matter what roles used to be.. AAA's biggest problem was content workflow, they asked and they recieved.

If I was to focus on nothing but "low level" coding I'd be rather bored a lot of the time, as for e.g. in UE pretty much every tool / shader pipeline / workflow system is taken care of for you. I fix the occasional bugs in engine an might extend class frameworks for the original systems I made, but apart from that if I didn't join in with content creation I'd have a lot of time on my hands.

At one point I had to do it, now I do it because I haven't got anything better to do ..! Hence why I take on side project to keep skills sharp.

 

If you are taking about Blocks plugin for Unity i puchased it and i was very disapppointed.
Blocks looks exactly like lines of code instead of a visual flow of boxes and nodes, It's like you was coding , and you'll loose too much time seeking a method and opening three lists.
FlowCanvas is by far superior while Blocks is just programming with colors.

I agree , among indie engines, UE4 is the one that have the most complete A grade suite of tools and functionnalities given to you.

 

To-may-to, to-mah-to. You obviously haven't try debug some longwinded nede script. I've had to once in Unreal for a friend. It wasn't pleasant.

Also, by far the most time consuming, aside of debugging (which again, is easier with Blox since you can see what does what) are getting syntax right. With Blox or other system like that, you don't have to worry about the syntax, block'll either fit or it won't. With text programming you have to worry about the syntax all the time. Few days ago I had to look up syntax for switch..case because for some reason I've forgot I had to add a colon after each "case".

So having syntax worries out of your hand, you can concentrate about what's really important: game logic. I don't have Blox, but only because I can't afford it right now, when I be able to I'll buy it instantly because I've seen VS systems like that working in other engines, like CraftStudio (dead now, unfortunately), Stencyl and Scratch.

Obviously sometimes you need to use actual code, but these are rare times and it's nothing that "raw code entry" block couldn't solve. Most of the times, with solution like Blox, you really don't.

 

You don't blame the tools when someone uses them incorrectly. I have seen poorly designed, formatted, and written code in every language I have ever used. Poorly laid out visual scripts are the fault of the person who made them.

 

I agree you don't have to worry about syntax, but Visual Studio has syntax auto completition, it insert brackets for you, and typing the first letters of a word and it will propose you the possible variable, method or Unity Objects.
It's way faster using auto complete than Blox.
When you'll use Blox or FlowCanvas, you'll see you'll waste the majority of your time navigating between three sub menus to find the function or object you need to call. It is like loosing 10 or 15 seconds in sub menus , while you just type the first letters in Visual Studio.
Only Nottorus do like UE4 BP , it proposes you some short list of possible methods or objects to call after you type some words to find the node you need.

 

Yeah although you've probably not used them much and it's not even your project so judging it like that is kind of short sighted.

 

Even when that "person" is Epic itself, who created Blueprints? I'm talking here about examples that shipped with the system, such as that camera script. If even the people who created the darn thing can't make clear blueprints, you can't tell me it's not the fault of the system itself.

 

It's called intelli-sense (in Visual Studio and Microsoft products), not auto-completion. Since I never heard the word auto-completion until many years later, I'm going to go out on a limb and state that MS invented and trademarked the concept, so everyone else that later copied it had to call it something else, hence auto-completion.

So you can call it that in MonoDevelop but people can and should look at you weird if you say that word in the same sentence with Visual Studio.

 

I'm late to this thread but... visual scripting tool? Yucky!

 

I'm a designer. I want visual scripting. That's it. A lot of people are like me. We, as designers and artists understand things visually. They just make sense to us. We don't want to mess with code. We're obviously not coders but we still have some logic. If the VS tool is well built, then we just type the word we want and we have some stuff showing up that we can chose from. I used unreal BP for 5 MN and I managed to do something that I could have never done with unity. Heck, even googling stuff for BP is faster than trying to figure some C# stuff. I used the VS tool from detox studio in unity and here again, I managed to do stuff that I couldn't do with C# in less than 5 MN. Of course programmers are not going to care for VS, but they might if that can keep an artist from bugging them for simple stuff...

 

Well I just wish that people who comment in here have at least fiddled around with blueprint and even better, blueprint and C++. Both of them provide nice programming ecosystem. I myself, a seasoned C++ programmer find blueprint to be quite addictive except for a few cases when things get too complicated or there are cases when a few innocent C++ lines can actually translate to spaghetti mess of blueprint.

With blueprint, as someone already mentioned will at least lift burden off from programmers to do things on artist/designer bidding.. Anyone can really do blueprint stuff, provided she/he wants to learn new things and it is not difficult at all. C++ on the other hand is so much more difficult - even yours truly try to avoid it if possible.

 

People seem to like endorsing Nottorus from the asset store as a really good visual scripting tool. So far that the plead to intetegrate it into Unity even has currently over 630 votes on feedback.

 

any of you guys heard of uScript ?
https://www.assetstore.unity3d.com/en/#!/content/52060
http://www.detoxstudios.com/products/uscript/

i havent given it much time because, yeah i dont like visual scripting either, typing is waaay faster than drag and dropping 100 string thingys, it get waay more tedious and annoying, to me at least.

uScript i guess turns the visual nodes into actual C# scripts
and it can turn scripts into visual nodes?

im not sure, ive hardly looked at uScript, but its been on my list of things to do
mainly just looking at it cause it says it turns script to nodes???
... im caring about visually documenting code, but yeah theres like class diagrams or whatever . .. i havent looked into that much either

oh wait...

whaaa..?

 

I applaud the dev for being upfront about it. So many others just seem to vanish into thin air.

 

This does not mean that the product will disappear. There will probably a new 'license form' (like purchased (again) the product ) from March 2017.

 

In the case of uScript they said it's not bringing in much money, so it really is the end.

 

Yes, I'm in the same boat here. I agree that it would be nice to have, for the many reasons elucidated in this thread. But, to the idea of Unity putting any programmers on another feature like this, I cry out "Please Don't!!".

The last thing I think we need is another big in-progress feature to spread efforts even more thin, while other areas are languishing. Bugs need fixing. The editor and some workflows need improvement. Mecanim is missing ability to do things by script and substate machine any state nodes. There's a thousand other things under Feedback. The input system needs higher priority (I wonder to myself sometimes how many people are working on it?). Shaderforge is pretty much required and should really be native. The terrain tools are ancient and embarrassing. Blah blah. I digress. Complaining gets tiring and I try not to let my furrows of worry become too permanent. The point is; other stuff first! (IMO).

 

I wouldn't be surprised if that's partly because of rampant asset store piracy. I'm willing to bet that uscript is one of the most pirated assets out there.

 

Also probably priced themselves out of business.

 

It's not the most expensive visual scripting tool on the store. It was cheaper back in the day too.

 

I bought it when it was stinn in the "buy now 50% off - the full version is coming next week" phase (for roughly 3 years).
Tried it and somehow never really used it after a few initial tests. Somehow it didn't click for me. Maybe I should give it another try but then again if it's discontinued ....

Maybe it will go open source. That would be awesome.
Or Unity buy Nottorus (or do something equal of their own) like mentioned above. Since I posted it a few weks ago it has ~100 more votes on feedback.

 

The uScript guys have mentioned the possibility of full source on their forums. But uScript also produces mostly clean source, so it's still useful. At least until a major script change happens in Unity.

 

Just curious ... who here has actually used Nottorus and how good is it really?
It seems to gather a lot of positive feedback but who has really used it? And for what?

 

ME Andromeda is made with frostbite 3 and they have a visual script to.

 

Some people in this thread really need to drop their programmers EGO. There is nothing innately better about building a game in C++, UNLESS performance of a system becomes an issue. With that in mind, you can build entire games without ever touching C++ depending on the project.

You believe in your heart that C++/C# is faster for everything? You must have forgotten that the vast majority of time spent developing a game is during the planning, prototyping, and documenting phases. Getting this step correct makes everything else so much easier.

What happens in C++/C# when you're still planning your systems out and you decide to change the name of ANYTHING referenced ANYWHERE in the project? Well you break all of those references and get to waste an hour or more fixing all of those references. So fast. So efficient.

What happens in Blueprints when you do the same thing? The system is smart enough to change all of those references for you...instantly. Prototyping is a MILLION times faster in Blueprints than doing the same thing in Unity C#. Need to comment out a chunk of code temporarily? Just re-route the wire. If you're dealing with massive un-readable scripts often, it's likely a result of your poor practice. By prototyping in Blueprints, you're also developing the final systems as 90% of the things that you feel the need to "code" can just be left as Blueprints.

In a large team, C++/BP interaction allows you to properly hide things from members of a team ...and I'm not just talking about precious unity style variables hidden in the editor.

Mixing code and visual scripting also has the vastly underrated effect of making your project folder structure in the editor MUCH CLEANER and easier to navigate. Need to move things down a level from a Blueprint into C++? That's also a very easy task.

The list goes on and on and on and you're only hurting yourselves by burying your head in the sand. You're no better than those people who fought against the invention of the Car because their Horse "worked just fine". There's a reason every major company and every large-scale modern game engine is being shipped with visual scripting systems.

 

It is not ego. It is experience and familiarity with programming languages.

I look at visual tool and see a toy, every time. Epic put the most effort into their blueprints but even they didn't bring usability to the level it should have in order to be taken seriously. Sure, I can program using my left foot, but why bother doing that when I have working fingers? Same applies to visual tools. In order to switch to them, they need to offer significant advantage, which they fail to provide with exception of few edge cases and very specific applications.

Modern programming editors have refactoring tools in them, specifically for this purpose.
In case you were referring to situation when your SCENE references a CLASS, then, once again at this point the data is already organized (by you) in such way, that making changes doesn't eat too much of your time.

Speaking of which,
Unreal used to have that bug where on windows platform unreal engine was subject to MAX_PATH limitation, even for temproary files (which are typically five subfolders deep in /Intermediate). Meaning your folder path is severely limted to about hundred characters, otherwise your build will fail during packaging phase. That was fun. Not sure if they fixed that.
And regarding updated references, it was possible to destroy your whole scene by simply moving things around. Sometimes redirectors don't resolve properly, and in that case engine nukes objects in the scene for which it couldn't find references. That was fun too.
---
Either way, I should probably stop wasting time responding in threads like that. People are stubborn and rarely change their opinions. If you found efficient way to program with your left foot, sure, keep doing that. Don't ask others to switch to your methods, though.

 

It sounds to me like you're an isolated programmer (though probably very skilled) who has little exposure to the design side. In other words, you're given a set of a requirements for a very specific thing and you build it while your teammates build similar pieces. This isn't an insult, it's just how work flows through a team environment. Visual scripting won't help you much in this case unless you're just trying to piece together some logic in your head...which again, Visual scripting is faster at.

If Blueprints makes the process of engineering and prototyping easier without affecting you as the programmer, how is that a bad thing?

You feel like Unity C# is perfect for this task because, as a programmer, you see Visual Scripting as a "Toy", which happens to fall in line with the exact definition of Programmer ego.

And I don't see the point in bringing up 2 year old bugs that have been long since fixed in an Engine.

 

Those weren't "2 years old" bugs, they existed during last year and with high probability persist to this day, without a fix.
Epic does nice job with new features and all, but don't put too much faith into them. There are still bugs in the engine.

What you call "ego" is common sense. If you're making blueprint glue code for someone else, that's one thing.
However, when someone asks a programmer to use that as primary tool, the appropriate response is middle finger gesture. It is bad. Heck, blueprint editor doesn't even try to minimize mouse movement, even though it could.

Imagine you spent ten years driving a car and got damn good at it. Then one day a traffic cop tells you. "Oh, hey. New rules. Everybody's gotta drive blindfolded with hands tied while steering with their butt and looking back. Here's your blindfold.". Are you gonna comply with that? That's visual programming experience for someone who can program.

If you want it to be used by programmers, it should be much better than what epic offers. If you're talking about making blocks for someone else, then it is usual job - extending tool for people who can't program normally.

There's not much to add to that.

 

Nobody is telling you to use BP instead of C++. I don't think I or anyone else ever said that. What I said was that it is very powerful for planning and design work. If you work on a large team, BP tasks wouldn't even hit your queue.

If you're an indie dev it's useful for both design of the game and design of pieces that you MAY want to push into C++ at some point. BPs are powerful enough that often times you don't need to push them to C++. Is it better/faster to do some things in C++? Yes, nobody is saying otherwise.

What you're feeling is the typical reaction to change that I experience daily at work. You have built a set of skills that are valuable to you, that you feel are being devalued or ignored by some change. It's a very illogical thing to feel since nobody is taking your programming tools away, and Visual Scripting grossly accelerates other non-programming tasks in the pipeline.

 

Also keep in mind its not a BP or C++ question, one supports the other. BP is made in such a way that you can inherit from C++ classes and override their virtual methods. Which actually makes it very ideal to be used as the glue between systems. Lets the engineers write the systems how ever they want and leave hooks and methods behind that the Level designer, FX guys or the art team can hook into for their own use.

 

Would you kindly stop trying to play armchair psychologist? Take your ideas about "people feeling devalued" and throw them into garbage bin where they belong. Or, I don't know, prove that you're a telepath.

For me those tools are garbage, because they do not improve efficiency, but reduce it. If you want ME to use them, make them better. Much better. Mostly because I see no reason to use anything that does not give me extra power.

If someone ELSE uses this, and needs some glue code/nodes written, I can work with that, as long as I'm paid, it is usual contract work. Heck, I could probably write those nodes in arcane language like whitespace and simply charge extra for it.

However, even though I can write C++ nodes for visual systems, I'll still think that those systems are still an equivalent of a wheelchair for non-programmers. And when I'm the one working on my project, I'll feel annoyed any time an engine forces me to work with a system that requires me to work inefficiently.

It is nigh impossible to avoid blueprints in unreal 4, did you know that? You'll still have to put nodes in some places. Forcing visual system down everyone's throat just because someone believes in them strongly - that's not the right thing to do, IMO.

Either way, nothing else to add.

 

@neginfinity I've only ever worked with noodles inside blender's game engine once, would those be comparable to blueprints in anyway? I just found it worked OK for simple prototyping, but anything more complicated was just a nightmare to maintain. Or is it wrong to compare.

Also, am I wrong in assuming, his argument that that blueprints can be exposed to script, thereby implying you need to know some c++ at a decent enough level anyway to this, which begs the question, if you know this then why aren't you using c++ anyway? Except for making life easier for non-programmers on your team.

 

They're slightly better than blender nodes but I think they were missing some features as well.

Working in unreal 4 requires use of blueprints and visual editor tools and cannot be fully avoided. Thats' the problem. Basically, someone got fascinated with the idea to the point where it started getting into the way of anyone who doesn't share the fascination. Another issue is that for quite a while C++ documentation was a second class citizen in the engine and took a back seat (or rather got kicked out of the car instead of being allowed to remain in backseat) compared to blueprint documentation.

In the end, compared to a normal programming language it is like what gamemaker is compared to unreal engine. That's my opinion anyway. I just find text representation easier to deal with.

 

Well my point of view is, if people want a visual scripting tool, give it to 'em. I just think there's going to be a lot of disappointed newbies who think it's going to make their life easier - on the contrary. Visual scripting is useful only when you want to expose limited functionality to a non-coder - for programming a game from the ground up, it's just an abominable mess that needs a new node and pair of legs for every word you'd type into monodevelop.

Put it this way, imagine you were writing a book, how would it look in node format? You'd have a hundred pages of nodes for every page you could have typed out yourself.

 

If the language assumed that the next node to be executed was the one to the right (or left for some languages) of the current node or was on the next row if the edge of the paper was reached then you wouldn't need lines to connect them.

Likewise if your written language was already one based on symbols for words and phrases rather than using letters to create them how much of a difference would a node-based language really be?

 

Well node legs are not just for order of execution, there are quite a few different relationships that they can potentially describe - and that's great but there are just too many of them needed for a coherent set of instructions and they quickly clutter up the workspace.

I don't think that would put visual scripting in a better light - in fact if a written language was composed of characters like that, it would be even more efficient than it is now, whereas visual scripting would already presumably have used up this efficiency as far as it was able. 'A node for every word' is a little bit of an exaggeration mind you ..

It would definitely be fun to explore a new written programming language composed of logograms, I've always believed that languages that used these were further 'evolved' than latin-based languages or similar.

In fact it's kind of strange that I'm arguing on this side of the fence, since I'm a very visual person and I'm quite sure I experience some degree of visual synesthesia - words and letters carry strong visual impressions when I see them in my mind's eye. However visual scripting as it is now is just simply a mess and horribly inefficient.

 

The struggle is real! Conway's Game of Life in APL!

life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵}

I once read there is a linguistic theory (it has an Official Name but I can't remember it) that the reason ideographic languages (especially Chinese) layers so many meanings into their language is because people have trouble remembering enough new distinct symbols to convey complex ideas. The ideograms end up being treated almost like letters to form new meanings through combining them in different ways. This suggests to me that alphabetic languages are the more evolved variant. With just 26 symbols we can express virtually everything Chinese requires tens of thousands of symbols to represent (or, if you like, the 2500-or-so symbols that most Chinese speakers actually learn; still a two orders of magnitude improvement).

I believe this also makes a great example of why @neginfinity argues for written code versus Lego blocks.

 

Another way to look at it is that a chinese character represents something more similar to a word - now it's 2500 chinese characters vs over a million english words. Sure, it's definitely not a 1:1 correlation between characters and words, but it certainly changes things.

Also, many chinese words are similar, and I wager it's the same for most logogramic languages. Which means all you're really memorising are the small differences. So in a way you might see the little tails and strokes as individual letters, but combined in a much more descriptive way.

I must admit I know hardly anything about logograms or chinese, but it seems to me to be a denser form of information and therefore potentially more useful.

 

Where it really breaks down is keeping pace with the modern world. Maybe ten years ago I briefly learned some basic Japanese ahead of a long visit. It has a lot more Western-style structure than Chinese, but even there you see a lot of characters combined to describe something new, rather than coming up with Yet Another Character. As a concrete example, I checked the Wikipedia page on Chinese in case they mentioned that theory I was talking about. They don't, but they describe the same thing -- "platinum" is written using the two characters for "white" and "metal"... and ideogrammatic dictionaries are a serious exercise in frustration and failure!

But I guess that analogy only works to a limited degree since it doesn't carry the squiggly-line "interactions" you'd get with a visual scripting scheme.

von Neuman applied flowcharting to programming in 1949 but they fell by the wayside when "modern" (70s) terminals and typed-in-code became commonplace. Attempts to add similar visual design features to actually-modern IDEs (like UML in VStudio) have kind of flopped. There is a reason for that, and it isn't "ego" -- every dev is always looking for better ways to knock items off their to-do list!