Unity3D getting Visual Scripting in 2019.2

Er.... yes. In general that's how life works.

 

That sounds great but it doesn't sound like you're generating the new approach with DOTS using ECS, which I was hoping for, but I understand if that's not the case - still fantastic work thank you and the team. Looking forward to updates as we're all enjoying the process here.

Really, fantastic news that has our team buzzing.

 

What

 

As in, yes, most people would rather get something of poorer quality now then wait twenty years. Many things in life are like that.

 

Yeah, you're being ridiculous by comparing it to that time scale and dramatically underestimating the benefits of ECS going forth.

 

Can you tell me what will be misssing since mono behaviours are not going to be part of it?

Can I still trigger a sound and particle from a collision event? or can I link a game controller input to the physics force of a player controller?

 

Hopefully it doesn't end up like Playmaker. Epic abandoned Kismet and made Blueprints for a reason. For me, it should be 1-to-1 programming and allow you to create proper classes. From that, you can group together complex code into simpler blocks for artists, and with some real design, maybe even create a Playmaker type software from within it using custom high-level nodes you've made, and a state machine, which is hopefully included.

I would also like a proper class/data designer like this @ 26 minutes -

Or here @ 6:47

Is this in ECS now, or just the Tiny Mode?

If there's a bunch of obfuscated 'action' blocks that don't relate to Unity's API in any way then I'm jumping off a bridge.

 

Subtract and branch if less than or equal to zero? Or are you referring to something more high level? I'll admit I only briefly tried out PlayMaker. I quickly realized I didn't care for it at all as it didn't mesh well with the rest of Unity's UI.

 

So what's the latest with the whole visual scripting saga???

 

Will visual-script support ECS?

 

Really?

 

@3d_Artist1987 and @DreReid

Read this : https://forum.unity.com/threads/uni...cripting-in-2019-2.577084/page-2#post-4146832

 

"overall long term velocity"

going forward...

visa-a-vis

thanks for touching base

 

More high level such as "Move Character" or something. It seems like it won't be 1-to-1 visual programming at all, otherwise it would just support MonoBehaviours by default.

 

Thanks for reply

 

Hey everyone! So obviously we've been asked a lot of questions about where Bolt stands in this whole situation, so we took the time to write a small FAQ and address all of them.

We posted it on our blog here: https://ludiq.io/blog/unity-vs

The tl;dr version is: because Unity's tool will only work with ECS in the future, we'll keep on developing Bolt as a premium MonoBehaviour-based visual scripting tool. Of course the FAQ has a lot more details, but if you have any more question, feel free to ask!

 

I'm a little bit affraid that unity will take its sweet time to get this out, meaning more than two years.
Im thinking to stop my subscription until the visual scripting is out. Because I feel like I waited like forever already.

 

Just curious but why have you even paying the subscription in the first place if you can just drop it like that, especially in the context of a feature that has always been a myth or work in progress with no solid eta?

 

Ok I was not going to rant, but since you want to know why I give you some of my reasoning.

Mainly because I wanted to try out the new features of unity. and I got the promotion discount with included some asset store packages ( bolt )

And because this feature was part of the roadmap for 2019.2. I feel like every time unity announces a feature it takes too long to get it released so by the time it will be released its almost ready for a rewrite. ( Input system, GUI, light-mapper, visual scripting.)

And I still have a unity 5 perpetual pro licence. which I bought just before the subscription came out. I payed like 1200 euro for that. I would have gladly payed that money in subscription for unity plus.

Anyway I'm just a bit tired of waiting. I still want my Wacom pen to have pressure support in terrain painting since 2011. still nothing happening. Same for vertex animations imported from Maya. Or a simple curves tool in the editor.
It's all still too much programmer oriented. Like its expected that we make our own editor tools.

And the main reason why I want visual scripting from unity it that there will be a supported standard for this.
Now I'm using playmaker, Bolt, Uscript, and none of the nodes I can copy paste between them. It's also for sharing work so we can share node networks and share them on the asset-store and know that the user can use them without having to buy external plugins.

I probably won't stop my subscription but I just want to make a point that I don't like announced features that don't come to life. Just release them and make them better while people are using them, not in isolation. thats how I feel it's going now.

I mean there is great progress with the preview packages, but still its more like the package is already feature complete and then it goes into preview, with little input expected from the users afterwards. mainly bug-reports of things that don't work as intended. Of course its not all black and white and I know people at unity are working hard to make it better all the time. So I'm going to wait a bit more and see what happens this year.

 

