Official Visual scripting roadmap update - September 2020

Now that you're moving away from Bolt, how do you plan to provide a means for quick and easy decision making "programming" creativity of your designers?

 

You may end up liking playmaker as it's so different than bolt.

Its easy to write actions in c#

 

I've had decent success with Unity Atoms scriptable object framework and with Odin powered custom Inspector editors.

At the end of the day, we're indie outfits as well and our needs are not that demanding for the games we make. I find existing VS tools add too much overhead in build performance, loading times and build size (especially on AOT platforms), are not well integrated into the engine be it in visual design, editor performance or debugging capabilities. Therefore, I choose to not use any VS tools currently available.

 

And it's easy to code PlayMaker out, once it's served its purpose as a rapid, easy iteration, exploration and experimentation maker. Or, as it's name suggests, a play maker.

 

You should really edit your posts to put them all in a single one if you're going to keep posting multiple times in a row.

Also, your comments seem like some type of conspiracy theory -- or at least are very over exaggerated for the impact. You're assuming that Unity users don't do any research at all and assume Unity's solution is the "be-all-end-all" solution, which isn't the case if you look at the existence of things like Unity's Shader Graph vs Amplify Shader Editor

 

It seems ever since the start of 2016 all you gota say is " conspiracy theory " to write off any
concerns of any kind.

 

I think you're deeply misunderstanding the tone of my comments.

An easy enough mistake to make.

Hope this helps autotune you to the tone:

Anything Unity creates and/or buys and makes for free that's from the Asset Store, or akin to facilities provided by assets, diminishes the market's perception of value and worth in 'rival' assets performing similar functions.

The ramifications of this are significant, and none of them good for users.

 

Any new user to unity would assume that since Unity has Bolt, it is the best thing to use.. So how much time do they use/waste before they find out they have to start over ... and invest more time, more money. more energy..

The REAL question should be does this help or hurt Unity in the long run ?

[EDIT] " Node Canvas also has some well known games under its belt like Kingdom (definitely indie) series and The Long Dark. In Kingdom it's used for AI behaviors. The Long Dark went way deeper than just AI but I also know for a fact that The Long Dark devs were shopping around for a different VS tool a couple years back because Flow/Node Canvas combo wasn't performant enough and they struggled with sustaining 60fps on target configs.They evaluated Bolt but it's way slower than Flow or Node Canvas. "

" We used Bolt for one project but we won't use it in the future. It has too many problems. "

[EDIT 2 ] For the record @april_4_short was NOT the First person to use the term " conspiracy theory " in these last few pages, they were replying to a previous post, by another user.

 

Exactly.

And you left out what I think is more likely to happen:

"We used Bolt for one project, and it got difficult to make easy progress very quickly and we got a bit stuck... we're going to try Unreal and Blueprints instead."

Which might go some ways to answering your question about what happens in the short and medium and long term, from now on in.

I suspect Unity is not only bleeding long term users griping about SRPs to Unity, and it falling on deaf ears then moving to Unreal, but also many new users. I suspect new users are coming across earlier stage problems without getting the benefit of little sunk costs (like Amplify Shader Editor and PlayMaker) that would help them learn, do and cause them to stay until they've done something, precisely because Unity is pushing Shader Graph and Visual Scripting as "their" features, when they're things done vastly better by others.

 

In any type of business, it is known as a fairly general rule... that for every customer that takes the time and energy to Complain....you end up losing ten/10 customers, that just walk away from what ever it is being complained about.

 

Add that up across the surface areas of things like Reddit, Discord, Twitter and other spaces not this forum and it starts looking a bit dire.

Sentiment has definitely shifted significantly in the last couple of years.

 

I have to disagree with this in particular. My counter is this: UVS is lousy overall and as a user you will recognize exactly how lousy it is after expending some time and effort experimenting with it or attempting to adapt it to your project for designers to use. There's a laundry list of complaints that come up in every UVS discussion, and the counter argument is usually something akin to, "Well, in the future..."

But, as someone seeking out a VS solution for the present, you will carry that lousy experience with you and it will feed into your decision making process as you evaluate other VS tools that other developers have successfully shipped games with. I think this increases, not decreases, the value of competing products on the asset store.

