Unity3D getting Visual Scripting in 2019.2

Yeah, and that doesn't sound even remotely as dramatic or as silly as:

There's this huge gap your imagination unhelpfully filled us in with.

 

We all know a small amount of UE4 fans are annoying when bashing Unity (noobish, trash etc) Don't be like those fans

 

The question to use it for dialogue is not cut and dried if it's precompiled source code. For example if you were intending to patch the game with DLC, you would be required to also change the binary. That is probably OK for most indies though?

 

People keep saying UE4 is for first person shooters and yet the first game I made when I was testing the engine was chess. One of the biggest fighting games out right now is powered by UE4. That same fighting game also uses cel shading everywhere, which people also like to say can't be done in UE4. UE4 is also being used for a lot of upcoming MMOs, from third person to top down. If UE4 was unable to handle these tasks without massive difficulty, these projects wouldn't exist.

 

Is Unity still offering Bolt as a free asset in Pro?

 

finally arrived.

 

GREAT!!!!!!. Finaly Done!. When is estimated time of 2019? Quarter 1 or 2 or...?

 

YEAR.2 generally releases in around June/July. So June/July 2019.

 

Well its not in public alpha yet, so don't hold your breath. Its entirely possible that it gets delayed a version or two.

 

Provided it's not pushed back, of course. I wouldn't be surprised if this ended up being a 2019.3 feature.

 

This. I'm not falling for it again.

 

It will be a 2019.3 feature according to the roadmap, in the first post it shows 2019.2 is the preview version

 

I would hope the visual scripting file is an asset which can be loaded through addressables or asset bundles. Although this might make it odd:

but I mean if it's at runtime....


Worst case the node graph and it's UI uses a nice API we have access to so you can make your own easier.

 

Most certainly not. It will build at build time. Does not make sense to include an entire code generator and then builder in the player...
Keeping interpreted would be abysmally slow. As interpreted languages usually are.

 

That would be disappointing. Having a built in modding language would be useful.

 

When it comes to modding the language is your smallest concern if you're doing it right.
More important to architect your entire application to avoid to freeze to death when one of your "modding friend" release some junk and a sizable chunk of your user base installed it.
Not to mention there are countless solutions for modding languages already from C# through Python until Lua or MiniScript.

But of course, if they want to release this visual scripting as kid's toy, they can make it interpreted run-time. Although you immediately kicked out the iOS developers from the user-base since iOS only supports AOT compiled stuff AFAIK.

 

Yep that would be nice. But yet to find out, how well it works, and if can handle multi threading.
I know now, this can be achieved with ECS, after my recent experimentation.

Not sure if this can be fully avoided.
It depends what method of mods distribution is involved and official check involved, if any.
If outside official server, it may be hard to control.
I think more important is, to proper sand box, to eliminate options of harmful code execution.

 

I was just quoting the slide in the OP, obviously we need more info on it.

 

I look forward to playing around with it when it's out of preview in say.... 2020.3?

 

I know, unfortunately that bullet-point was very poorly written. I'm actually curious how they want to pack in the entire Roslyn+compiler chain in the player or they will poke around with a run-time interpreter if your interpretation is correct (given the weird language of the sentence I interpreted on the way that it is performant run-time, but obviously I may be wrong).

Will see in a year or so.

 

I'll be damned if I'm not going to give it a try!

 

Please an you add LISP as a programming language.

 

U know that Unity actually goes opposite direction. Removing language every few years.
First boo (I think), then following will be Unity JS, eventually C# and .. hmm, well, I suppose C# will stay

 

Yeah, like when singers pretend to be singing, they are lip-syncing, now when you pretend coding you're LISP-syncing...

 

I agree here. I think having the OPTION of using visual scripting is nice, especially for newcomers that want to get their feet wet.

 

Yes, most people accept it's not all or nothing, no need to be concerned. I have decades of programming experience and will be using Unity's visual scripting system throughout and build all our tech around it.

I already have my own visual scripting system I developed myself. The Unity one merely replaces that so I never need to maintain it.

 

I do Scratch a lot so I will be able to make a smoother transition

 

I'd quite like to have visual scripting right now, so I can build up AI trees with it, and nice patrols and all sorts of fun stuff. As it compiles to C# it won't be data driven as much though.... sadly. But if it makes it easier for us to create emergent behaviour at editor time, with less invasive code, I'm still all for it!

 

Is this the “official” visual scripting thread or is there one I missed which developers actually read and post to? I guess it’s perhaps too early, still?

Either way, some impressions from me:

