Unity is really missing a native Visual Scripting Tool

Yet very few small teams have released anything. But 100,000+ games in Unity. Wonder why? Sorry, not buying. When you get past demo stage, that's when you find out what is absorbing time.

 

Mobile games.

 

I have tried UE4, beginning with the UE4.0 release. I have over 30 years of programming experience, and have used C and C++ for more years than I have used C#. But even in my case, I have to admit that using C++ in UE4 is more effort than using C# in Unity. C++ in the latest versions of UE4 is better than it was in the initial UE4.0 release, though. For example, UE4.0 did not have hot reloading of code, and that was annoying at the time.

 

Can't wait for native visual scripting in Unity. We would use that bad boy all day long. I don't want inefficient asset store hacks with weird design.

 

@hippocoder

https://wiki.unrealengine.com/Category:Games

I know of a metric ton of "PC / Console" games getting released from UE, also it seems that a lot of AAA / AA / A and lone wolf PC creators seem to use it.

This applies to @ShilohGames as well, I won't deny in the beginning it was a little "rocky" and in several cases a complete PITA.. But it's had a couple years refinement and in many cases find it quicker / simpler, as much as I love Unity and I both think they're great engines.. UE is today an actual true viable competitor as opposed to pretty much anything else.. Even 2D games are starting to take off..!

We've never had it better and they both can learn something from each other, I personally like the BP system in UE and it's saved me a metric ton of time. So has the game framework.!

Some more quality game demo's in Unity would be nice as well, did you know Ark survival was built atop of the shooter project demo made by Epic?

 

Jesus, somebody actually thinks that it's easier to analyse the code than a visual representation of it?

Code analysis is all about finding the hidden pattern. Every system just consists of an intertwined bunch of repeating patterns (conceptually taken from OO programming). Every time you have to sift through somebody's code you have to waste some time to understand what on earth it is that they're trying to do. They have differently named parameters, their layouts can be disturbingly different, they might just fuse/inline another pattern instead of keeping it functionally separate, to save some stack pushing time. They trick around to "save time" but only trick themselves, because in the next compiler update all that "speedup" stuff might already be formalised at compiler optimisation level.

It's tiresome to have to spend time analysing yet another simple piece of code because it's the same darn pattern X written in a slightly different way.

Nobody can seriously think that they prefer to waste time on untangling all this mess instead of having a proper encapsulated graphical formalism that enforces proper OBJECT-ORIENTED programming?

Frankly, in this day and age, "object orientation" is like an anecdote, it's supposed to be there but you can't even grasp it for all the clutter. I'm more from the Java side of things, but also there people trick around to get away from the GC overheads, basically in parts trying to return to C-like coding style with unsafe buffers and hardcoded struct offsets, to handle massive data throughputs.

 

Hippo, I just feel really sorry for people that have to write screenful of spaghetti to make a simple countdown timer, just because nobody gave them proper tools. And the reason why they don't have proper tools is because someone somewhere got overly enthusiastic with visual programming nonsense.

 

But who and / or what are they doing that with? I know in UE I certainly don't have a screen of mess for a simple timer..

I honestly can't remember much about playmaker, as far as I remember I preferred to code. But that might just be me..

 

The screenful of mess for a timer was actually from early official unreal demo, which could've been unreal 3.

I remember thinking "who in their right mind would work this way" and being surprised at how proud the guy presenting the demo felt after developing a system which will waste people's time due to being inefficient.

Your earlier controller demo, by the way, has few problems compared to code - I need to zoom in to see what it is doing (also, even when it is zoomed in, the text is unreadable), and people won't be able to copy/paste it. Basically, inconvenience after inconveniecne.

I can't completely write off programming visual assistance tools, because there are two instances where they are useful in context of UE4 (behavior trees, and making animation controllers), but the system falls flat as soon as you need to to write anything above simple. Basically, text representation most of the time is more compact and more expressive than blueprint noodle soup.

In addition to that after all that time blueprint editor still feels clunky, and it is quite obvious that nobody ever bothered to speed up working process.

