Unity is really missing a native Visual Scripting Tool

Hey guys, I was reluctant in posting a thread like this, but I think that the more people demanding this from Unity, the more they can consider it. I am a designer, and as such, I'd really rather implement and prototype things using a Visual Scripting Tool. I like programming as well, but VS just makes things that much easier from a designing perspective. For that matter, I use Playmaker, and it is awesome. Very powerful tool. But there are clear disadvantages not being a native tool, like Blueprints in Unreal. The support is naturally much smaller. I mean, community is great, forums are helpful, but still, for me at least, not enough.

Truth is Unity is made for programmers. To me as a designer, there's not a single way for me to implement stuff without coding or paying for a plugin. I believe this is detrimental because you stablish no clear communication between designers and programmers in the engine itself.

Some of you may think "Go learn C#!" and I have nothing against it, truly. But these are different fields of study. You don't tell a programmer "Go learn game design!" or "Go learn 3D modeling!" because these require an entirely different study, and in gaming production I really think we have to work on our strenghts - and of course, have a somewhat good notion of other fields at least.

Well, I'm strongly considering switching to UE4, specially because of the designer-programmer better communication through Visual Scripting and other tools as well. The workflow is simply different.

Please let me know what you think and what are your experiences in that matter!

Thanks!

 

Unity has visual scripting on their roadmap "wish list" but we're not going to see an official one any time soon.

http://unity3d.com/unity/roadmap

 

I agree with you, Unity needs to be accessible to artists and designers.

 

I would absolutely tell this to a programmer who is planning to create a game alone.

The best idea would be to team up with someone who can script/program.

 

Sure, but one of the main goals of Blueprint is to allow your non-programmer team members to assemble very simple functionality without constantly badgering the "real" programmers who would be working on far more complex topics.

 

Yeah, well... good to know but... It's a very loooong list. I hope they give it some attention but I don't hope to see it anytime soon. And though many people think this is not an urgent matter and I understand that, I think the people who says that are almost all programmers. In other engines like UE4, you have a very good solution for both designers and programmers, whereas in Unity you simply restrict designers, make them pay for plugins and do not give native support.

I understand, they have a lot to do in the engine. But... for me that's a big thing.

 

Exaclty. This for me is a correct workflow. Designers should be designing. Level design, combat design, quest design, prototyping... all of this. What happens is that coders are designing and designers have to code.

And considering there are already a lot of available solutions, Unity should simply integrate one of these, make it native and improve on it.

 

I still think that blueprint system is one of the worst features of unreal engine.

They got rid of scripting language and then... created another scripting language with clunkier interface. Because reasons. Not to mention massive negative impact on documentation quality....

 

Well, hard to argue with that because it's just opinion. For me Blueprints is great, and if you research small and big projects use it, because Unreal is meant to work with both BP and C++ combined, not isolated. And what exactly is bad about the documentation?

 

Unfortunately that's just not Unity's approach to bringing new features. They may temporarily bring someone in who has past experience developing that feature but they won't necessarily stick with the path they implement. I do believe when they finally bring us a visual scripting language it'll be fantastic but like Unity's UI it'll be a long time.

Until it's made you're just going to have to live with the options available on the Asset Store or pick an alternative engine.

 

They replaced the scripting language with C++. Once again Blueprint isn't meant for those of us who can write code.

 

For programmer working with blueprints feels like, I don't know... trying to play violin using only your left foot. Sure, you can get hang of it with some practice, but it'll always feel awkward, especially if you have all your limbs intact. Because of Epic's obsession with blueprints, quality of C++ documentation is abysmal (almost all tutorials are written by one guy from community), meaning in their quest to make the engine more accessible the made it harder to use for people that want full language power. Which is, in my opinion, quite bad. As they say "GUI makes simple things simpler while making complex things impossible". So I'd prefer if unity didn't follow epic's way here.

 

They replaced it with blueprints, in my opinion.

Try making animation controller in C++ without using blueprints. See what happens.

 

It's certainly coming- State Machine Behaviors are a good step- when a programmer lays the groundwork first, it's a great way for non-programmers to get things up and running and tweakable quickly. But it's not ready from the get-go. The standard utilities are a neat accessibility addition as well, but there's a lack of support there, as most tutorials available don't use either- most of the time tutorials are aimed at adding permanent functionality through scripting, rather than temporary functionality for rapid prototyping.

 

Unity should pick a winner in the visual scripting, buy the full rights to that asset, rename it Unity Visual Scripting, and then include that as the standard visual scripting solution for Unity. They should have done that same approach with the UI, but obviously did not.

 

