DOTS Visual Scripting Experimental Drop 8

Hi everyone,

I hope that in these difficult times, that you are safe and taking care of yourselves and loved ones.

We are making the best out of the global situation and have been working remotely for the last 2 weeks to keep you busy with new stuff!

Drop 8 of Visual Scripting for DOTS is ready for you to try!

This specific version is released as a project with the packages embedded in the package folder:

You’ll need to create a project using 2019.3.5f1 and up.

The big changes

As you may have noticed, this versions has been longer in the making. We started working on a higher level of abstraction to make this a non-coder friendly solution and, because of some some major changes, we kept drop 7 for internal iterations. This is what we’ve been doing:

  • Focus on the workflows and simplify the concepts inherent to DOTS.
  • Lots of simpler nodes that are closer to what non-programmers would expect and less 1:1 with the C# API. No worries, the other nodes will still be available.
  • In order to iterate at a better pace we came to the conclusion that we needed to put aside codegen at least temporarily. We are not sure yet if we will bring it back as originally implemented since we have other very performant options that we would like to evaluate first.
  • Also temporarily ignoring performance optimization and focusing on the feature set.

What we’ve been working on in more details

  • Event Node: Broadcast Send
  • Event Node: On
  • Event Node: On Start
  • Event Node: On Trigger
  • Event Node: On Update
  • Event Node: On Destroy
  • Event Node: Singlecast Send
  • Event Node: Enable/Disable state
  • Data Node: Math Function
  • Data Node: Caching
  • Data Node: Variable
  • Data Node: Compare
  • Data Node: Logical
  • Data Node: Arithmetic
  • Data Node: Interpolate
  • Data Node: Time
  • Data Node: Random
  • Data Node: Input Data
  • Data Node: Output Data
  • Data Node: Rotation to Euler
  • Flow Node: If
  • Flow Node: Once
  • Flow Node: Wait For All
  • Flow Node: Stepper
  • Flow Node: Wait
  • Flow Node: On Changed
  • Flow Node: Input Trigger
  • Flow Node: Output trigger
  • Flow Node: Tween
  • Flow Node: Switch Case
  • Flow Node: State Switch
  • Flow Node: Wait Until
  • GameObject / Component Node: Destroy
  • GameObject / Component Node: Enable
  • GameObject / Component Node: Get Parent
  • GameObject / Component Node: Get Children Count
  • GameObject / Component Node: Get Nth Child
  • GameObject / Component Node: Enumerate Children
  • GameObject / Component Node: Instantiate
  • GameObject / Component Node: Has Component
  • GameObject / Component Node: Get Component Data
  • GameObject / Component Node: Set Component Data
  • GameObject / Component Node: Get Rotation
  • GameObject / Component Node: Set Rotation
  • GameObject / Component Node: Get Scale
  • GameObject / Component Node: Set Scale
  • GameObject / Component Node: Rotate by
  • GameObject / Component Node: Enable Collision
  • GameObject / Component Node: Enable RigidBody
  • GameObject / Component Node: Set Velocity
  • GameObject / Component Node: Get Velocity
  • GameObject / Component Node: Set Mass
  • GameObject / Component Node: Get Mass
  • GameObject / Component Node: Set Use Gravity
  • GameObject / Component Node: Get Use Gravity
  • GameObject / Component Node: Set Is Kinematic
  • GameObject / Component Node: Get Is Kinematic
  • GameObject / Component Node: Impulse
  • GameObject / Component Node: Instantiate At Position
  • Debug Node: Log
  • Message Monitor Node
  • Drag N Drop Support for Assets
  • Bezier edges
  • Fix live edit (in and out of subscenes)
  • Integrate placemats in Visual Scripting
  • Dropdown query selection for events
  • Remove Bypass
  • Parallel flow for coroutines
  • New Script Creation Flow and Onboarding
  • Node collapsing
  • Sticky Notes
  • Macros executions
  • Subgraphs
  • Add/Subtract on Vector 3
  • Variants to handle On Key Down, On Key Up and On Key Hold
  • Object Graph References: drag and drop an object with another graph to interact with it
  • Node Inspector (edit properties)
  • Graph definition Inputs/Outputs
  • More types in math operations
  • And numerous fixes

Disclaimers

As with the previous experimental drops, this is work in progress that we share to engage in an open discussion with our community. Expect issues and weird workflows as we work our way up to a more final product.