Frankly, I just felt disgust every time I had to work with blueprints in UE4.

 

If they do get around to making a visual scripting system, I just pray they wait to do it until AFTER they upgrade the Mono version. If they start writing the whole thing in .NET 2.0 and then have to constantly be playing catch up with the regular API, the Mono update will never happen.

 

Well firstly, if it's UE3 you'll probably be talking about Kismet which no it wasn't great but things had moved on over the last decade. On the "readability" y'know I could just scroll in further on the BP editor and take more detailed screenies, or you could just move the uasset file or I've seen people say they copy and pasted to notepad.

The whole point of BP's is to be smart with them so you don't create "noodles", I'm not going to implement an MP framework via them but for most game logic I've found it actually fine. Used it for Enum selection wep's via constructors / MZ flash / particle prefabs and basic level logic / TOD / Interaction etc. some of it I derive into C++ and vice versa. Also to say a fair few have made games with nothing but BP's speaks a fair bit about them..

I honestly don't get what the problem is, it's as simple as it possibly could be and powerful to boot. So I guess we'll agree to disagree on this one..

 

Clunky/slow/mouse-centric interface. Needs major ui speedup and way more polish. If you could, say, create that entire controller blueprint tree in 2 to 3 seconds, then I would definitely investigate them, because the creators of blueprints would obviously be onto something. Or if you could type function text within a nodes. As of now it needs improvements and is not good enough.

Fine with me.

 

It has been just 2 years. Ppl are still working on it

 

For one of our current projects the developers tried using PlayMaker for the first time so that my colleague and me could also prototype gameplay into the project. We can both script a little - he probably a fair bit better than me. Ultimately though, this turned out to be a really great addition so far. It is really fun to use and makes prototyping a faster task than if I had to remember all my scripting capabilities that i didn't use for 9 months again.

So yes. I absolutely agree - a visual scripting addition that is native to Unity, works reliably with updates and is performant has the potential to increase accessibility a lot. And it's fun and fast.

I was really excited when I saw a small preview clip in the hackweek trailer. This can't come fast enough for me. Until then Playmaker is more awesome than I expected (at least if it doesn't break over project updates).

Well, I am an artists first and foremost.
I've had a few basic Java programming courses in university. I also taught myself OOP with the help of several books and tons of Unity programming training videos. I can script my way around a lot of basic problems now but I tend to forget a lot if I don't use it.

Then we had PlayMaker as visual scripting tool as mentioned above. And while some things probably are achieved a little more direct in script - often it is a matter of different thinking. If you can encapsulate visual logic blocks or programm (or have programmed) function blocks yourself then it's not so much of a problem, really.
The same goes for code as for visual setups. Comment and structurize.

Same difference with Photoshop and Substance Designer. A nodal system for layer/matrerial setups felt very alien and weird to me at first. I knew it was capable of awesome things but it felt weird and slow. That was because I was used to my other way of thinking. After some time the real benefits become more apparent. And with everything (back to scripting again) one system doesn't completely replace the other.

Please don't call something that just doesn't cater towards your way of working as nonsense. It is not. And I know programmers who are very positive towards PlayMaker and use it themselves now.

 

It is. By catering to only one group visual scripting fails to deliver to another group that could use it. And that's a problem.

Why can't a programmer write visual programming script as a text?

Blueprint node network is not very different from, say, common lisp code, except it is artificially restricted to cumbersome input method. And that's why I think the whole idea is bad. Instead of providing alternative input method for traditional language, people create a system from grounds up that is artificially locked into one way of working with it. That's the issue with visual tools in general.

 

I'd imagine it's because writing the links between nodes as text would requiring typing out an ID for every node and putting a bunch of "goto" statements all over the place referencing those ID's, which does not sound fun. Devs freak out enough when they see a single "goto" in their C/C# code; they would mostly have heart attacks if they had to deal with an entire language based around goto.

 

Not really. It's not supposed to be for programmers, for a start. It's intended design is for non-programmers. Next you'll be saying photoshop is flawed because non artists suck at it.

