Unity is really missing a native Visual Scripting Tool

Yea its only 10x slower now.

 

So you're saying C++ is 10X slower than C++ right?

 

Thats great for UE it took them long enough. Does not change the fact that Unity has Playmaker and the devs are better off working on features that would benefit everyone.

 

No im saying that blue prints is still slower than c++ just not as slow.

 

Well, it's not supposed to be.. It is of course native C++, but anyway in Unity things are quite different. For one with GC C# in Unity isn't all that blistering quick for a start.. It's taken Epic two / three? Years to get their implementation into a state that's actually usable in a game. Epic's track record of implementing new features is far quicker than Unity's, I ultimatley agree Unity should focus on all the other stuff before a native VS. system comes into play.

I did some demo's at the beginning of this thread to contrast difficulties between Unity and Epic's implementation of C++. It shouldn't be too difficult for a programmer, but for a artist well that's a completely different matter and as UE4 is kind of graphics orientated which draws in that kind of crowd. Then they need to pander more to that market for several reasons..

Not to mention as @hippocoder said in the beginning of this thread, VS which is in all major AAA engines that I know of is ideal for teams.. Like BP's for level designers and artists, as opposed to Unity which is more small indie orientated.

End of the day, I like it.. I use it because it's quick, I don't have any issues with it and any major system I'll code it.. That's it really..

 

I actually like it as a programmer because it's far faster to throw prototypes of systems together for design purposes. Most of the time I don't even need to push that code into C++ so I'm effectively building the game as I prototype once I arrive at the desired result.

 

From what I understand reading discussions by those who have used PlayMaker, it's abysmally slow compared to C#.

 

It's also not native, like the title of the thread says. It's a third-party addon you have to pay extra for.

 

@ShadowK it looks like people here are getting confused between a visual scripting language, and blueprints. C# is a scripting language, when I hear 'Unity needs visual scripting' of course I imagine a visual language in which you can do anything you can do in C#. That's unfeasible imo and would be incredibly clunky.

I've taken pains to make it clear that blueprints are not what I'm talking about. I like blueprints, and I think they're great. But blueprints, as I understand them, are not used to replace coding, but simply to store re-useable chunks of code - they're in fact more similar to full script components in Unity than anything else. It's not even close to being the same thing. If you had to make that camera system in a visual coding system that had the same API as C# I'm betting your nodes would be in the hundreds or thousands.

The key difference is that with blueprints, you don't have the same control as a full scripting language like C#, and unless you want to begin restricting your ability to control what happens in your game, you still have to know how to code or rely on someone that does. Whereas with what (it seems to me) people are looking for here, you would be able to do whatever you like (equivalent of C#) in the visual scripting editor. That's not feasible.

I'm all for game specific and user-friendly tools, a 'game logic API' and blueprints but let's not start thinking that we're replacing C# coding here.

 

There are so many variations of compilation and JITs and ILs and bytecodes and syntax trees and so on -- at this point "scripting" is a largely meaningless adjective.

 

OK well put it this way: people don't want to learn text-based C# and JavaScript, they want a visual language instead - so unless they clearly specify what the differences are my default reading of the argument is that they want a visual version of C# or JavaScript.

 

"Don't want to learn" is the key phrase here.

Going way back to the original post, I think my point is that Unity isn't somehow missing out by not catering to that limited audience. Everyone wants short-cuts, but I truly don't believe this is a smart place to go looking for them.

A worst-case scenario was the Microsoft Project Spark application or system or game or whatever it was. In theory you could build entire games without programming. But it flopped. It was terrible. There was a fairly complex 3D world there, but the creation process was so dumbed-down to suit interactive/visual creation that everything people made ended up being minor variations on the same-old-thing.

 

C# isn't even a scripting language, it's just a "high level" language. Doesn't mean it can't be used for scripting, but you can go ahead and build the underlying engine in C# if it pickles your fancy.. You couldn't do that with something like Skookum which IS an actual scripting language. Same as C++, in UE4 it's used as a scripting language but that's not what it is.. Scripting in the context of "games" is game logic..