Thank you!

 

UE's visual scripting is a nightmare. Performance is terrible, and it doesn't output C++, at least the last time I checked.

Actually, Visual Scripting is usually a bad idea for most projects, unless you re able to convert it to C# and manage it like normal code.

You end up with a lot of crap that is difficult to debug and refactor.

Text-based software engineering is decades ahead of visual scripting software engineering in terms of tools, methodologies, refactoring, etc.

I can't count the number of projects that have had to manually convert their Visual Scripts back to C++ when using UE.

 

The fact that it is hard to get right is an opportunity for Unity! If they take in all of the lessons learned from other visual scripting systems and put those into the Unity visual scripting design then they could leap frog UE. Just because it is a challenge does not mean that Unity should not do it! I believe that Unity going with ECS for their visual scripting architecture is a game changer!

 

UE 4.15 (released Feb, 2017) brought support for cooking Blueprints into C++.

Spoiler: Benchmark Video

 

We are not talking about UE

Unity vs will convert to C#

 

Agreed. Learning C# and the MonoBehaviour approach to scripting in Unity is not that challenging compared to the current state of Unity's ECS. Being able to visually script the more complex system will benefit more people than being able to use it for the relatively simple one. Including actual programmers.

 

It's going to be interesting to see how they visualise ECS data flow.

 

I'm not speaking nearly as complex as some of the smarter folks in here, but from a "code" management and visual standpoint I hope this doesn't end up a "spaghetti" code editor, with lines and nodes connecting a million different things. Some of the children's educational apps use a "block" that "snaps" to a "block" method and it keeps it very nice and clean.

 

Those systems are entirely pointless because they require you to know and engage with code in the essential exact same way as typing everything, especially when overloads are so easy to find with VS's built in tools.

 

From my standing point, when working in past with visual editors, building visual graph require similar self organisation, as with scripting. While these comes from experience. Meaning, inexperienced person more likely will make spaghetti with any tool, than more experienced. However, VS allows for better unification. Is easier to impose some visual style, than when typing code by hand.

 

Come on people, VS cant mean both VisualStudio and VisualScripting

 

Pointless? Try moving code into a state machine, or adding/removing states in regular C# when each state is its own file. With VS you can completely refactor your entire code by copy and pasting blocks. And everything ends up in the equivalent of Regions and is neat, organised and reusable. There's other subtle ways where VS can improve workflow, such as variables being available over across an entire gameobject, without being coupled to any class, etc.

Do you really want to hand-code what Mecanim does?

Anyway, I think ECS adoption is miles off, even with a completed framework and a VS option. I don't think many regular users will use it until it matches the user experience of gameobjects/components in the scene, so they should still make a Monobehaviour version. In saying that, I don't think they're capable of competing with Bolt 2, anyway, but it would be nice to have something that's free and has the stability of something Unity made themselves. It seemed like it was close to being released.

 

Yea I would still want the mono version too.
If it was almost done, why not get it out there? and in the mean time make it ECS optimised. Now we got nothing to play with yet.

 

It's not that they couldn't release, it's that they don't want to support a half-baked something, which Bolt (and especially Bolt 2 will) does better.
You always forget support. Which is the bigger part of the Unity development problems.

 

Visual scripting with nodes and lines doesn't have to be a mess. Most modern visual scripting systems have the concept of a "macro" where you can create a new custom node out of other nodes. From there you can combine those custom nodes in the same way that you would combine multiple custom code functions.

https://ludiq.io/bolt/manual/concepts/graphs-machines-macros#macros
https://docs.unrealengine.com/en-us/Engine/Blueprints/UserGuide/Types/MacroLibrary

Clearly the solution here is to buy up Bolt.

 

That train has passed

https://ludiq.io/blog/unity-vs

 

I don't think Unity should support everything across the board. It's completely fine to hold the status quo.

In business there is no such thing. They can reopen the negotiations tomorrow with different premises.

 

I'm talking about code blocks. They suck. They're garbage. It is literally the code in front of your face but now you're dragging blocks around instead of using a node-based structure where it's dramatically easier to come to grips with things like data flow and traces. Code blocks are garbage and exclusively make your code just take up more vertical space.

 

There are many reasons I always liked the Flowchart more than the Nassi–Shneiderman diagram...

 

If this is your opinion that is fine.
But if you try to generalise, purpose of flow chart type coding, then you are wrong.

There is definitely purpose and reason, where block based applications success so much. See for example blockly google project and all its forked and derived projects world wide. Result is surely opposite, from what you are stating.

 