I understand asking for an extension to the features of visual scripting, ie being able to script directly inside a node, but that's a feature or extension that improves upon an already perfectly good concept used by thousands in production across a wide range of engines. For now in UE4 or Stingray you create extra nodes in C++ or just inherit other premade node graphs.

 

That have to show up in every thread concerning visual scripting for the sole purpose of shooting it down. I understand that some don't like it, but there are apparently enough people using it that Unity has decided to build their own.

That's not to say those who dislike it don't have some good points but some of them could be applied to normal code too.

 

I think everybody has this need to be right... right? Visual Scripting is not a noob feature, c'mon, there's some better argument than that. Programmers spend years and years coding, so of course they believe coding is best; the question here is not "what is best", but to show that many workflows actually work, people. Visual Scripting is awesome. If you are a programmer and disagree, that's fine, but odds are you've never actually used long enough without saying "I prefer code, I prefer code".

This argument that Visual Scripting gets very messy is lazy. So you do not have to spend the time to organize your code and scripts? You do. And many times your code gets messy, you get bugs and you don't know where they are. Same thing in VS, just the same. VS has performance issues? Have you had any? Is it very common? I think most of us speak and refute ideas without actually knowing. And just because your experience with VS - or with code as well - was bad it doesn't mean the tool is bad. But well, whatever...

Options is the key here. Designers do NOT have a native option for implementing in Unity, besides learning C#. I'm not saying learning it is bad, on the contrary, and VS DOES require you to know programming logic. But options are better than no option.

 

Umm... collapsing blueprint into function can be done automatically and would result in fairly clean code. Lisp-like.

"We need tools for non programmers? Let's build a tool only non-programmers can use!". Because screw logic. Totally the best, most reasonable approach.

I don't like half-assed solutions. Visual Programming is a half-assed solution. It is not even a "good enough to get the job done" solution. If something better shows up, I'll support it.

---

I'm done here.

 

The way I see it, either way more of my screen has to be taken up by a visual scripting tool to perform the same functionality, as has to be taken up by code... or the node is doing a bunch of work for me. I don't like when it does a bunch of work for me, because then I lose flexibility and control over performance. (Unfortunately, that's the big problem with using Unity - lack of flexibility and control, which is why I mostly write my games at a lower level.)

Still, that's the basis of my dislike for visual scripting: performance and lack of flexibility/control. Too rigid for me.

And... my interpretation of it is that it is messy, whether that's a "lazy" argument or not. I don't want to have to see lines connecting all my function calls. If I call a node from several places, I have to see lines all over the place. In code, I don't have to see lines. I can do a nice CMD+Shift+R and see a list of all places the function is called. And when I'm not seeing that, my screen doesn't have to be filled with lines going all over the place.

Since I hate it and don't use it, this may not be as big of an issue as I would imagine it being. I've only used it minimally.

If Unity added visual scripting, I'd be very unhappy if they tried to force me to use it for anything like Unreal seems to (procedural meshes for example, though perhaps they changed that by now).

With that said, I can't offer a compelling argument not to add it to the engine for designers provided that it doesn't force the programmers to work in a different way as a result. I certainly wouldn't want designers who work with me to use it, and pollute my game with whatever nasty code is likely generated by visual scripting tools. I'd create a custom system that allows them to do the things I need them to do. But that's just me. For Unity, it may make a lot of sense to add visual scripting. And so all the power to them if they want to.

 

But then you have no ability to "rewire" anything; Lisp by itself doesn't have the state machine aspect of a node graph, where each node is a function but the inputs and outputs are routable. I mean, you could make a state machine in Lisp, but it's a lot of extra code... a "convert directly to visual nodes" language would have to be based on FSM's.

 

I don't either but, rather than present the same tired arguments for why it should or shouldn't be made, I'd rather see discussions on ways to improve the currently existing solutions. At least something productive would come from that.

 

