Unity is really missing a native Visual Scripting Tool

Yeah I think characters are not exactly correlated to words as you show there, but still, two characters is a lot less than two syllables or an additional prefix/suffix. Overall I imagine that logograms are a lot denser. You can change the word entirely with a little squiggle here and there. It uses much more efficiently the space in which the information is laid out. And the fact that the form of the characters can be more diverse makes it easier to be a more visually descriptive medium, and generally speaking we're hardwired for visual information much more than any other kind.

However, visual scripting is not efficient in any way whatsoever, as it is now - it uses vastly more screen real estate than characters, by orders of magnitude. And what a programmer can see at any given time affects their ability to efficiently work since the more they see the less they have to store away in memory when dealing with a lot of information at once.

So yeah, visual scripting has flopped, and I don't like it as it is now. Who knows, maybe some kind of better system will come some day. I wonder if less reliance on keyboards would be a factor in that?

 

Some artists uses Blueprints only to make some Unreal 4 games, many non programmers uses Playmaker to make games with Unity.
Do you think your opinion is good ?

 

You missed my point entirely. What I am trying to say is that visual scripting cannot replace written code - you simply cannot expose the same level of interaction in a visual scripting tool without it being a horrible mess.

Games are often very cookie-cutter, and functionality can be very similar. For this, a well coded blueprint can be very useful. You might have missed my encouragement in many threads for Unity to adopt a blueprint system, I'm totally in favor of it. But it's not the same as a visual scripting tool - you still have to write the blueprint in C++. Blueprints are a great way to create and share generic cross-project functionality or expose some particular functionality for an artist or something, but they simply cannot replace written code for coding systems from the ground up, not by a long shot. They're far too cumbersome.

So yeah, blueprints, by all means, in fact I really like them. Visual coding, nah.

PS all the games I've seen that were made in playmaker were pretty simple ones, I'd like to see a real AAA game made with playmaker.

 

A lot of difference, actually. Human writing systems usually follow a direction. Even if we're talking about ancient egyptian writing, there's a flow of text and in the end it is you follow the direction of the text to see what it is about. Basically our entire cultures are based around ideas of telling things in serial fashion - character after character, word after word, sentence or sentence. We don't exactly think or talk in nodes and use them as exception in situations when they're necessary - for example, when designing electronics.

Node diagram would've been intuitive if we were communicating differently - one sentence at a time with all its components at transmitted at once, in parallel. Or if our words were two or three dimensional.

Spoiler

Basically, imagine lovecraftian eldritch abomination kind of alien creature that has ten thousand mouths each of which sing words at its own note with all mouths speaking at once. This kind of being would be capable of transmitting the whole human books in a few words and it would find human writing system extremely limiting and awkward. It would probably write in complex structured glyphs where one character takes the whole page and represents entire idea at once or in some sort of equivalent of punchcards or tables. This kind of entity would find "nodes" intuitive and easier to understand than our text-based programs.

I believe it is 6 thousand characters for chinese and about 3 thousands for japanese coupled with two separate alphabets (iirc) 80 characters each. Words are very often formed by combining several different kanji together. (Example: Subway - 地下鉄（ちかてつ）　－ "ground" + "below" + "iron"). Even in this case, one character is a symbol that usually corresponds to a core idea (or several) and has multiple readings because of it. It is still not a node chart and not lego blocks.

 

This is why bp works with the inheritance model in cpp. It's not designed to replace but work with code. Also a BP object in ue4 is similar to that of a prefab in unity. You can even have data only bp's, or just use nodes as glue between all the components on a object.

 

Interesting, that's actually a very awkward way of describing a subway. But it doesn't seem to be an awkwardness inherent in the language itself - imagine if it had one symbol for 'way' or 'road' and another symbol (or modification) for 'sub' or 'underneath'. I can't say for sure though if the language structure itself has anything to do with this inefficiency?

But anyway, I definitely agree that any written language would be far more efficient than visual coding.

