Visual scripting in Unity

Well, there's blox <something> for Unity which is pretty much like Blockly/scratch, but it is fairly expensive for just VS solution and nodify is free (though I wanted to ask here to see if it's free because it was abandoned or are some strings attached).

Again, this may be my Blender background speaking, but personally I think nodes are as much if not more powerful than scratch-like solution. Don't get me wrong, I think such things have its place (was using Stencyl which is as scratch-like as you can get without actually being Scratch), but not when third dimension is involved. Back when I was still using Stencyl (I've dropped off around the time they've introduced that $99 annual subscription, without flat price choice) I remember scratch scripts were fairly involved even for the basic things in 2D game, like platform movement.

Nodes on the other hand are better, because many "paths" can lead to the same code, which removes code duplication so common for Scratch-like systems (and systems similar to Construct/Klik'n'Play).

IMO, from worst to best, here is my ranking of VS type solutions:

- Klik'n'Play (makes sense since it was one of the first)
- Construct-like (several improvements over KNP model, but still basically same thing)
- Scratch-like
- Nodes

 

My goal is a tool that can ultimately help me learn C#. Not because I can't grasp the language, it's a hobby and I find the visual side a little less like work. Something that generates C# fills my wishlist. I think that narrows it to uScript or Blox2. I like Blox2 because it feels more like programming than drawing nodes, but that's just my quirk. I figure most deciding on visual scripting have their own quirks so no one solution will fit all.

Playmaker looks very easy, I think if I may still go down that route because it looks the best for prototyping and the plugins will make it plain fun.

I also bought training for uScript from Udemy, the first diagram the trainer coded had way too many nodes for my liking.

Oops, I thought iCanScript went bust but I've just got a reply from one of their devs... they are working on V2, should be going beta around April... it will generate C# also... def one to keep an eye on.

And is it just me, or would any of the above, including coding C# seem much easier than Blueprints?

Rix

 

Believe me, the fastest, most efficient and most accurate method of learning C# is to try making a game in C#. It will teach you alot more about writing scripts and how everything works with creating game logic and the Unity game engine than a Node-based scripting system that may export some garbled C# that would likely to be unreadable or not easy to learn from.

 

Tools designed to export code usually produce very specific code that is not easy for a beginner to understand. They export code primarily to allow the compiler, and any programmers on your team, to perform optimizations on the logic created by non-programmers. They are not intended as teaching tools.

One of the best tools for learning C# is simply Visual Studio and a book covering the language.

http://www.robmiles.com/c-yellow-book/

Unity's learning section also has numerous scripting tutorials and they are very easy to follow.

http://unity3d.com/learn/tutorials/modules/beginner/scripting

 

It's also interesting how different scripting feels compared to the logic applied to a nodal/FSM approach. I worked through a few of the PlayMaker basics and then tried to recreate one of the "more complex" (they weren't overly complex) scenes in C# to see if it's as fast or easy to do.
Some things which are super easy to do in Playmaker are rather annoying in script while other things are pretty long winded in an FSM that are super easy to do in code.

I still think ... or better - hope ... that either a form of visual scripting or even a completely different system will be introduced to Unity in the future but the way of thinking in an FSM and in C# is different. Difficulties are shifted.

Though the thing I love about visual scripting so far is how super fast iterations can be. I think after trying to re-code a playmaker scene I understand what Bret Victor means when he says that coding can be too abstract and should be connected closer to the process of creation.

 

Personally, I find visual scripting useful for two areas: super simple actions (for example: make this thing rotate on the spot continuously) or teaching young children how things such as conditionals or loops work. The node-based system in Scratch is amazing for getting young school kids to begin getting their heads around simple logic, functions and action-flow.

However, for anything else I would always use, or recommend learning, some element of actual coding. I find it both significantly faster and more flexible in the long-term when a project reaches a substantial size. I have met many developers who have openly admitted they wished they coded everything from the start as their visual scripting system gets too large and complex for them to maintain when optimising their game for release as it's just a spaghetti of wires and things linking everywhere. If I was working on a project, I wouldn't even let a game designer begin to visual script it; it's just much faster, and less likely to become problamatic in the long-run, for a programmer to write a simple prototype script for a mechanic and expose things to be tweaked by the designer.

 

Isn't that tool called Visual Studio, or MonoDevelop? Using something that sits between you and C# isn't going to help you learn it, it's going to hinder.