That's some really nice feedback, thanks for sharing. The most valuable here is to hear everybody's experiences and take lessons from it. And I totally agree, even though I'm no programmer: most programmers see C++ as a headache. Solely for coding, Unity is better, or better saying, C# is better. What I think is in engines like Unreal programmers have a good tool - even though not the best - and designers have a great tool to work with. In Unity, only programmers have a good native tool.

 

@neginfinity

In YOUR opinion, there's many who do not struggle to get the "job done" with BP's. I know I certainly don't.. Ultimatley depends what the "job" is..

@JasonBricco

In UE not only can you code your own VS nodes, it's all compiled down into native C++.. There is no rigidness / inflexibility and / or performance loss. Question is, would Unity's implementation be the same?

@Harry3D

Things have changed dramatically since UE 4.0, Unity wasn't always the engine it is today either..

I might be getting old, but have you guys ever used XNA? Torque? Custom frameworks, what we have today makes life so much easier and it feels some times either some of these opinions are baseless or completley nit picking to the point of it not really making sense. It's ironic, because on the Unreal forums it's the exact same but the other way round ..!

I don't really have a personal preference for engines, they are tools and today they don't want to make me set my machine on fire.. That's progress in it's self..!

 

@JasonBricco

Agree with you, in the sense you have every right to use whatever suits you best. That's the point. It's up to the engine to provide tools that many people can find appropriate for them. And I agree that Unreal for example has to balance VS and C++ better than it has done. But again, calling VS as messy or other things is just a matter of perspective and experience. Some people have a messy experience with VS, some have with code. It does not have to be a one-suits-all solution, right?

And if you are a programmer, you spent years and years learning that code is the best option, so that's most likely what you're gonna think. But not everyone has to agree with that.

 

The greatest benefit of Visual Scripting is to code in a system (a language, if provided) when you can't devote your time to learning a new system (or language, if provided).

I've done c# for years... but as soon as Shaders are concerned, I rather not touch it with a ten foot pole.
So, I gladly use a visual scripting system like ShaderForge.

Its just a matter of what your knowledge is, what your time constraints, and your desire to learn another language.
Some love to learn it for the added power it might bring, the rest might not get as excited at the prospect, either because of time constraints, or just plain cause its would be an impedance.

 

I think UT doesn't like rendering asset store products obsolete.

At any rate, $60 is not that much for the options available right now.

 

So you're saying it isn't rigid/inflexible because you ... code the nodes. Well, yes, it wouldn't be in that case because you're programming, not visual scripting.

And now that I think about it, that's a fairly interesting idea actually. Programmers create nodes that designers can make use of.

I stand with my view of visual scripting in of itself, but this idea where programmers can work with it in this way is interesting. I wouldn't use it myself still, because why would I want to program a node over just... programming directly? The only answer I can think of is if I were building tools for artists/designers to use, not for myself. Otherwise, that's pretty much what the purpose of functions in code is: make reusable systems that you can call multiple times. Not sure what visual scripting offers me over functions, other than needless visual clutter.

I'm one of those people who is making claims about it without having taken the time to learn it. So I'm really trying to say why I haven't bothered to take the time to learn it, but it could be that there are many things I'm missing about it.

Yes, "messy" is rather subjective. I perceive it to be messy and I perceive code not to be messy. That doesn't mean someone else will agree with me on that. I wouldn't suggest that anyone should agree with me on that, either.

I do think my productivity would fall considerably if I decided to use visual scripting, though.

 

Well for some things as already said, it's far quicker to use BP nodes in some scenario's than it ever would be to code it.. If you can build a camera controller / player movement / projectile spawn and basic combat system in under 20 - 30 minutes than I conceed the BP system looses it's edge for programmers. A lot of functions work like Macro's which allow you to just plug one or two nodes in for multi-functionality tied to things like the input system..

Also the BP system is built upon an extensive game framework that's built by AAA engineers who work on games and engines, yeah I'm sure there will be oversights in places although as much as I have faith in my coding abilities I'm not pretending for a second I know more than Epic on their many subsystems..

