[Visual Scripting] Unity Technologies : can they buy an external tool?

Hi,

With the arrival of a 'new player' on the forum, i ask myself the possibilty of a redemption of a solution (out of the box) by Unity. Can this be done?

 

I haven't seen or heard of them ever buying an existing solution and integrating it to Unity. However I've seen them hire several asset makers in to their team to do similar or same stuff their asset was about.

This is what I have been always wondering why aren't they hiring the skilled people and integrate their asset (more native integration with the help of core engine/editor team). They have offices around the world and working full time with x asset would make them even better. Most of the guys are pretty skilled in general so they could work on various other things too outside the engine itself.

 

Do you think x Asset makers are jobless?

 

No, but I also don't expect all of them to have one or be more happy with their existing job than Unity job might be. Remote working and/or part time working is pretty common too. Assets usually provide "limited" amount of money after initial launch season/sales compared to steady work as they can get obsolete in future versions or lose appeal.

 

This tool is a copy of UE4 Bluprints it seems, too bad it is not integrated in Unity editor but it seems to be a stand alone tool.Anyway there is very good ones like Uscript or NodeCanvas that are cheaper.
Unity should buy Uscript and ShaderForge.

 

I'm not sure if they can or want to officially integrate any stuff that are nearly carbon copies or heavily inspired from other engine interfaces and stuff cause it could possibly lead to other problems.

 

You know someone is "not a real programmer" when they think visual scripting is a viable option for professional work.

And by that I mean they don't have a computer science degree.

 

Honestly these kind of tools are not meant for programmers. They are meant for the level designers themselves. Ideally you would have a programmer code something like an AI. And then you would have a level designer use visual scripting to triger the AI when for example the player enters a trigger.

 

Yes, maybe, but i'm 'tolerant' with those who export/generate code/source, like uScript.

 

Exactly. It's intended that programmers create custom nodes and everyone else makes use of them.

A computer science degree does not make someone a real programmer. Computer science is one of those interesting fields that does not require a formal education in order to be competent. I have met a number of people with degrees who were far worse than those who didn't have one.

 

I'm sure Epic has a few "real programmers"

Anyway everyone who has a Computer Science degree would have done flowcharts yeah?

I think visual scripting is a powerful tool if used correctly, like when the player presses a button a door opens or when a monster dies play a random death animation. You wouldn't do something like write a networking system in a visual scripting tool that would be done in code but for lots of things it makes sense.

I think that Unity could redevelop mecanim as a visual scripting tool, actually ICode already does that :
https://www.assetstore.unity3d.com/en/#!/content/13761

I think they should change it a bit more but the general idea is sound Mecanim + Unity Events + Sequencer could make a really decent visual scripting tool, but for some reason it just hasn't happened yet.

 

Visual script for me is a pain.. it's not "no more programming" by a longshot. And all the fiddly mouse clicky connecting of boxes just to implement really basic stuff you could've typed in 1 second, makes it a chore at times. And trying to 'follow' program flow based on a graph (maybe due to organization mess) is not easy. Hmm let me see, I need to trace my eye along this bendy line to get to the next step. What I think is really needed is a whole leap upward in terms of higher-level development where the computer does more of the work of automating and generating the logic that's needed to pull of the 'vision' of what you want to happen.

 

I am actually considering a visual scripting asset, but not sure which one. I am not a coder at all. I can write flow charts and give a passable explanation of what I want to my programmers...and they get it, but I want to be able to test small things, like triggers, without having them write a little code every time I need something.

The perfect tool would be something I can use out of the box for some things and then ask them to create nodes I do not have. Also, it needs to work with their C# scripts and those of other assets.

Node Canvas seems tempting but I keep hesitating, worried that it may not do what I want. We tried Playmaker some time ago, or rather my programmers did, and they didn't like it very much. It was harder to tie in with existing code.

 

That's a pretty offensive comment to me, about the degree, just so you know. I have no degree, been programming since I was 10, and am quite good at it. Natural talent, it has been said numerous times. And like someone else said, a degree does not equal talent. Talent does.