If learning a language is your objective then put that first and foremost. Get yourself a programming book and start at the front cover.

I hear great things about The Yellow Book, which is also free.

 

Heck, with code completion, a few tutorials and the ocean of references on the internet almost anybody can make basic C# scripts. Probably with greater ease than they expect.

 

That's some great Unreal Engine publicity.

Stretching the principle, if text programming was always best, visual editors like the scene view or the inspector would also be undesired by seasoned developers.

I agree that visual scripting environment with big nodes and named sockets gets slower and messier very early in the learning curve comparing to text programming. But I believe those critics never used a design like the pre-OO Quest3D that steer away from the shader editor heritage of big thumbnails on every step.
On minimalistic Quest3D, with a bit of practice, you can roughtly tell what each part is doing on a zoomed out snapshot, even without notes.
http://tale-of-tales.com/ThePath/bl.../2008/08/20070807-quest3d-motioninterface.jpg

Current acceptable design paradigm of visual scripting (Vizio, uScript, blueprints, kismet) often imposes horizontal strips of nodes and you have a harder time telling one part from another. Also a bit of overhead is spent fitting those big nodes on screen space.
http://callanw.com/wp-content/uploads/2014/07/2014-07-28-22_22_50-Tower_BP.jpg

I can see how those horizontal strips adds little maintenance benefit over the linearity of text programming and I can see how it's frown upon by the likes of you since inevitably 1 mouse pointer will often be slower than 10 typing fingers. These designs ease the start, but does no better on the long run. But they are improving. Blueprint's context, Vizio's right click on a socket...

Semiotics would say that squares and connections are easier to identify than verbal symbols references and you get a better view of the whole. The no-sintax-error is very useful all along the learning curve and even developing. As well as the auto-updating of cross references. Level of abstraction is a valid criticism, but it varies from tool to tool. I like Vizio lower level of abstraction, lower even than blueprints, and there's very little I can't do that I would need Unity's C#. It's even easier to integrate fourth party plugins with those wizards. It is a bit cumbersome on design, but that's a 1,5 man side-project.

I hope not everybody on Unity is so tucked in on their comfort zone and that Unity will eventually buy ACT3D or at least Neodrop's Visa. Otherwise, there's hope that it is a matter of time until UE fix their multi-platform issues and lower a bit more blueprints abstraction.

 

did you people check out the iCanScript. I think it is closest competition to Unreal blueprint system.

 

Thanks for the reminder, I have The C# Programming Yellow Book ;-)

I've probably stated my goal too loosely, I think what I should have said was "to learn the unity API" as opposed to C# in general. I can read code fine, just couldn't write it off the top of my head but practice is the only solution.

I just like the idea of visually coding, seems more fun. Have you checked out Blox2? It seems pretty well tooled for visual coding, not so much a state machine...

 

Yes, I was in contact with one of the Devs because it crashes Unity 5.x He said that they are currently working on Version 2, hopefully released mid next month. It is a complete rewrite, dependency problems, so the next version will produce C# which is a huge plus.

It is complicated, but very powerful. Looks easier that Blueprints though. I really don't know how they have caught on so well, IMO it is way easier to learn C# than BP's !!

 

Thanks, and yes I admit that the more advice you guys are giving me the more I'm realising I'm wasting my time on the other tools. I bought the Yellow Book a while back, just forgot that I had so I'll get stuck in !!

Although I'm still the kid at the toy store when I look at those tools... doh !!

 

I don't see how it is. I stated 'Personally' in another post about it. As in, not as an official Unity statement but of my own personal opinion on the matter. Im sure the other 500 people who work at Unity also have different opinions on many things; after all we are all human.

And I don't see how its so bizarre to think that making a game in C# isn't the best and most effective way to actually learning C#. To use a Graham Car Analogy™: When I wanted to learn to drive, I signed up for driving lessons, sat down in a car with an instructor and then begun by learning the basics of how the steering wheel and the pedals made it go forward.

 

One more stab at showing you a powerful visual scripter, I'm sure designers will find it easy too but I reckon it targets coders more:

Just go to around the 4th minute, see just how easy it is to create "blocks". It's like copying/pasting from code snippets, only you keep this handy in blocks that are a click away!! I'm thinking, import tween examples, convert to blocks in seconds, write your blocks in seconds. Any personal libraries you keep, or code snippets... you get the point. Zero complication, see for yourself. I'm buying this tomorrow, it looks plain fun.

