Unity3D getting Visual Scripting in 2019.2

i think it would be pretty lame if they were to deprecate monobehaviour as a whole. the community has already developed quite a bit around it, it's easy enough to understand that newbies can get into it and begin to learn scripting.

if people wanted to solely concentrate on visual scripting, most would just choose Unreal. i haven't really spent much time investigating ECS, but it seemed slightly convoluted from what i've seen. granted that was only their "hybrid" ecs system, but it just seemed like standard monobehaviour with extra steps.

 

Don't worry, it probably won't happen in the next 5-8 years at least. I think.

Well. Hence they make the visual scripting in ECS for you to make it super simple, so you don't have to fiddle around in the "convoluted ECS".

 

ECS is only complex right now because it's in development preview. One of their long term goals is to make it easy to use.

 

it just seems annoying that they'd be trying to work their way towards deprecating c# and are putting so much work towards visual scripting. hybrid ECS seems like it's just standard C# with the annoying extra step of having to separate your variables from your methods in multiple classes, is "pure" ecs not C# based? and if it's just supposed to evolve into a simpler language that is geared towards VS, doesn't that abandon people who don't want to visually script?

 

This is phenomenal news!

ECS seems weird at first, but don't brush it off. It's very clever, and requires a totally different mindset to creating games. The visual editor will definitely come in handy.

 

WTF? No one said they will deprecate C#. (BTW, no Unity official said that they may deprecate MonoBehaviour either, it's just speculation).

It is. But it's not really OOP. Which you call C#. But you're just mistaken. The two aren't the same.

What?

No one abandon nobody. I don't want visual scripting for my base systems (I don't mind having it for AI for example or for UI-plug-and-play). And even for some game play, it's okay to have VS. If they base it on ECS, it may become performant enough to use for any purpose. Will see what they do, let's not start whining too early on practically zero information.

 

Who said they were deprecating C#

 

alright, thanks.

 

@Lurking-Ninja You raise a good point about the Asset store. It should be labelled visual scripting. Even better, listing which type of visual scripting language.

However even though visual scripting may produce poor output to the untrained, or be unwieldy to specialized and highly skilled programmers, to artists (and level designers), it can make a huge difference or all the difference, especially if free, and built into the engine. That was one of the advantages of Unreal (The advantages Unreal has is dwindling fast). Unreal, which the main difference used to be mainly the Graphics, and now isn't, as Unity is better or equal to them in most respects, is the blueprints and visual system.

I think there will be a massive artist "brain drain" from the Unreal ecosystem (and maybe other in house Engines) into the Unity one in the next few years because of all the great visual scripting things.

As an aside: look how many engines are used in the Top 100 steam games (taken a few days ago - last 2 columns are total players at the time I looked at the data, and then total daily. FYI Without PUBG, Unreal would be roughly same players as Unity)

 

Thanks, fantastic news. I love how multiple things align to make DOTS based VS the only sane decision. I only ask that it's also the higher-performing solution too, so as a programmer I can take guilty delight in optimising with a graph.

And once the general public realise that a DOTS graph means an unprecedented way for graphs to be more efficient than regular monobehaviour code, well I think artists everywhere will let out a cheer.

 

I just wanted to say that I'm very pleased to hear this news. ECS will see far better uptake with good visual tooling like this. It's like shaders - far more people are doing shader work with the node based editors than before, and since they generate code users can use the visual tools as a learning environment. Great move Unity.

 

Absoutely, just mildly concerned by Unity's wording with it being artist-centric, since I'm a programmer who very much becomes interested in VS as opposed to slogging through ECS - and let's face it, ECS is a bit of a hassle boilerplate wise. This would fix all that. It would go away in a master stroke.

 

Spoiler: Unity has so much market share because most shovelware games are made with it

Unity is still on top when it comes to "being easy to handle". Ever looked at CryEngine? It's complexity at its finest*! Unreal Engine can also be very intimidating at first...

