Unity Visual Scripting 2017?

Few minor things... I'd like to add that it is generally impossible to change programmer's opinion about visual programming tools by arguing to the death about it.

Basically... "Big studio uses it, so it must be good" is a fallacy. "Appeal to authority" coupled with failure to realize difference in budgets. "A lot of people want it, so it must be good" is a fallacy. "Ad populum". "The company is interested in making it easier!" is an assumption. TO know what they're interested in you'll need to deal with their accounting department. "people are doing cool things in visual tools" is irrelevant. Some people can draw mona lisa in MsPaint, it does not make MsPaint the best drawing tool, however.

Basically, if anyone is trying to prove usefullness of visual scripting tools, they'll need to prove that they're at least as efficient as classical programming techniques, or more efficient. And not in "peak efficiency", but during daily operations.

To the date, dealing with visual tools, compared to normal programming was extremely unpleasant, slow, inefficient even in the most polished products (like unreal engine). The tools did not seem to be designed in order to increase productivity, but the seemed to be designed in order to implement visual programming paradigm. Obviously, valuing a paradigm over practical goals is a big problem for anyone who know their way around programming and they'll see visual tools either as a fad or as a toy and nothing more.

Just a few cents.

So the bottom line if you want to convince a programmer that visual tools are not just a toy or a fad, show them an example that would make a programmer excited. So far all the mentions and arguments in the thread weren't it.

 

There are literally hundreds of examples and is only getting more and more popular to code via vs.
If you think for one second Epic is investing all their resources in BP because is some kind a fad or a ploy then you are sadly mistaking. This is the future of game logic creation and is only just begun. Blueprints has burrowed very deep in the UE4 engine and is only growing bigger. Why would anyone think is some kind of fad or a ploy?

By now you should know that artist, programmers and game designers all play a different roll in the creation of a game.
If a programmer is more comfortable coding it then he or she reserves that right to do so. Only different now is artist and level designers can join in and create great games also. Is no longer an exclusive club for programmers, but for anyone with a little imagination, can hold a mouse and follow instructions.

Since the beginning of UDK vs has always been marketed for simple game logic and to help out programmers that constantly had to go back and forth with the designer. UE4 blueprints is at a whole new level never seen before and should not be confused with what Kismet was. You can iterate ideas 10 times faster with bp than coding and if somethings needs a little performance boost than c++ is use. Although their are always workaround these problems.

Visual scripting is here to stay from now until the end of time and Unity is just simply embracing it by adopting their own secret sauce.

So in conclusion, if programmers want to stay on that side of the fence and not fuse the two workflows to perhaps gain more momentum by iterating quicker ideas. Is like the old saying "you can lead a horse to water, but you can't make it drink.

 

They're not investing all of their resources into BP. Neither will Unity.

Then let them. Having choices means if programmers don't want to use visual scripting then they shouldn't have to.

By the way I'd love to know who this whole marketing spiel is supposed to be aimed at. It's almost as if you wrote it under the assumption that those who dislike visual scripting haven't taken the opportunity to at least try it out. I know @neginfinity has tried it out because we've had discussions about it in other threads.

Do we even need to have this discussion still? I feel like I could have skipped over this whole thread and not missed anything.

 

Why does this seem to devolve into a "OR" argument that you have to choose between using visual scripting or text based. People keep mention Unreal's Blueprints, but if you actually used BP before, it is one of the best examples of "AND", with how it extend and can implemeant functions on existing C++ classes and interfaces.

I can see this helping artists and designers a little, especially as the programmers build higher level nodes and tools for them to use. But once you get to a certain level of logic in BP it is no longer useful for artists and designers, since even its terminology it uses is very C++ based and you get in situations where the logic can be understood and represented faster in code.

I can see it getting more on par with a programming language in the future though, it is still in its infancy. Compare the experience of programming before the time of good IDE's and Code editors, to doing so now, well node editors are at that stage right now.

Until it advances a lot, i think it will have its uses where it is the better tool, than code where have its uses where it is the better tool.