Visual scripting can be useful for some things even for those who program well (I use it for cut scenes and sometimes AI).

 

You're not alone. I don't have a degree either. It's increasingly unnecessary in the tech industry or "some" folks. Everyone has a different way of learning. I personally learn better by self teaching and getting my hands dirty. Some people need structured instruction. That being said, I have interviewed many potential candidates who have degrees (some high level) and 8 / 10 of them still flounder and haven't made it past entry level. The point of college education in tech / programming is less about giving you the experience and more about giving you the tools. Some people have a natural knack and passion for learning and don't need it.

 

I have degrees, and I use visual tools where they provide benefits over text code. I'd rather build and debug a behavior tree visually in something like Behavior Designer than in text code. Or build and debug a state machine in Mecanim or PlayMaker. Or build and scrub through a cutscene in SLATE. Or position objects in Unity's scene view rather than entering their coordinates manually in a text file. These are all examples of using visual tools to get things done more efficiently or more reliably than in raw code.

And this is on top of visual scripting's previously-mentioned ability to delegate high level logic to non-programmers such as level designers, which frees up programmers for other tasks and shortens the iteration cycle for designers.

Getting back to the original topic, I do think Unity could leverage a lot of Mecanim's visual editing and state management functionality. But there are a lot of approaches to generalized visual scripting. Maybe they're not ready to lock into a specific paradigm.

 

I said that it usually appeals more to the people who didn't have a degree, not that everyone who doesn't have a degree does that.
If you did have formal education you would probably had math classes as well where you would learn if A implies B that doesn't mean B implies A and you wouldn't get offended about things no one was implying.
And if you started at as 10yo kid then that's not a talent that's hard work.
Also saying that you're good, especially saying it 3 times, makes you seem desperate to make a point. Did this struck a weak spot in you?

I agree about the cut scenes, they are pretty generic and simple, writing a script for this is a really time consuming. I've also seen people write components and use those to manage the animation sequence.
And I know a lot of people use this for AI, but I really can't see this as productive for anything other than a trivial AI, and making that into a component(s) would be much simpler than making a new visual script every time.

 

I see a lot of - less than pretty - stuff floating around developed by people with computer science degrees a plenty.
The level of book knowledge education correlating with the amount of money spent on becoming a "professional" does not directly reflect anyone's ability to create quality content.

And I WILL prove your implication wrong that non-coding visual script users can not create professional quality content. you just wait -

 

That's assuming Epic Games hasn't already accomplished it with Blueprint.

 

True! From my understanding (never used it) blueprint is a starting point for users. Not sure if a game could be developed using only blueprint. Would be interesting to read/see if there are publically released games created without code - solely with blueprint.
Comparitively - there are dozens of commercially released games from this community that has been created solely in playmaker.
A very nice looking quality (solo developer) rpgs currently in development here on the forums has been created completely in Playmaker (dang phone - cant find it).
Wont be long before there are successful releases using nottorus without code.

 

I would 100% disagree with you and would say that it more-so appeals to artists and workflow/level designers who have little to no coding experience. Just like tools like Substance Painter appeal very much to me as a coder because I have almost no design skill and (as a hobbiest), I like to just take the premade stuff and paint it on... it makes me feel like I've accomplished something really pretty.

 

Somebody built a basic Minecraft clone (with infinite, generated worlds) in blueprint, so it's definitely possible to do it.

I really haven't had any good experiences with graphical programming of any kind. Ironically, the flow becomes hard to follow, and I haven't seen any that are debugable to any degree. The screenshots posted in the thread linked by OP does not look like they're easy to follow, and you're using very much space to express very little interesting information.

I think the devs at the 2015 Unite QA session said that Unity have tried to implement a node-based tool like this three times, and scrapped each attempt. I really don't want them to make more attempts - there's a lot of major things missing from the scripting side, and solving those issues should be a priority over creating new and novel ways to script. There's a ton of assets already there if people truly want to do visual scripting, too, so Unity wouldn't really provide their customers with much value at all by creating yet another one.

 