* Disclaimer: The last time I looked at the CE was when it went free for everyone - almost three years ago.

 

This is only true for nodes that copy the code syntax, there will be higher level nodes that do many things where you simple connect the nodes without the need to know what the code inside is.

You are doing the same already when your using the unity build in physics engine, you are only connecting the nodes,but now in script. you dont need to know all the code for the physics engine to be able to use it

 

Those are the top 100 games. Shovelware doesn't have a real presence in the top 100.

 

I am super annoyed at people/Unity calling these tools "artist-centric".

I am an artist.

I can code.

If you want to say that it's for people that can't code, say that.

But I even think that that's false.

It's for people that enjoy working with Visual tools, regardless of whether they can code or not.

 

Not All Artists, pal.

 

@Murgilod is right. Those are top 100 steam games, good games, and Unity represented the most of them at that time (16%). Yes, it's true, Unity probably has the most turds on steam, but that's a compliment as well. It means Unity is easy to use, easy to download, and has the most resources for beginners.

One could also say the most crappy applications are on Windows. Most crappy websites are hosted on Linux servers. That's to be expected when a tool totally dominates a market. Be prepared, because there will be much more shovelware coming from Unity, as there will be many more great games and applications too.

 

Great choice! I was a bit frustrated when i saw monobehaviour based visual scripting on the roadmap talk. ECS is the future so focus for highly optimized and performant visual scripting solution seems absolutly logical for me. I also think that ECS is even better suitable for this kind of modular node based workflows. Looking forward for super extensible cinemachine nodes

 

So, so true. And given the tiny-program boilerplate nature of ECS, I cant help but wonder if this would be the same performance as hand-written ECS. If so, then a whole lot of programmers and artists of mixed capability (I, like you am an artist and programmer hybrid) - I just love the right tool for the job. With ECS being a pain (frankly) to code in and the programs so small... this is an actual industry changer AGAIN if Unity pull it off with the same perf as hand-written ECS code.

I said this right at the start and really hope that Unity can really generate ECS code with it. If they can ....

.... I'm changing how I work, right there, right now.

 

Yeah, as I said in this thread a long time ago, ECS and the DOD are better candidates for visual scripting bases than OOP and the Component-centric infrastructure. Just because it's less abstract and the system they built is closer to the "let's just wire up these systems in relation to each other"-methodology, which VS naturally is.

See? Even I'm hyped a little bit, and that means something...

 

ECS with a good visual scipting front-end could really help adoption. To those that say they “don’t need” ECS are crazy. You don’t want more performance by default? You don’t want better battery or the ability to target lower-end hardware?

I also feel ECS methodology fits into a VS paradigm better than OOP.

I think this is a great decision and fully support it. ECS and HPCS are the future of Unity scripting. I am sure the full C# and .NET stack will continue to be supported for compatibility, but ECS is what should be done by default.

 

Change is scary.

 

Hey I wasn't invited? You know that's the ind of party I like to crash!

That's teh single best argument in favor of VS ever

[ i n t e r l u d e ]

Right now I'm enrolled in a training on webdesign, while I have already most of the skills I don't know how it goes professionally, so most stuff taught are cakewalk to me now. But I'm seeing people struggling with html and css right now, and those aren't even fully form language that programmer like to consider.

Learning to code is not about the logic most of the time, html and css si easy, it's barely code, it's barely logic, it's merely description. No the real killer is syntax. Most people cry at programming not because of the logic, but because text is that awful interface between them and the logic, you have to baby sit the code, and pamper it with distraction like ";" and correct tabulation and other misery.

The pain is real, when I say people are crying it's not hyperbole, tuesday a second person broke in tears in the group and I'm pretty sure other are just crying internally. When helping them I see the same struggle, that F***ing syntax and text that broke whenever they make a change to match the logic. And that shot isn't self documented, all the feedback like underline, color, emphasis (we are using sublime text) just make stuff harder to parse because the text is basically a strobbing christmas tree blinding you with all those color.