I'll also learn C# the old fashioned way too...

 

Just a bit of newbie-input here
I started out trying to learn a bit of C#, but was turned off by the slow progression. I wanted to learn how to make a game, not how to program. I'm considering picking up the C# in the future, but I bought Playmaker and I can't praise it enough. After a few months of learning how to use it (and Unity and some very basics about gamedev), I've got an MVP, as well as having made a couple of programs to assist me in my AD&D pnp RP sessions (eliciting much respect from my players!)

I can't speak for other visual scripting systems, but Playmaker's been invaluable for me. I'm still learning a lot, but now I can actually get a lot of functionality running without needing to search the Internet for hours. It's also taught me a LOT about programming logic, I'm sure trying to pick up C# will be much easier now.

OP expressed hesitance to try out Playmaker because of tutorials. There's so many tutorials for Playmaker though, and I expect the same to be true for other visual scripting systems.

 

It is understandable given that most of your time programming won't be spent with the language itself so much as analyzing and debugging your algorithms. Learning the initial steps of programming can be daunting, but once you have the basics mastered you'll find picking up a new language is frequently a one or two day process.

Playmaker's tutorials far outnumber the competition. It has been around for a long time and many developers have released custom nodes to allow it to work with other API's. One example of this is @LaneFox's Bolt (a networking API) nodes.

https://github.com/LaneF/PlayMaker-Bolt-Networking

 

To use a Graham Car Analogy™, that's like saying "I wanted to learn how to get from A to B, not how to drive."

Visual scripting certainly has its value, but as a replacement for a standard coding environment? I don't see it.

You can? I see there are potentially recognisable shapes for familiar developers, but I've got no clue what those are doing from seeing some connected squares.

For reviewing code and design this stuff can indeed be super useful. There are plenty of tools that let you visualise code without having had to create it visually, though. You can have the advantages of both and the drawbacks of neither.

 

Using Visual Scripting can help new users to learn the engine classes in easier way. It doesn't need to know the full names of the classes, because they are visually represented. Easier to remember.

For experience user it can help to create a main logic in a way that is easy to mange, and to recapitulate.

Visual scripting is basically an algorithm on steroids.
If you really want to learn how to program, You must learn to write an algorithm. It's a meta knowledge.

To be understand correctly, I am not an advocate of pure Visual Scripting. I just found it very convenient to use it a lot. I even made couple of projects that are completely made with VS. Not a single line of text code.

Should every project be done only and only with VS?
NO!

Small routines, optimized functions should be written in text code.
Game logic and FSM ( Final State Machine) is good place for VS.

I believe that there is no need to make two opposite sides of programmers.
Ones that use text code and ones that use VS. These two are meant to be used together.

I will use a little analogy to explain it better:
If you can imagine a text code file as a leaf, you can see your program as a collections of a leafs, like a herbarium (herbar) or a book.
As analogy goes, visual part of your program can be observed as a trunk with branches.

For me, if I need to look at a program made couple of years ago, it is much easier to look at a tree with leafs in a glance, then to read the whole book, page by page.

Also, visual debugging of the visual script in real time is an experience that once used, is not easily forgotten.
Here is the picture of applications main logic part, made in Antares Universe Vizio.

 

@kshaja, Oh boy thats a big graph. iCanscript is so powerful that this much big graph can become a small node in it.It's package system makes everything easy. It gives experience of writing a code.
The big benifit of any VS is it helps understand the logic behind the program easily as it is visible. (which is hard to read in code)

 

i can totally seeing myself in this post. I had the same route. picked up some c# books for beginners and didn't really get it. so i switched to visual scripting which thought me sooo much more than every book and now I am fine with c#

 

I will assume that there is such a thing as 'visual people' and 'text people'.
If you are 'text people', maybe this is not your thread, and should be in the 'Text scripting in Unity', debating on whats is the best code editor in Unity.
(Of course this is only for contextualizing purpose, you can be and write where you want, obviously.)

For my side I am 47 years old 'text programmer' with a few languages over the years, now mostly in Objective-C, and Unity. With Unity, first I opted for UnityScript, hoping to someday have something like Quest3D, my favorite visual programming system. (Too bad it's dead. If they had continued to evolve, I wouldn't have changed to Unity.)

That said, for obvious reasons for 'visual people', and too complex for me and personal to explain to the 'text people', I prefer by far the 'good' visual languages.