@passerbycmc sure, I don't see the same conflict between blueprints and written code that perhaps @neginfinity does - for me, it's all a question of how low-level the interaction is. There's a point where, particularly to someone who is not familiar with programming, a blueprint system would make it far easier to interact with the code, but the point is that the blueprint system could never allow access anywhere near as low-level as written code does, without becoming very difficult to deal with. So the blueprint user would be heavily restricted in their ability to interact with code, if they want to retain the benefits of the visual aspect.
That's why it's great for artists and level designers, but they are still dependent on programmers who can code in the traditional way, and I can't see that changing anytime soon.

 

The thing is each of those characters correspond to multiple concepts at once. The character is sort of a "fuzzy cloud of meanings" which becomes "subway" when they're together.
See: http://jisho.org/search/地下鉄
Also, they word does not represent its reading. You're supposed to figure or know how it is read and in case of spoken words, you're supposed to figure out which word is meant.
There are jokes related to that too. For example: ”koi” can mean "love" (恋) or "carp". The funnier example is "meido" which can mean "maid" (メイド) or "underworld" (冥土, as in "Hades"). Because of this it is important to know how someone's name is written in addition to how it is spoken (for example, there are at least three kinds of "Akiko" - "clear child", "bright child" and "autumn child", which are differentiated by characters used in their names)

However, this is going way too far away from the topic and deep into "language learning" territory.

On a final related note, speaking of human langauges... this is a language too:

But it is still not a network of nodes.

 

I raised the issue of a syntactically simpler or more basic and game development specific programming language that would be an ideal platform upon which a visual programming language could be developed.

The language could just be interpreted tokens that produce C# at runtime/compile time.

Pros: Unity gets it's very own simpler faster language and a visual programming language.
Cons: Could take some time and effort to produce, test and release.

 

And you also dodged some questions in the process. I still want to know how you're planning to express "func1(arg1, func2(arg 4, arg5), arg3)" without temporary variables in a language that does not braces, semicolons and only uses whitespace for separators.

 

Quick side note since you brought it up: while you're right about the end-product, at least in my experience, the design process and any subsequent interpretation of a electrical schematic is still very linear. (My wife and I took several semesters of an electrical engineering course to support our robotics tinkering.)

This makes me think the visual tools are less about some "visual gestalt" approach to design and more about limiting the opportunity for making mistakes.

It also reminds me there are "visual" coding tools for very simple languages that only allow you to choose valid keywords. One example:

https://scratch.mit.edu/projects/11804271/#editor

 

Why are you so tied to the syntax of the language, all languages are just a token stream. Most language syntax is to help the compiler, and as compilers have developed and improved simpler syntaxes can be used. But when you make something simpler you can probably make it too simple, so in effect working out what it does becomes complex.

For syntax I would personally opt for similar to but simpler than C#/C++, can or should we remove all of the grammatical symbols. No, just like written language symbols can make comprehension easier for people and compilers.

Syntax is separate from your point regard temporary variables, in a visual language using a variable would probably be a matter of creating a node and linking the variable into other nodes where needed.

Let's say my visual language translates to Unity Basic, adding a node to a Visual script that is used more than once would produce a temporary local variable. If used only once it would be passed as a parameter.

I believe most programmers would agree this is a good practice.

 

That's like saying all XLSX files are just XML documents. Yes, they are, but you don't work with them as raw XML any more than I generate token streams (or raw MSIL) instead of writing C# syntax.

You seem to be arguing that a simplifed (perhaps interpreted) scripting language would make visual node editors easier to offer. If so, why would you care about the language at all? Just use the node editor and let it spit out whatever language the engine already uses. As you said, why are you tied to the syntax? You want a node editor and to only use a subset of what the engine and language can do, so be it -- but there is no good reason to unnecessarily limit anybody trying to write code.

 

You have just agreed to my point, that syntax gives meaning and aids comprehension. So a completely syntax free grammar would be hard to read for people and parsers.

Inherently by making a visual programming language you are removing a lot of the syntactical elements and therefore making a simpler language. Why not introduce a visual programming language that has a graphical representation and a symbolic/textual one.

I can understand that you might think the nodes should then generate C# code, but why not generate a Unity Basic as an interim step. You already have a simpler visual programming language. Or provide the user with the an encode as option, so the visual scripting can produce IL2CPP, C#, Javascript, Boo or Unity Visual Basic!