Node systems are great, for AI and Animation state machines, and can be great for stringing together bits of logic for the world. Great for if condition met, do this list of things type operations. But it turns into a unreadable mess when it comes to the internals of a larger system. But when it comes to acting as the glue between systems i like visual scripting.

 

If I had to guess the programmers who are against it are worried they'll be the ones stuck debugging and optimizing the node graphs made by everyone else. Which is likely not that far from the truth.

 

Anyone can try something out a few time and make an opinion about it. If you work on it all day than that's another opinion.
Is aimed at loss lambs that are staring out and could possibly get discouraged by some of the negative talk from programmers about vs.
New generation, new outlooks fresher minds, better ways to make games.

 

On bigger projects you can still take advantage of visual scripting , like manking complex functions within nodes, and use a library of nodes to make different behaviours. You can mix code and Visual Scripting successfully.

 

Yeah and how do you get that having more users and growing a company somehow implies I don't think they want profit? A cynic might think you're just trying to flog your patreon in your signature to get suckers to give you some easy bucks, all in the good old name of greed. I'd rather think that's not the case for both you and unity.

 

Look dude, I wasted my time explaining which arguments don't work, and you throw the same thing again. Reread the damn post I wrote previously. You can bring this kind of statement billion times, it won't matter. You need a different argument.

I worked for much longer than a day on it while converting a unity project to unreal. The blueprint system is S***. It gets in your face at any turn, and it only slows you down, never offering anything in return. The especially disgusting part happens when you need quickly design a basic condition for animation system and you need to start dragging noodles for something you could've typed in 2 seconds.

It simply isn't designed for productivity. It is designed to make a visual programming tool. Overall I had impression that someone obsessed over the idea for too long, and that's why blueprints happened. Would be great if rather than "let's make all VISUAL!" they took a step back and thought about productivity a bit. As far as I can tell, it is a crutch at best.

If "lost lambs" starting out could get "discouraged" by one post, they never had a chance to begin with.

This kind of statements usually happens when someone runs out of argument, gets frustrated due to unable to win. If you wanna change opinions, provide better arguments. It is that simple. Taunting, getting sarcastic, or repeating things again is not gonna work.

 

But what constitutes "bigger" here is not a matter of something factual, it's a matter of your personal values. You want some other feature more than you want this, so you want whoever is working on this to stop it and work on the feature you want. That way, you get what you want, because who cares about the people who want this? You don't want it.

Except...

Because development in general is not a democracy.

So why are you voting? What is the point? You're not going to get what you want. They've announced the feature. They're not going to cancel it and go work on some random crap you want them to do instead. Even if you could vote, you're trying to do it after the winner has been announced. That's too late. It doesn't work like that. It never works like that.

 

The issue is that process of extending blueprints is not, how should I say, convenient enough.

Basically at the time when you need to introduce a slightly more convenient operations because what you can do with blueprints annoys the bejeezus out of you, you need to make a full stop, and waste some time implementing a full blown C++ class. One other thing annoying thing is that registering the class in the blueprint system required a full reboot of unreal editor, which doesn't really help. Another fun thing is that unreal 4 is built with exceptions disabled so one typo often will result in another restart.

The system is also wired everywhere in the engine, and trying to avoid it fully if you don't like it is impossible. At least in one place it will be required and there's not a thing you can do about it.

So, the issue is that somebody in development team was obviously a big fan of visual approach, they poured a lot of resources and in the end made a system that is uncomfortable for heavily code-oriented people and is definitely not optional. THAT's the problem.

THe irony of the situation is that they made it to replace Unreal Script. The reasoning was that they wanted to reduce amount of duplicate code, and so they scrapped one scripting system and replaced it with another.

You know how occasionally programmers get fascinated with one idea and try to implement it without looking at disadvantages ("When all you have is a hammer everything looks like a nail" kind of thing). As far as I can tell, blueprints are that. A mistake. Someone thought about a way to bridge a gap between artists and programmers, got an idea about visual programming, became a fan of visual programming, implemented it and forgot what it was all about to begine with. So as a result, there's a large community of blueprint fans which waste their lives doing an equivalent of coding with their left foot, and at the same time, blueprints offer a good deal of annoyance if you dare to approach unreal 4 with a coding approach.