That being said, it's not a one or the other solution.. If you don't want to use visual scripting, then simply don't.. Personally I use a hybrid, it has it's benefits.. It's something you try and see if it works for you, then again I don't find Unreal particularily difficult to code in either.

When it comes to Unity, I find C# so simple (With Unity's way of doing things) that the only way a VS system would appeal is if a lot of it was macro based, as in I could make a char system / tod / procedural generator / wep system in 20 nodes a piece or less. I've used other "VS" systems, they were more verbose than just coding the damn thing which I'm not sure who that appeals to.

I ultimatley believe it was made "originally" for the sort of programmer / artist layout of larger teams. But then it became vast enough to support full games and some have made their game that way.

I'm not saying it's a coding solution for all, I'm not saying it's the best thing ever.. All I'm saying is it does have a couple of fringe case pro's that I will take advantage of, because it makes my life easier.

 

I don't understand how this is supportive of visual scripting. It sounds like you're talking about the fact that nodes exist that do a huge amount of work for you already.

Couldn't the engine have done this same huge amount of work for you directly in code, to where you can do the same functionality in code in that same time frame using what the engine offers (in terms of functions, macros, you name it.)?

I really feel like the only advantage (assuming that the developers of it didn't prioritize the visual scripting system to where it has way more available functionality than the engine offers directly through code), is to give non-programmers a different way to code that may be more compatible.

But I'm not sure why I'm actually arguing about this. I guess it's because I don't understand. I probably do understand for the case of Unreal Engine - they prioritize Blueprints to the point where they put a lot of functionality into it that isn't available outside of it. But couldn't it be available outside of it? Why isn't it?

Is there something inherently about 'visual scripting' that makes it so visual scripting is the only way to have this productivity? I'm failing to see it.

 

Well the BP's have to come from code at some point, so there isn't more in BP than what's in the engine.. I will say the documentation is far better for BP's than the C++ API is.. Which is a little frustrating, but it's getting better..

You've pretty much figured out the answer, there are C++ Macro's built in which you can use. Although you have to be fairly involved with the API to make sure custom code will seamlessly integrate which isn't as simple as you may think, or you may end up reverse engineering said macro's. Although of course it's something you get used to, with BP's there are no issues as it's all based on a standardised framework where you just plug one into the next, it even gives you hints as to what the next node should be.

Even from a debugging / compiling scenario it's much simpler and this is more towards Unreal specifically than Unity, it uses a runtime flow system to tell you exactly where the issue is. There's relatively no compile time whatsoever (which using VS and UE is quite hefty) and no chance of crashing the engine if you miss a null PTR or something (as it won't let you compile).

The whole point of it is to be simple, quick and slightly idiot proof. So there's many reasons to use it, for e.g. as a prototyping tool, as an artist / level designer tool, as an AI tool in which state tree's are infinitley simpler in VS nodes with flows just like Mecanim and it's animation flow system.

Where it does become more interesting is how it applies to Unity, for UE it's a given it simply makes life easier. But for Unity? Well, I'm not entirely sure.. Because firstly, whilst compile times aren't instant they don't take long either.. The code base is fairly fool proof, debugging log's are definitive and fairly explanatory in some cases and you can easily copy and paste code, change a couple of things and it'll work..

Where it could come in handy, is again things like AI via flow nodes.. But an extension of Mecanim would probably do the trick, as opposed to a full blown VS solution. Also it simplifies and removes the effective need to reverse engineer game frameworks etc. I suppose the rest is preference?/! If anyone can think of something else, it would be interesting.

 

Is it possible yet to make UE4 games without Visual Studio? Entirely with blueprints and the editor, including the final build?

 

Has to be possible without Visual Studio if there is a Mac OS X version of the editor.

 

I asked this question before some time ago and I remember only getting a couple responses. I believe ShadowK provided the best examples.

 

Just searching for the typical features you'd need for a game should give you a good idea. There are ways to spawn things in the world, to receive input from the player, to handle an in-game HUD and menus, to save the game, etc from Blueprint.

https://docs.unrealengine.com/latest/INT/Gameplay/HowTo/SpawnAndDestroyActors/Blueprints/
https://docs.unrealengine.com/latest/INT/Gameplay/HowTo/RespawnPlayer/Blueprints/
https://docs.unrealengine.com/latest/INT/Gameplay/HowTo/SetUpInput/Blueprints/
https://docs.unrealengine.com/latest/INT/Engine/UMG/index.html
https://docs.unrealengine.com/latest/INT/Gameplay/SaveGame/Blueprints/

 

Okay ... what do you propose as a better solution, then?

(edit)

Visual scripting is great. Programming takes a very specific way of thinking and sometimes a very specific way of setting up syntax that is apparent to someone who does it all the time. But for people who do not write code on a daily basis these are roadblocks. They take up time and you have to bother a programmer for help or to do it for you. They have their work to do as well. It sucks.
Visual scripting can take away these semantical problems because a node shows what it is capable of and only lets you input the correct variables.
Nodes can encapsulate common setups into a reusable block programmed by someone who knows how to set up and optimize code (when I do it it works but god forbid a programmer should check more complex code of mine for being performant ).

People have different ways of thinking. Some are much better when they see a visual flow. Some like to read the code. Some groups of people think differently than others - be it because of the things they've learned or even how they like to learn. Some learn better with videos while others learn much better with books. Is one better than the other? Hell no! Both are diferent and either one works for a person or they complement each other.


I am glad Unity try to incorporate it into the core engine. We need evolution. I think it is the right approach but if it isn't we still need to test and improve upon it. Otherwise we'd be stuck with the status quo forever. And I cannot think of any reason why this should ever be the best option.
I mean if we'd stuck to the first most performant working structure in programming - wouldn't we all still be programming in assembler language? Isn't C# scripting already an evolution of programming into a more easy to understand and readable form? If visual scripting was a bad way of progress what would be better?

 

If nothing else good comes out of a visual script editor, at least we can hope the editor GUI team will be pushed to make the interface API better.

 

"Trying is the first step towards failure" - Homer Simpson

 

...
​

 

Does it? Can I compile a working OSX build of a Unity game from the Windows version of Unity? I honestly just don't know.

I googled it a while ago and only found responses along the lines of "that's not possible".

I was naively assuming they already had basically all the functionallity covered ^^. I was thinking more of "technical" limitations like "You need to have visual studio installed to click build and get the .exe file for your game".

The thing is, I never used visual scripting and I'm not super keen to use it, but I seem to be too dumb for Visual Studio and C++. I tried, but I was unable to get C++ compilation to work with Visual Studio, back when I wanted to learn UE4. I tried again to use Visual Studio for Unity coding very recently, but I just can't solve my error messages, I have zero interest in spending time fighting with an IDE, and it would take me too long to do a system reinstall to see if that works (I have audio stuff that literally takes me more than a full day to install). So I feel like there's no point for me to try doing something with UE4, unless they pave the path for a 100% blueprint workflow.
Also @ShadowK mentioned compile time differences between Unity and UE4 and I rely massively on trial and error. I wouldn't be able to get much done if I had to wait a long time whenever I try something out.
It's possible that once I try to do anything serious with visual scripting I'll be so annoyed that I'll say "F*** this S***" and give up. Can't know that without trying. I might even like it, who knows.

 

If you read my previous posts - do you really think that a Homer Simpson quote is my true and unsarcastic opinion of trying new things? Just in case the three emojis weren't hint enough.

Seriously - I like what Adam Savage once said about failed builds and projects: "A failure is never a bad thing to me. It is a step that was important for the ultimate outcome of the thing I was trying to build in the first place. From every failure I make I learn a lot of valuable things that go into the next iteration of my process of reaching my ultimate goal. A failure is never a bad thing but a necessary step on the way to success and thus it is also never a waste of time." I paraphrased it because I don't know in which podcast he said it but I love that quote. It is so true.
So without any sarcasm: Even if visual scripting turns out to be a failure it is one we should dare to make because it might result in a better iteration. There.

 

Failure is data for the next try.

 

Someone converted the entire multi-player FPS demo from Epic into nothing but BP's (with tutorial), it doesn't really get more complicated than that from a basic "what you can do scenario". The only thing I've never tried BP's with is heavy event driven data from let's say a dialogue system and / or mass inventory class. Cool to use as item prefabs though..

In regards to compile times, it really depends what you're doing. Firstly you don't have to use C++ again there are such things as Skookum which is a scripting language, it's well documented and often updated. Secondly if I was to suffer project compile times every time I updated a paragraph of code I'd of thrown the PC out the window. So luckily there is a hot reload function that will swap out the .DLL instantly.

That being said the hot reload function has on occasion been a little bit buggy.

Not trying to sell Unreal here, it is a lot more "faffing about".. Even things like restricting project texture sizes you have to mess around with .INI files and knowing CVar's helps as well. You do get the feeling it's a "AAA" engine even if it is a friendly one.

Although it's nowhere near as bad as some make it out to be, if Unity does it for you though then you're set.

 

Thanks a lot for all the info! A complete BP example project sounds like a great opportunity to sift through and learn from. At the moment I'm not "looking to switch", I'm quite happy with Unity overall. But I was thinking it might be a good time investment to do a small project in UE4 some time in the future, to broaden my horizon. And most importantly to get a minimum level of UE4 gamedev competence, that would allow me to be better able to do freelance 3D art jobs for projects using UE4. I reckon I don't need to touch C++ to understand the art asset side of working with UE4.

Edit: I haven't looked into Skookum, but I wouldn't mind learning a new simple scripting language. I'd imagine some things would be a lot easier to do with that than with just visual scripting. A combination might be cool, where you code your own blueprint nodes in a scripting language and then use it in a blueprint.

 

You are an exception. I find BP lot more fun than code, and you can use both, BP and C++ for complex tasks.

 

I understand most of the statements and opinions, but I think many of you are missing one point. VS is not a tool made for programmers, not primarily. Tim Sweeney, founder of Epic, said that himself about Blueprints. It's made for designers. Programmers will mostly think code is best, and that's okay. That's why you have C++ in Unreal, and a good transcription between C++ and BP. I've read hundreds of posts in Unreal forums about C# vs C++, and that' a whole other discussion. Many think C++ sucks, and for many others it's the ultimate power.

It's like programmers cannot accept that there's a tool for designers. But designers are meant to create gameplay. In the old days, game designers were all programmers, because they had to. Not today. Coding is a great knowledge even for designers, but not mandatory.

So that's all the point. There's no reason arguing C# against VS. If you wanna code, you wanna code. Designers do not have to. This thread is about empowering designers the same way programmers have the power with C#. And I think this is one very correct way to approach game development: designers have VS to prototype and implement gameplay, and programmers have code to do more base and robust programming, making tools and systems so that designers can make more gameplay.

 

Unity's missing much more than a visual scripting tool. Such as better input, better terrain (possibly voxel-based so making caves and such is easy), better profiler (as in, causing less overhead so it gives more accurate values), bsp/csg-like level editing for either prototyping or making levels for games that don't require anything more than standard bsp-quality levels. Those things are far more important than visual scripting, though I agree it would be nice to have it.

Plus, I don't get fascination with node-based systems for visual scripting (they make sense for things like Mecanim or Shaders because you rarely need to analyze flow of them). It's clumsy, messy, nodes get lost or you can't easily look at the flow. Block-based visual scripting is much better. Those who claim otherwise obviously never used Scratch, Stencyl or Blox.

Block-based visual scripting is beatter as it's close to real code, but at the same time easier to manage as it's drag&drop so there's little chance you make a typo, forget a semicolon or things like that that are all too common in the "real" programming.

 

True.

That.. plus, you can transcribe it to any other language. So all you'll Ever need to learn is Blocks! and use everywhere, if you have a way to transcribe them to a system.

 

Flow charts do a pretty good job of showing flow...