So kindly take note of the usual disclaimers:

  • Not for production use.
  • Early picture of Visual Scripting, not be representative of the final version.
  • Things will change.

As always, we are very eager to hear from you.
Stay safe.

16 Likes

Woo Hoo! I am at home because of the Virus all week! Guess what I am going to be playing with all day! :slight_smile:

Normally I would be at work at my real job! lol

@ans_unity thanks for being on time! A lot of us are really looking forward to Visual Scripting in Unity!

Gotta say this definitley looks a lot different :slight_smile: and I am a little confused. I am assuming we are supposed to build our own triggers and events.

Looks like I am stumped right away. How do you pick the key for the On Key Down node?

If you click on the OnKeyDown node you should see a local inspector on the right with 2 selectors : KeyCode and EventType.

1 Like

To complete @ message, we did not provide any documentation yet. So here is a quick tutorial on how to Create/Send/Receive custom events.
In the future, we’ll probably add an Event Editor or something that will let you create events without coding but right now there is none, so here is how to do it:

  1. First things first, you need to create a new script. This has to be a struct that inherits from IDotsEvent. Just like the following example :
public struct MyEvent : IDotsEvent
{
    public int MyInt;
    public string MyString;
    public Entity MyObject;
}

The data types supported in an event are : int, float, Vector2, Vector3, Vector4, Quaternion, GameObject/Entity, string

  1. In your graph, press space to prompt the searcher and type the name of your event (MyEvent in this case). This will show you Send and On nodes (see attached screenshot).

  2. Just click on the Send node to add a node that will fire your event or on the On to add a node that will be triggered when the event is received.

5653474--587962--Screen Shot 2020-03-31 at 12.32.07 PM.png

3 Likes

Do we also need to make our own Triggers? Not quite sure how to connect the triggers to other nodes and make them trigger something.

what do you mean by “make our own triggers” ? you just connect the yellow ports between nodes ?
5653876--588004--upload_2020-3-31_14-5-28.png

These trigger here:

I’ve made some input and output triggers but I am not entirely sure how they work?

EDIT: FYI and yes I know how to connect nodes together and do flow/state logic. I’m not that green at this :P.

these are used when you reference a graph from another graph:

this is the referenced graph with triggers

If you drag and drop the object with that graph to another graph, you’ll be able to create a Smart Object, which is a graph reference as a node.

you can also create a subgraph, which is a reusable graph asset not living on an object.

5654038--588028--MM2srOJEl6.gif

3 Likes

wow very cool! Thanks.

Initial Feedback/Observations from a Non-Coder (I still keep up with ECS and do small amounts of scripting)

It seems like a completely different tool to what we’ve been using the past 6 drops.
I like the colors, how the nodes look, and some of the neat UI on some nodes (like the timer bar on the stopwatch and other similar nodes)

The rest of this might seem negative but I’m just kinda confused and need some clarification on what’s happening with this drop.

This new version seems a lot more restrictive than previous versions from what I can tell. More like you are locked to a script per game object, rather than working on the systems that can affect a lot of objects/entities that ECS is known for.

Maybe I’m missing something. Is the tool being rewritten and functionality that was there isn’t currently ready? From what’s being said it seems that it just got changes and higher-level nodes but it doesn’t feel that way.

Are we now only able to changing variables in the Blackboard and not the inspector?

Also, the Separate windows for the Blackboard and Minimap feels cumbersome. Maybe If I dedicate a monitor just to the VS Graph window I wouldn’t mind but the way it was before Drop 6 I think, basically integrated like Shader Graph, or the VFX Graph seems better. I use one monitor screen for the Game View and another for the rest of the editor. I usually dock the other graphs (VFX and Shader Graph) in the game window to have a larger space to work with so using the Blackboard or Minimap for VS Graph just add Tabs to the left that are visible when you switch to any other tab.

Image 5654071--588010--upload_2020-3-31_14-18-37.png

  • Will the other nodes come at a later date? Currently, there isn’t any in the create node menu and you can’t find anything related to entities in there as well.
  • With the new setup, how would you make a system that only works on certain/tagged entities as you would with an ECS system?

I really like the node UI changes in this drop, the other changes I’m struggling to see how they are beneficial over what was previously available.

1 Like

This will be an option eventually. funnily enough this is really divisive: people tend to hate one or the other option.

At the moment, yes. We just just haven’t ported it yet.

Which nodes ? remember this is a WIP.