I'm sure that if Unity does not do this Unreal will it's a good idea, makes using your engine easier to beginners and advanced scripters and artists.

The key would be to have Unity generate a visual representation of any code you write and visa versa.

I hope Unity will develop this as Unreal have a massive head start.

 

@Arowx

I don't see any connection between:

And

We can go further. "All computer languages are streams of bytes". That's completely unhelpful, however.

If you want simple and powerful syntax that is easy to parse for a compiler, you should just grab one of lisp dialects. Common lisp could work too if you drop backquote/comma/defmacro... although dropping defmacro will cause it to lose most of its power.

The most of your post regarding languages doesn't make any sense to me.

The reason why I brought up passing function result without temporaries is because it is actually an important problem which you're trying to avoid.

As for the rest:

Grammatical symbols do not make language harder.
If you're talking about visual languages, then why do you bring up C#?
Why would someone even back up visual tools in specifically made language?

"most programmers would agree" is false, because I'd expect them to start asking questions instead.

Also:

Something that is easy for people is hard for parsers and vice versa. XML is a good example. Its human readability is very low.
I'm not sure why you think someone would want generate intermediate "unity basic".
"produces multiple languages" is hard to implement.
And no, unreal isn't going to do this either.
I'm not sure why would you want to convert between code and visual representation as well. There's doxygen which can document what is being called from where (among other things), but its primary use is documentation, not converting back and forth.

 

In terms of design. If Unity makes a visual scripting tool. Can it be more like Scratch and less like Unreal Blueprints spaghettification?

If you took the best ideas from PlayMaker and put it in a more scratch-like design. And have it so C sharp scripts can be converted to and from visual scripting. That would be the ideal.

Or what about having scripts as 3D objects you can place directly in the scene with wires come off them sort of like mine craft? Like you could have them on different layers you could turn on and off.

</mythoughts>

 

Scratch practically is programming, just with predetermined line-blocks.

In theory with visual programming you could write a for-each block that is inherently called for each object without needing to write the for-each wrapper code. E.g. for each could be a box you draw around the nodes within it.

The whole point of visual programming is to be more powerful than code, e.g. game development specific nodes, loops as containing boxes of nodes. You want to be able to do the same thing but with less work.

Which brings me back to a Unity Basic language that has commands that empower users to make games. You could take the Unity questions on the forums and answers section and see what people keep asking (most common) how to do and where it takes more than a single command make a command that solves that problem.

 

Scripts as 3D objects doesn't make a lot of sense to me, as a set of instructions doesn't intuitively have a position. That said, I've implemented "wires" between objects for some of my scripts where relevant, and it's pretty easy. If an object with a position has some kind of relationship with another object that also has a position then just using OnDrawGizmos() to put a line between them is easy:


You might even be able to use OnDrawGizmos to draw handles that you can drag around and snap to things to use in setting the variables, though I've not had a need for that.

 

Maybe that's what you want the point to be, but I strongly doubt you'd find anyone who agrees. "More powerful" and "less work" are not two sides of the same coin.

As we've discussed exhaustively, it is trivial to do things in regular code that would be exceedingly difficult to represent in a comprehensive, consistent visual programming paradigm. In the other "wishing for a new language" thread (which also got bogged down with visual programming) I posted a real but very short, simple utility function from one of my games and asked one of the visual proponents to simply draw a good visual representation of the function. Apparently no one was up to the challenge. I'll give you a second chance. It's just five lines, how hard can it be?

Code (csharp):

1.         public static void ComposeForClient<T, U>(T dataDefObject, U composeWithObject)
2.             where T : class
3.             where U : class
4.         {
5.             IClientCompose comp = dataDefObject as IClientCompose;
6.             if (comp != null) comp.Client_Compose<U>(composeWithObject);
7.         }

The core problem with your assumptions is that a visual paradigm will always be a restricted subset of what is possible in a modern, general-purpose programming language. "Games" as a limitation on scope is not sufficient since we all know many real games involve practically every aspect of programming.