Some people have already made games with Blueprints only, it is possible indeed.

 

There are no impossible things, there is only lack of skill needed to complete the task as one wise person had said to me.

That being said, how performant it was? How easy to debug? If the answer to any of these is "not much" there's no reason to use blueprint for any other reason than to prove you can. And if you want to prove you can, there are other (better) ways to do it, like learning Z80 assembly to program some games for the Speccy.

The only visual programming kind that was any good for me was Scratch-like coding that was used in Stencyl and CraftStudio among the others. So if I were to buy any visual coding for Unity, it would be probably Blockly or similar.

 

Well I'm not here to argue, just to basically tell you I was offended so hopefully you might think twice about making comments like that in the future. However, lol, it looks like I misread your comment, just read it too fast. Generally I don't verbalize skill assessments about myself. I just repeat what others have said about me, which is what I was doing here. And yes, I had a formal education haha.

Your comment about the talent / hard work correlation is flawed, but this isn't really the place for this discussion. In short, even when I was 10 the talent was evident - yes I worked hard to hone it much much further and still do to this day. Talent doesn't imply you don't have to work hard. No one is born "awesome" at something. Perhaps with talent you have to work a little less hard and grasp things easier. Steve Perry couldn't sing perfectly on day 1, yet he is immensely talented.

 

Started out as a nice discussion on Visual Scripting. Sad that it will probably be closed soon.

 

Why ?

 

It got a bit off topic, disparaging programmers without CS degrees, etc.

But it might be worthwhile to salvage the original topic. Among the interesting insights I picked up:

• Mecanim's visual node editor and state management seem like they would give Unity a head start on a visual scripting tool.
• Even experienced programmers use visual scripting for many things:
  • Organizing their own code modules (e.g., AI state machines) and getting a visual representation at runtime
    
  • Delegating high level logic to non-programmers
  • etc.
• Some users would rather see Unity focus their efforts on improvements to the core engine rather than dividing their energy by tacking on another system.
• Users' preferences vary -- some like the way Blueprints works, others like uScript, ICode, etc.

I wonder if these last two are some of the reasons why Unity hasn't done a visual tool yet. Since everyone wants something different, I don't think they could please everyone.

 

It'd be very hard to please everyone, I'm looking into making a special-case visual tool for certain situations myself (and using other tools for their strengths). Making something that can cover all cases, please everyone, and has good performance and features is hard. I'm also trying to create something that tries to solve UX problems I have with a lot of node-based tools, especially with dealing with complex graphs.

 

May I ask what UX problems you have in mind?

 

You don't need to please everyone, you just need to please everyone other than the people shaking their fists at visual scripting for no good reason.

 

I do think there are differences between the tools. Some work for different sort of users. I work with programmers so need one that is easy enough for me, but still easy to integrate with C# scripts written by my programmers. Not always an easy task.

Still looking at Flow Canvas but of course, it says you must be a programmer to use it. lol Playmaker does not work for my programmers. So haven't yet found the perfect fit.

Yeah, some really dislike the idea of visual programming, but some don't like the idea of a lot of newfangled stuff. Human nature, I guess.

 