But if any of you know free visual tools to code html and css, so I can help my new pal in the training center, I'll take it (a dozen actually lol)

[ i n t e l u d e ]

I can code, I just hate it because it's unwieldy and miserable, and ugly to look at that stupid wall of text, 99% of my error always come from the interface being text and being terrible at conveying the logic. BUT I didn't really visual coding up until ye old strumpy, remember that? good days ! Strumpy is where my argument about self documenting came from, I mean just read this testimony:

Also designer tend to have tight iteration loop, which is prone to introduce error due to high rate of editing we need to do. while visual node are slower to manipulate, it's actually not entirely true in practice, removing all syntax error, either from copy pasting, erasing, permuting line, reviewing if the logic flow is correct after modification and debugging any consequence of that, heck even just naming variable correct name are MAJOR distraction from logic and design. I mean consider the simple fact of testing an idea for a behavior, and different implementation.

In visual node I will have group of node and bypass them by simply rewiring a single link, in code I'll probably have to comment in mass, check if some expression isn't a step in the relevant logic caught in the comment (because "sequentiality" of text isn't the same as the "sequentiality" of the code and you can have interleave logic because logic isn't linear like its text representation) etc ... which can lead to simple error due to overlooking something commenting the wrong thing, having nested commented code and uncommenting the wrong code part due to that nesting. All of which can create error that become stealthy. Problem that visual node don't have because it has the same underlying layout than the logic, it's easy to seen easy to manipulate and iterate on and don't introduce error that aren't logic error.

Also get real people, visual coding and visual node ARE NOT SYNONYMOUS hey seriously
I mean spreadsheet are a type of visual coding too. Excel is the most use programming language

[ i n t e r l u d e ]

So there is two solution, find a correct paradigm of interface either by:

1- finding the correct visual metaphor to allow real coding and escaping the text trap

2- make text less painful by patching its flaws with better presentation (ide)

Or we can do both and embrace a mixed representation, which apparently mean visual node will win, because you can isolate text code into text node entry, which allow to get apple and eat it too, you have local sequential routine, and global non linear lay out that map the logic structure.

[ e p i l o g u e ]

BY THE WAY, I always complained (on these forums and elsewhere) about how unnecessary is the ";" I get why it's there and how it make thing less ambiguous for the parser, last time I didn't have the correct answer, but since I had the epiphany: command prompt. They have gone a long way since I used to program basics on amstrad 6128. Basically it's the idea that you enter your expression and submit it, and it's parsed immediately.

Okay nothing ground breaking so far, and is what's next. Now command prompt have evolved into the chat interface, ie you have en entry field and a log field. The log field basically itemize the input and format it properly, and the entry field mean you can "present" your code like you want and don't have to input any termination tag because it's implicit in the submission. AND you can still modify it by clicking into the log area and edit them in their custom entry field because they are itemized, they have local scope and you can't forget the end of scope tag (ie the satanic ";").

Modern ide (I have used anyway) seems to follow a paradigm from text edition, text is loose you can edit it in anyway you want it won't break, that looseness is kept into ide, except with a lot of training will that lit them up like a christmas tree to pretend they are helping you, but no matter the highlight, they show the syntax not the logic. In code logic is key.

So yeah even text code is ripe for disruption TOO, you can keep the rendered code the same as now, just change how we interface with it.

[ a f t e r c a r e]

Sincerely, your friend the non programmer

 

I know the feeling. I was crying when the teachers asked me to draw an apple in primary school. And later they expected me to draw scenes with proper perspective. It was painful. I still have nightmares (and also the people who took a look at my non-Euclidean drawings too).

 

I don't think anyone cares what anyone else thinks about VS only that I guarantee anyone posting in here is interested in using it because it doesn't replace anyone's precious code.

All we need now is to light a fire under Unity's arse so it gets to us in blazing quick time with blazing performance, and no butts.

(I kinda think visual scripting is not really even the right name for it any more. We're not essentially visually scripting. We're creating behaviour for our program with a graph, similar to shaders)

 