In fact, this is pretty much the reason the "Generate MMO" button has become a common joke around here.

 

I've been using a bit of visual scripting in GameMaker lately. Seems to work alright. The key point to note is that the GameMaker drag and drop code is meant to complement regular scripting, not replace it.

So if I want to something like this

Code (CSharp):

1. void Update ()
2. {
3.      if (Input.GetKey(Keycode.left)){
4.          transform.position += Vector3.left * Time.deltaTime;
5.      }
6. }

I can replace it with two symbols in the drag and drop language.

On the other hand if I need to do something more complex, I can just drop directly back into scripting.

Its a decent system for making small jobs easier. I wouldn't bother with it for anything complex. But it is faster for setting up some boilerplate stuff.

 

Also in similar threads people have from time to time posted images of stuff they've made in visual programming systems to convince us of how simple it is, and you can not at a glance tell what any part of it does. On the other hand, you can easily tell what a (well written) function does by looking at its signature.

I mean... obviously I'm biased. I know that.I've done little visual scripting and have many years of experience reading and writing code, so of course I'm going to lean towards the written stuff. I admit that, and I do try to take it into account. It's just that nobody who advocates visual programming for non-trivial cases has explained to me why they think it's better on any other basis than "this is the thing I'm used to".

Indeed! I've implemented a visual programming system before (so clearly I'm not against them), and it made the job easier specifically because it limited what could be done. It was made for a very specific task, and allowed only actions specifically relevant to that task. That way the people using it could do so based on their understanding of the task, rather than their understanding of computer science. The gap between the task and instructions for the computer was up to me, and that's specifically what the tool solved.

To make something simpler you need to reduce the amount of knowledge or understanding that is required, and making something "visual" does not do that in and of itself.

 

Unfortunately blueprints seems to have tainted points of view by making the programmers use it for things they could create themselves in code. I think we can all agree 'if' there is a visual scripting tool to be used - it should not be used in place of anything in the engine, or force coders to use it. It should be setup to be used along side - or instead of, but totally optional workflow. To force it to be used is stupid design logic, why Epic made that choice - idk.

I really think the visual scripting tool isn't for an experienced programmer to use. As an experienced coder/programmer ya'll can do anything you need to - and think in 'code' just as Neo sees in 'the matrix'.

I see visual scripting benefiting two specific individuals. The designer/level designer (not a coder) who wants to incorporate simple functional elements into a level or mock up or prototype some type of gameplay.
And the non-coding artist who sits in the same boat as 100 programmers, they want to create a game, there own vision (hopefully knowing to keep scope in check) and either can't find someone to partner with, or doesn't want to partner with someone.
These guys aren't different from a programmer who can code up a game solely in a couple weeks and then sits around wondering how hard it would be to 'recruit' an artist to help them out, because nobody is interested in playing the greatest RTS game ever created with Unity cubes and spheres, or sitting wondering how hard it would be to learn to use blender. They are the same people looking to create there vision, they are just sitting on the other side of the boat with just as much knowledge and experience as the 10-15 year programmer vet. They just have artistic knowledge and experience, instead of code/scripting knowledge.
Visual scripting is for these guys to allow them to create things they couldn't before. Same as the asset store and mixamo is there for the programmers to get/use visual assets that they generally couldn't create before, especially at the level of quality they envision.

Hearthstone, although Im sure you mean totally created in Playmaker.
There about 10-15 ongoing playmaker projects here on the forums, one is a pretty awesome looking RPG with some extremely complex melee fighting mechanics - similar to dark souls. Not similar in visual quality - but similar mechanics. I can never remember the name and really don't feel like looking around for it.
And though not AAA - Inside was purported to use Playmaker for one specific aspect of the game, I think dialogue, but not entirely sure.
A couple other non-trivial product recently released - Quality isn't AAA of course, but the products look like solid releases imo. Not extremely simple (mobile mvp-ish) but solid. Something they should be proud of.
Warcube
Combat Core
Not sure about Warcube but I can confirm from talking to the developer Combat Core was developed entirely using Playmaker.