Node based systems are overwhelmingly popular in comparison. People have tried block based systems and they are overwhelmingly slower and less approachable.

 

Possibly. But that wasn't an argument that I was responding to.

 

The argument is that they don't see use because they're not very good.

 

In my humble opinion (as I research and compare methodology):

Block is just text based on training wheel, that is the little wheelie is the ability to avoid syntax errors and have the documentation and interface be the same. They are fine for small project, but you will generally upgrade to "serious" intellisenses interfaces. You still struggle on huge code they are still as opaque as text due to the problem of identifier I presented on another thread, they obscure the data flow. Local logic however is clear, as long as it can fit one screen.

"Spaghetti" VP is at least letting you control the layout closely to group stuff semantically, also the global logic is way easier to detect. Bug are faster to detect (follow the line, which they are two aka the command order and the dataflow) and you can quickly discard unrelated stuff. They are also super fast to test various alternative by rewiring group of node, which is like the huge stealth thing that attract "non programmer", ie it's malleable. HOwever it can grew into a mess very quickly. To combat that we use "node of nodes" container that makes it cleaner at a high level, but still get messy internal, those local pocket are usually what's best read in a text/block format.

If you want to hold the statu quo (instead of finding alternatives to the paradigms)



It's obvious it doesn't have to be an either or none.

You can have code blocks into a node, and a prompt field that itemized regular text into blocks, that has output and input as link to other node. If you don't like the node style, well stay in a single node, you can either drag and drop or just type (and itemized logic into block can easily be reversible to line of code). If you don't like block, well use the node library available. In fact we can one step further and just have node be their own container of a specific view on code, like you can have a "node view" that works like an excel spreadsheet.

If you think a bit, unity DO HAVE a (partial) visual scripting system, it's call "attaching component to gameobject" thanks to serialization of code, it lets you initialize all type of variables and slap "block" to get desired behavior. A programmer friend can easily let you have variable and structure declaration with a scriptable object editor. It's just that it's inefficient for large project and not very optimized the more granular you go (though apparently scriptable variable is a thing that caught on on some dev circle).

 

I'm going to address the visual scripting "spaghetti" a bit here as I keep seeing many people somehow think you can't write clean scripts using node graphs..

First of all, you can write also garbage text based code just as well you can wire up a real spaghetti mess in node graphs. This is first and foremost the fault of the user writing the script/code and not something you can blame the system you use for (unless the system actually lacks means to fight this).

I'm going to take UE4's blueprints as example for this (even this is Unity discussion) mainly because they do provide these tools. You can properly collapse bunch of nodes into new function, make functions, use references, casting, interfaces. You can use local variables to prevent miles long wires across the graph if you for some reason don't want to split it into more pieces. You can use reroute nodes to organize where the wires run and tons of more. In the end, their system works VERY similar manner to most programming languages and you can do mostly the same things to clean up the graph as you can do to clean up your own code.

Now to get back to Unity side of things, I want to stress how important the things I just mentioned are for this: please do give your users means to keep the graphs clean and don't make it an afterthought. I'm still waiting for Shader Graph "pins" as well

 

Ill just leave this here https://blueprintsfromhell.tumblr.com/ .

 

I'm personally excited for VS. It means cleaner segmentation of tasks and dependencies between developers and level designers. No longer does a designer have to learn code to make environment interaction. No longer will some pseudo coder designer go into your beautiful system architecture and fritzel it real good, or for non coding designers they won't be bottlenecked by developers having to code things they want to use in the environment for interaction.

 

Hilarious fail. That's precisely what is totally wrong with visual scripting. That mess is what has to get solved, primarily. It's a totally unreadable tangle of nonsense. The visual styling, layout, hierarchy, visual flow etc is very much key to doing it well and if it's left up to users to end up with a disgusting spaghetti mess then I'm not interested.

 

I just copy image, in case images ever gone, or some didn't accept thumblr policies, to view content.

UE4 diagrams hell.

Spoiler

...

This are very good example, why "fancy" way of wiring is bad, where spline is used, instead of "step" / "straight" line based wiring.

Lesson should be taken from wiring diagrams.


Some diagrams reach even 1960s

Spoiler

And some more modern approaches

Spoiler

Here connections are marked with bold dots.


This one is rather colorful, for wiring identifications.


On next, notice that wires intersections, where no connection is made, are marked with little curved (bridge) wire.

Matlab simulink diagrams.
By all means, these are not simple examples.

Spoiler