This is why I think UE really got it right when they call theirs Blueprints. Maybe ScriptGraph? Or CodeGraph? Or LogiGraph? Or something like that would work.

 

Visual Behaviour Graph? Data Flow Diagram?

 

Nodal Interactive Procedural Planned Language Engine

 

And if it doesn't feel right, you can just tweak it.

 

Yeah, problem is when you are done designing your sub system, you have a few thousand lines of code split over a dozen or more classes to write. Just imagine doing that in VS: You could get away if you write the core logic in C# and then just use VS for the flow similar to how you design AI. Though the benefit would be minimal if at all.

 

I hope that they make Entity+ComponentData a first class citizen in the scene like GameObject+Component/MonoBehaviour is. Right now "hybrid" ECS is a workaround and is dependant on GameObject and MonoBehaviour. That beats the purpose of the lightweight of the ECS. So, it they add Entity+ComponentData in the scene besides GameObject+Component/MonoBehaviour, that you can still work the way you used before, but when you want more performance, you can easily upgrade to ECS.
I think this would make the transition to ECS much, much easier.
P.S. I like how easy to use the ECS in TinyProject is, but there is so much wrapper code for it to work. I would like for that to be native in the engine.

 

Why does one need a different mindset in the first place? Massive 500 hour+ gameplay open world RPG's have been made out of standard practice methodology. It seems a little bit like re-inventing the wheel.! Also there's potential issues / unknown's with re-casting gameplay implementation in a constrained model and scalability. Just because Unity has issues (in extended scenario's where it fails) it doesn't mean ECS is a necessity, although I am willing to retract this statement if an indie manages to make a game comparable in size to the Witcher 3.

Don't get me wrong for rendering pipeline code and back end architecture that I don't (or ever will) touch Unity can knock themselves out. I'll take additional performance for zero effort any day (if there's much to be had).

As for visual scripting? First let's get this out the way, you are still coding (visually).! Although dependant on implementation it can greatly benefit designers and artists, for e.g. UE's BP's run almost like a macro architecture so what'd be a 1000 lines of code (for a multi-use char and camera controller) would probably take 30 BP's. A programmer couldn't physically write the code faster than you could create the controller via VS.!

Where VS. epically fails is complex operations, toolsets, editor additions (or anything that requires in depth implementation). Firstly Unity has to abstract functions for you to use them, secondly it becomes a complete mess architecturally and thirdly without supportive macro functions it's quicker to write in code.

Although this isn't the purpose of VS, it is a level designer / artist tool that saves many hours of boiler plate, team development headaches (backing and forthing) and prototype woe's. Like everything it has it's pro's / con's but it's handy to have. In previous UE projects I used a mixture of both..!

 

I don't want to downplay the effort that goes into developing a game like this, but the reality is the actual CPU and GPU resources needed to run an open world game are very low because the majority of the game world is completely static.

Once you start trying to create a truly dynamic open world game you will quickly run head-first into the dead end that is the current approaches to game development. We need frameworks that can take advantage of the way our hardware works or we will never be able to go approach that wall of complexity.

I want to see open worlds that feel like they're living. While the current games are fun they just don't feel alive.

 

Unity loves threads like this. The excitement in their users. They know they've done the right thing delaying it (weird huh?)

It means despite appearances, people are smart enough to hold out for a better bet - but you will have to keep us in the loop, Unity!

When something is delayed, all people ask for is regular updates - perfectly reasonable! Even better? Let us have DOTS VS early as possible on PM!
Or else we'll set fire to this jacket potato.

 

Yes please give regular updates.

we have been talking about this for a long time
https://forum.unity.com/threads/unity-visual-scripting-2017.462181/

 

That's not true in the slightest, you can tank a GTX 1080 in about 5 seconds with complex materials, full post effect stacks, excessive draw distances, lots of skinned meshes, rendering techniques (foliage overdraw etc.), physx, streaming issues.. etc. etc. etc. etc. having been part of several attempts at an RPG and a couple of MMO's you're constantly on a dipping finite ms budget and besides content plus time I'd say performance is THE biggest issue with these types of games.

