Unity Visual Scripting 2017?

Hello,
First off i wanna say that i'm happy that Unity is working on own visual scripting and cant wait to see the results.
After i heard about this on Unity GDC 2017:

i go and check "Roadmap" where i find Visual Scripting waaaay down at the very bottom in the "Research" part of the "Roadmap"....Ok so i give this at least 2 years before this go live (if not more) based on the position where it lie on the roadmap. But then i see the Unity site home page where i read:

"Unity 2017
The next generation is coming. New features across graphics, performance, efficiency and platforms, plus tools for a new audience: artists and designers. Meet Unity 2017.​

So there is chance for this in 2017??

 

I wouldn't hold my breath... perhaps in version 2019 it will be great. Until then.. just learn to code, if I can do it.. anyone can.

 

Or just use Playmaker:

https://www.assetstore.unity3d.com/en/#!/content/368

Which comes free with Unity Plus, at least for awhile:

https://store.unity.com/offer/unity-accelerator-pack

 

Hope visual scripting doesn't come with it's fair share of problems.

 

Not if you are a current subscriber. They do offer a discounted price of $75 for the whole pack. I suppose that is good if you really want all three.

 

The roadmap is out of date and I wouldnt assume much from it until it includes at least one version of Unity 2017. Stuff they have announced about what will be in Unity 2017 certainly trumps the roadmap in its current state.

 

I think the "Visual scripting" item has already been under the research section for almost 2 years, or at least from the day they made the public roadmap page

 

No.

 

If it's anything like Blueprints for Unreal, then you'll loose all the performance of C#.... I've researched Blueprints an such and they say if a person makes an entire game with nothing but Visual Coding, it makes the C++ as slow if not more than C#.... So what would that make Visual C# in comparison in terms of speed? I'm sure you can still make pretty nifty things, but I can't really see any serious AAA game using nothing but Visual Scripting, i could see it only being useful for small repetitive things, but not every single thing.

 