And within available for Unity, after trying other (PlayMaker and uScript especially), Neodrop's Antares Universe-Vizio is with whom I work. I have developed several relatively complex projects with him, without having recourse to the text at all.

It's not like PlayMaker and others who are intended to be an additional help, or 'feel inferior' in front of the text (no, it doesn't generate code). It is fully comprehensive, powerful and enjoyable. With it you also learn programming Unity in text (there is a 1:1 equivalence with Unity Engine, plus additional tools) only then you will feel too lazy just thinking about it.

There are others like Nodify or iCanScript that looks good. I have not tried them, but I can say that at least one (Universe) is good enough.

(And there is no need to put all in the same graph as kshaja )

 

Most people are "visual" when it comes to things that lend themselves to visual representation. GameObjects that render something in Unity are a perfect example. Certainly representing FSM's as diagrams makes perfect sense. And I'd say that Shader Forge is a good example of a visual tool, since it's output is something visual that you want to tweak in real time.

But anyone who can read and understand the letters in this thread is more than capable of understanding text-based abstraction. Symbols don't get much more abstract than these little glyphs that represent sounds. I don't fully buy the "but I'm a visual person" as a catch-all excuse to avoid text-based abstraction. A node editor is full of variable names, event names, action name, transition names, etc that represent a level of abstraction via text anyway.

There was an early trend with web creation tools (Dreamweaver or whatnot) to try and have "what you see is what you get" visual editors. Those were a double fail in my opinion. It's not an ideal way for beginners to learn, and the visual/GUI parts of the tools weren't expressive enough for pros.

Pros use text editors for HTML, CSS, and XAML because of the degree of control needed. It's a nice idea that you can just drag boxes around to get what you need, but I think that's bad for learning and bad for getting things done in many cases.

 

It is nice that you position that view as a personal one. But you are one person of the people steering Unity development and, if not determinant alone, that view influence does add to the reasons that there's no Unity native visual scripting efforts in sight. That's where I based my argument, nothing personal.

Back to the debate, the goal shouldn't be about learning C#, the focus is about programming games to do fun stuff.
But complying to the driving analogy, I could still propose a driving simulator as a potentially better way: a safer and ideal* environment where you could test all your doubts without caring for impeccable execution, thus, improving faster. I remember how Carmageddon TDR 2000 really did made me more comfortable on the real streets than real practice could (and I never scored a single point outside the computer ). I didn't learn to drive on Carmageddon because keyboard and 15" screen, but I still aquired some aplomb and agility it would take years if ever on the chaotic roads with those expensive lives and cars.
* The driving simulation does not need to offer a 1-1 fidelity to be helpful, the idealized environment is better for pattern recognition and... learning. Without syntax errors and searching the manual for cognitive synonyms of what one think he means, one can walk greater distances sooner. Otherwise, the expectation is of a few years of timid repetitions of a overly scared behavior. Similar games galore.
** I'll grant that how much high abstraction is too high is subjective, but we can agree that we don't want to be purists to the assembly level. This does imply that ultimately some level of low abstraction is objectively disabling to the programmer/designer.

I remember on this forum years ago someone inside Unity on one of those free fun Fridays (or something like that) sketched a visual scripting environment. I wonder how far that went and if there was any ramification.

 

Andy is a product evangelist. I doubt he has that much influence on the development process, but assuming he does it isn't going to be the bigger factor. I feel like those who are inclined to use a visual node-based system are not going to be primarily the programmers on the team and/or are already using a third party solution.

Yes, but how efficient can you truly be at achieving that goal with a visual scripting system? My experience is mostly limited to Blueprint as despite owning a copy of PlayMaker, I haven't put it to any real use.

With Unreal 4 it made more sense to use their visual scripting as the alternative was more involved, but with Unity I simply find C# is the more efficient choice.

 

I can see this being the case even if I still prefer Vizio most of the time in Unity. But as you saw a positive hole for blueprints on UE, there are possible alternative designs (to what I reference my previous post about Quest3D) that I claim could be objectively more efficient if designers improve on design instead of reproducing (like uScript blantly copied Kismet and "forgot" for a while to have input nodes).
Programming with the game running on Quest3D was one of the great boosts to efficiency of that visual scripting environment. Vizio does also magically allow runtime programming but has some drawbacks that I dislike like big descriptive fool-proof nodes (cumbersome on the long run) and link redundancy between procedure call and parameter feed. Vizio's also introduce some performance overhead, but the pros still outweighs this and some bugs.

 