Mass Effect was made in Unreal with both C++ and BP, Batman Arkham series, Hellblade, the new Devil May Cry, Street Fighter V, Bloodstained (the successor or Castlevania), Mighty N.9... I don't think all these companies share this opinion about BP and C++ being a bad combination. As a preference, I understand: programmers spend years and years coding, so they prefer code, it's natural. We designers don't, usually. The best case is when you have good integrated options for both. For me, everybody wins. And I think the programmers who work with Unreal and C++ might have a different opinion as well.

And one thing about VS and prototyping: with playmaker and other unity 3rd party VS, all I hear is PROTOTYPING. Like these tools are not able for full production. I cannot assure that and I've heard of people who use Playmaker in production, but Blueprints for example are used aaaaall over, in small and big projects. And they work just fine.

 

Sorry, but while the other titles may have used it, Mass Effect was not developed in with it. They used Unreal 3 to develop their later games and Blueprint didn't appear till Unreal 4.

 

Oh, my bad, was not UE4, but at the time it was Kismet and UScript if I'm not mistaken, and it's kinda the same interaction. Blueprints is just the evolution of Kismet. But we could probably say that about ME Andromeda. But I'm not 100% sure they use UE4.

 

• That's appeal to authority (logical fallacy),
• Mass Effect 3, Batman Arkham Asulym, Devil May Cry used Unreal 3
• We don't exactly know what they used internally and how.
  

Well.... http://va.lent.in/should-you-use-playmaker-in-production/

I heard that it suffers from certain problems that make it inferior to code. Then again, using another "visual programming" system may result in similar or even identical problems.

 

Mass Effect: Andromeda uses the Frostbite 3 engine.

https://en.wikipedia.org/wiki/Mass_Effect:_Andromeda

 

Yes, but those are more limitations with PlayMaker than anything else.

 

My only concern is if Unity tried to replicate Playmaker and ended up with a crappier/less supported version of it, everyone will just buy Playmaker and all the time/work the Unity team put into their worse version will be a total waste.

They'd be better off creating more "hooks" that devs like Playmaker can utilize to make their tool better overall.

 

Well saying is a fallacy is not exactly an argument... Big production studios use BP and C++ everyday. Do they suffer from cluncky interface, bad performance and integration? I would not say that... For me this kinda proves that the model works. Is it the best? I don't know, maybe it's just preference. But it works. And Epic has bet on Visual Scripting + code for so many years now, from UE3 era and maybe a little before that too.

Well, the original point is that I believe it's extremely important having good tools for both designers and programmers. After all, programmers should use code, because they think it's best. And designers should use VS. Without limitations for one or another. And that's up to the engine to provide. Right?

 

I agree with this being a necessary step forward. Humans have a visual interpreting machine, that's just nature.
Overwatching code is a steep and long learning pattern that will keep most people away, for better or worse. You have this immense spaghetti with logic stretching three files away...

Having an action block chain machinery with automatic exposure of parameters, code snippets by mouse-over with instant editing capabilites would be unbeatable. And how is it different from closing shut function bodies anyway?
Direct self conversion of code into action blocks even better so. There's ABSOLUTELY NOTHING bad about it, frankly, and it's already used for shaders.

 

When big studios use both BluePrint and C++, they are only doing very simple things in BluePrint. For example, if a level designer wants to configure a door to open, the designer can use BluePrint to quickly set that up. Anything more complicated than that is going to be a giant spaghetti mess if they tried to do it solely using BluePrint. For all of the complicated tasks, programmers still need to use C++ instead of BluePrint.

Is the BluePrint and C++ model the best solution? Maybe, if it is a large group of very specialized developers with a clear separation of design tasks and programming tasks. For smaller groups (and especially solo designers), Unity and C# make a lot more sense. C# is very easy to use compared to C++, so it is easier to script with for designers. If you are a solo designer making a game in Unity, you will probably be able to pick up enough C# skills to complete your project. If you are a solo designer making a game in UE4, you need to pray you can do literally everything using BluePrint. If you can't, then you are in trouble with UE4. Big studios have dedicated teams of programmers that can easily handle C++. Solo indie designers don't. That more than anything else is the real danger for solo indie designers that are considering UE4.

 

The biggest issue with most proposed visual scripting systems(Like the one Unity made during hack week) is they try and replicate traditional scripting. This is obviously because it's called "visual scripting" and is made & designed by programmers.

