Unity Visual Scripting 2017?

Visual scripting for the win.

For anyone here with too many Youtube subscriptions I recommend using https://youtube.videodeck.net/ to organize all your favorite channels. If anyone knows any other similar tools please let me know.

 

We have a team working on it. Nothing to share until we have something more concrete.

 

You're not pulling resources away from other aspects of the engine though, correct? Some people seem to be under the impression that Unity is diverting resources away from other parts of the engine like the new terrain system in order to develop a new scripting system and last I was aware that's not the way Unity handles things behind the scenes.

That's a shame because sometimes the failed attempts can be just as interesting to read up on as the successes.

 

He dont say they have failed attemp....only they have nothing concrete to share at the moment so probably work is at early stage.

 

And it will be within 5% performance of native code!

 

the dark skin is not a bug or missing feature in the free version... its one of the last remaining "incentives" to upgrade to Plus or Pro now that the free Unity version comes with almost all the same features as the free version.

Last remaining ways to give the free Unity version a little bit less appeal is the splash screen and the missing dark skin.


In what way would freeloaders complaining about the missing dark skin and Unity not reacting to that show that Unity does not always listen to its customer base and shift its focus based on who screams the loudest? That must be the worst possible example for that. The dark skin is a feature that has been withhold from the freeloader Unity version for a reason, there is no focus to shift and nothing to develop. All that needs to be done is to add some code to the free version or not even that, change some build config and everyone gets the dark skin.
The problem here is not development focus, but a business decision by Unity.


And coming back on topic, if we argue that Unity is NOT developing VS just because of a certain loud minority amongst its user and based on the "fad of the day", well, lets just say me and a lot of other users in this thread disagree. VS is nothing new, Playmaker has been around since before UE4. It never was a big thing until UE4 gave the freeloaders VS for free, thus a lot people got access to it.
And incindentally, a lot of users that where NOT working in big teams, or on big projects where a VS only process usually falls flat on its face, and VS only is really useful in an ancilliary role when the project lacks enough programming manpower.


That is why I call it a fad. Not because its not useful, it really can be. Used in the right place, integrated correctly into the engine and taking a backseat to the real scripting/programming language of the engine, there certainly is a place for it.
But the zeal some users here preach their praises for VS with is both a little bit confusing and alarming.

Confusing because along with the usual noise of fanboying about Blueprint, we hear a ton of critical voices about its use in UE4. And the people who have tried all have enough negatives to share about it. Not saying blueprint it the pinnacle of VS systems, quite the opposite. Its a rather MEH implementation. The fact people suck that up and still think UE4 is a fine engine just shows a) how cool the rest of UE4 is and b) how many people got stuck to Unreal C++ from the UDK days and don't care about bad documentation for C++ in UE4 because they already know how C++ in Unreal works.

Alarming because with Unity hopefully busy working on new features, they might NOT look enough into the problems reported with their competitors products, and try to replicate their features based on hype without listening to the complaints about the feature they are trying replicate.


Current VS Systems are nowhere near ready to replace code in all but the smallest of projects, and even if used along code there are still tons of unsoved problems... like missing copy-paste functionality for sharing VS "code", like readability, like the amount of dragging and dropping needed for sometimes even small scripts. Like lacking standardization between engines and VS languages.
Hence why I call it a fad, as the people screaming the loudest for it seem to be unwilling to aknowledge these limitations, which would call for Unity to actually take their time and try to come out with a VS system that at least tries to solve some of the easier to solve limitations instead of rushing just the same trainwreck to production Unreal did some years ago and then leave it lingering in an unfixed state as Unity turns its focus to other things.