It says on their official documentation it's a gameplay scripting system.. That's it's purpose.

It's not just "blocks of code either", what you're essentially doing is mapping out the API.. Which is essentially what you do in text with Unity, thing is if you want to go beyond the engine's API then tough luck.. You can't do editor extensions in BP's, you can't do system toolsets etc. (well you could do custom editor extension nodes, but I mean what's the point? you've already put the code in to extend the editor??)

Question is, why would you want the same control as a full C# API or C++? It's purpose in life again is game logic, there are only so many types of games out there. There's a limited subset of what you can do, if you go beyond that you'd be implementing new systems into the engine anyway.

 

Technically not, but the point is that people want to avoid C# or JS, so that's what I'm comparing a potential visual scripting language to.

No comprehensive 'game logic API' has been scoped out for Unity (or anything else really) - although there is API for a lot of things it doesn't get you out of coding altogether. And although I agree with you that there are only so many types of games, technically you could want to make anything inside or outside the norm - so again, if a 'game-logic specific' language is what people want I would ask them to define in which ways they'd like to be restricted from the baseline text language which is C# or JS. But without knowing programming it's likely that in a lot of cases these people aren't really certain of what it is they could do without.

So I think blueprints are the best of both worlds, people who know how to code can work with those who don't through the asset store by providing a bunch of easy-to-use blueprints based on what these non-coders want. The key is that it doesn't matter if the blue-print coders leave out something, someone else can come in and add it. On the other hand, if Unity were to try to develop a visual coding system they would have to make sure it was useable for virtually anything anyone wanted to do, which takes us back to how versatile a visual language could be.

The best Unity could do is provide the means for this to happen, which is a standardised blueprint system, and that is something I wholeheartedly agree with.

 

There is no "technical" bit about it, it's NOT a scripting language.. The developers of it tell you exactly what it is:

https://msdn.microsoft.com/en-us/library/z1zx9t92.aspx

"C# is an elegant and type-safe object-oriented language that enables developers to build a variety of secure and robust applications that run on the .NET Framework. You can use C# to create Windows client applications, XML Web services, distributed components, client-server applications, database applications, and much, much more. Visual C# provides an advanced code editor, convenient user interface designers, integrated debugger, and many other tools to make it easier to develop applications based on the C# language and the .NET Framework."

As for what Unity will do, well I'm guessing not a lot.. Mono would need upgrading first (if they wanted to do it that way), C# isn't exactly lightning in Unity.. Then from a VS extension standpoint, going VS - C# - C++ probably isn't the best idea in terms of overhead it'd probably be VS - C++ which would mean exposing the whole API to the VS system (which would take a while). That's if they can "shortcut" the system to make sure it's nowhere near as verbose as the C# system itself.

Further on the expansion point, not everything is covered in Unity's API and if we bypass C# we'd need to invoke it from somewhere else. Hopefully not the dark mysterious black hole called "plugins".. You'd need references to all their sub-systems, in UE you can affect the material editor system / sequencer / animation system / AI system etc. via BP's.. We don't even have core access to those systems now/?! (also some of them don't exist)..

It's fun to talk about though ..

 

As I said, technically it's not a scripting language, but in Unity's case that's what it's used for. The point is that when someone wants to avoid learning C#, then C# is what they are going to have to replicate, whether the editor involves noodle graphs or an urban dictionary doesn't change the fact that it still has to do the same thing.

If someone wants to argue in favor of a new visual language with different constraints to C#, the onus is on them to tell everyone on the thread exactly what those constraints are.

And that's the other thing, a non-scripting language that is used for scripting like C# is versatile enough to be used for a lot of things outside of the usual game logic that is still useful for a lot of games, whereas a constrained scripting language is not. To what extent this takes away the benefits is debatable of course.

In the end, if you want to simplify C#, you also simplify what is possible for you to do, and that's fine as long as it's fine.

 