The asset store itself is anecdotal proof of this in my opinion: several components of Unity have high priced, highly polished alternatives sitting on the asset store right now because Unity's implementation is half-baked or buggy. See A* Pathfinding, Animancer, terrain system augments/alternatives, etc.

I can see a future where UVS is as deeply integrated into Unity as Blueprint is in UE4, and at that point I can see significant disruptions or even the death of assets like PlayMaker, FlowCanvas, etc, for greenfield projects, but that's the future, and this is now.

 

Have you seen the results of Apple's shaving of the price of Motion and FinalCut?

It's the counter argument. And then some.

The only professional video editor gaining market share, since then, is free.

Premiere, which had been getting better and better, turned a dark corner 7 years ago, at exactly that point of the cheaper price move of FinalCut.

It's become a race to the bottom, which never ends well for users of tools.

Unity has created several of these little subsection-of-the-asset-market races to the bottom, and concurrently greatly annoyed and driven out some of the best asset store makers with their SRP workload requirements to "keep up with the versions" race.

Which is to say nothing of the actual confusions created by the disparity between Unity's claims about their new features and the actual experiences of using them.

 

Bolt dominated the asset store at full price for years before Unity acquired it. Probably why they bought it in the first place. It's a great tool for Unity/gamedev newbies, just not for serious production. Once that Unity newbie will reach the limits of current version of UVS, the tool will be updated to be up to production standards. They're actively working on it.

And Unity had a huge community backlash once Bolt was not made immediately free after the acquisition. This is what community wanted. What's the alternative? DLC microtransaction Unity packages? We sorta already are there with their AR offering. Is that what you want so Asset Store devs can stay competitive?

Plenty of asset store developers are still relevant while having free Unity alternatives. uModeller, Amplify Shader Editor, etc. Are Unity killing those tools with Shader Graph and Probuilder, is that unfair market advantage? Smart Lighting 2D is doing great in the face of official URP 2D lights because it runs on the CPU rather than GPU, is way more performance friendly and has a ton more features. I fail to see how Unity releasing something for free is creating unfair market advantage. They're a game engine developer, they have to release new tools to stay relevant. Asset store devs have all the chances to build something different or better as the aforementioned devs have done and keep doing.

If anything, inept Unity implementations are motivating people to find a more competent alternative on the store. So assuming UVS do not fit their needs but they like the idea of VS, they can look up alternatives.

And devs are not dumb. A good dev is capable of evaluating all available tools and determine for themselves which would be best to use. Some random video editor analogy is not really applicable here. Especially when all the new graph focused tooling (like Graph Tools Foundation) is available for everyone to use and make their own graph tools if they don't like UVS.

 

It's not that simple, time and money is an important factor.

 

Especially so when the platform holder puts their finger on the scales, so to speak.

 

It's exactly that simple. Time not spent on evaluating tech in pre-production means the project can come upon some unresolvable tech issue which could be fatal to the project years later. If you're basing your project on unproven tech that you don't even know if it fits your needs then that's a development process problem, not a tooling problem.

You can can check out the basic UVS capabilities and compare them with other VS tools in a day or two. They're not exactly the most complex things around. And unless you're in a gamejam, any dev has that much time to make sure their project doesn't crash and burn later.

 

I have been using bolt for about a year now, and I believe it is a great tool. It has greatly increased development on my end. creating macros and building them to be reusable is insanely useful, it also helps to see the flow of all things. Bolt supports integration of all scripts and 3rd party tools through its reflection, so if there is something that does not work as well in bolt, I can easily integrate it.

I also enjoy using bolt within scripts. There’s a however many things, I would like to see improved.

1. Make them as integrated as scripts in the inspector UI, so that flow machines can function more like components too, if one wishes so.

2. Fix custom events, so that they are more hard typed. Maybe even a separate section on the variables tab, where you can see the events and their reference?

3. improve performance, even though I don’t really have any issues on that front. I feel like the people complaining are either building large projects or not optimizing their game/code properly.

separate canvases, separate scenes in one inspector, not using update functions (only if absolutely necessary), and respecting that unity updates all children and the parent if a change happens to any of them.