Despite all the polishing and effort put in it, the system does not look well thought out and have flaws. And this is pretty much the best product in this area made by a large company. As @MV10 previously mentioned, those kind of ideas pop up from time, and it is always "the big next thing that will do away traditional coding!". Except they never work out. Because they never really work out and because there's not even ONE product anywhere where you could look at it and say "Oh, Now I get it. This is it!", I see the whole visual programming idea as an equivalent of an evolutionary dead end. Something else should take this niche. Did anyone try to make something else though? No, possibly because of extreme fascination of noodle dragging.

I don't think I have anything else add on the topic, though.

 

I'm old and remember when Visual Basic first came out. Lots of people made the same criticism: you have to drag and drop and move and configure all these controls on your dialog, when you could just write the .dlg file yourself so much faster.

Yeah. If you know how to do it. Like if you've already been doing that for years without the benefit of this handy tool. The real payoff of Visual Basic was that suddenly, your idiot manager who thought he knew how to write software would stop bringing you harebrained ideas because he could fire up VB and try to do it himself. Which meant you could concentrate on real work.

And over time, an additional benefit appeared: non-programmers could suddenly do 80% of the work without you. And it was the boring tedious part of the work that you didn't want to do anyway. Which meant you could get an intern to do it. Suddenly, you had a lot more time to do real work, instead of writing the same stupid boilerplate over and over.

I suggest this is an advance.

 

Obviously not, but that feels twisted. Everyone here knows you can't make decisions based on someone's opinion.

At the end both engines are just tools and if you don't like the hammer then use something else.
Personally I love both engines and will probably never choose one vs the other.
Both can deliver quality content and using one vs the other depends solely on your project.
I think Unity needs to make a nice splash with vs and incorporate it into materials, ai, particles, etc. I mean who wants to code materials or depend a an asset from a third party. Is better if the basics are all incorporated into Unity like UE4.


btw. working with bp is blissful and that include animation, materials, umg, ai, and all things bp.

 

It is the truth though.

This does not match my experience, unless you find swimming in cement blissful.

If unity manages to make the first ever visual system that does not waste people's time and actually solve problems, sure. There may be ways to make it right.

If this is about making another Blueprint knockoff, I'd very much prefer if other features were given a priority, because this kind of tool at best is a toy.

While both engines are tools, they both have parts they got just right (animation system in unreal 4, or component system in unity), and some parts which are... very awkward to use. So the best idea would be not to borrow awkward parts from the competitor.

Either way, it looks like a standard time to make a feature go live is between one and two years. (Timeline, Progressive lightmapper) and on occasion much longer (Mixed mode shadows - did this fix ever go live?).

 

Mixed mode shadows are apparently coming in 5.6, but I have no idea if they work, given their history of never working

 

I bet Unity will use a mix of vs similar to gamemaker 2. This way one can code or mix it up with nodes. Is mix martial arts.
Than everybody is happy, is a win win for all. Just need to keep things efficient of course.

 

I work heavily with visual scripting in my day job. It has a few strengths for process automation. Namely that it's easy to write, verify, and troubleshoot. I can give an operator a five minute rundown and have them troubleshooting the code with me. That's impossible in any textual language.

It also fits the problem domain well, ladder logic behaves the same as the relays, contactors and solenoids that are interacting with the system. So converting a soft PLC program to a hard wired electronics program is literally a two second job.

But a scanning PLC is quite a different paradigm from a game loop. It's not object oriented, there are no methods. The most complicated data structure you deal with is a int. Fully 90% of the program is simple Boolean logic.

In this case visual scripting shines. But that doesn't mean I want to do it to make a game in Unity*.

*Okay, in some of my less sane moments I've considered building a ladder logic binding for Unity and putting it on the asset store.

 

