Unity is really missing a native Visual Scripting Tool

He wasn't referring to the node-based aspect so much as the underlying technology.

Just having nodes doesn't make it a visual scripting language.

You seem very fired up for someone claiming that we're arguing for the sake of arguing.

Just about everywhere else it refers to itself as a visual state machine.

 

What do you mean you dont know? You all have referred to playmaker as visual scripting prior in this very thread! This is to funny.

 

What does it matter? If Unity was to roll out a VS system I'd expect it to be more like UE4's BP's.. In all fairness, like you mentioned VS is probably near the bottom of the pile of actual want's / needs..

 

You didn't answer my question Ryiah, can FSM be classified as visual scripting?

 

It says right on the store page

https://www.assetstore.unity3d.com/en/#!/content/368

What is the very first line, "Editor Extensions/Visual Scripting
Hutong Games LLC"

 

No.

 

You guys been talking about playmaker as if it was visual scripting this entire thread. Now all of a sudden its not.

 

Yes it can be.

 

If we stretch the definition of a visual scripting language.

 

You going to tell Hutong Games LLC that they dont even know what their own product is.

 

If you're seriously this upset over it you're free to poke the developer and ask him yourself.

http://forum.unity3d.com/members/alex-chouls.5919/

At the end of the day though the definition semantics aren't that important.

 

Why would I need to ask? He wrote on his store page.

"Editor Extensions/Visual Scripting
Hutong Games LLC"

Playmaker is graphical not textual like C++ thus its visual scripting.

 

You just like to argue for the sake of arguing.

 

Quoted from the actual documentation.

https://hutonggames.fogbugz.com/

Only once does the front page of the documentation refer to scripts and only by saying you can access existing scripts (as in C# scripts).

 

I dont really see C# as scripting more than text based game making.

 

You repeating this does not make you correct. C# is an actual programming language that has been adapted to scripting.

https://en.wikipedia.org/wiki/C_Sharp_(programming_language)

 

The fact this thread devolved into this is a joke.

 

Playmaker is graphical not textual like C++ thus its visual scripting.

 

PlayMaker is a finite state machine under the hood and C++ is not. A rose by any other name and all that.

 

I understand playmaker is a finite state machine that does not make it also visual scripting. I did not say c++ was I said it was textual.

 

How are you not seeing this.

https://www.assetstore.unity3d.com/en/#!/content/368

What is the very first line, "Editor Extensions/Visual Scripting
Hutong Games LLC"

 

Then you should be capable of understanding why a finite state machine doesn't really qualify as an actual language.

Same reason you're ignoring my direct quote of the official documentation.

 

Once more you guys been referring to playmaker as visual scripting this entire thread now all of a sudden its not. Why would that be? Could it be because you just want to argue for the sake of arguing?

 

Who said playmaker was an actual language?

 

So because the official documentation doesn't say explicitly that its visual scripting that means it isn't? You for real or you trolling me?

 

Wikipedia's definition of a visual programming language (or visual scripting language for that matter) is that it's a programming language where the user develops programs using graphical representations. Notice that Blueprint is in the list of examples it gives. That's because Blueprint is an actual programming language (albeit in visual form).

https://en.wikipedia.org/wiki/Visual_programming_language

You. It has been your stance the entire time.

 

Okay so it lists this


^^^^^ You call this visual programming language but playmaker is not?

 

You for real right now or you trolling me?

 

In computing, a visual programming language (VPL) is any programming language that lets users create programs by manipulating program elements graphically rather than by specifying them textually

You cant create programs with playmaker?

 

Scratch is an actual programming language under the hood. PlayMaker is a finite state machine.

Quoting myself from earlier:

Yes, you can create programs in PlayMaker, but only within the limitations of an FSM.

 

Google "visual scripting unity"

Whats the first thing that pops up?

 

Google's search results are not guaranteed to be factual.

 

You can only do anything in unity within certain limitations that doesn't mean anything.

 

It means everyone else calls playmaker visual scripting even you earlier. Now all of a sudden its not, WEIRD.

 

http://forum.unity3d.com/threads/be...r-vs-brain-buider-vs-antares-universe.143648/

Look at all these people calling playmaker visual scripting and not one arguing that its not.

I wonder what that says about you?

 

Unity's limitations are far less of a problem than the limitations of a finite state machine.

Only weird thing here is why I'm wasting my time with your flame bait. I'll just assume boredom at this point.

 

It says that I'm pedantic.

 

You just want to argue.

 

If so then we both share in that pasttime.

 

I wish OP would clarify what the clear disadvantages are of not having native visual scripting. I wish Unity had blueprints too but Playmaker and other assets is all we have for now and besides unity devs will be adding visual scripting this is a fact. Native visual scripting is coming!

 

Just don't hold your breath. Unity's UI and Networking were coming for years before they finally arrived.

 

UE has been out a lot longer though it wont be long before Unity catches up in every regard.

 

Whats crazy is Unity has even passed UE in some regards.

 

Just keep in mind that Unreal receives massive rewrites between major releases but Unity does not. Unreal 4 and Unreal 3 share very little if any actual code. At this point they're the same engine in name only.

 

That could just mean that UE devs are bad at planning.

 

Woah, talk about spamming the thread!

Also, it's ok for people to change their minds during a discussion. That's partly why we have discussions - to share experience and learn things and such. If you weren't willing to change or learn then why bother?

 

Wiping the slate clean every so often can do wonders for your code. Unity's approach means that fewer things are broken but also that legacy nonsense survives much longer.

 

Definitely, but so does doing it right the first time. XD

 

You can only plan ahead so far before it becomes a guessing game. Unity is slowly phasing out the legacy but it's slow going.

 

Absolutely! That's why (as @neginfinity mentioned) I show "wires" between related things when relevant. Usually I only bother with this when it's not a relationship between parent/child elements, because those should be intuitive.

I posted an example image of a case earlier, where puzzle objects in a cave had wires showing what switches were connected to what lights, doors, etc. That's a quick-and-dirty implementation for a game prototype/demo, it just checks the references and if they're not null draws a line between their transforms. But it makes it super clear how a puzzle is set up without having to manually walk the references.

If you've got ships that have similarly complex setups then I'd suggest doing the same. I also agree with @neginfinity about how to hook things up appropriately. If you're using GetComponent(...) then it should be for an automated task that a designer doesn't need to be involved with, and in that case showing the "wiring" is just needless complication. If a designer should be in the loop then the references should be explicitly set, and in that case it's super easy for the programmer to add what I showed. I think it was 3 short lines per "wire", and if you do it a lot and want to add extra functionality then you could make a static utility function. I also wouldn't want that wiring to be done for all references, so it's something I want to add in as-needed.

One thing I haven't tried yet is graphically representing UnityEvent hookups. I expect that there's some way to see what is listening on a UnityEvent, but haven't tried it.