4. The same way object variables show up in the inspector, so do graph variables when viewing a flow machine. The experience needs to be the same as it is with scripts.

so there’s a lot new developers can get out of bolt, I personally created many applications/games with phenomenal performance even on AOT platforms. I’m looking forward to the future and many other improvements.

 

2021.2 is going to release soon... Is there any update high performance interpreter and high level nodes for visual scripting???

 

Will these visual editing utility avaliable after build in the future release? It may be convenient for debugging, or provide the ability to generate script-like action for DLC creator.

 

I wish to know anything would be changed for ECS Visual Scripting. Any progress so far?

 

Any news on the high level nodes front? Like a timeline or the kind of nodes that will be made?

 

I've been testing the new interpreter and yeh, it's pretty fast. Can't wait for the final release. That's probably going to be at least mid next year I reckon, but hope there will be a proper pre-release by 2022.1

 

Okay checked the 2022.1 a15 notes and it's landed as pre-release... Thanks for letting me know

 

Yep have fun! From my side I have been experiencing a lot of various glitches/randomness. Main one being, if I want interpreter speed in Editor, I must have no graph window anywhere/loaded. Have also been making my own interpreter nodes which gets a bit screwy too if I'm changing class names, haven't fixed my current issue where they no longer show in the fuzzy finder, something is stored somewhere that needs rebuilding but no idea where. I also had this issue pre-1.8 without knowing the cause, just my custom nodes suddenly no longer show in the fuzzy finder, while already being in a graph working perfectly.

Here's some misc results anyway Int = Interpreter (based on creating a Macro embed reference node, WIP). In ticks but obviously these are not going to be completely accurate, but give a rough idea. Also showing difference between x32 x64 which I didn't really think about before!

 

We need 1.7.7 hotfix release ASAP. It's nuts how many errors are getting thrown in console just by doing basic tasks like full screening the graph or when making node groups and entering play mode.

 

Couldn't agree more, though the problems have been going through several recent releases.

I'm having to apologise to my students for the poor state of UVS. It's a second-year course on Game Development, with early principles being taught using Visual Scripting. Frankly, I'm going to have to bring forward the C# coding because Unity is starting to look like a poor choice of engine.

 

As someone who taught game dev at a university, I'd recommend using C# as early as possible. Knowing the basics is almost always going to be useful. Visual Scripting isn't at a level where it will be better than code for a long, long time. Maybe in the distant future it will be used more often and be advanced, but I can't imagine that anytime soon, especially with Unity.

 

It's also hard to justify using the tool for client projects. I just had to revisit 1.5 year old project and migrate its custom scripting system to UnityVS since UnityVS is a lot more designer friendly in many ways. But the sheer amount of errors and warnings in console just from doing basic actions all users do is insane. It didn't have these issues more than a year ago when I last used it.

If anything, it seems to be regressing stability wise. At least it works in build.

 

This is quite sad.

They had such a rocking demo with DOTS Visual Scripting in drop 6 (so much so that people were even doing machine learning on it). Now, well, I don't even know wtf Unity is doing these days.
They've essentially dropped the ball on DOTS, then, by extension, they dropped the ball on Visual Scripting (which was _supposed_ to be based on DOTS), and now, we (may) get a watered-down, buggy mess that the poor developers stuck on this project must somehow salvage. This happened with Mecanim, this happened with Kinematica, and this will likely happen with Visual Scripting too.

You can put all the lipstick you want on a pig to try to make it pretty, but it is _still_ a pig.

I'm sorry, but no matter how many companies Unity buys up these days, Unity can't seem to even manage its _own_ technologies, much less those of a whole other company. That's why it is just _insane_ to imagine them trying to manage more than even ONE additional company. Keep throwing money at it all, Unity -- I'm sure you'll fix the leak in your ship. Maybe put some of that thicc cash to practical use and plug up the holes in your _own_ ship with it first (and then maybe determine their _origin_), rather than just keeping on buying _new_ ships to inevitably sink with your poor management style.

With these larger projects like Visual Scripting, it seems like they're always trying to fix bugs (and put fires out), rather than focusing on just making a functional _product_.