I think this is a case of the thing a person wants being different to the thing they're asking for.

People ask for visual programming systems because they want things to be simpler. (That, by the way, is not the same as being a "crutch" as someone mentioned before. Getting jobs done quickly and easily is a good thing, not a cop-out.) With that in mind, they might think they want the power of a full programming language, but what is really going to be more useful for them is something that's more task specific.

 

That's why those asking for a visual scripting editor need to define exactly what they expect from it. At the moment, I'm not even sure if they are trying to avoid text as such, or programming logic - and a visual editor won't do much for the second one.

In the meantime, blueprint system would go a long way toward taking this sort of discussion to the next level - after a year or two of people trading blueprints back and forth there might be enough information to make a rational attempt at integrating a visual game logic API into Unity (or decide that it's not needed, or it's not going to work at all).

So yeah, Unity needs to add a blueprint editor. I would love to start working on blueprint assets that could be used to build a functioning fps or third person rpg without having to know how to code. A lot of game development stuff is ripe for this kind of thing.

 

What, in your opinion, do you think that "blueprints" offer on the whole that effective use of components can not?

To be fair, the lack of nesting support on prefabs does significantly limit how far you can practically take this.

 

Not an incredible lot actually, I think components are generally well made. The main one though, as I think I mentioned in this thread or somewhere else, is that components don't show very clearly the relationships and interactions that they have with eachother. When you have one component open in the inspector, you can't see all the other ones that it is dealing with - I think it would be very pleasant and help keep the 'mental model' fresh to see all of the interacting components in a visual editor - at least all of the ones in the same hierarchy if not in the scene (on toggle maybe?)

For example, when making a weapon system for my ships I have script links between the main Weapons script (root), all the different weapons assigned to the ship (children), the powerplant, the heat module, and so on - they all all part of the 'firing' sequence, yet they are often on different gameobjects and the script calls use GetComponent so it's not possible to 'see' the interaction in the inspector. So it would be great if somehow the anatomy of these relationships was more visual.

IMO a visual editor such as a node editor should describe relationships between scripts/components rather than bits and pieces of the same component - since it's very likely that these relationships cannot be described in full on a single screen of text code. And this is what blueprints do (as far as I know, I've not used them in UE).

 

The problem is that in order to do that, people usually need to overcome learning curve.

There are two scenarios where visual systems are applicable.

First one is building state machines (animation, for example)
Second one is ai decision trees.

Mostly because in both situations it really helps to have visual feedback and know what the system is doing at any given moment and where it might go.

Please note that neither of those is technically a "visual programming". Trying to program with nodes is generally highly inefficient, so when a system starts having "+", "-", "add" or "subtract" node, it is not going in the right direction.

I'm not 100% convinced that state machine is the best option for animation, it gets job done, sure, but I think there should be something better. Unreal's montage felt more "right" to me.

Technically, decision trees can be replaced with coroutines, BUT this requires coroutines to be serializable. Which is not the case with unity.

 

I think this is not a good approach, and that's why it is difficult to use.

Last time I had to wire a weapon into character, I had "[SerializeField ] SomeOtherComponent someOtherComponent" which was explicitly linked to the desired component. Meaning I could go to the target object by clicking on the inspector field. You can also visually represent relationships by drawing wires and whatever you want in OnDrawGizmos() calls. But in general, I think parts that important and are on different gameobjects should be explicitly linked via serialized fields, while parts that that are less important or optional and simply responds to some action wouldn't need visualization of relationships.

 

Well that helps, although it doesn't really specify anything except that SomeOtherComponent is related in some way. A visual editor opens up more possibilities for specifying what kind of information and inputs/outputs are being used, and is a lot more intuitive than looking at a list of related objects.

It's also a possible way to improve debugging. The worst bugs are those which depend on dynamic states of information (i.e., the 'building blocks' of the problem are not the same at the time of the incident as they were at the start).