Regardless of the differences between the tools, there are two points (to me) that should be common to all:
- The possibilty to integrate external scripts
- The ability to export the code (in C # or other).

 

Absolutely. It's kind of useless without this.

Why? You could technically do everything that Mecanim does in code, but I'm perfectly happy to let Mecanim do it. The purpose of a visual tool is to abstract away the code so you can work on a higher level. If it's a performance concern and you think generating C# code will make it faster, then I think the real requirement is that it be efficient, regardless of how it does it.

 

I had this question as well. One answer might be to get assistance from a person who doesn't have the visual scripting tool.
I have several programmer friends who I'd like to ask there opinion about something I created. If they don't own the visual scripting tool, how could I show them the logic without showing them code?

 

Good point, especially about sharing with someone who doesn't own the tool. But as far as showing them the logic, I'd think that they'd be seeing it on a different level, kind of like viewing a rendering of a 3D model in the Scene view versus a list of vertex coordinates in a text file. But maybe if they're really good they can still see blond, brunette, redhead.

 

Exporting can be a (good?) 'Starting point' that we could complete. Is not only about performance. Sometimes i have trouble (blank page syndrome) starting a script from scratch and in the mean time i'm really fine for 'playing with nodes'.

 

Specifically the "wire spaghetti" for complicated graphs (yes I know, nested graphs, that still doesn't fully solve the problems). I used to work in a AAA studio, and even with indie productions using tools like blueprint, etc can get complicated as I've seen (and had to debug). As a programmer, trying to understand a level designer's wire mess (which may need to happen to diagnose problems with the node) is difficult if you aren't on the designer team and aren't used to working with visual scripting tools. What I currently have are a few paper designs that might alleviate the problem, and I just need to find the time to implement them now that contract work has died down for a while.

If nothing else, I'll have a tool that works for my studios needs, to bridge the gap between my creative director's high-level design (he prefers working with visual systems) and my own technical nuts-and-bolts design (I prefer working in pure code). And we'll still be able to use the more targeted visual scripting solutions for their specific niches.

 

I hear you! I thought The Spaghetti Machine was brilliantly named when it came out on the Asset Store. Care to share any of your ideas? (I understand if you want to save them instead for your own work.)

 

While I'm not ready to share them yet, I will once what I'm working on gets out of the design phase. Mostly what I'm working on will be a sort of "Glue" layer to bind disparate systems together in a visual way, instead of having a programmer write another inter-op layer between things where it can be avoided. The other driving mantra is that I shall not constrain programmers into working in a specific paradigm, other than what the glue layer needs to be initialized and communicate with the various systems. This allows the right paradigm to be used in the right situation, instead of going whole-hog into a framework or paradigm design and realizing it wasn't exactly what was appropriate and now you're locked into a inflexible tool.

I will be watching this thread and will post when I have a working prototype. I'm currently the only programmer on the team, and the designers wanted me to revamp the core gameplay systems so they can test movement. I'm resuscitating a project that was effectively suspended for a year, so it's a good time to re-design and re-implement old systems and build the "glue" tool properly.

 

Sounds good. Best of luck!

 

Blueprint now supports automatic conversion to C++. He mentioned enabling it gave a massive performance boost.

https://forums.unrealengine.com/sho...-an-Infinite-Voxel-World-similar-to-Minecraft

If you're curious though you can try running it yourself.

https://goo.gl/KKpEia

 

The only visual coding tool that I've found remotely productive were Scratch-like blocks. Maybe that's a better direction than nodes?

 

There is no better direction or better tool, or no better 3D engine. If you are at ease with some tool and make a game, than use it and stay with it whatever it is.

 

Better is subjective. You may not have found nodes to be productive but Blueprint and PlayMaker show that others have.

 

Probably because they've never tried Blox. With node-based systems you quickly get "wire mess" as someone nicely put it in this thread. Don't get me wrong, nodes are good, but for things like state machines or materials (really stretching with state machines tho), things that are visual anyway. But for actual game logic? Nope. Wire mess.

Scratch-like blocks, like in aforementioned Blox have good balance between easiness to use for non-programmers and being able to actually read and follow the thing.

And no, I don't own or are affiliated with creators of Blox. I've just seen it in Stencyl and CraftStudio, both entry-level game creating programs and I know it just works and is readable.

 

I like node-based stuff, although there are obviously downsides and peoples mileage varies.

If Unity had already incorporated a node-based material/shader tool directly into Unity then I'd be more optimistic about the chances of them doing the same for scripting. But they haven't, so I have to think their priorities remain elsewhere at the moment.I certainly wouldn't mind seeing one or the other of these as a headline feature of Unity 6 one day though!

 

Or maybe, like myself, they have tried it and didn't care for it? Trying to claim that one visual language is better is a bit like claiming that one programming language is superior. Or one engine. Or one modeller. I think you should get the picture by now. It's purely subjective.