Because they think it's pointless when you can just learn to code. Although... these ones still want a terrain system, even though they can go learn to model/texture a terrain in any 3d app right now, then program some tree placement + billboard generation script.

Then there's the uber nerd programmers who would rather Unity was some command-line only thing.

They just need to get with the times. 20 years from now there's no way Unity will have less features. The likelihood is it will soon even have a full mesh modeller and material painter embedded, not the other way around. Engines will be full creative suites.

Resistance is futile.

 

Don't know if you're aware, but Epic is implementing a basic modeler in 4.17 which could save you from going to maya, etc.
Also they're talking about a real time animation bridge for maya. (you can grab it from Github now) The idea is once your character is fully rigged then animations can be transfer instantaneous between programs. I can only imagine live content and material conversion is next. Modo for example has a direct plug in, but is only for materials. For quick prototyping entire levels and mix matching content from Blender/Maya plus a live update back and forth should be a small hurdle and is coming soon.
Take a look a these two links and see for yourself:

 

So much this.

My 67 year old father will pull out his phone and say "Call Ted!" and it dials his golf buddy, then during the conversation he'll start looking at his iPad for tee times, and while he's doing that he'll say "Alexa, what's the weather forecast for Tuesday?"

Somehow, my parents' kitchen has turned into the bridge of the damn Enterprise D. And it's hysterical.

Meanwhile, my dad's friend Ted is still confused by wireless telephones. He doesn't own a mobile phone of any sort, and his landline still has a cord connecting the handset to the base. He doesn't trust these things where it just goes through the air, and doesn't believe that it's basically just a radio.

Ted is angry a lot.

 

You're comparing apples to oranges. A visual scripting language, despite how some would like to paint it in a different light, is basically a crutch for people who cannot pick up actual coding. That's fine. Nothing wrong with that. It's an entirely different thing to try to justify them with this sort of insane logic.

Likewise there are differences between a static mesh and a terrain system with both having their own ups, downs, and ideal uses, but allowing the user to perform a task due to a lack of a skillset isn't the focus for one while it is for visual scripting.

 

'Get with the times' would be valid if most of the world was using visual scripting. In your example a cell phone is clearly superior to a land line. Visual scripting does not have that clear superiority.

However visual scripting is currently a dream rather then a reality. A few nieche products use it really well. A couple of game engines use it in a weird hybrid system. But no one has yet produced a visual programming language that is clearly superior to a text based one.

If you can show a programmer how visual programming is superior to text based programming, they be on it in a heart beat.

 

You don't need to go left or right, but rather zig zig while building a game.
If you're an artist and don't like to code no problem. If you're a coder and don't like noodles, no problem.
If you know how to code and know how to hardness vs for what it truly is than you are a wrecking ball and nothing can stand in your way. Visual scripting is not just for artist, but in the hands of a programmer can become very powerful way of building.
It allows you to be nimble while smoking ideas and prototyping scenarios. Don't fight with it, embrace it and become more.

 

Here's the thing though.

I don't care what programmers think about tools that aren't meant for programmers. I don't need a programmer's opinion on After Effects, or Photoshop, or Blender, or any of the other art and design tools I use. Their opinion is actually completely irrelevant, especially when they have things like C# which remains completely functional and isn't going anywhere.

And to add to this, I think a lot of people here are losing sight of what artists and designers actually do. As a designer, my job is more than just "come up with some sick ideas and do rad kickflips on a skateboard while sitting in a beanbag chair." My duties entail coming up with relevant concepts that are practical to implement. With visual scripting, I can knock out a prototype in a matter of an hour or two when my difficulty with code would make the same thing take hours, possibly even a full day in C#. Similar situations also apply to art based concepts.

And here's another thing that I think people aren't exactly grasping: not everything needs to be executed in the most completely efficient way possible. My playmaker script that opens a door, causing a particle effect to go off, alongside a few incidental lighting effects, is not going to require that I write the most efficient code in the world. It's a door and they tend to open one at a time. Sure, things get a bit more complicated if I need to do the same with 1000 doors all at the same time, but that's an edge case that can be solve by getting down to the code if I need to.