So I'm not sure how feasible this is, but I like to imagine a visual editor than records information transit and can be rewound and played back slowly - where you can follow a piece of information as it goes down the road to perdition. The problem with text debugging is that it shows an optimistically static view of information at the very beginning, and debugging is very arduous with copy/pasting Debug.Log calls manually - you often don't know what to log and have to 'scattershot' the calls and clean them up afterward. Whereas a visual debugger could be zoomed in and out and you could see the possible routes that the problem took while it was developing.

The thing is, when I debug, this sort of 'road network' of information is exactly what I picture in my mind, but it of course takes mental energy to construct and maintain this model. If it was there in front of your eyes it would help things along greatly.

 

No reason you couldn't imagine the same thing for code debugging, though you're going to need a pretty beefy PC to make it happen. (There are debuggers out there for certain libraries and languages which record everything for playback. I even ran across one for the Javascript RxJS reactive library that adds visualization of streams and their relationships and transformations over time.)

 

That's, uh, very different from visual programming. You're asking for a system that monitors scenegraph, records all communications between components and can play that back.

That's very close to "you need a different engine" level. You could make snapshots of all objects every frame, though, but that won't be very fast.

Also, instead of Debug.Log you'll probably want your own logger. Debug.Log has a lot of overhead in editor, and while Unreal's logging system can happily handle gigabytes of text being thrown at it, it is possible to completely kill editor performance with just a few hundred messages in Unity.

 

This is very disputable - as the ONE article published about using Playmaker in production nearly 4 years ago, he was using v1.0. and using it as an experienced programmer in a team environment.

As far as I have been able to tell - Playmaker isn't ever the cause of a drop in frames rate, though beyond my hands on experience, developing a extremely complex network of systems for a complete game - may result in reduced efficiency.
I have not seen any concrete proof of this and only one coder who wrote up one article detailing his specific test results, which were equally disputed in the comments - does not provide enough proof to confirm that Playmaker is 'slow', or causes fps drops.

For reference here is the article. I suggest if reading this article - please also read the comments below as they provide much more indepth, varied, unbiased opinions about Playmaker 1.0. Also note Playmaker has been updated a ton since that article, had an extensive update specifically for Unity 5 and went through U5 update with very little problems.

 

Really? You going to tell me what I have been saying this entire time? Do you even read the thread?

 

There no question that visual scripting has a very important place in game development. OP claims there are clear disadvantages to a visual scripting tool not being native yet never names one. He even said he doesn't mind if visual scripting hurts performance as long as it works.

There is nothing wrong with using playmaker for visual scirpting. If you dont like playmaker because it has poor support or whatever you dont like about it thats fine, but dont claim its bad because its not native.

 

Yes it would be nice if someday unity had native visual scripting. However we have visual scripting options and I would much rather see the unity devs work on features that would benefit everyone features that are completely missing and do not have a viable solution in the asset store.

 

After a certain point I start tuning out certain people.

 

What does that mean?

 

.

 

I just want to know what the clear disadvantages are of a visual scripting tool not being native that OP claimed. I mean they are clear so what are they? I've asked for clarification before there still hasn't been a response. Obviously OP just wanted to complain about unity.

 

It's nothing aimed at anyone particular. I just start tuning out or skimming the posts in this section past a certain point because they become repetitive. Occasionally it trips me up when someone points out that I was just repeating what they said but it doesn't happen that often.

 

Can't blame you I think we all do that XD

 

Because UE4 provides a visual scripting solution out of the box you don't have to worry about supporting multiple different solutions (eg if you're making a code asset), you don't have to worry about receiving assistance (everyone has it).

By comparison there are about three or so major visual scripting solutions for Unity. Out of the relative few code assets that support integration with a visual scripting language the majority only support one language (usually PlayMaker).

Finally a native solution provided by Unity would have the support the remainder of their engine receives which is important because there are third party visual scripting solutions that have gone almost a year without updates (Antares Universe as one example).

 