I think we need to stop thinking about programming at all, If we just think what's the best way to create a game we'll make much stronger systems. If it's node based things can happen asynchronously at the same time without issues, nodes could have execution times(Play a jump and it takes 0.5 seconds then the next node is called)

The very worst part of visual scripting is that people think it's some kind of learning tool... A visual scripting tool in a game engine should have absolutely no interest in teaching people to program. It's only task should be to help people make better games.

 

Just wanted to point out that visual scripting was what made traditional code an attainable thing for me. Being able to see the logic flow and immediate feedback was really important in learning how to approach code in the first place. Regardless of if teaching is a goal of visual scripting or not, it is good for teaching because of what it is- a more visual, more accessible, more intuitive interface for adding functionality to a project.

 

Well hundreds if not thousands disagree with you, and are happily wiring up animations, doing dialogue, creating tools and more without touching any C++ / script because, well, artists and designers should never have to.

 

I tend to view any Finite-State-Machine whether visual-scripting, substance designer, material editors, etc. helpful for beginners to a topic at hand. It's a way for it to not be a wall of text which will usually convey the flow of things better to people just starting out.

I think most people that are already used to the topic will usually dislike the FSM because it will usually have some features missing, will be somewhat slower, and doesn't tend to scale all that well (large FSM's become hard to look at). For that very reason I love Substance Designer because I am a novice at that subject matter, however I generally dislike blueprints or playmaker and would rather just code.

 

I hope Unity will never make any visual scripting tool. I want most my game logic to be portable in other game engines or softwares. In my opinion, creating game mechanics and gameplay with nodes or visual scripting will only lock me in one game engine.

For example, Unreal Engine 4 and Houdini. If I use Blueprint or Houdini nodes (SOP, VOP, POP, DOP, etc), it would be very difficult for me to port the logic to other softwares. If Epic Games or Side Effects Softwares suddenly change their licensing policy and I don't like it, I cannot move easily to other softwares, because I have made the mechanics with nodes, which are exclusive in each software.

Although each scripting language of the softwares has its own set of API, it is easier for me to find similar methods in other scripting language, rather than trying to find similar nodes in other software. And the good thing in Unity is we use C# for scripting. If someday Unity increases the subscription price and I don't like it, I can always use Xamarin or other softwares. There is still Godot or JMonkeyEngine that uses scripting for making game mechanics.

I think it is better if Unity focuses on enhancing the visual quality and performance, rather than allocating their resources to create a visual scripting tool. For example, it is better if Unity does some research on real time water and hair simulation (like Nvidia Gameworks), or full GPU rendering with Enlighten.

I know it is easier for designers to create game logic with nodes, because I am a graphic designer. But in my experience, creating complex game mechanics with nodes/ visual scripting is limited. It is okay if I use Playmaker or Blueprint to create casual games. Or using nodes in Houdini to create procedural visual effects. But for the game I am currently working on, a complex 3D tactical strategy RPG, I have to use C#. I am grateful that I have a scripting language in Unity, whereas in Unreal there are only visual scripting and C++.

 

That's another mistake people often do; thinking that visual scripting will allow people to not learn scripting. You cannot use visual scripting if you have not idea of what you're actually doing. Devs will always have to learn their scripting language.

 

It doesn't matter. "Someone disagrees with you" is not a good argument.

When you have any opinion on any subject, there will be millions of people that agree with you and millions that disagree.

 

Maybe you should elaborate a bit?

I wouldn't consider visual scripting as the worst feature ever but it's dangerously misleading people into thinking that "scripting is easy".

 

The workflow is terribly inefficient. UI is clunky/clicky, and visual tools make it harder to see the whole problem at a glance than usual script. Basically, it offers no benefit over traditional scripting, yet it is positioned as a flagship feature.

Epic sings praises to their system and claims that working using C++ in conjunction with blueprints will make you more efficient, but no matter how many times I tried to work this way, the system always feels like it is getting in my way and slows me down instead of helping. As a result of epic's obsession with their blueprint fetish, documentation for deeper C++ features suffered.

Basically, no matter how many times I tried visual programming tools, I've never seen even one system that would give any advantage over traditional coding approach. It is a toy, and learning it in the end only makes user waste time (like "playing violin with left foot" example), because even the most trivial programs turn into unwieldy unmaintainable noodle-based mess. That's why I dislike blueprints and visual programming. It is a dead end, it wastes people's time, and usually people would just need more expressive scripting language instead.

----

Basically, you know how a beginner programmer sometimes gets too fascinated with specific practice and tries to apply it everywhere, even in situations where it is a bad choice? That's what blueprints look like to me.

 