It's better because it allows non coders to develop gameplay that used to be created by programmers before. Taking away precious coding time from the difficult stuff - like systems integration and behind the curtain stuff.
If on a team I could see how this would be better to have designers designing instead of sitting with programmers working up complex systems.
I found this first talk from Unite 2016 particularly interesting to listen to and points out pretty well how Playmaker has benefited there team and how they use it to supplement the pipeline, along side programmers - not replace it and force programmers to use it.
Unite Talk 1
Unite Talk 2

 

I do completely see the benefit of that. However, once again, making something "visual" does not in and of itself make it simpler.

Between the Inspector and UnityEvents, Unity already provides for many (not all!) of the use cases that visual scripting systems allow with a minimum of complexity or learning from designers. To get access to additional power or flexibility they need to learn some programming, and that remains true whether they're programming with a nodes and lines or by learning to type simple scripts. (To put this in context, plenty of artists do simple programming with systems like MEL scripting.)

Probably the issue is that most programmers aren't using UnityEvent yet, or aren't using them in a way that's useful to designers, where the workflow of something like Unreal seems to make those things "just happen" via Blueprints. (Though maybe that's not true, and the people who were showing it to me were demonstrating best practices that aren't actually in common use. I don't know.) Keep in mind, though, that things being integrated with UE's Blueprint system doesn't come for free (just like using UnityEvents and/or the Inspector isn't free) - there's a lot of annotations added to C++ code for UE to tie things in with the Blueprint system. That's not a bad thing, and nor is Unity's approach, it's all just worth being aware of the fact that there's no magic silver bullet solution (just like there's no "Make MMO" button).

 

I guess AAA wasn't the right term - I know a lot of people use Hearthstone as an example of an AAA game, such as when people ask "can an AAA game be made in Unity" and so on but while this is technically correct (it's made by Blizzard after all) I don't think it's relevant to a lot of these kind of discussions. Apart from the skill and polish put into it, there's nothing technically or graphically complex about it - it's not comparable in any sense to a game like Uncharted or something like that, except in the point of fact of it being made by a AAA studio.

Basically, I'm not sure at all that playmaker could be used for a huge, dynamic scene with a hundreds of different objects changing state and interacting with eachother in a lot of different ways at the same time, such as an fps or rpg. The scene would be simply too complex for the extremely low resolution information that a node editor is capable of dealing with. Bear in mind, I'm not talking about blueprints but a true ground-up visual coding system.

Who knows, maybe I'm wrong, I've never used it. But when I see a huge screen full of nodes describing something that would take a few lines of code in VS I'm not convinced it's going to work.

 

Someone could create said Node with those few lines of code and then your Node graph would look nice and tidy...would that make you happy?

 

I was waiting for someone to point out macros. Well, for starters, macros are basically what I do like about blueprints, so nodes for macros is fine by me. But that's just 'long-term storage'. When you're creating or debugging code and trying to understand the flow of information, macros can just hide stuff you'd like to have in front of you. The problem is that when you go and 'unhide' all that stuff it's not going to be pretty in a noodle editor.

What it comes down to, for me, is how much information you can have in front of you at any given time, without turning things into an unholy mess. The moment you hide part of the information, your brain has to reconstruct it from memory to keep the integrity of the mental model, and that's taxing and not as good as having it in front of your eyes.

On top of that, I find that the relationships suggested by nodes and wires are very one-dimensional, they imply a clear transition or flow that's not necessarily the case - and it's not really possible to get them to show different relationships without it being fairly arbitrary as to how you tag them, such as colors or double/triple/dotted wires or whatever.

I dunno, if it wasn't for the ridiculous waste of screen-space I might have given a good go to getting used to them by now, since I like logograms and visual communication at least in theory, but I hate having to look at only a tiny portion of information that could easily be captured in a few lines.

 

First of all, I am not talking about Macros, but sure macros could clean it up as well. Visual scripting, at least in BPs case, follows the same practices that you do programming.

A Function signature also "hides" information from you does it not? It's not any different in BPs. You make a function, macro, or event (can be entirely in C++ even). Ta-daaaa your node graph becomes cleaner.

Debugging in Blueprints is very straight forward. Afterall, you can double click any custom node that errors out to "zoom in" on that function, macro, or event. For general readability, you do not care about the details of that individual node. While VS can take longer to do certain things due to more mouse use, it can also speed things up; such as screen navigation and jumping between separate blueprints or functions within a blueprint.

Seeing as how most programming is nothing more than a linear set of instructions, I would say that BPs represent this flow in exactly the same way. When things are not called in such a linear manner, you have EventDispatchers and a robust Event System at your disposal. What more do you need for game logic?

I will state that performing basic arithmetic operations in visual scripting is very tedious when you can just type it out in a single line of code.

 

Sure, functions hide stuff as well, but you usually would keep everything inside of a function that is basically part of the same step. Whereas with visual coding as I understand it, there would be nodes for probably each line, or more.

And with nodes, it's not simply a question of arranging nodes for optimum use of space - to convey the flow of information, you need clear separation between groups/blocks of nodes, a minimum of 'bent back wires' and as much directional continuity as possible. And basically (unless you want to be really messy) you're constrained outside the 'bounding box' of the previous nodes, which might flare out in bunches and then go back in, wasting a lot of space.

I know substance designer has nothing to do with code, but I've played around with the visual aspect of node grouping and the screen layout in that software and given what is usually encompassed in one node in visual code editors, I calculate a relatively very tiny amount of information on the screen. And it would be heavily fragmented whereas written code is very 'continuous'.

I'd like to think visual design has something to give programming in general, since I definitely see what people don't like about written code especially as beginners (in fact I'd decided I hated programming right up until I had to do some stuff in Matlab at uni) but nodes and wires are not it. Something else entirely is called for - but the problem is that since we don't have an already established means of visual communication in society, it would be handicapped by being something that programmer's would have to learn from scratch, and that kind of devalues the whole purpose.

If I had to make a stab at a revolution in programming, it would be speech - speaking in layman's terms to a programmer, you can usually get them to understand fairly well what it is you want, as they translate internally what you've said into logic and ask the right questions to fill in fuzzy spots. If a computer could do that, it would definitely massively lower the difficulty bar for programming. But it's not really a revolution in programming but sort of avoiding it altogether. And that's the crunch, the hardest thing really for a beginner I don't think is so much the text itself but the brutal logic of computerized 'thinking' which is not our natural way of thinking. And visual coding won't help that.

For beginners making very simple games, I can definitely see the benefits of visual coding and for that reason maybe Unity should put it in, but it won't be an efficient way to make anything more sophisticated than an endless runner or something.

 

As far as I'm aware, construction workers on a building site might well be the last speaker's of a whistling language, just look how they communicate when a young lady walks by.

 

A perfect programming language should be able to intelligently interpret what I mean when I type.

For example.

Code (CSharp):

1. Make Awesome MMO;

Semi colon optional.

 

It should be able to understand how utterly void your request is, for starters, and direct you to the Learning section.

 

I'm not sure where you are going with this. Good text programming also hides a lot of information. Typically inside function calls or inside encapsulated classes.

Programming is not about holding the whole model in one place. It's about breaking the model up into chunks that are small enough that you can understand an entire chunk at a time.

There are plenty of reasons to criticise visual scripting. But collapsing nodes to hide information is not one of them.

 

Even UE devs said that their visual scripting (blue prints) is meant for prototyping and that it should be replaced before release. One of the major reason being it does not perform as well as c++!

You can get by using visual scripting to design your game but you're constrained to the logic and capabilities the visual scripting allows for not the language itself.

 

I agree - I'm not sure either if Playmaker could be used to develop the type of game you describe high end. But I really don't think that is relevant - only because I think Playmakers strengths are geared at lone wolf and small team development creating moderate games that are not attempting to push the envelope up to triple A standards.
It could be an acceptable tool to use for a high end game like that - but not for the entire creation of course. Possibly for certain aspects of the game - like the developers of Inside used it for, or how the guy in the first video I linked to above talks about using it.
Anyway - we are indie -- We don't need no stinkin triple A - we as a community develop compelling content that makes us money and doesn't even try to compete with those corporate shills!
Indies really should not try to compete with triple A - it's a different league - not saying they are better than indies - but there are 60 team members (random high number) working on the next whatever awesome looking, cool mechanics, complete character and texture scans with 100k mocap systems to capture uber-animation detail. We create flappy bird and walk away happy.

I'd like to see one day a developer (maybe me) will create a very short high fidelity game play experience, maybe a demo level - of a game that I can make look as good as I can. The game will be very short, maybe 30 minutes or 1 hour, and have as much functional elements as I can muster to create added into it. It will look fabulous - because humbly thats my gig, I know I can create high quality content.
Would this game be considered triple A? Nope - and I would hope anybody checking it out would not expect that type of experience. But it could show a lot of people lone indies can create high quality content as nice looking as a larger team. But scope has to be sacrificed somewhere - so if the game is visually extraordinary - similar to the big guys - mechanics, functional elements, story and duration will have to be limited, de-scoped, of course.

Also just because another non-trival game developed in Playmaker is coming out soon

 

You ask if its the best and everyone is trying to tell you no its not the best. You said it yourself who cares as long as it works right? So what exactly is your gripe about having to use Playmaker? That its not native? You claim that there are clear disadvantages to a tool not being native yet you never name a disadvantage. You dont know of any disadvantages nor do you care if visual scripting performs as well, your only real kinda good complaint is that the support community for playmaker is not strong enough for you. Playmaker is to hard for you, you don not care if visual scripting lessons performance, all you care about is that its not native and for no good reason.

 

It's all a question of degrees - of course functions hide information, but not from one line to the next! It's not reasonable to break up code into functions at the level of types or operators. Functions usually contain an entire step or cohesive operation which can often take 20 or 30 lines of code or more. That's the thing, with written code, the function can be as long or short as you want, whereas with visual coding, whether you like it or not by the next 'line' you'll be looking at another node, and wondering what the hell the wire coming out of its behind really means.

Just take one page of reasonably heavy code (e.g. using a variety of types, function calls and operators) and try to imagine it as a series of nodes - nodes that have to be fine-grain enough to constitute a programming language with the same level of interactivity as C#. It would be just insane, it's not going to happen, it hasn't happened and its for a reason.

@theANMATOR2b I don't think it's unreasonable to assume that an indie game could have the same level of complexity of mechanics as Uncharted, I certainly wasn't talking about visual fidelity. It just blew my mind when I saw that long chase scene, quite apart from how pretty it was, how much 'stuff' was going on, from the player movement to the NPCs to destructible environments to vehicles to terrain material interactions, covering hundreds of square kilometres. I simply can't imagine visual coding being able to capture anywhere near that amount of dynamic interaction without being totally unuseable, especially for debugging.

That's what I'm going to do as well.

PS that Virginia game looks quite interesting! But it just doesn't appear to have very much mechanical complexity or stuff going on at any given time, it's seems to be more of a visual novel.

 

why do these discussions always devolve into a all or nothing type thing, node editors have their place where they shine, just like code does.

 

I'm not entirely convinced. At a basic level all a line of code needs is a set of input variables, an output variable, and a cue to execute it. That's all code is. And that can be represented quite simply visually. The most common form I'm seen is inputs on the left, outputs on the right, and execution runs from top to bottom.

Collapsing several nodes into a single node is really no different from encapsulating functionality within a class or another function. There are several valid criticisms of visual scripting systems. But this is not one of them.

This.

Visual scripting is a really powerful way to let the designers design and the coders code, without having them constantly looking over each others shoulder. One of the coders from Pillars of Eternity gave a talk on this at Unite Melbourne last year, apparently the system worked well for them.

 

Yeah I thought the same thing - the look of it reminds me a lot of the mechanics used in Minecraft Story Mode. I might check it out though, just to see.

 

Well since I've spent most of the time getting stuck into visual coding (building code from scratch visually) I do want to make it clear that I'm totally in favor of blueprints and I imagine that (as I've seen mentioned in a lot of places in regards to UE's blueprint system) you could build a lot of a game this way without necessarily having to code or know how to code. That's great and I think a well-built blueprint system backed up by a wide variety of blueprints on the asset store would be immensely powerful for helping people prototype and maybe even build the whole game.

Also, I think it would be great to try to come up with an simplified API for game-related tasks that could be used for a lot of different cross-genre tasks such as weapon systems and inventories, AI, UI and so on.

In short, I'm totally in favour of simplifying game development, but not of trying to replace coding itself with a visual system that does the exact same thing in a much more cumbersome way - although if someone showed me a visual coding system that operated at the same level as C# and was as easy to use as text I would happily withdraw my arguments. I just think that nobody has really proved the benefits of such a system or showed how it could be used for a wide range of different games at different levels of complexity, and it's relatively easy to see some pretty big weaknesses.

 

I could not say better

 

Harry3D I want to know these so called clear disadvantages you claim exist in Playmaker for it not being native? I don't mean go Google it, share some of your own experiences.

 

Maybe I've missed something here, but that's not the point (or ever was) of a visual scripting system. It's mainly centered around game logic, even though C++ / C# can be used as a scripting language we of course know that's not it's primary function.

A VS system has to cut down the legwork in doing generic transitions / game logic, examples being things like character systems / camera controls / UI functions / AI functions (flowgraph's) / Animations events (flowgraph's) triggers etc... That's why they exist, if it's far more "verbose" than scripting equivalent it then becomes a pointless feature. A CC / Camera with collision / tracking / zoom / input etc. would probably border on 300+ lines of code. In BP's it can be done in <20 nodes..

 

They would argue that those 300+ lines of code are easier to read than 20 nodes of spaghetti wires lol.

There are all sorts of commonly used functions built into BPs, such as Camera Shake. Tons of tedious little things that some people here would rather build manually. Well I'd rather just insert a Node personally and be done with it.

 

If you have to ask "why" you haven't been reading the thread... The visual types demand the ability to draw a program and declare pictures as enormously superior to pages of text, and the code types insist it's a crutch and can't match the flexibility of regular code.

 

Uhm no...it's more like the people who have actually used Visual Scripting recognize where it is and isn't beneficial, while the code types believe that hard coding literally everything is more efficient...

Meanwhile in the real world, most major studios, whether they are using Unity, UE4, or some in-house engine, have adopted Visual Scripting into their workflow.

 

Coding produces more efficient programs theres no question about it. Nobody is saying dont use visual scirpting. If you want to use it then use it. OP claims that he is going to switch to UE because unity does not have native visual scripting when it doesn't need it, it has Playmaker all because of clear disadvantages playmaker has as its not native which is absurd. The unity devs are better of working on features that unity really needs that everyone will benefit from while third party devs can make awesome assets to expand unitys functionality.

 

Well that's probably because you don't make programs via VS. It's made for game logic, not for making an engine.. Also in terms of "efficiency", when it's compiled down into native C++ (like UE4's BP's) it isn't any less efficient. In terms of work flow for generic tasks VS. is far more efficient in terms of workflow, because as said you can do 4 hours worth of scripting in a matter of minutes.

It's an enhacement nothing more, it's like Mecanim vs. legacy scripted animation system. It just so happens the BP infrastructure in UE4 is sufficient enough to create all your game logic. Sub-systems and tools for the forseeable future will always be code.

 

I dont know where your getting this but its not compiled down into native c++ and its not as efficient the devs of UE have said this themselves. Its intended for prototyping and they recommend replacing it with code before release! This is the creators of blue prints own words. You can use visual scripting to program game logic and it will run great but its not as efficient as code.

 

UE4 has the ability to convert Blueprints into C++. It's very effective too.

https://forums.unrealengine.com/showthread.php?101416-Thanks-for-the-BP-gt-C-Converter-it-s-awesome

 

https://www.unrealengine.com/blog/unreal-engine-4-12-released

New: Cooking Blueprints to C++ (Preview)
To reduce the VM overhead that goes into executing Blueprints, we’ve added a feature that lets you package Blueprints into native source code.

It was added in 4.12 and improved in 4.13.. In the old days it used to be around 15 - 20X slower than native.. Not any more.!