I wonder how many times they'll reprogram UVS before they realize they've lost the battle before they've even begun simply because they can never build upon (and maintain) a solid design -- mostly because their technologies (and teams -- including management) are all splintered and divided and nobody ever has to take responsibility of the product as a whole??
Their technology "design" is like quicksand. Unity _never_ prioritizes good programming design architecture -- they are always too scattered internally (teamwise) and just go at it all willy-nilly, with a boatload of ambition and a pocket full of dreams, with no clear plans to do anything but showboating (because decision makers do not know the codebase or anything beyond basic management and PR), and yet still expect things to turn out great in the end. It doesn't matter how great your programmers are -- if your project leaders and decisionmakers do not have a (combined) clear and passionate vision, then the project is going nowhere. UVS is no different. Talk to any number of successful (and some unsuccessful) gamedevs -- they'll tell you your fate in no uncertain terms:
After too much indecision, motivation tanks, and quality (and productivity) takes a nosedive.

Some further thoughts about what I've seen so far:

I run into this kind of technology "management" fiasco in (local) government all the time -- i.e. bigwigs that have a nice bachelor's (or even master's) degrees in some technology-related field from 20 years ago (or more), who, if you're lucky, can only tell you a tiny bit about 1990's technology or some algorithmic philosophy they learned (i.e. garbage-in-garbage-out), who has no idea about how or why any of that matters in today's world, but who still get chosen to lead a modern technology-based project anyway because "experience" (and since they're nice guys with a nice degree, who cares what _kind_ of experience they have aside from "technology", since they can learn, right??) -- so it's sad to see this tendency to assign "random-technology-experience-guy" to lead projects he has no business leading (btw, "leading" is _very_ different than "managing" -- one is _very_ active and responsive, while the other is mostly passive and reactive and aims to "put fires out" rather than "produce a product" of some kind). It's crazy to see this kind of thing run so rampant in the corporate technology world -- especially for a _technology_ product as important to the (technology) world as Unity is. I can see this is in local government, but I cannot for the life of me understand how it came to be in a "successful" corporation.

Because of this, I worry about the future of Visual Scripting (and Unity in general)

Unity has a chance to innovate, but instead, we get a company that tries to emulate. If that isn't "managing", I don't know what else is... :/

 

I remain optimistic and understanding, I think 2022 may be the year some powerful tools come together in unity. It's been a rough couple of years for everyone, I'm sure Unity hasn't been immune to those pressures.

I do agree they have a lot of different things to look after, must be a challenge. And now more acquisitions to add to the challenge. It all takes time, but I still have a hunch that this year we will see some great things, maybe even some things to surprise us.

As for Visual Scripting, I think the direction has been greatly innovative. I'm really excited about the new version when it's out of pre-pre-release, I'm sure previous Bolt users won't be disappointed.

 

This is the absolute _worst_ thing one can do when being "challenged" to begin with. E.g.:


"I suck with math. Let's go calculate how to go to the moon! Oh wait, I suck at English. Let's go learn Chinese _and_ French, possibly Korean too! -- When I'm done, I'll be Einstein and the Tower of Babel, all in one person!!!"


Challenge is great, and dreaming big is important, but you've got to _overcome_ those challenges before you go ahead and take on further ones. Overconfidence is a real thing when one cannot accomplish what they set out to accomplish.
Maybe Unity just likes the publicity high:
Overpromise and Underdeliver -- (Shareholder) Marketing 101. :/

I used to think like you, but look at the state of Visual Scripting (or DOTS) compared to ProBuilder, Mecanim, or even just smaller projects like Timeline Events. It's all virtually the same. In 2023 we _may_ get a watered-down version of those technologies (in experimental state for 2 more years), but we will _never_ get a full-fledged tool.
Mark my words.
This is over and over. Either it is a simple combination of managerial incompetence (and their splintered teams and nobody to take the blame when things fail, which is most likely) -- or this failure to deliver is actually purposeful.