My feelings exactly.

 

Actually visual scripting or programming tools are useful to create procedural stuffs. For example, nodes in Houdini. Its main advantage over Maya, which uses MEL/ Python scripting and C++ API as the scripting tool, is the ability to create procedural stuffs easily by creating node network. The nodes are mainly used to create procedural visual effects.

Artists, animators and technical directors that are not comfortable with C++ can quickly create procedural animations and visual effects prototypes with Houdini nodes. And revisions are also easy to be done, because I can just unplug some nodes and plug some new ones. This was not available in Maya, where I either had to use MEL/ python script (which is slow, because it is not multithreaded) or C++ (which needs to be compiled first). Now Autodesk is trying to add more nodes into Maya, to make it more artist friendly.

It is the similar to Unreal's Blueprint, where artists can easily create interactivity and revise it by replacing the nodes. But I think visual programming or scripting has limitations and I can create more complex game by using Unity's C#. I also don't like visual scripting tool because I cannot reuse most of my logic in other softwares.

 

C++ isn't really C++ in unreal, it has dynamic memory allocation functionality and GC. Whenever I hear this sort of stuff it sounds like you've never actually tried to use it, on top of that there are various other scripting API's available like Skookum which is pretty simple to use from the limited exposure I've had with it. Although it has been used from small games to AAA endeavours.

I use BP's for one off systems all the time, some more complex than others like a TOD system and character controllers and it's simple / ridiculously efficient. I use it for some sub level logic and it's fine for that too..

A lot of this sounds like some are creating problems when there really is none. I've found UE's programming pipeline relatively simple in most scenarios (besides from some engine related stuff I had to sort out). There's even a conversion guide that allows you to relate to Unity's code architecture like below:

P.S I'm not saying it's quite as simple as Unity, but it's not vastly more difficult either.

Unity

Code (CSharp):

1. public class MyComponent : MonoBehaviour
2. {
3.     public int MyIntProp = 42;
4.     public SphereCollider MyCollisionComp = null;
5.  
6.     void Start()
7.     {
8.         // Create the collision component if we don't already have one
9.         if (MyCollisionComp == null)
10.         {
11.             MyCollisionComp = gameObject.AddComponent<SphereCollider>();
12.             MyCollisionComp.center = Vector3.zero;
13.             MyCollisionComp.radius = 20.0f;
14.         }
15.     }
16. }

UE4:

Code (CSharp):