The benefit of a simulator is that it reduces physical risk and cost of practice. Visual scripting does neither when compared to writing the code, and could in fact hinder the latter.

 

That's an analogy. The original also didn't imply you would learn C# turning a wheel.
In the context, visual scripting forgives (as in eliminate) syntax errors and also expose the user to many more situations quickly with it's easily-er accessible command library (like a driving simulator can change scenes), while text scripting hangs you on "hello world" for a while longer.

Your logic implies that writing code is less hindering because writing code reduces physical risk and doesn't cost as much practice. I see how you are confused and connected loosely the words. It wouldn't happen on visual scripting

 

I'm fully aware of what an analogy is. My point is that I can't see how your stated goal - learning how to program things more quickly - is supported by your suggested solution.

No, my point is that there's no risk involved either way. A syntax error doesn't hurt you, doesn't cost anything, and is an opportunity to learn - which is your entire stated point!

For the sake of someone intending to learn how to program, what learning benefit is there to not having to deal with syntax errors? How is a syntax error a "risk" that is to be "reduced" by abstracting away the thing you're ostensibly aiming to teach people?

Again, how is this different to intellisense or similar functions in commonly available IDEs?

Or by "command library" are you referring to supplied scripts and functions? If so then you're again not actually referring to teaching someone to make programs, you're teaching them to use someone's libraries without understanding how they work which, again, doesn't seem to support your goal.

As I said, I do see a place for visual scripting. Getting people doing simple things quickly? Yes. "Teaching" them how to program in general? Not so much.

 

I assume that you can concede me at least this premise?

I don't mean to be blunt, it's a rhetorical question: If you were a machine reading code, wouldn't this imply that what I said?

Yes, you learn how to be impeccable on a very low level of abstraction (typos, grammar nazi level), but you lose focus of your project (I disagree with "no cost").

