为什么unity没有可视化编程工具？Why does unity have no visual programming tools?

像unreal和autodesk的stingray都有可视化编程，为什么unity没有，这可以大大提高我工作效率；也许你们说可以用playmaker或者uscript，但是他们更新的实在太慢，还有不少bug，所以希望unity公司考虑一下这个需求。

Like unreal and stingray Autodesk have visual programming, why unity no, this can greatly improve the efficiency of my work; perhaps you said you can use playmaker or uscript, but they are very slow to update, there are a lot of bug, so I hope unity company to consider this demand.

 

https://unity3d.com/unity/roadmap

--Eric

 

Because Visual Programing = dumb.
Nothing in life is easy. You want something? Work hard for it and earn it.

Yeah Visual Coding may vastly improve things speed wise, but guess what? Somebody has to code the functions, etc. So what happens when you want something that's not covered? You've wasted time you should have learned coding, to make a tool do everything for you so now you're lost on how to actually make things work.

Not hating on you for wanting to use it, just saying, the best route is to just get nitty gritty and learn to code, yeah it sucks when you don't understand it at first. But once you do, it's worth it.

 

What? Those functions could just be written by the user.

 

Not if they don't know how to code and strictly rely on visual coding lol.
I mean it may just be me, but I actually even find visual coding harder.
I tried it once for like 2 minutes and didn't even know how to work it. Buy no loss to me lol.

 

I think the point he's trying to make (at least with something like UE4's visual coding) is that at some point you will likely need to understand the implementation of lower level visual scripting blocks and what they mean. At that time what you will be looking at is code not a pretty box. So in the end if you'll most likely need to learn coding anyways you might as well do it up front.

I think the reality is a bit more nuanced than that, sure on the basics of a coding language you will need to learn what casting is, what loops are, etc. regardless. Then after you have the base language down you will need to know the API's/libraries and what they do. You will need to learn the different overloads, what they do, what they don't do, the performance, etc. You can learn it either way but the bottom most blocks are always going to be code and not a visual tool. For many things you might get away with for awhile not having to leave the visual node world but eventually you will have to, to get serious big projects done. This isn't to say you can't spend a high % of your time in the visual node world but some % will have to be in the coding world. I think his sentiment is if you'll have to bite the bullet eventually then you might as well do it up front.

To be honest I'm more neutral on visual scripting. At least in the coding world to me they represent the same stuff and I don't see it as a win or a loss, just different. Use whatever you can wrap your head around the easiest most of the time but don't live exclusively in visual node land or you will always be at the mercy of others when things go wrong.

In other areas the win is a little more clear (i.e substance designer) because the underlying datatypes you're manipulating are narrower (textures). When you can specialize that much and have a datatype that is easily visualized at least to me visual nodes make total sense. When your as general purpose as a coding language to me it's just another way to represent the same thing and making blocks for all feature's of a language don't always make it easier to understand.

For solo artists that never intend to learn the innards of a language, if it enables you to at least get a bit deeper with less frustration then go for it. At some point you will encounter an issue though that requires that understanding whether your using visual or textual coding and most likely the answer will only be found by looking at code.

 

I honestly don't think anything note-worthy has ever been made with a visual programing tool.

 

Although to be fair, the visual node programming is a relatively new phenomenon. Yes there's been UML diagrams before it or the Rational Rose's of the world that way over promised writing the code for you. In the web world .Net forms or various workbench type things for designing the UI. These were all hokey and only partial situations.

However, the top to bottom "nodification" of a C-style language to me knowledge is very new, so obviously its too new to have anything great made with it. Recently, it seems to be a trend. Whether it's a fad or here to stay is hard to say. That being said if it is here to stay, I have no doubt that something of note could be made with one. Whether people actually want to are not is a different story.