Does speed really matter in terms of visual scripting? I mean as long as its not magnitudes slower, the point of visual scripting is more to enable people who cant script traditionally, I think a speed tradeoff is fine in this situation. If performance was the only thing that mattered, you might as well make the argument for switching to Unreal and C++ over Unity.
@OP Don't hold your breath. By new tools for artists in 2017, they're probably talking about the iterative lightmapper, or cinematic tool, both of which have been shown off in various forms for a while now. Visual scripting on the other hand has never been demoed in any way or form. They talked up making things better for artists in that video, and then spent 5 or 10mins on another programmer feature(not that I'm not excited for the possibilities of scriptable renderloops, but as an artist primarily it was irksome).

 

Well I only mentioned that because C# is quite powerful now compared to how it used to be, and in some cases can be faster than C++ if a C++ coder don't know how to code properly.... However, I've noticed with my game, I have 80 AI Spaceships and the FPS went from 60+ to like 49. The profiler says it's coming directly from the script that controls the AI Spaceships, so imagine that in Visual coding, it would probably be near 25/30 FPS because of the Milliseconds per frame time.

I mean I have nothing purely against Visual Coding, I mean too each their own, I just hope they never make it forced or I will have to change engines. I just dislike Visual Coding only because it's a tool that you can get comfortable with, and in doing so when it comes to a really trivial problem that the Visual Coding just can not do - then your lost and stuck because you never learned to code.

 

While I have zero affiliation with Unity, I'm pretty confident in saying they will never in their existence "force" visual scripting on its users over coding. That would be product suicide.

 

I learn how to code and even already learned a lot but this not disable me from curiosity how Unity execute visual scripting in their way. I hope this will not be copy-pasta from Playmaker and not because i dont like it, i'm simply curious about how Unity execute this feature.

 

Blueprint just hides a C++ code generator. I've read it's 20% slower on average than handwritten equivalent code. I would imagine Unity also plans to go the codegen route, and I would guess they'd choose C++ for the same reason they're investing so much blood, sweat and tears on IL2CPP.

It's also worth noting that anyone fantasizing that visual programming in Unity will have feature-parity with real programming is likely in for serious disappointment. Get on Google and take a long hard look at actual visual programming "languages" in the real world. There are actually two I'm aware of that can output C# ... Microsoft's own VPL that was part of the now-dead Microsoft Robotics platform, and DRAKON, pretty much a glorified flowcharting program used by ROSCOSMOS. VPL was little more than a state-machine graphing tool, and DRAKON doesn't have normal, largely mandatory programming concepts that would make it useful for complex interactivity (they're more along the lines of single-function console programs). If visual programming is such an obvious, valuable feature, why aren't there a huge variety of examples to choose from?

Ironically (given it's association with game dev), 3DS Max's MCG is probably the one visual programming language I'm aware of that approaches the flexibility of real programming in a visual way. And guess what? The resulting programs look pretty complicated.

As Euclid said of geometry, there is no royal road...

 

I would hope before they rush the visual scripting feature, they will speed up their work on the terrain system which has been promised since at least 2014, if not 2013, and has been in the Research part of the roadmap for just as long.

IMO an updated and modernized Terrain system is way more important than a visual scripting tool when you already have a) one of the best and most comfortable C# APIs available, and b) can choose from a ton of thirdparty visual scripting tools on the asset store for fair prices.
Even before we take into account that other stuff in the research category is just as highly anticipated by other people, and stuck in this development limbo for way, way, WAY longer than this new kid that is visual scripting.


Update us on the current status of the terrain system rework already, Unity!

i would have never thought Epic would do that... but then they went and made Blueprint the de fact standard for UE4 development, and wrote all documentation for it, leaving C++ documentation for later (and never got around to do it).

So even if Unity does not intend to force their visual-scripting-thing on anybody... if they are not ready to DOUBLE their documentation effort and write the same documentation for C#/Unityscript AND visual scripting, and vote for documenting visual scripting over the programming languages, they are in fact forcing visual scripting on people, especially the newbies.

 

That's the part that always kills me about the Visual Programming Debate -- there are so many other far more important problems to solve, and limited resources available.

Hell, Unity isn't even the right place for a visual programming feature. Unity is a scene editor, not an IDE. It would make more sense as a Visual Studio extension.

Maybe we programmers should start ganging up on Unity, demanding that it's imperative that they turn the editor into a dumbed-down Maya so we can design models for our games without having to learn any of that pesky art stuff. Unity's time and money is a limited resource, we might as well push for our interests, right?

 

You DO realise that these features are helmed by like... entirely different teams, right?

Right?

 

You DO realize they're all paid by the same company, right?

Right?

 

You do realise that Unity is loaded as balls, right?

 

I wonder how many people gunning for visual coding have even tried playmaker or something, to see if it's even going to be any more approachable than written code? If so, what were the things you did/didn't like about the visual coding tool you've tried, and how far did you get making any sort of game with it?

Right now, I could be wrong, but I just see people basically looking at visual coding with little understanding of where the real difference lies. Put it like this, if you can't draw a flowchart on a piece of paper (or ten) to describe all of the class declarations, variable assignments, calculations, information passing and handling and so forth in your game, visual coding is not going to be any more easier.

I'll say what I said before - I think Unity should provide an empty blueprint system and let the asset store figure out exactly how micro or macro the interface should be. My guess is that a very macro blueprint produced by a good traditional programmer is going to end up being worth a lot more to non-coders than the ability to spawn something that has more right to the term 'spaghetti code' than any written code could claim.

 

That might be true... but given only a limited amount of resources are spent on developing new features, programmers can be moved between teams, and teams are competing for resources and programmers, guess what happens if the team working on visual scripting suddenly gets most resources assigned because its "super urgent because of user demand"...

Other teams will have to suffer because sure as hell Unity is not employing more staff just to speed up development of visual scripting. If they speed up dvelopment on the feature, the team members added to that task will have to come from somewhere. And as developing the terrain system tools is just as much an editor UI and engine tool task as is developing the visual scripting tools, the programmers might be coming from this task.

Or from developing better light bake tools. Or from any other task that is needing engine programmers, but is deemed less important by Unity management.


Entirely different teams does not mean every team works in isolation. People and money are finite resources even in big companies swimming in money.

 

It wouldn't even cost anything.

https://www.assetstore.unity3d.com/en/#!/content/1566

 

Unity has like 1500 employees at this point. You're making a mountain out of a molehill here.

 

About a year ago somebody from Unity (I think in yet another Visual Programming Debate thread) pointed out that only a tiny fraction of the headcount did any programming.

Maybe Unity first needs to develop an in-house visual programming language for the engine so all those receptionists and interns can help out, eh?

 

And how many of these are engine programmers? 50? 75? 100?

I guess the number is FAR smaller than you, or even me, thinks. There is management, there is HR, there is marketing, graphics designers, project leads, and so on.

In the end, the amount of people that COULD work on engine programming is most probably <200. And how many tasks is Unity working on at the moment? How many guys are assigned to each task?


There is a reason why tasks have been stuck in development limbo for >3 years now. And the reason is not because the tasks are so hard that even 50 guys couldn't finish it in 3 years.
Its rather that not even 5 guys are working on it. Might be that the task was deemed to be not very important by management... might be that Unity still doesn't know where to go with the task.

Still, the fact that stuff gets delayed shows that programmers ARE a finite resource even in a company the size of Unity.

 

A fraction of 1500 is still a substantial amount of programmers.

You're seriously acting like Unity making the engine more accessible (and this IS an accessibility feature) is somehow taking away from things like terrain, which are massive undertakings, which is why they're taking so long. Unity has teams dedicated to input, 2D features, experimental features like visual scripting and more recently Cinemachine, and a whole host of other things. Nobody is taking terrain away from you.

 

I welcome a visual scripting tool, and look forward to the first experimental betas

 

I'm still really interested to hear from a non-coder who's even tried a visual scripting tool at all. Anyone?
I'm not against Unity spending resources on it if it's going to help a significant amount of people, but I seriously don't think it's going to change very much at all. Maybe if those who are asking for it could be more specific about what it is they want, we could figure out something that would actually be useful.

 

You won't find many here because Unity skews so programmer heavy specifically because of its lack of tools like VS, but Hearthstone specifically used Playmaker so its artists could better create effects for cards, and Project Wight is using tools like Shader Forge, which is another form of visual coding, just for shaders instead of scripts. If you want to find more people using VS, look to places like UE4, where artists flock specifically because it's so much more accessible.

Or look at the fact that Playmaker has been one of the top selling assets since it was released. You know, stuff like that.

 

I've never used terrain, and getting a visual programming language right is a massive undertaking. It's particularly ironic that people who don't want to learn to program seem to think they're experts on the difficulty level of implementing visual programming.

The VPL crowd is acting as if this is some grand conspiracy to deny them a quick-and-easy fix. Which is even more ridiculous because you've already been told it's somewhere in the pipeline.

If it were easy, VPLs would be everywhere. Marketing people love a simple-looking boxes-and-arrows picture instead of a clump of scary-looking braces and geek-words. I've been writing code for 40 years and there has never been a VPL of any significance. Blueprint probably comes closest, and their forums are full of complaints about it.

Come to think of it, why aren't the people here flocking to UE4 if VPL is the defining characteristic of what makes an engine attractive to you? It's there, go get it.

 

@Murgilod : Now that begs the question: How many Indies do you think have released games worth playing with it? Not just another clone of flappy bird that took 6 hours to make.

I mean clearly it's a very popular tool, but I wonder how many (Indies) actually release these games. I have Play Maker, it was in one of the free discounts that the asset store had one day, never even downloaded it yet. I just like to have things to have them. As the ol' saying goes "It's better to have it and not need it, than to need it and not have it". lol.

EDIT:
@MV10 - Which is why I think it's important for anyone who wants to make a game or an application in general, really needs to learn to code. Because as you mentioned - it's a massive undertaking to make a VS Language, who's to say this new feature ain't out yet and won't be for 2+ years and you must REALLY need it. Well you either suck it up and learn to code or wait 2 more years lol.

 

I've played a couple games that were made entirely with playmaker from here on the forums. If you want to see more you can always check out the playmaker thread. I've also played games that were made predominantly with Blueprints coming from UE4. It's not like people are just dropping $65 on Playmaker, or $90 on Shader Forge, or $50 on Amplify Shader Editor and just never using them. They're consistent sellers for a reason.

 

https://www.guerrilla-games.com/read/creating-a-tools-pipeline-for-horizon-zero-dawn

Read here why an AAA studio such as Guerrilla uses visual scripting in their pipeline for Horizon.

 

First of all, have you used playmaker (or the free one that MV10 linked to) and what were your thoughts?

Well I've certainly seen a lot of artist showcases made with blueprints, but the question is whether it's useful for making an entire game of any reasonable complexity. In regards to shader forge, a shader is essentially a single class, and the lines of active code usually run in the tens of lines (for obvious reasons, since it has to run thousands of times for a single mesh for the vert function, and probably many more on average for the fragment function).

Visual scripting on the other hand calls for the ability to create classes with the equivalent of hundreds or even thousands of lines, which then interact with other classes in extremely complex ways. If you take that a visual editor has on average (just as an example, I have no idea) four nodes for every line of code, what is a game with the equivalent of 20,000 lines of code going to look like?

Let me say, I definitely support a visual material editor and even shader editor, but this has nothing remotely to do with whether or not visual scripting is going to be a feasible option for anyone.

 

Nobody said a visual scripting tool should be isolated to non coders, The scripting classes can be written by programmers, and even be sold on the store. It's just another way to hook things together.

 

Creating custom tools with a high level node interface is perfectly logical where appropriate, and that's the main reason why I like the idea of a blueprint style system where programmers can create blueprints for level designers and artists.

But what visual scripting entails is basically creating a node editor to create the node editor that you see in those slides. It's an exercise in unnecessary complexity if you ask me.

 

Well that's what I'm in favour of. But don't forget that a visual scripting system made by Unity would have to be fairly comprehensive. They can't just say "ah yeah, that won't work with visual scripting, better write that in code or find a programmer".

The way I see it is that no matter how much you polish the user interface, the entire visual scripting system would reflect to some extent all of the levels of detail that enable you to get from "int x = 0;" to creating a star wars battlefield. All of those levels of 'zoom' have to be captured by the system and handled in such a way that the user has a minimum of unnecessary information on the screen, and that seems like an extremely difficult task to me.

 

@Billy4184
yea so for example more of an state machine visual editor?

 

Yeah I think it would be great if programmers could write character/vehicle controllers, level creators and even gameplay managers in such a way that non-coders could interact with them inside a blueprint style editor. I would love to make stuff for that and even use them in my own games.

At the moment, there's no real way to make even a very high-level modular script asset that a user can interact with without coding to some extent. If I made a spaceship controller and exposed the yaw, roll and pitch input values as -1 -> 1 inputs for a node editor, then in the code I could handle all sorts of stuff such as exactly how the force was applied and so on, and the non-coder could integrate it in a node editor without writing any code. I think Unity are missing out on a huge market for this kind of stuff.

 

yes I see, so in that way it can also function as a script manager, with a standard way of storing and exposing script interactions.

 

Yeah exactly - basically the equivalent of the Inspector, but with a standardised interface for interacting with attributes exposed on other scripts. It would make perfect sense to make it a node editor.

 

Unless its visual scripting which can be controlled entirely from the keyboard I'm not interested. It might be nice to type stuff that automagically formats into pretty visual code.

I'd actually like LESS visual scripting in Unity. Instead of dragging a texture here, making a prefab there, etc. Just give names to everything and control it all from scripts. Much quicker. Keyboard > mouse.

When I see blueprints in Unreal I can't make head nor tail of them and I'm quite a visual person. Maybe what they need is icons and pictures to appeal more to visual thinkers. Otherwise its still just text but with wires to make it even more confusing.

What they should invest in is more domain-specific-languages. I've seen some quite good ones created specifically for making games. But I can't remember what they're called.

 

Yes all visual scripting should be accessible via code, I do agree with this, especially for search and replace actions.
I do think that its possible to have the best of both worlds,
I do however also feel a little bit unsure how unity will implement it. If we look at the animator is not so friendly and results in a lot of manual labour.

There should be nothing that stops visuals scripting from working well with keyboard commands.

 

Yeah, it always looks like a tangled mess to me, too.

 

Some smart sorting can untangle the mess
At one point we want only high level script to be connected by a simple wire, and at the other hand it may be useful just to have a single variable in a node. it all depends what the end goal is.

A tool that can guide good practice will be a nice thing to have.

with smart grouping and hiding complicated things and exposing what is meaningfull.

 

Unity has always been in favor of programmers vs artist, but they realized times has changed and need to revamp the engine.
Epic has always been artist friendly since the early days of UDK. UE4 marks a new chapter in game engine technology by empowering the artist and is super easy to get started. Now the tables are turn and the artist can go out and make a game without any help from a programmer. It can also convert the blueprint code to c++ as of 4.15.
Unity needs to revamp the entire engine not just in visual scripting, but also in materials, Ai, sequencer, etc. That is if it wants to compete with UE4. Unreal Engine is now being presented as a pre visual tool for Hollywood and for design firms like The Mill and ILM, Wetta and many more.
Unity is a great engine, but it needs to get with the times. God speed.


btw.
The plug-in Nottorus which is a very robust visual scripting tool and can convert c-code and vice versa was created by one person. Granted it took him over a year to do. If Unity focus its effort with all their resources, than we should have a nice polished piece by Christmas. Two years is not acceptable especially when seeing Epic with their legion of coders catapult every release.

 

I think it was roughly an order of magnitude slower.

IIRC unreal team was working on a feature that would turn blueprints into C++ code, though, not sure if it ever was finished. I remember reading blueprint nodes source, and those definitely aren't just "hidden code generators"

The budget is not infinite, and would be more intieresting to have those "different teams" work on a different feature. Ones of interest are Timeline and Progressive lightmapper. When was the progressive lightmapper announced the first time, by the way?

That's still less employees than in Microsoft/Google/IBM/Sony, and not all those people are working on coding part.

Also see Brook's Law on wikipedia.

Brook's law. Adding more programmers to a project does not necessarily make it finish faster. It can make it finish slower, though.

Epic Games sank several years into their blueprint tool and it still has flaws, and visual tools have very limited usefulness. That's the problem.

 

Limited usefulness is still better than no usefulness, if you can't use the visual scripting because its not in the engine, it has no use at all.

At least in unreal it has limited usefullness, in my book that makes it great to have.

programming in c++ also has limited usefullness if you dont have the time and resources to make most of it.

 

I

Its still both a marketing coup and legitimate feature helps drive new people to the engine, as well as enables those who cant code traditionally to be able to work with it to a degree. Visual scripting has its place in development, whether you like it or not.
I'd honestly rather Unity allocate those resources to other things since in my mind visual scripting is the one area where they are in an extremely strong position thanks to the asset store.

 

Which is nice, but begs the question just how important that thing is, compared to more pressing needs (like a better lightmap baking tool (which might partially come with 5.6, but I will not get my hopes up yet that this will do anything to remove the limitation of lightmap baking for large meshes and terrain), a new terrain system, and a ton of other things that are currently impacting ALL devs, not just the ones that are not able to write code).

@Murgilod: Sure, Unity has a ton of programmers. But it also does a ton of tasks in parallel, and each of this tasks will eat up way more programmer time than you might think. These are not just game devs hacking together a game they release with bugs into early access, and they are not working in a game company or their moms basement on constant crunch.
Also, many of the tasks have nothing to do with engine improvements, rather its for things like the asset store or the new Unity dev network, which most probably are more important to Unity management than both the new terrain system or a VS tool. Because it makes them more money shortterm.

Sure, writing a new terrain system COULD be a big undertaking... altough seeing how far some devs got working on improvements ON THEIR OWN (see RTP, see Gaia, and many others) makes you wonder why Unity spends YEARS on this without ANY work to show for it... my guess is they are NOT working on it, instead the shelfed it because of more important tasks and because they think users are not whining loud enough about the old terrain system yet.
I guess if they had 5 guys working on it dedicated just to this tasks, had clear goals and deadlines, they could present something spectacular after 2 years. The fact they haven't shown any kind of progress after 3 or 4 years shows they are NOT working on anything (or if they are, its 1-2 devs spending 10-20% of their time on this task, or they only started months ago).

Writing a VS tool on the other hand is clearly more work than this. Maybe the more visually oriented devs have a hard time understanding this, but a VS tool is more than just drawing nice shapes in Photoshop to represent the visual nodes, and then hooking everything up behind it with simple scripts.
That might work if you were ready to take a BIG performance hit because your VS tool would now work on top of the scripting layer which works on top of the actual engine code layer.

But what you actually want is something that compiles the visual script into actual code. And let me tell you, writing a compiler is hard work, no matter what the input language is, BECAUSE you expect the compiler to not make 1-to-1 translations, but improve the resulting lower level code it produces, so that it actually performs well.

I will not go out on a limb and say writing a new terrain system takes less time than writing a good VS tool. After all, there are also VS tools written by single devs in the app store, and neither are all terrain system created equal nor are all VS tools.
If I may make a wild guess in one thing it would be saying that whatever you see under "Research" in the roadmap has no real dev time put into it yet, and Unity will not put much time into it until it gets moved to a different part of the roadmap. Past expierience shows that stuff stays there for years without any work done on it (else they would show a sneak peek at some point), and sometimes gets dropped from the roadmap because what Research really means is this: Unity is thinking about looking into it. It hasn't yet committed to really develop the feature, thus will not put much dev into it.

So don't get your hopes up too much. Unless Unity suddenly feels the urge to put in VS into one of their releases for 2018 or 2019, VS in Unity will stay a thirdparty thing. And if you are unlucky, by the time Unity would get around to actually start looking into it, the VS fad has come and gone, and Unity will just drop the feature... don't know. Maybe Unity is waiting for Unreal Engine 5 to see if Epic still is all over VS.