And you know what? More often than not I actually don't.

 

It would be great if someone played with a mixed approach when you can type code within nodes. I think this could be interesting.

Or if the whole visual part was a different representation of a text based language. I mean, something like lisp forms would be easy enough to visualize as nodes.

Basically, the main issue is that visual systems seems to be obsessing over placing stuff with mouse, rearranging it, and connecting it by dragging things with mouse. This is generally a big waste of time.

An automatic node placement with rigid positioning that would also correspond to an actual text based language might work better. At least for game logic purposes.

 

They are. It's just that they don't think of it as visual scripting.

In Unity, you declare a public variable of the type you want, and then you go over into the editor and drag the desired component into a box. That creates script to initialise the public member you declared, but you didn't write that script. You created it visually.

Similarly, you drag files around in your code editor, and it automatically maintains what amounts to a makefile. That's visual scripting. You open any dialog editor or resource compiler, and you drag things around and nudge them into position where you used to write dialog templates and resource definitions by hand.

The knee-jerk reaction when I point this out is to say "well, that's different" when it is totally not. You used to do something with code you wrote by hand, and now you click the button or fill in the box or drag the link instead. There's a line where you have no choice but to go write some code, and that line just keeps moving farther and farther down the process.

But it doesn't move all by itself. Someone has to push it, and if the folks at Unity want to push it even a little farther, I will applaud and cheer and never use it because I can write code. I'm still glad someone else can do their little toy project that doesn't matter with colourful blocks.

 