• I’ve been using Unity for VR at work for two years now. We wrote our own simple interactive product visualizer and configurator, and if I reimember correctly, the code itself took a few weeks to figure out (never done C# before).
• Everything we do, 100% is basically cobbled together by searching forums, answer sites and tutorial videos, or buying assets. This is basically how I do things at home for my hobby projects as well. I know what I want to do, and then try to find someone who has already done it and adapt their solution,
• Just before Christmas, we switched to Unreal at work. Oh, my god. It was hair pullingly frustrating in a way Unity never was, and so messy to work with!
• But now, something quite profound has happened that I never would have dreamed about doing with Unity: As usual, I searched for an example of what I wanted to do (and so much fewer examples exist for Unreal), but when I looked at the nodes used, I noticed that a node gave me a whole bunch of output values. The example only used two, but some of the others looked interesting.
• One of the values was a VR feature we always wanted to have in Unity, but I had never seen any example of it, so I never dared to attempt it. But now, in Unreal, I suddenly found myself reading their documentation, and suddenly, not only had I built the feature we always wanted, I had created an entire VR interaction system from scratch!
• In Unity, after two years, we still use Valve’s stock SteamVR plugin together with a purchased asset which extends it slightly. In Unreal, after two months, we have our own, with features we never had in Unity, and we made it ourselves.

I’m still surprised myself.

Still, it’s of course not perfect. I don’t know if there’s custom editors in Unreal, and we have our Unity set up with so many custom editors that we never have to go into C# at all these days! Blueprints seem to be quite literally code, since certain ugly syntactic things like casting is still prevalent, and I really hope that Unity’s visual scripting is more intelligent and knows more what you are trying to do than in Unreal. Sure you can search for anything in Blueprints, but if you don’t know the exact name of what you want to do, it might as well not exist.

 

Wouldn’t it be more effective to just hire people who know what they are doing? That sounds like a nightmare.

 

Um, what about the people that are still learning? Even the best creators had to learn a thing or two at one point.

 

An easy thing to say if you don't know the full scope of the subject. "Still learning" is something that doesn't end. Nobody working at Unity today isn't learning...

 

I feel nitpicking as to why we work the way we work kinda misses the point I was trying to make.

I just wanted to say that I was surprised at the sheer speed of learning that Blueprints enabled, and also the empowerment to do new things. Just today, I did an animation based on a timeline curve that I could visually edit, and from just seeing that graph, I went "hey, what if one axis was distance and the other was scale" and so I implemented distance based scaling of an object in a few minutes using basically the same nodes.

In Unity, it feels as if I have to look up everything I want to do. In Unreal, I'm discovering new things as I go along which constantly opens up new possibilities. I think it's seeing vs reading that just switches the brain into a different way of thinking (and also the act of writing vs. almost drawing).

It suits me better, since I'm a designer not an engineer, and thus, by making these comments here, I hope that Unity's visual scripting will become even less engineering/coding influenced than what Blueprints still clearly are.

 

He was talking about a company that does that.

Learning is one thing. Running a business as described doesn’t make much sense.

 

Since it has to map to C# as it generates C# source, I would not expect it to be any more or less complex than the current shader graph.

If you want it fancy or something, have to wait for community to make nodes for it if you are imagining some kind of game-maker stuff.

But since components are really simple to work with, by default I'd imagine it'll be easier.

 

Playmaker has actions that are just a c# script, unity visual scripting could have the same, or it could have grouped / nested nodes that have the similar functionality. so that higher lever abstraction coding is possible.

This way an assetstore creator for example can create complex pieces of code that are nested and people can just connect the inputs and outputs without having to know the compex inner workings.

I think its a great way forward.

 

Seems too complex for complete code noobs to pick up quickly, and mapping to C# means it won't really do anything you can't do in C#. I'm thinking this is great for a small number of specific use cases, but otherwise more exciting in concept than it will be in practice. Perhaps those specific use cases are worth the effort on Unity's part though.

 

If the scripts can be nested, complex action can be made by the community and be shared this way it would allow for creation of higher level nodes.

 

Big question is when will we get an alpha version?

And where s the DOTS forum ?

And keep also in mind we need more than just scripting nodes like in c# but also higher level nodes. For example nodes for the new input manager.

Can nodes be nested?

 

Why not just make it for both? Does development speed matter that much?

This just leaves Unity completely fragmented. Standard pipeline is already missing shader/vfx graph, and I think you're overestimating how many (and how fast) people will shift to the new ones.

 

Expandable does that mean nesting? Like grouping a bunch of nodes into a single node

 

I guess I'm glad I was wrong and I think I need to buy some lottery tickets, be right back.

 

For the same reason they discontinued UnityScript. Having to support multiple systems means increased cost (money, staff, etc), potentially increased time between releases (we were on older frameworks for so long for a reason), and potentially fewer features common between them (eg UnityScript had fewer features than MonoBehaviour).

We're already fragmented. Last I heard MonoBehaviour and ECS were going to co-exist with each other. I see this change as a possible avenue to eventually discontinue MonoBehaviour (by that point ECS should have had an improved workflow and no longer be in preview).

 

How dear you preach so badly Monbehaviour?

But I think that is very realistic thought now. This can be very interesting to watch, of turn over events.

 

Such a let down, was looking forward to using this. We have no need for ECS any time soon. maybe this will make it easier to get into ECS whenever its actually ready. but being able to get Unity into hands of beginners, artists and non-codes now seems less likely at least for the next year or so. sure go buy Bolt, uNode, or Nottorus. really how hard would it be to make it compatible with ECS and monobehavior. if these single developers *uNode / Nottorus can do it by themselves and generate clean C# scripts from the visual canvas, why can Unity not figure it out, with all the staff and support behind them. just seems short sighted.
not holding my breath...

 

Do you want something of a lesser quality soon or do you want something of a greater quality not as soon?

 

i think this is a huge mistake, and was made to preserve asset store sales and save money on VS dev, i dont need VS from store or unity as long as i have c# nothing else matters
newbies and artists better learn to code else they have no place in game dev industry VS requires the exact knowledge and time put into it to learn as code hence its pointless

 

You'll have to tell that to the game dev industry. It seems they missed the memo because just about every major game engine, whether publicly available or privately developed, has a visual scripting system.

Some people have problems with the text-based format of code. It's not at all pointless to them.