1. UCLASS()
2. class AMyActor : public AActor
3. {
4.     GENERATED_BODY()
5.  
6.     UPROPERTY()
7.     int32 MyIntProp;
8.  
9.     UPROPERTY()
10.     USphereComponent* MyCollisionComp;
11.  
12.     AMyActor()
13.     {
14.         MyIntProp = 42;
15.  
16.         MyCollisionComp = CreateDefaultSubobject<USphereComponent>(FName(TEXT("CollisionComponent"));
17.         MyCollisionComp->RelativeLocation = FVector::ZeroVector;
18.         MyCollisionComp->SphereRadius = 20.0f;
19.     }
20. };

I'll add some Skookum, this is a simple case switch.

Code (CSharp):

1. case expr
2.   val1 [do_one]
3.   val2 [do_two]
4.   else [do_three]
5.  
6. case expr
7.   val1
8.     [
9.     do_one1
10.     do_one2
11.     ]
12.   val2
13.     [
14.     do_one1
15.     do_one2
16.     ]
17.   else
18.     [
19.     do_three1
20.     do_three2
21.     ]
22.  

 

That is not an argument. I think they should call their visual scripting language "Snowflake -Safe Space Visual Scripting". As an artist who learned to code I don't get the big leap from properly understanding and using 3D toolsets to writing scripts in Unity. Their component based system is very similar to node systems in most top end 3D apps.

 

There are legit applications for node-based setups, however, programming basic logic is not one of them.

Nodes are useful when you need to connect a LOT of inputs/outputs in very non-trivial fashion, need preview or when you need to create filter graph, for example, for purposes of image processing. In this cases nodes help. AI decision trees also benefit from having visual aid.

However when someone tries to create a level countdown timer for a level, and it "only" takes two screens of nodes, that's just ridiculous. Tools should be efficient.

 

To people who hate visual scripting:

I guess all those AAA engines which use visual scripting like snowdrop, frostbite etc are also wrong. Don't mind me but please keep your heads firmly buried in the sand where it's nice and dark, and keep working on your tiny projects which don't require artists or designers. And by all means, please code up every quest, feature, door opening thing etc instead of actually coding the game.

Go right ahead, sadly we won't be joining you because we're too busy splitting the workload between programmers and artists evenly, while finishing our game.

My point being, visual scripting is not designed for anyone but those who will not be using time to learn how to code, but to do their existing jobs without tying up already-limited programmer resources. It's not even intended for you.

 

Good or Bad?

ex: Increment a text labels value, without creating a new script for it?

 

You seem to be under the impression I was saying that you don't have to understand the concepts behind programming in order to use a visual scripting language but nothing could be further from the truth. You do have to be able to learn or already understand the underlying principles of programming.

Writing code though isn't the same thing as understanding programming. Writing code is simply the application of programming and not the actual concept itself. Writing code requires you understand programming, but programming doesn't require you be able to write code. You can learn it entirely through visual means and many people do.

Visual scripting, regardless of which method is used, is simply an alternative to writing code.

Absolutely. Tools must be efficient but then you wouldn't write tools in a visual scripting language. Likewise your example of a timer is ridiculous. If you were going to employ timers frequently in your scenes you would ask the programming team to build a timer node and you simply place that and any triggers (one node each) as well as parameters (one node each).

Your examples are giving me the impression you haven't actually tried visual scripting in the way its intended. It was never intended to replace the programming team. If you need more than a few nodes you should be using a custom node.

 

That's a pity; people programming without knowing exactly what they are doing by using machines which are not able to know what they are doing.

I don't hate visual scripting; it's fun as long as you are able to understand what you are doing but it's just a machine that cannot be trusted, mainly because it's programmed by people who can make mistakes. Better write the code directly.

 

Yet here you are using Unity and C#. Both of which are made by people who can make mistakes. Both of which are very abstracted away from the hardware. You could argue that you need understanding of the hardware, but my argument is that the hardware itself is further abstracted away by the drivers and you're basically developing for a black box.

We're no longer in the old days of counting cycles in order to ensure we can run both our game logic and draw our game environment. We're in the days where you open up a window that shows you a series of graphs, resources and time taken for each function, etc. You almost never write code directly now.

The only real difference between code and a visual script is the way they are represented on the screen.

 

UE has some of the most "direct" VS node scripting I've seen, whereas in CE for example or Stingray it takes several nodes to get to it's "purpose".. Variations of timers and handles for example:

https://docs.unrealengine.com/latest/INT/Gameplay/HowTo/UseTimers/Blueprints/

Let's take a basic character controller, you can set one up in BP's far faster than you could ever write the code to do the same. A basic example with projectile spawn's etc. Mine has about six extra nodes for the camera controller..

It takes less than 15 minutes to set up a fully playable character, again there's no way you could do it that fast in code. Although, the "node based" system has to offer something above a standard scripting workflow or the appeal of it starts to leave by the wayside.

In later versions, you compile it all down to code so it doesn't really even have a performance impact. Yeah, VS isn't for everything, but for general GP logic it's hard to beat.

 

UE4 is easier to use than Unity.
It only takes longer, months to years to learn how to use all the tools it provides.

 

No, it's not easier to use than Unity. It's different to use. It very much depends on what you're doing. This is assuming you know both engines.

 

I'll agree provided you know the fundamentals of how games work, take for example I use SLS reflected HDRI lighting in a scene. In Unity, import HDR + add to material and then plop it in lighting (adjust the influence).. In UE4, I use spherical mapping of a HDRI image on a sphere (of course) use an unlit shader and disable mip maps, then add the absolute world position to a rotational axis and normalized output. Finally using the emissive colour to "influence" the scene added to a skylight..

Now, if Unity didn't "provide" the shader to be able to do this, UE4 would of course be far simpler (and quicker) to do the same job (that's if you have at least fundamental knowledge of shaders).

That's the thing, Unity allows you in a lot of cases to skip the fundamentals. You only need a fringe understanding of various components in UE to get by whereas in a lot of cases in Unity you need no understanding whatsoever. If Unity doesn't provide it, the asset store most likely will. But near enough every case I come across Unreal has a tool for it provided you understand (again the fundamentals).. I whipped up a procedural terrain material in an hour, based off the "game framework" I can build a TOD / Char Controller / AI system etc. in a matter of days as opposed to weeks.

But where many will trip up is it's a completely different way of thinking, once it "sinks in" though it is FAR easier.

 

I measure "ease" with "time spent" not "mental difficulty"

 

Well in that case, Unreal is far quicker (easier). I can only speak of 3D games of course..