I'm already nimble as a programmer though. I have very good knowledge, excellent memory (I can recall APIs for libraries I haven't used in years), and a very high typing speed (I've actually broken the graphs for some typing websites).

I'll willingly embrace a visual scripting system that allows me to go beyond my current skills. I have yet to find one though.

My understanding is that you can do it with GameMaker 2 but I haven't bothered to download and verify myself.

 

I don't disagree with you here. A high level visual language that lets designers hook things up would be great. Basically a more enhanced version of what happens with the inspector.

That's great. You can effectively sandbox designers away from stuff they shouldn't be touching. And you don't need to bother a programmer with trivial tasks.

 

Not everyone is a freak of nature or a supercomputer.
Some of us are a little slow and that is just fine by me. Your speed is not going to win best game of the year. Maybe employee of the year, but that's it.
Its all about the options these days and the more at your disposal the better will be.

 

Getting frustrated? Not at all, just refuting your logic that everyone is out solely to enrich their own pockets at any and all costs. Hopefully you can see how that kind of cynical worldview doesn't look good applied with a broad brush.

@stormwiz That livelink sounds pretty good. Asset management and program linking is always something I appreciate and its something that doesn't seem to occur too much unfortunately(but maybe not all that surprising since many middleware companies are competitors). Unity having a GoZ like button for major 3d programs would be pretty incredible.

As a sort of unrelated but still related sidenote; this topic reminded me of this game called Code Rovers, which was incidentally made with unity: https://gfycat.com/MellowEvergreenAndeancockoftherock
Visual scripting applied in different ways allows you to do some really cool stuff. From an educational standpoint, I think a system like that would make for a fantastic learning tool.

 

The profit motive is just a sublimated form of the self-esteem motive. Everybody fundamentally just wants to feel good about themselves. Many people believe they would feel good about themselves if they had something they don't have. Like money, or a nice car, or a pretty girl, or big muscles, or a visual scripting editor. Most of those people are wrong.

 

None of us started that way though. We started as beginners and through actual practice became good at it.

No, but my knowledge of traditional coding may allow me to implement functionality in my game that due to performance constraints may not be feasible to the developer who relies on visual scripting. After all to my knowledge none of the visual scripting systems available achieve performance on par with actual code.

 

No, as far as I can tell, my world view is fine. A business is at its core is all about making profit. Because when business stops getting profit, it dies.

...

If typing at a high speed is a "freak of nature supercomputer" these days, then we are all doomed.

What ever happened to improving one's abilities and reaching full potential?

 

Now that I'm thinking about it, perhaps Autodesk should implement live links with other game engines instead of just with stingray. If they don't the competition will siege that opportunity. Even if they do Epic is going balls deep with this one and it now has a raw plug in for anyone that wants to further this technology while they continue to push themself.

 

Of course not. Don't hand pick from the post and twist things. As a whole it gave that impression "I can recall APIs for libraries I haven't used in years" . If anyone that can type superfast is a supercomputer than yes we as a specie are all doom.

 

I'm sure there's a middle-ground which we could work out if we put our heads together. Something which is as fast as typing, but has the clarity of visual scripting. The features it should have would be:

• Be able to be completely created from keyboard
• Easy way of finding the needed name of something (search/intellisense)
• Get rid of all brackets {} [] () replace by automatically created text fields and tables
• Collapsability of functions and classes easily
• Nice to have: Inbuilt equation formatter so you can write nice equations with pretty square roots and powers etc.
• Additional toosl: Be able to change color values with a color picker for example.

As an example, you might press Ctrl+C to create a new class. This creates a block with some text fields. You type in "void" space takes you to the next text field "myClass". Press enter. Now to define functions press Crtrl+F. This creates a function block. All the brackets (,,){..} are already drawn for you (or implied by the structure of the block) so you can't accidentally delete them.

So its kind of visual programming in that its not simply writing to a text file. But its also visual programming because there are things which you can't delete and it keeps the structure of things. All you would need to learn is a couple of extra keyboard shortcuts and it would be just as fast as coding but a bit prettier.

And maybe you can press a button and it displays everything as nodes and spaghetti.
Also this site https://processing.org/ has some good ideas too.

 

While it may take them years Unity is generally able to create a good end result. An article or thread that consolidated interesting concepts from different visual scripting systems would be interesting though.

For a limited time you too can see how your code looks like to everyone else!

 

As another thought. What would also be nice would be a way to easily copy a table from an excel sheet and paste it as an array in your c# code without even thinking about it. Or just drag an image into your c# code and it automatically imports it, creates a public variable for it and write the variable just where you want it. There's lots of things that could be done if you think about it.

 

Visual Studio already has a feature, for pasting json data as a class that represents the model for that json.

But direct referencing of assets like you mention, isnt all that generic, and i really dont think a click and drag there is much faster than just writing the field you want. Refactoring tools like ReSharper really let you get code out fast, and let you create properties and methods based on usage.

 

Some type of Visual Studio class diagram would be good. I use NClass sometimes to design my classes before I start projects. All other UML programs I've found have been more like awful drawing software.

I was going to make a Unity asset that would let you design your code with blocks, then it would generate the C# code.

 

This is a case of what I call the un-problem and the anti-problem.

An un-problem is a problem you cannot tell you have until it has been solved.

An anti-problem is a problem cannot tell you don't have until it has been solved.

Both cases require a solution to be built before the truth can be seen. And it's next to impossible to tell the situations apart.

In fact, sometimes they coincide: a person who does not understand how to do decompose their problem may think that a visual scripting tool will fix that, but this anti-problem is that no matter what tools you may have... you still have to use them to do the job. Which means you have to understand the job. No quality or quantity of pipefitting tools will ever change the fact that you need to understand the pipefitter's job.

Meanwhile, the traditional coder may very well have the un-problem that even though they can write whatever code they want... a shocking quantity of what they write is the same thing over and over, and dragging a few boxes around the screen might be more than enough to write more than half of the boring parts. I mean, sure, you could do it manually - but why? I mean, you don't have to anymore.

In both cases, you need the visual scripting tool to know what you have. Otherwise you don't really know anything.

 

This is not a valid comparison. UI layout is an inherently visual process. I wouldn't argue against visual layout for the same reason I've never argued the Unity editor is a bad idea and we should only describe scene layout using a hex editor or something equally l33t. Also, the endless incompatibilities and revisions to the CSS standards are prime examples of exactly why non-visual UI layout is a frigging nightmare.

In response to a few other comments, visualization tools such as class diagrams are also not visual programming. We've been over this in the thread already.

As for being old: check. I was actually a beta tester on the last QuickBasic and got a sneak peek at the first VB. I still have a 1991 VB 1.0 manual on my bookshelf (because reasons). Remember when MS actually included printed manuals? And they were quite good compared to the "Recursive: See Recursive" minimal-effort junk on MSDN these days. /damnkids

 

I have completed a base game (third person, combat, rpg) with Blueprints in combination with behaviour trees, and i had no issues, it was well designed and i had fun.
Perhaps you cant' handle Visual Scripting, you need to be faster with code ? You can't organize it to be readable ?
Or you simply don't like it , anyway there are lot of other people that need it and that already have done games using Visual Scripting or a mix with code.

Why do you need to repeat Visual Scirping is bad ? It is bad for you not for other people.
You are stuck on your preferences and won't use it, that's ok , but it's childish to say it's a bad feature.
And whatever you say it will be included in Unity

 

@zenGarden Not if we get Unity to agree with Lithium for life! lol. JK.

I mean I have nothing against it, only that they don't at least learn to code some, then they will only be limited to what they have in front of them, crutches aren't meant to be used forever, at some point in time, if they never made a game in their life and want to make the next MMO (yeah happens way too often), they will realize very quickly even if they grasp VS fluently, there will at some point in time be some sort of Node they WILL need, and without any experience with coding they will do nothing but stare blankly at the screen and give up, or beg people to make whatever it is for them (happens more than one could imagine). Everyday on Facebook groups "Make me this, free" lol.

But hey, to each their own, whatever works for them, if they believe with out a reasonable doubt that it can do everything you want go for it. But I still recommend to at least get basic coding skills down, sucks to not know how to code and when you try to explain what you need to someone who does know how, you don't even know how to explain the proper context of what you want to do lol.

 

Funnily, as a web designer, and a VS fan, I'd prefer an HTML/CSS-like UI system for Unity. Unity's new UI requires you to make your own CSS system for it to be useful. The old UI is much faster for prototyping, especially if anything like dynamic lists are involved.

 

Why ? I seen many people learning Visual Scripting and do great things, and many didn't left Visual Scripting for coding once they got the basics.

You are talking about the extreme, who indies and lonewolfs will make a mmo ? No instead they are making action games, small scale RPG, exploration games, or mobile games. Visual Scripting suits a lot to that kind of projects and people that like Visual Scripting.
It's a preference to use Visual Scripting for some people, that's something coders don't understand lol
We are not talking about project size or what can be done, but a tool that suits people that won't code, or that will mix both.

 

Ah yeah I'm just talking about massive projects, not smaller games or anything like that.... Just stuff that's 40+ Gigs in size.
Believe it or not though, there's tons of people I've seen wanting to make the next big MMO, it's not as small scale of a group as you might believe, nearly once a week I see someone asking to make a team for the next big MMO LOL.

 

I think I explained everything in great detail in last few pages. Even if you really want me to repeat same thing again 50 times, and really love reading more walls of text, i really don't feel like writing the whole thing again.

Maybe, maybe not, or maybe it'll happen somewhere around year 3000.

If it gets implemented I sure hope it won't be forced down user's throat everywhere, like it is done in Unreal 4.

Then again, as I said many times, I"d really prefer to have other features implemented first.

 

And on related note...

... why do you need to repeat that you think visual scripting is good? Even if it is good for you, you are not the other people. Like, seriously, you even post jabs aimed at people who dislike blueprints in unrelated topics (HZD procedural positioning).

Aside from two or three scenarios I mentioned many times where it works and is useful, I mostl y see visual programming as a bad, overrated toy that teaches people a way to waste their time by doing their work in a very inefficient way. So I naturally would recommend to avoid it and naturally I would list shortcomings when it comes up. That's all there's to it.

I might change opinion on it at some point later if a good example of visual programming (that deeply impresses me) comes up, but so far it hasn't happened.

 

More importantly, it is not an inherently verbal process, and neither is programming.