We want to converge back to that kind of feature eventually, but we’ve been focusing on actual usecases from real world clients/users, hence the current feature set.

1 Like

Thanks for clearing things up.

The nodes that are close to the C# API for DOTS that are in the older drops, 6 and below. This is probably tied to when the graph starts to get back to an ECS like workflow.

Ah, alright.

Wouldn’t this cause issues moving forward? Currently, it’s more like working with monobehaviour and not like ECS. So further down the line wouldn’t this cause performance issues that shouldn’t be with propper ECS workflow?.

From my understanding for ECS you work on setting up entities with components (necessary data you want to work on) that systems would act on (use that data and manipulate only those entities)
The current VS drop is the complete opposite and makes you write ECS code like monobehaviour that is attached to one game object, as you would do with monobehaviour.

This part I’m not fully understanding.
How is this better, what are the benefits of working this way?
Is it actually taking full advantage of ECS/DOTS?

5 Likes

I’m seeing this as well – I really liked the “non-UE4-inspired” direction Unity was going in drop 6, with the ShaderGraph output-style / vertical behavior approach. It seemed a heck of a lot more DOTS/ECS friendly than what I’m seeing now.

This approach is very localized, which is pretty offputting. I was looking to use the power of ECS to modify many gameobjects at once in an easier, more visual, way.

Definitely agree on this. The drop 6 ShaderGraph approach was much nicer and felt more comfortable to use.

The Triggers being underneath the Variables (rather than in a new tab or something beside “Variables”) really makes things feel cluttered/cumbersome. Definitely not liking this so far.

I consider myself a real world client/user and I think the current node types are okay, but ECS is a new paradigm and it needs a new way of thinking (as well as a new approach) so why keep catering to old ways of thinking when users like me and the guy above are asking for a better UI to approach ECS features?

I can’t see myself using this over Bolt or NodeCanvas if it doesn’t let me work with multiple entities easily without bogging me down with the overhead that the old gameobject approach did. This is the kind of thing that needs to happen in the initial design stages – not later on as a “tacked on” feature.

Preaching to the choir my man. I totally agree – out with the old, and in with the new.
Just not this (drop 8) new.

I wish more of the Unity Team would get out of the rut of “thinking like a programmer” and think more along the lines of data management. This is not a hard idea to adopt – except when you’ve been doing it for years and are resistant to change. Most artists/designers are totally open to a brand-new way of thinking about code. I know I am. Why not give it to me? – I am not about to be okay with sloppy memory-management overhead when I have a tool that can help me manage my data the right way.

Unity Team, by default, needs to go the way of the Data Oriented programming style – so give us a tool to do it right.

That being said, I don’t hate everything about this release – the node list isn’t terrible, but it definitely lacks of any ECS-inspired efficiency. Unity got me worked up about this one with its “Performance by Default!”, and now it’s letting me down. The “default” in Visual Scripting seems to be “not so performant” because I’ve now got to add individual object management to my setup, which is a TERRIBLE way to program a game. The more you can abstract, the better (and more “performant”) your design (and its scalability) will be.

DOTS Visual Scripting should definitely allow me to scale from an “object-based” approach seamlessly into an ECS-based (multi-object) approach with minimal effort.

Right now, this looks to kill me with heavy object-level micromanagement (rather than system-level tuning) of my cool design, which totally disheartens me about the whole thing. As a designer, I wonder why do you hate ECS so much that you would burden me with such a huge amount of tedious garbage-work that could be simplified by giving me a systems-level overview of my visual scripting? I should be able to write a system once – then easily (and intuitively) plug it (visually) into a different system. With that “shader output” or “stack-based” approach in drop 6, this was easy and intuitive. It hybridized the vertical and horizontal visual-connections, minimizing spaghetti-code. In this drop, that is back – and in full force. I would never be able to easily-visualize my whole system in a “REAL” project with this. So far, the kind of intuitiveness in drop 6 escapes me in drop 8.

As a plus, I don’t hate the colors – I’m just worried that with the direction drop 8 took, it’s probably going to look like a disco / rave / neon-laced-drinking party if we’re not careful since there is no real reason why the connectors need to be colored. This kind of non-utilitarian color promiscuity harkens back to the UE4 color-vomit I can’t stand to look at, much less code with, which is why I don’t use UE4. Please don’t go UE4 / Blueprints color vomit. PLEASE don’t… Keep what made drop 6 unique and easy-to-understand. And PLEASE take my feedback into consideration. This drop just isn’t working for me so far. D:

If you have any questions, I will not hesitate to explain my reasoning to the best of my ability.

Just don’t write me off.

5 Likes

I have to agree. The 2-axis design where the time flows vertically and the data flows horizontally was a stroke of genius. I also liked how it felt like the data going through a pipe with transformations being applied in each stop. I’m not a fan of the direction that drop 8 has taken.

5 Likes

Been playing around with the sub graphs and made a Vector3Add subgraph to test. Is there a way we can script our own input/output nodes through C# so we don’t have to do this trigger in and out approach? It works, it just kinda makes the flows messy. Unless I can accomplish doing calculations without doing the triggers?

1 Like

I tried making a node myself but it doesn’t seem to pop up in the graph node menus

using Runtime;
using System.Collections;
using System.Collections.Generic;
using UnityEngine;

[System.Serializable]
public struct Vector3Add : IDataNode
{
    [PortDescription(ValueType.Float3)] public InputDataPort Input0;
    [PortDescription(ValueType.Float3)] public InputDataPort Input1;
    [PortDescription(ValueType.Float3)] public OutputDataPort Value;

    public void Execute<TCtx>(TCtx ctx) where TCtx : IGraphInstance
    {
        var f0 = ctx.ReadFloat3(Input0);
        var f1 = ctx.ReadFloat3(Input1);

        ctx.Write(Value, f0 + f1);
    }
}

Is this made correctly or are custom nodes not permitted?

Also, we at least need “Drop Zones” for our Visual Scripts:

See my article about why this is important here.

Drop Zones are the areas labeled “subject” and “main idea” in the image above.

Ideally, these “Drop Zones” could be auto-organized.
In these zones, you are either setting up your data, converting it, outputting it, or converting it to be output, but you are never changing or utilizing it. This happens in the “verb” portion of the script.
The “Visual Script” should happen in the “verb” portion of the script, keeping everything you’re doing (functionality-wise) easy to understand at-a-glance.

I feel like the vertical “blocks” of “main ideas” and if/then/switches in the previous drop (drop 6) was a great way to organize script logic, and having that verticality to separate different portions of the script was indeed “a stroke of genius”, which was well-put above by another user. I was quite impressed by this and really surprised to see it go. We at least need some kind of a “Drop Zone” area for the beginning/end of our scripts if nothing else.

@ Programmers

The visual clarity of a tool is KEY for artists/designers.
Many of us could code all day long – we’re not stupid – yet we artists/designers keep being treated as such.
However, this thinking that “artists/designers = simpletons;” is just fundamentally wrong.

Without code having that visual clarity we crave, code just drives most of us nuts. Yeah, maybe we’re picky, but that’s why you programmers love us – It’s a huge part of the reason why we take time to learn how to draw stuff besides stick-figures. It drives us nuts when things aren’t how they’re supposed to be. If things are to break the rules, then they had better do it in a really interesting way! – Which is partly why we loved the drop 6 before. I hate to say it, but your “internal” team of “real world use-cases” suck at figuring out the majority of artists and designers. That – or they’re too nice to you guys and don’t want to hurt your feelings because you worked so hard on this. I’m sorry, but I appreciate you guys more than that. I can’t be okay with you going the wrong direction with your work when I know it can suit your goals so much better. You previous work, drop 6, was vastly superior to this. So please take my criticism with the utmost love and respect for you guys. I appreciate all of your hard work.

5 Likes

I’ll try to give you a more detailed answer later, but that point was a surprise: you seem to assume a lot about the actual implementation and our current plan, and the reason MonoBehaviour code is slower

So this drop is really confusing. What is the workflow we should be following?

  1. What are the input connectors for? Are the input connectors for Events or something totally different like Flow?

  2. I spent the last 20 minutes just trying to rotate a cube, that should only take less than a minute.
    A spinning cube is like the “Hello, World!” of visual scripting. Could someone post a simple example of a simple spinning cube?

  3. The menu that comes up when I hit the space bar is confusing also! I am guessing that the right side is just for documentation in that menu but it looks like it has nodes and connections I can click on?

  4. What does this message really mean, it is not clear? Warning: When editing a project asset and not a scene object, scene references cannot be edited. ( Technically I should not have to worry about whatever this message is telling me. It should just work! )

Is there a User Experience (UX) person on your team? If so they need to speak in a louder voice!