It's fantastic in principle but that has nothing to do with ECS, if you're talking about fully interactive environments (grass bending etc.) / advanced physics (like APEX) with ToD randomisation events etc. etc. you've been able to do that for years in CE or UE. Let's put it this way, if it takes nearly a 100 mil to make something like the Witcher 3 then how much extra developing power / time would it need to create a fully interactive enviro?

The major problem staring everyone in the face isn't the implementation, for the most part you can already do it (in something).. Again it's time, time destroys projects before they've even started when scope creep rears it's ugly head. Finally this is primarily a small game indie engine so my point was if nobody can come anywhere a game the size and complexity of W3 what does it even matter?

Wouldn't generic 3D tooling be a better option? Whilst Unity is really stepping up their game they're still a decade behind CryEngine in terms of 3D features and functionality. Sure GC issues had to go, now they've done that so let's focus on the fun stuff like visual scripting.!

 

The thing that bugs me about visual scripting is all the clicking and stuff required to set things up, it often just does not "read" well, all the spaghetti mess usually doesn't look obvious as to what the actual "program flow" is at a glance, and you spend forever setting up all these variables and independent math operations and stuff like that which is just too low level to be efficient.

It almost always seems like a horizontal transfer from simply keying in programs as text versus using the mouse to do almost exactly the same thing. Practically the same API, the same kind of "programming". They definitely should never claim to be "not programming" because it sure as hell is. What I'd really hope to see is a step UPWARDS in terms of automation, clever configurability, or something that really genuinely saves a heck of a lot of time and makes a wide range of common things much easier, rather than having to basically do in a visual way everything you were going to have to do in text anyway. If it has an "add a variable button" I mean, really, is that progress?

 

This is true but then you have the LOD problem. What happens is that vertex pressure becomes really quite high because of the fact the further you can see, the wider you can see, so obviously that means way too many triangles for an actually-populated world.

So you spend a heck of a lot of time making that static world reasonably dynamic - at least dynamic in the sense you have to LOD constantly. But LOD brings with it render state changes and that pressures the CPU on top of the vertex pressure. You lightened the load on the GPU, but now the CPU is crying. This is where something like SRP batcher (shader change matters more than material) + ECS (culling / lod) can finally shine, so that's a pretty major deal really.

In addition to the pressure being eased from GPU via LOD/Cull, then the resultant pressure being eased from CPU to GPU we also have to figure out time of day if it's applicable. For most open world games, it's a given - you need time of day. This means your reflection probes need updating regularly, your baked options are few and your CPU/GPU just lost all the gains you gave it.

TLDR? I consider open world rendering by far the toughest and most brutal abuse of hardware today but only if you want it to look as rich as a corridor game. If you're happy with just the terrain and trees, then that's not a problem, that's totally solved. Want towns, buildings and non natural features? that's when you're going to be hurting for performance.

I've spent 5 years (I can time it because it was partially my project) solving this before moving onto an open-game rather than an open world, because this stuff is always going to suck quite a bit without concentrated tech to solve it, and you previously couldn't get around it in Unity without a huge bank balance and source or accepting less quality.

For now. Megacity / ECS + SRP will fix it though but I am wildly tangent from this thread so I'll stop now.

TLDR: open world rendering done right, ends up being more, not less dynamic.

 

Good point and as a playmaker user who can read a little code, but still will use actions perhaps this quote from jeanfabre who works with playmaker is interesting:

Re: In-built Visual Scripting in Unity 2019 ?

 

Also free, volunteer alpha testers included in this offer.

So, I will translate it for the others. Because you can't and don't do it, no one else should do it. Got it.
It's not a chicken and egg problem. If the tooling isn't there, no one will do it (right), but they will try. If the tooling is in place, someone WILL do it (and then lots of others).