From the outset, they purchased a pre-made solution (Bolt), threw away the progress being made on it (Bolt 2) and even scrapped their own (promising) solution (DOTS VS) in order to make their (purchased) solution (Bolt 1) work like Blueprints (because this seemed 'easier', and they could point their finger at Blueprints' design if anything went wrong). But then they realized Blueprints was far superior in everything but design _after_ people backlashed because they dropped the ONLY 'innovation' they had (DOTS Visual Scripting) from drop 6 to drop 8 of DOTS VS (after an internal version 7 supposedly 'flopped'), and then went full-force Blueprints. Only then to finally listen to people and try to add in a speed boost (the interpreter), rather than focus on eventually adding DOTS to VS or C# code generation. (DOTS VS is listed as "maybe" on the roadmap, btw -- so definitely NOT a sure thing at all).

So "innovative" is definitely _NOT_ something that applies to UVS in its current state (even if you include the interpreter layer, since interpreter layers have existed for VS in various incarnations for as long as VS has existed as a concept).


Not trying to be an ass, nor discount your opinion, but I've been watching this sh*t-show for a good minute -- and it's not as rosy behind the scenes as you clearly _want_ to believe it is.

There is a LOT of indecision at Unity -- and it _is_ affecting those of us who do this professionally.

 

I don't think acquisitions impact VS development in any way. They're 3rd party companies with their own engineering teams that seem to handle deeper Unity integration themselves. And there's no direct contact with VS in any shape or form.

Now this is harder to refute. It's been nearly two years since they acquired Bolt and the only new feature is basic Input System support. Graph Tools Foundation seems to be up in the air too. Can't even tell if it'll land in 2022.x cycle, might even be delayed to 2023.1 as Unity seem to refuse to answer if GTF will come out this cycle or the next.

The new interpreter will be the first real improvement to the tool, but how long we'll need to wait for it to become stable enough for production? Another year? That'll be nearly 3 years after the acquisition for some performance boost and cleaner API. Which is nice, but I might die before this tool becomes production ready.

They definitely took the easy way out by choosing to integrate Bolt 1. But I don't think they look at Blueprints as the goal as Blueprints has way more features and even supports polymorphic graphs as far as I'm aware. In that sense, Bolt 2 was closer to Blueprints than Bolt 1, with its class structure and strongly typed variables/events.

I think the crux of the matter was that Bolt 2 was too far from a stable release and much more complex to integrate into the core of the engine. And some higher up decided they need their VS acquisition integrated in 2021.1 pronto. They couldn't do that with Bolt 2 in time, so they took the easy way out.

They basically integrated outdated tech and are now redoing EVERYTHING from the ground up. The runtime, the UI layer, variable management, serialization tech. But they're also sticking to bad legacy design that was done away with in Bolt 2 for good reasons but they're keeping those bad decisions in Unity Visual Scripting for some reason.

Like a separate GameObject Variables component that's not tied to any graph. In a Discord progress report they've written that they can improve variable management and base them on GUIDs for all variable types except GameObject variables because of Bolt 1's design of having them be separate from the graph. But instead of fixing that poor design, they're intent on honoring backwards compatiblity above all else. Which signals a lack on understanding of why this was done away in Bolt 2 and why it's bad design in the first place.

So not only they're wrangling with redoing the tech from basically 0 while also attempting to honor backwards compatiblity with Bolt 1, they're also keeping Bolt 1's bad design decisions a solo developer made more than half a decade ago (and later corrected in Bolt 2).

It'll take another two years at least to do the GTF migration, serialization migration, etc. And then we might see some new features, I guess? Will we finally get graph search 4 years after the acquisition? What about better debugging tools? Refactoring capabilities? Strongly typed, strongly referenced custom events? Anything? I've yet to see any promised backports of Bolt 2 features of which there are many.

 

I think DOTS is the priority. From that will branch many other things.

 

Pretty sure DOTS VS is shelved indefinitely. There's 0 focus on it. The main dev of DOTS VS was transfered to Bolt/UVS team. They did the new interpreter. Then they left for another internal Unity team which is likely VS unrelated.

 

True, I just meant this in the sense that they are already biting off more than they can chew with the _current_ size (and "direction") of their technology business, and changing their overall mission isn't doing them any favors.

To be clear, "Democratizing Game Development" isn't their mission anymore. Adding more convolution (i.e. film / auto / industrial technologies) to the mix _will_ (inevitably) affect the budget / management of Unity's budget to develop game development technology (such as Visual Scripting), since Unity isn't likely to keep this newer technology open (as it is now) to the likes of Unreal / Epic customers, assuming the acquisition was meant to be beneficial to game development efforts, and thus will cost them money that the businesses they've now acquired currently still have access to. When said money disappears, you bet Unity's tooling / available developers will take a financial / production hit. Therefore, the acquisitions are just one more management / technology integration headache / business direction to contend with for Visual Scripting efforts (for example) when the current (gamedev) business _could_ be lucrative (assuming it was being _led_ properly on the local / team / technology scale, and with a solid vision and clear accountability for the technology's integration). This, however, does not currently exist. It will only be harder to implement across the business as a whole, if Unity's (seemingly random) technology purchases continue like this.