If I'm right on these samples and I see a pattern, I'm sorry but on your text I can only see points that work isolated from the rest of our argument to discredit every isolated sentence. I can only understand you don't want to debate but defend a traditional point without measuring other sides as deep as your starting position nor letting room to digress to those interested in exploring.
Or I see a need to debug your reading/writing (but I'm brazilian, what do I know?).

Since you equally interpret my argument with inconsistencies, let's leave at this? It is a great distance between our points to get to the middle now. It's a paradigm shift that is taking decades to happen, but it is happening (a very small proof is the importance on UE of kismet and blueprint).

 

I can concede that we're talking about different things. To me, independent of language, "programming games to do fun stuff" isn't something you should take a quick-and-easy approach to if you want to get the most out of it.

Yeah, it's happening because it works really well in some use cases. I myself have made visual systems for specific systems. There are plenty of cases where it is indeed the best tool for the job. By the same token there's plenty of places where it isn't.

For what it's worth I'm not trying to nitpick individual sentences. I'm only quoting snippets to make it clear what bits prompted what bits.

 

I see syntax errors and looking up ways of writing something (sometimes much differently) than expected more of a roadbloack than a risk. It's no physical harm to the game or the hardware or the user.
But coming back to the idea of Bret Victor's video: It can be a risk fo an idea. And in that way i actually do have to agree. Coding really took me a long, long time to get to a point I felt okay with. I nearly gave up often along the path and I am sure I still do a lot of things wrong. Maybe if we do teach programming to children like a regular language things would (or hopefull even are going to?) be different.

Then again I still am all for an additional visual editor. I actually had written up a lengthy post yesterday about how I'd imagine a visual editor at the moment but after checking over the feature list of Antares Universe I think that this might actually already be the editor I've described.

 

If old schoolers usually frown on visual scripting mention because it seems easy, let's face it this way: visual scripting is not easy, it is enabling. You are free from the sintaxe hell (for once) so you can focus on the polishing demands of a different market than it was years ago.

It's almost like a modeler frowning on zbrush because it was not box-modelling centric. We can safely agree that modeling with brushes is not less sophisticated than translating vertices. Actually, its often the other way around: brushed models shows more the professional human intellect than the poly-modeling models.

Although theoretically those that can program on the lowest level of abstraction can do anything a professional acting on a higher level can do, the truth is that with so much on their plate the hardcore programmer wouldn't consider if an animated button is better than a square one with the traditional 4 boring stages. And maybe that new unique button is more valuable in a game than another methodical button.

 

I hope that this tread is not going on code vs visual scripting .
They should be done in parallel!
Some things are definitely easier and more natural to do in code, some are better in visual scripting .

About Unity's path to visual scripting we see that mecanim is their way of doing it.
https://unity3d.com/learn/tutorials/modules/beginner/5-pre-order-beta/state-machine-behaviours
With this new possibility to call snippets of code from a visual editor and state transitions, we are getting near of full visual scripting tool (I hope).

@rahuxx There is a way to make all those block into the one user created block. I use that when I have repeated blocks of code. This big graph is good for me to see the program working in real time, with visual debugging tool implemented in Antares Universe VIZIO.

 

Very rarely do I run into any meaningful syntax errors that are not automatically caught by my IDE (Visual Studio). If anything the majority of my time is spent correcting runtime errors and those are going to exist with visual scripting tools as well.

Visual scripting can play an important role in development, but I simply cannot see it completely taking over. My approach with Blueprint was to create the majority of my logic as custom nodes and then wire them together as needed for each task.

If anything a big part of Blueprint's success is due to how easily it integrates with C++. Not that it completely replaces it.

 

And I'd really hope for this to be the case for a Unity visual scripter as well. The two should not contradict each other but go hand in hand. Knowing Unity this will be the case if there's ever going to be a natively integrated system, though.

 

And if you could code while running the game. Wouldn't it speed up correcting some runtime errors? Syntax error is not the only thing visual scripting can help.


(image from http://www.shaderplay.com/products/nodeflex/overview/overview.html, note that even here the designer is unaware to research Quest3D)

I see a problem: many people consider Blueprint to be the current pinnacle of visual scripting because it's the biggest marketed so far. And when they compare Blueprints to code I'd agree that often it can be less efficient than typing code.
I say it can be better than it is widely known to be (not that it can replace code). I used better with Quest3D, but no one that haven't used it already will give it a try for it's limited publishing capabilities and halted feature almost a decade ago. Anyway, some people may measure the merits of a design only by popular adoption or discredit it by nitpicking something on unrelated. So it's impossible for me to convince you that... ah, nevermind.

Just because most visual scripting environment designers follow the same line, it does not imply that it is the optimal approach. It IS the most natural one. But designing is a process of artificial iterations to improve something in order for men to better use it.

I think what I'm trying to get through is: "Yes, visual scripting is nice for some uses and we all already agreed to it at some level. But wait, there's (or there can be) more to it than what you saw! - Also, currently there's a very nice wide open window for Unity to be the best at it iterating on the flaws of what's already there"

 

I don't know ... I think Ryiah actually agreed with you to a large extend.

Also on a nitpicky note: That picture you are showing there doesn't show only editor scripting but also a lot of texture and/or shader networks. Also i saw a few systems in there that aren't available or updated any more.

Really - no need to get defensive. I actually find this thread to be surprisingly open and friendly towards visual editors. More than I would have expected and I am really really glad about that. Though it might be a better idea to talk about new systems and ideas rather than trying to win everybody over (which just isn't every going to be possible).
What is it that made Quest3D so good in your opinion? I've never used it and I don't know anything about it's scripting system.

 

So here's the thing, for those of us who are good at writing code, IDE's, much less visual scripting systems, just slow us down. And when making real games, you will have developers to write the code for you. So whatever work Unity puts into visual scripting environments takes away from stuff that matters to teams that have developers, which is pretty much any team working on a commercial game.

I understand the frustration. I'm on the other side and would often love to have design/modeling tools that did what visual scripting tools do for scripting. But to do that, it would dumb down the software to the point where people like you would probably not want to use it.

Even with prototyping, a non developer using a visual scripting tool is not going to even come close to someone like me writing code. And long term it's even more pronounced as I can slowly turn prototype code into production ready code as the right abstractions start to show themselves. Generated code almost universally has to be thrown out if you care at all about quality.

So the most productive, sane approach is to just get a coding partner.

 

That is not true.
Of course it depends vastly on what you want to achieve but there are artist tools that are taking different aproaches. And there are also tools that make things a lot easier than the "traditional" 3D packages (meaning Max, Maya, Modo, Cinema ...).
A very good example of a toolset that is super complex but astoundingly easy to get into is SketchUp for example. I saw people without 3D experience pick it up after a few tutorial videos. It might not be a tool dedicated specifically to game art but it's an example.
Modeling in the Unity editor - fast, super easy, and astoundingly mature, already: The "ProTools for Unity" set from the Asset store. You can pick that up for prototyping, Level editing, or even objects. Including texturing.
I've also been told that people who aren't so much "stuck" in the traditional 3D box-modeling way of thinking were a lot faster to pick up ZBrush, which takes a very real-worldy approach to its way of thinking.
Substance Designer is a hell of a lot different from Photoshop and like nothing I had seen before. But the more I use it the more I love it. It grows, gets more flexible, can do a lot of things and is nearing complete non-destructiveness. Which can't be said about traditional Photoshop authoring. Also it takes a different way of thinking. And if things continue as they are right now I am pretty sure it's a big part of the future of texturing.
For characters there's programs like FUSE. I can't say a lot about that, though because I do my own character art but apparently it is there and can save time if you don't need the characters to be super unique.

What I am saying is: There are changes and evolutions. Some are easier some are different. Some work better some worse but they all are important and they all push things further. So I am sure there are ways that don't necessarily "dumb things down" just because they differ from the status quo. They may need to be worked out and they may work better or worse. But dismissing them because of the diffuse feeling of being inferior or unnecessary, I think, may be a little shortsighted.

 

Has anyone given or even implied that as a reason, though? Where are you getting that from? Being "easy" or "enabling" isn't the problem. Being limited or slowing people down to achieve it is the problem.

I don't understand what this has to do with visual vs. written code.

They're really good parallels, actually. Those tools all do an excellent job of making specific tasks easier. I wouldn't want to do, say, organic modelling in ProBuilder, but for level layouts and architectural type stuff it's fantastic. Using ProBuilder I could start constructing levels effectively with only a few hours of practice. The same practice in a fully fledged modelling tool hasn't even got me a solid grasp of the basics. A general purpose modeller I am not, but with the right tools I can easily be productive in certain areas.

By the same token, visual coding for specific use cases can work amazingly well. Like I said, I've written such things myself. Do they turn the content team who uses them into coders? Not at all, but for their given purposes they don't need to do that, and they absolutely enable non-coders to make things that would otherwise require coder attention. Win.

 

First, being pedantic, Visual scripting is not an algorithm, it is a tool for creating algorithms. Second, it's not really "on steroids", it is more like "with training wheels". Since in all cases, it is an abstraction, it is a trailing edge tech. You can not only do more with traditional methods, but you can do it in variety of ways, meaning optimization.

Still, as @angrypenguin and others have said, I agree that it can have its uses for some folks.

 

Having a decent IDE (ie Visual Studio) assists me quite a bit. I don't think I could live without IntelliSense at this point and I was ecstatic when Microsoft released Visual Studio Community.

Visual scripting though definitely slows me down beyond anything but very simple functionality. This is why I mostly relegate it to the status of glue logic. I can write custom nodes that implement the vast majority of the task and simply have the level designers and artists wire up the events that are appropriate.

 

I think you will be pissed to find out that UT employed Emil Johansen AKA AngryAnt who developed Behave the first Behavior Tree extension on Asset Store. After he left UT he developed Behave 2 and removed the original Behave which was free. When I heard the news he was going to UT I thought he is going to help UT to create visual scripting editor for Unity.

 

That's the thing with most visual scripting solutions. Blocks, nodes, event lists (think Kick'n'Pray). That's why good visual scripting solution includes "code block" that let you use arbitrary code for things that are not easy with visual scripting and would be better done in code.

 

all of you posting here about visual scripting, how many actually used it? How many used icanscript from assets store?
Try it and then think again. Specially those who do not know how to code this is great option.

 

You mean the visual scripting asset that is no longer sold? It seems to have been discontinued due to Unity 5 and is only being updated by the community now.

http://www.icanscript.com/downloads/category/3-community-releases

I have used Blueprint though and it is roughly similar at first glance. It is also significantly slower for anyone who can type more than a few words per minute.

 

iCanScript2 is currently in development. It will significantly improve the interoperability by generating C# code directly from the visual script. You can then easily intermix the generated C# code with any other script that you have.

Furthermore, the C# generated files from iCanScript2 auto-populates the iCanScrip2 library. Yes that means that as you build visual scripts, you are also building up your library.

Since iCS2 generates C#, several programming language elements are now directly included inside ICS2. For example, you can create types (classes/structures), public/private variables, public/private functions and their "static" counterpart. The generated C# code is as good as a programmers code and does not suffer performance penality do to the fact that it was created with visual scripting. Once can also start a script using iCS2 and continue with standard C#.

An another important addition is the node with C# source. You can define a node with its parameter and inject your own C# source using the parameter name creating mixes of pure C# source code and visual script code.

Finally, iCanScript2 UX is inspired by Blueprint in some fashion.

We currently have some users in beta for iCS2.

NOTE: iCS version 1 was removed from the asset store until iCS2 becomes mainstream. iCS1 paying customers wil be given a free upgrade once iCS2 becomes available.

 

High performance doesn't necessarily imply clean easily maintainable code. It won't be commented either.

Is this for creating custom nodes? Or merely injecting source? The former would be very useful but the reason people were using visual scripting was to avoid dealing with code. If someone is going to learn how to inject it, chances are good they're already using it.

Sounds good. Blueprint is practically the only visual scripting tool that I was inclined to use.

 

iCS2 is trying its best to generate maintainable code. See the attached image for an example of the player script of the unity space shooter tutorial. It produces the following C# code:

Code (CSharp):

1. using UnityEngine;
2.  
3. namespace iCanScript.Engine.GeneratedCode {
4.  
5.     [iCS_Class(Library="Visual Scripts")]
6.     public class Player : MonoBehaviour {
7.         // =========================================================================
8.         // PUBLIC FIELDS
9.         // -------------------------------------------------------------------------
10.         [iCS_InOutPort]
11.         public  iCS_PulseGenerator pulseGenerator=  new iCS_PulseGenerator();
12.         [iCS_InOutPort]
13.         public  Object bolt= default(Object);
14.         [iCS_InOutPort]
15.         public  Transform boltSpawnPoint= default(Transform);
16.         [iCS_InOutPort]
17.         public  float maxSpeed= 10f;
18.         [iCS_InOutPort]
19.         public  float left= -6f;
20.         [iCS_InOutPort]
21.         public  float right= 6f;
22.         [iCS_InOutPort]
23.         public  float bottom= -4f;
24.         [iCS_InOutPort]
25.         public  float top= 8f;
26.         [iCS_InOutPort]
27.         public  float tiltFactor= -4f;
28.  
29.         // =========================================================================
30.         // PRIVATE FIELDS
31.         // -------------------------------------------------------------------------
32.         private  Vector3 p_velocity= default(Vector3);
33.  
34.  
35.         // =========================================================================
36.         // PUBLIC FUNCTIONS
37.         // -------------------------------------------------------------------------
38.  
39.         [iCS_Function]
40.         public  void Update() {
41.             var theAudioSource= GetComponent<AudioSource>();
42.             p_velocity= maxSpeed * new Vector3(Input.GetAxis("Horizontal"), 0f, Input.GetAxis("Vertical"));
43.             if(Input.GetButton("Fire1")) {
44.                 if(pulseGenerator.GeneratePulse(0.25f, true, true)) {
45.                     Object.Instantiate(bolt, boltSpawnPoint.position, boltSpawnPoint.rotation);
46.                     theAudioSource.Play();
47.                 }
48.             }
49.         }
50.  
51.         [iCS_Function]
52.         public  void FixedUpdate() {
53.             var theRigidbody= GetComponent<Rigidbody>();
54.             theRigidbody.velocity= p_velocity;
55.             var thePosition= theRigidbody.position;
56.             var theVelocity= theRigidbody.velocity;
57.             theRigidbody.position= new Vector3(Mathf.Clamp(thePosition.x, left, right), thePosition.y, Mathf.Clamp(thePosition.z, bottom, top));
58.             theRigidbody.rotation= Quaternion.Euler(0f, 0f, iCS_Math.Mul(theVelocity.x, tiltFactor));
59.         }
60.     }
61. }
62.  

Each node and port has a description text field that will generated in the source code using Doxygen JAVA syntax if provided.

Visual script does have an advantage of allowing to see the big picture and a mental image of your script. Mixing C# and visual script is a nice combination especially if you want designers to modify the high level and programmers to create the detail code.

All code generate with iCS is automatically included in the library of iCanScript and this for pure visual script as well as a mix of C# and visual script. (see the tags in the generated source code [iCS_Function]/[iCS_InOutPort]: these tags tell iCS2 to pull the code into its library).