In case you haven't noticed, Unity is actually breaking out from the "small indie engine" category with these very steps. HPCS, SRPs, Vfx, new audio pipeline in the works, correct mesh instancing, etc, etc, the list is very long (luckily).
I understand your wish to stay warm and cozy. And boring. But apparently Unity is aspiring to a new level. You always can stay behind on previous versions for a while or can ask them to not neglect your pet peeves. You know what I mean.

 

Knock it off muppet, are we wanting to feel especially proud because we have the stones to be facetious today? Plus you're completely missing the point, I will take whatever benefits I can get.. Performance is always a key factor, so I'm not saying please Unity don't give me excellent performance and great rendering!!

I'm asking whether or not it's a necessity right now when there's a more important factors, that's all. ECS is cool but it's not a necessity and increasing difficulty whilst implementing is kinda against Unity's ethos.. If you want amazing yet difficult there's plenty of better options out there.

 

This is where I think you're mistaken.

Judging by the bread crumbs they dropped over the past two years, Unity's insides are under heavy change. ECS is merely a complete alignment with this (and a very good piece of Software Engineering I should add).
You may think that ECS is a l'art pour l'art project, but it's not. My guess is (since I have no source access) that these changes coming from there.
Also, there are always "more important factors". At least everyone have their own set of "more important factors". You have yours, I have mine, Unity decides theirs (which usually should be a user survey of some kind).
And one more thing. The "there are more important factor" argument is inherently flawed. Software Engineering isn't a zero sum game. If they weren't developing ECS, that does not mean automatically that they have more manpower to fix UI for example. Not to mention that this kind of fundamental change (and performance boost) benefit everyone (on both sides of the Editor/Engine).

 

Then you're again missing my point, so a game the size of W3 can be made in a traditional OOP based methodology. When you say just because "you" can't do it and I'm stagnating in boredom, let's factor who CAN do it.! It would be nigh on 250 mil to 1 Billion plus games outfits.

There's a very finite amount of game outfits developing with that sort of resources, now let's factor in how many who have those resources would use a closed environment........... Yeah, most of them use their own engines and a small fraction use UE4. So what? Whilst we can both agree it's a fundamental change for the positive (for a limited few), so would many other things that could benefit every user or even just a large subset (like 3D).

I never said they could automatically refactor their workforce to specific toolsets, I never even mentioned a specific component that needed implementing. Unity are implementing VS, again it's far from a necessity but a welcome addition that many teams could struggle without but how many teams (of decent experience) would struggle without ECS as the OOP approach can do more than most can handle or need?

Sure, I am thankful that their archaic old version of mono with extra GC goodness is going the way of the dodo but still.

End of the day, they've made it.. I'll probably use it (for cool things like spawning islands full of chars in ns), I'm not trying to argue it's more a debate / discussion. The more Unity wanna throw at us the better IMO.!

@hippocoder

Exactly.!

 

If it can be somewhat abstracted for speed and ease of use via VS + C# then all of this is a none issue. Ton's of benefit w/ zero downsides.

 

Hiya, I think you're still reading me wrong... to be clear I'm asking if it's designed around performance, that is would it be equivalent performance to writing ECS in Unity?

The words I used were chosen because typically artist centric tools are lower performance. As ECS is so restrictive, I believe its technically possible to make it the same performance as hand written code.

I also want to be able to use it aggressively for lots of things so forgive me if I come across demanding or anything, thanks

 

The CPU comment is accurate, but the GPU comment is me not having enough caffeine and just having woke up.

No. I'm not referring to directly interactions between the player and the environment. I'm referring to the game world being simulated and not merely scripted. Dwarf Fortress is my typical go-to example for a game that creates a world that feels like its alive.

Edit: Emergence is the term my brain wasn't able to come up with until just now. The idea that complex systems interacting with one another create something beyond what they're capable of on their own. We can make fancy games with scripted events but it tends to have a very artificial feel to it.

https://en.wikipedia.org/wiki/Emergence