Otherwise (and in this case too, somewhat), I totally agree with what you've said.

Again, not so.
The whole scope of what DOTS was _supposed_ to be (i.e. editor-wide integration) has recently been scaled back even more. DOTS API is now supposed to be (forever) hybrid with Mono API, so we will no longer be getting a DOTS editor (or likely other tools). This leads back to what I said before about Unity's business model and mission changing drastically to more film / auto / industrial-style industries than gamedev. They're essentially giving their market share up to Unreal / Epic for greener pastures elsewhere (and saying nothing _very_ loudly about it). :/

 

One thing I didn't think about is that if they have set their eyes on non-gamedev related fields (which are the fastest growing for Unity right now), they might implicitly want to keep VS as simple as possible so designers of these non-gamedev fields can use the tool as well. But that sounds too much like a conspiracy theory and doesn't explain bad decision making like retaining Bolt 1's design or integrating outdated tech into the core of the engine in the first place. Should've started fresh and used Bolt as a guideline, not the final solution.

Democratizing Game Development is definitely not their mission anymore, it's appeasing their shareholders. The Blog posts seem to be targeted to suits, rather than actual content creators too.

Not sure why going hybrid is giving up market share to Unreal since Unreal is single threaded and will remain so.

 

Well you can't work on DOTS VS when DOTS itself isn't decided. Who knows on that front. While DOTS is based on Unity's concept of what it is, VS is based on C# so, very different.

 

It seems you misunderstand me:

The business model itself (being shifted around to cater to other industries, rather than gamedev) is clearly Unity throwing their hands up, admitting defeat, and giving up their portion of the gamedev market share to Unreal / Epic (clearly, over time). This is likely being done in favor of greener pastures (i.e. with other industries) since they clearly do not grasp the game development industry anymore. I imagine they're tired of all the b*tching by unsatisfied gamedevs atm, so now they'll hear the same b*tching (albeit a little later) from other industries that slowly begin to rely (professionally) on Unity's bipolar technology development practices (mentioned above).

True -- and cringingly so. They're just hard to read most of the time. Lots of "word-soup" to gobble down these days...

Sorry to be so disagreeable, man. But, no. This is a common misunderstanding. C# has the concept of classes. Unity's VS does not have this concept. This is actually a huge downside, as it makes programming in UVS more convoluted (and less performant) if you aren't aiming to use the instantiation of (slower) gameobjects / prefabs for substitution of strictly data-oriented classes.