I think thats a good point but OP has Playmaker and a lot of assets do come with solutions for those who have playmaker. So I hardly doubt this was one of his clear disadvantages. Even still he could use any asset with playmaker he may have to do some work himself but there are no assets that are incompatible with playmaker, none that I have ever seen.

 

Sure, but that's additional effort and a lot of people buy PlayMaker and other visual solutions because they don't want to actually deal with code (which if I recall correctly you'll have to do to some degree to make the nodes for PlayMaker).

 

That was a good point though but I would like to hear from OP. I can think of lots and lots of disadvantages as I am sure many people on the forums can. But my point is that OP just wanted to complain and offered not one valid reason to switch to UE except that playmaker does not have good enough support.

 

I understand its frustrating when you cant figure something out and things do not go they way you want OP. But do not blame playmaker, and certainly dont blame unity.

 

One obvious disadvantage is cost. A lot of people REALLY REALLY believe they can make money without spending money (disputable) and want to believe making games will allow them to do what they always wanted - and not have to get a real job - (there belief not mine). So they come into it completely uneducated in relation to game development and without a dime to spend - think they can develop something in Unity that will earn money.

OP obviously has not done due diligence looking around for support. http://www.hutonggames.com/
Probably why nobody else corrected this uneducated fabrication from OP.

We frequently have lively debates and discussions while OP never returns. These are some of the best threads on this forum.

 

I don't really see playmaker as visual scripting more than node-based game-making. It's it's own thing that just so happens to overlap a fair bit.

 

Are you kidding me? Are you really going to start a debate over what playmaker is? I swear the people on this forum just argue for the sake of arguing.

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

In computing, a visual programming language (VPL) is any programming language that lets users create programs by manipulating program elements graphically rather than by specifying them textually.

http://www.hutonggames.com/


VISUAL SCRIPTING FOR UNITY3D
Realize your creative vision without knowing how to program!

• Visual state machines are intuitive and powerful for beginners and pros!
• Programmers love visual state machines too.
• Works with Indie and Pro versions of Unity.

Intuitive Visual Editor

• Quickly add States and Actions.
• Connect States with Transitions.
• Manage Events and Variables.
• Save time with Templates and Copy/Paste.
• Integrated Help.

Powerful Debugging

• Realtime Error Checker finds errors before you hit play!
• Runtime Debugging lets you watch state machine behavior.
• Set Breakpoints and Step through state changes.
• Watch Variables as the game plays.
• Send Events and Set Variables at any time.
• Use the Log Window to watch transition events.

Highly Extendible

• Write Custom Actions and they appear in the editor.
• Custom Actions available for many popular addons:
• Photon, 2D Toolkit, iTween, NGUI, Smooth Moves...
• User Community shares actions on the Forums and Wiki.
• Open API allows you to make FSMs in code.

 

UE's blueprints has nodes I guess that isn't visual scripting either?

 

I dont really see C# as scripting more than text based game making.

 

Agree with hippo
From Playmaker forum
"PlayMaker, exposes the power of the popular Unity game engine in a user friendly visual state editor."

"Playmaker is a powerful visual state machine editor and runtime library for Unity3D."

Is a FSM a visual scripting language? I don't know and have a college football game to get ready to watch - so I really don't care - It works for me and that's enough.
Go GT!

 

It has nothing to do with the nodes. It has everything to do with the way PlayMaker functions under the hood. It's a finite state machine. That fits the bill for some situations but not for every situation. By comparison Blueprint is an actual language and is thus far more flexible. If every API were exposed to Blueprint you could use it exclusively to make any game.

 

I didn't say it had anything to do with nodes hippo did. You guys can describe playmaker all you want its still visual scripting. Just proving my point that you argue for the sake of arguing.

 

Visual scripting can be icon based, form based, diagram based, node based, hence the word visual.

 

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

What is the very first line, "Editor Extensions/Visual Scripting
Hutong Games LLC"

Ryiah, FSM cant be classified as visual scripting?