When the dust settles in a year or two, people might start to see that no VS system really does nearly as much as they hoped it too, they still need basic programming skills to create good VS scripts, there is still code needed for bigger projects to not make them unmaintainable, and VS is not the second coming of christ.
UE5 might ship with C++ as the leading language the documentation is based on, with Blueprint being an alternative you can avoid just to make sure the customers doing their work in C++ only do not have to open up the source of the engine just to get a C++ based character controller running.
Lets just hope that by then, Unity hasn't blindly followed the Unreal route without avoiding falling into the same traps Unreal did.
VS has the potential to be an important tool to speed up development for the pros for small quick scripts in programmer starved projects, and maybe ease some newbies into learning programming. IF implemented the right way.

 

The team that looks after Visual Scripting is not the same team that looks after Terrain. Not sure why some of our community assume that our R&D department only focus on one feature at a time.

In regards to 'failed attempts'; I think it better to share information like that when the main feature is actually shipped in core Unity. Otherwise we share 'failed attempts' (I don't think we have any 'failed attempts' with most of the features we make; more like prototypes and experiments) and community members take that as gospel & representative of the final product.

 

Have you seen the code that comes out of Amplify Shader Editor? I was impressed.

 

Yeah shaders are one of the domains where a node based system really shines.

 

Well it's just some of those prototypes and experiments make it like navigation - many failed issues with the old navigation system, which is being improved. UI - don't need to get into that... in fact I get what you are saying but it's hardly roses in Unity land. The fiasco with baking. Networking. I could go on. These are things that broke down or failed a lot of people in final shipped Unity versions.

Saying it's merely experimental would be a bit too much spin otherwise and a complete smack in the face to every dev that shipped stuff having to REPLACE Unity functionality (probably... almost everyone who shipped).

It's not an attack but it's just a rebuttal, Unity will never, ever be perfect and if it can own it's issues, it will become stronger for it.

I prefer to think of all of Unity being a work in progress, after all there are so many use cases that pull it in different directions, and it's no different for visual scripting. Some people want it in mecanim. Some people suggested it would be great to do particle system behaviour. So maybe visual scripting will be a work in progress for years to come.

The problem is Unity prefers to share when it's ready, and this ends up being not very useful for anyone outside of Unity staff and internal teams. People end up trying to use it, getting somewhere with it and having to accept the result. Other people don't use it.

It would be better to share often, and early.

 

I don't recall anyone saying that, but (obviously) if anyone is spending time on Feature X, that feature is getting attention at the cost of something else.

I haven't used any shader editors, I've just seen SF code posted in the forums. I was a lot more interested in just getting off my butt and learning shader programming (prior to last year it was something I put off as "don't have time for it" and now I regret that). I'm constantly amazed by the effects I see posted by the real pros on ShaderToy using remarkably tiny bits of code. I'd be shocked if someone told me those tools can accomplish the kind of things IQ regularly posts.

 

I struggle to use node based systems, I find them incredibly counter-intuitive and confusing in the current UE4 style, but accept a great number of people use them successfully.

 

Also consider that the director sequencer and the progressive light mapper have been in dev since 5.0 and they are only starting to show up now. Things could still be pretty far out of things are going to be done right.

 

We do share often and early; I was giving talks about the Tilemap system in November 2015, and currently the feature isn't released yet in core Unity! We also distribute experimental builds months and sometimes years before release (Again with the 2D features, also Input, Timeline, etc). Its good to be accurate with the information that is shared and when it is ready, rather than sharing something too early for it to be redone and pushed back for whatever reason (prime example: Nested Prefabs at Unite 2012 Keynote).

There is a balance that is needed; I think with Experimental Builds being public and giving talks about the features years in advance, we give plenty of eyes and hands on the features before they are released, and plenty of opportunities for people to deliver feedback on it.

 

And the solution while features are coming is the Asset Store that most of times already has the plugins that does the same job.

 

You're right. He didn't. I'm assuming that they didn't hit upon the perfect combination with the first prototype or it would have been moved from the research section of the roadmap into the development section. It has been in the research section long enough though that it is fairly easy to assume some of their early prototypes were failed attempts to create a good system.

A prototype that fails to meet the needs of the project and has to be heavily modified or scrapped is a failed attempt in my opinion. It's a normal part of the development cycle and can be both interesting and highly amusing to discuss.

 

That was quite nice, what happened?

 

Went back to the drawing board and other things were prioritised.

 

And that's why we think that visual scripting can take resources away from other features. Unity has a finite number of resources. Which means they can develop a finite number of features at a time. Which means that every feature Unity chooses to work on is other features they choose not to work on.

Every time 'other things were prioritised' it means the current features Unity is working on have come at the expense of other features Unity might have been working on.

So you can understand the concern. Even if we are wrong on the specific features.

 

The fact is that teams working on feature A aren't available to work on B. Logically, this isn't always the case, only where skillsets apply. I mean we can see the guy who did strumpy shader editor get hired for absolutely everything except making a shader editor.

Or we see skilled people moving around on different jobs. I totally get that's actually realistic, but sometimes priorities can and do pull resources away from jobs. Often there's just one person on something and they're on holiday.

That could be two people on something, shadowing each other so at least work could be continuing, but as end-users we don't have a say and probably should not have a say in the way teams are managed internally at Unity.

We don't have the big picture so it's better to argue what we really want, not how to get it.

 

I am not sure this is a great way of using ressources ? This is certainly why 2D features that are not complicated has taken so long and still not completed unfortunatelly.

I would prefer announced features to be worked on until they are completed instead of only working it from time to time and delaying it during some years because focus is lost and people have been moved to new features.

 

No. They would not survive as a company if that were so as these simple game makers don't have any bucks. I have been freelancing 7+ years in Unity and that is "mostly" the case. I have dealt with many companies who never produced a single game and do not use these forums. The architecture viz market is huge. It is used in the automotive industry for terrain generation and obstacle placement for self driving car training and visualization. It is used for designing HUD in the military aircraft fields, it is used as a scientific simulation and information display application for near ral time visualization of data. it is used for Las Vegas casino games.

 

I said that because lots of people make games using Unity just for fun, check itch.io/gamejolt/kongregate for example, there are lots of games there that are from hobbyists.

 

I have no interest in these games. I am a real time interactive VR developer for AEC, automotive, live entertainment and film industries. Your premise remains flawed. Unity is not "mostly" used by small time freebie game makers. They would be unable to sustain their massive payroll and international offices.

 

My premise was Unity's mainstream are indie games..why is my premise untrue? What are the statistics? I know there are lots of other industries that uses Unity, that's why I didn't say "all" but "mostly". And I never said they make enough money and/or sustain Unity as a company, I just said they use it, there are literally millions of indie game developers, solo or small teams, that uses Unity.

Here are some infos:
https://unity3d.com/pt/public-relations
https://madewith.unity.com

This community is toxic than ever.

 

Not always. Sometimes it's just radioactive

 

The trouble with gamers is it is all about games and they are blind sided to the larger picture. I have seen so many requests for features outside of gaming core that would be extremely useful. For example..the Wolfram plugin was shot down hard a few months back and my defense of it got me banned. I could certainly use that interface to the Wolfram servers currently to generate engineering data for structural members. The Unity techs came on and asked who wants MIDI incorporated.. well alot of non-gamer devs/musicians/realtime multimedia/sound designers wanted it...but damned if a whole slew of RPG-ers and FPS-ers griped and moaned about putting engineering resources to it. It went on Unity's very back burner. So label someone straightening you out on the bigger picture as toxic, yet i find your myopic gamer oriented focus toxic to the continued development of a wider focus to the tools in Unity, as well as your acumen in figuring out how Unity's business model may keep them in business having little to do with forging your argument.. BTW..the toxic statement is not an argument (nor grammatically correct) but if you want to respond emotionally with an opinion I offer mine up in return. Have a good day and carry on

 

So still people here who are upset because a new visual scripting feature is coming to unity?

I have a hard time understanding this, why does it hurt so much? Where does the pain come from?

 

Visual Scripting is coming, and when there is more to show we can have more threads about it, otherwise this is just stirring the pot again.