Unity's Visual Scripting not having an object/type/classification system (like C# has) actually breaks one of the biggest no-no's in programming in a very fundamental way (the "Don't repeat yourself" philosophy) by having graphs be so free-form. Importing data, scripts, gameobjects, and other assets from all over the place and from anywhere you want, without thought, causes lots of need for data duplication (and retrieval), which makes your program bloated and slow. No centralized way to store and retrieve data efficiently in the correct scope (and only where necessary) makes UVS unnecessarily complicated (and weak in performance). C# (nodes) made this way would bloat the graphs even more though, so ideally we'd be programming in specially-designed (interpreted) modules -- not classes.
Granted, since this is still "early" (at least for Unity's timeline), I won't say their _eventual_ VS technology is garbage (it still has potential), but it definitely will not have C# parity (or speed) no matter how you look at it, especially considering how badly they fought the idea of implementing C# code generation from nodes (for speed) from the outset.

 

Can you explain more on your module nodes? I mean in a way, the macro assets are the modules, reusuable, even for storing data across nodes.

Bulk data is the main no for visual only, but I had a thought of using processor nodes. Also had a thought for a background pipeline (albeit designing custom pipeline affectors). At the end of the day, in a programmer/designer orientation I think it can be very powerful.

I did test the idea of using processor nodes, eg. my FastTranslate node takes in directions/transforms and then processes movement via TransformAccessArray jobs which then Instances all the items, worked quite well. In a sense, then it would be a case of sending Commands to update a particular transform/direction, which in bulk could also be a processor node of say one command eg. rotate 10deg, aim towards X.

 

Congrats that a great plan you have given and the work on the given script is also amazing

 

Hi. Can anyone explain what happened to the puzzle-platformer tutorial? Just yesterday I started to watch the video that explained visual scripting but now it's gone. And the link simply returns to the main page of Unity Learn:
https://learn.unity.com/project/creating-a-puzzle-platformer

UPD. Ok, link restored. Apparently, it was a bug.

 

Anyone got an update on the latest updates to Visual Scripting?

Last I paid attention to was they dumped Bolt 2, and promised strongly typed events/etc being added to Bolt 1.

Last time I tried it there was a basic bug (all views on the linked video are from me BTW) and no strongly-typed events.

What's happened in the almost 1.5 years of work?

#BringBackBolt2

 

They integrated Bolt as a core package of the engine (supposedly a first of its kind, so they had to create a bunch of new workflows and processes). That took about 6 months. Also, they fixed a bunch of long standing Bolt 1 bugs, UI events not responding correctly with complex, layered UI, etc. And massively improved performance in the editor.

Then they threw a new coat of paint on it, migrated namespaces from Ludiq and Bolt to Unity.VisualScripting and renamed a bunch of stuff SuperUnit->SubGraph, FlowGraph -> ScriptGraph, etc. These renames typically broke upgrading between Bolt 1 and UVS 1.6 and also broke upgrades between earlier versions of UVS. So the promise of backwards compatibility has been partially honored - it sorta works if you spend hours fixing broken superunits, etc.

There are a few new nodes added. HasScriptGraph, SetScriptGraph, etc. Also added support for the new Input System.

They're also writing a new interpreted runtime. It's currently in preview for UVS 1.8 and Unity 2022.1 beta. Supposed to be some 10-12 times faster than the current reflection runtime. But it's not stable yet. Come back in 6 to 12 months for that.

Workflow wise UVS is identical to Bolt 1 from late 2018. It's just more stable, and better performant in the editor. The promised Bolt 2 feature backport hasn't happened yet, and no progress has been shown towards any of that. I guess a lot of it is gated behind the big UI migration to Graph Tools Foundation UI layer. But no one knows when that's happening. Could be later this year, could be the next or even the one after that. Graph Tools Foundation will be used by all existing and future Unity graph tools, so progress on that so far has been glacial.

The biggest new feature was actually done by someone outside Unity, they made a full blown node search for current version of UVS: https://assetstore.unity.com/packag...node-finder-for-unity-visual-scripting-205655 It's nearly perfect, it can't search for nested asset subgraphs, but everything on the top level it can find easily. EDIT: As of 0.1.0 it now can search for nested subgraphs as well.

 

Is this abandoned?

 

package last updated aug 2023 - what makes you think its abandoned?

 

I've not checked the packages, I came to the forum to learn about it and there isn't a post for over a year, so I was checking to see if there are actual updates or just bug fixes.

 

Just look at the changelog: https://docs.unity3d.com/Packages/com.unity.visualscripting@1.9/changelog/CHANGELOG.html

But TL;DR: Only bug fixes.

 

@SevenPointRed @PanthenEye @bugfinders
as i understand, the reason development on the production releases are quiet is because all the new exciting features for visual scripting (and shader graph, visual effects graph) are built on graph tools foundation in a completely different codebase.

you can see a lot of active development reflected in the graphics packages github repo, but the visual (c#) scripting graph side of things is less transparent. the entire entire point of graph tools foundation, to unify these disparate visual graph editors. and also someday provide a node graph api for custom editor tools, not just unity's own.

graph tools foundation is also actively developed in an internal repo and hasn't been updated to a public package in a while, but is obviously updated often as commit messages for "shader graph 2.0" (which depends on graph tools foundation,) mentions this often.