Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. The 2022.2 beta is now available for testing. To find out what's new, have a look at our 2022.2 feature highlights.
    Dismiss Notice
  3. We are updating our Terms of Service for all Unity subscription plans, effective October 13, 2022, to create a more streamlined, user-friendly set of terms. Please review them here: unity.com/legal/terms-of-service.
    Dismiss Notice
  4. Have a look at our Games Focus blog post series which will show what Unity is doing for all game developers – now, next year, and in the future.
    Dismiss Notice
Dismiss Notice
Submit bug reports tagged with #Beta2022Win_Unity when you encounter unknown issues while testing the 2022.2 betas for a chance to win a year of Unity Pro. For more information, have a look at our Beta Sweepstakes Announcement.

DOTS Visual Scripting Experimental Drop 8

Discussion in 'Data Oriented Technology Stack' started by ans_unity, Mar 31, 2020.

Thread Status:
Not open for further replies.
  1. ans_unity

    ans_unity

    Unity Technologies

    Joined:
    Oct 12, 2017
    Posts:
    124
    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:
    https://drive.google.com/open?id=14DqyoreUrjFWz9qhgxMwYZfoobvId6uw

    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>
    • Event Node: On <Event>
    • Event Node: On Start
    • Event Node: On Trigger
    • Event Node: On Update
    • Event Node: On Destroy
    • Event Node: Singlecast Send <Event>
    • 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.
     
  2. createtheimaginable

    createtheimaginable

    Joined:
    Jan 30, 2019
    Posts:
    29
    Woo Hoo! I am at home because of the Virus all week! Guess what I am going to be playing with all day! :)

    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!

     
  3. toomasio

    toomasio

    Joined:
    Nov 19, 2013
    Posts:
    166
    Gotta say this definitley looks a lot different :) 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?

     
  4. jeanedouard_unity

    jeanedouard_unity

    Unity Technologies

    Joined:
    May 2, 2019
    Posts:
    41
    If you click on the OnKeyDown node you should see a local inspector on the right with 2 selectors : KeyCode and EventType.
     
    Last edited: Mar 31, 2020
    toomasio likes this.
  5. jeanedouard_unity

    jeanedouard_unity

    Unity Technologies

    Joined:
    May 2, 2019
    Posts:
    41
    To complete @ans 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 :
    Code (CSharp):
    1. public struct MyEvent : IDotsEvent
    2. {
    3.     public int MyInt;
    4.     public string MyString;
    5.     public Entity MyObject;
    6. }
    7.  
    The data types supported in an event are : int, float, Vector2, Vector3, Vector4, Quaternion, GameObject/Entity, string

    2. 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<Event> and On<Event> nodes (see attached screenshot).

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

    Attached Files:

  6. toomasio

    toomasio

    Joined:
    Nov 19, 2013
    Posts:
    166
    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.
     
  7. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    187
    what do you mean by "make our own triggers" ? you just connect the yellow ports between nodes ?
    upload_2020-3-31_14-5-28.png
     
  8. toomasio

    toomasio

    Joined:
    Nov 19, 2013
    Posts:
    166
    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.
     
  9. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    187
    these are used when you reference a graph from another graph:

    this is the referenced graph with triggers
    upload_2020-3-31_14-39-4.png

    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.
     

    Attached Files:

  10. toomasio

    toomasio

    Joined:
    Nov 19, 2013
    Posts:
    166
    wow very cool! Thanks.
     
  11. Grimreaper358

    Grimreaper358

    Joined:
    Apr 8, 2013
    Posts:
    787
    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.

    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.
     
    Sarkahn likes this.
  12. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    187
    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.
     
    laurentlavigne likes this.
  13. Grimreaper358

    Grimreaper358

    Joined:
    Apr 8, 2013
    Posts:
    787
    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?
     
    Sarkahn, davenirline, JoNax97 and 2 others like this.
  14. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,397
    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.
     
  15. JoNax97

    JoNax97

    Joined:
    Feb 4, 2016
    Posts:
    596
    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.
     
  16. toomasio

    toomasio

    Joined:
    Nov 19, 2013
    Posts:
    166
    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?



     
    laurentlavigne likes this.
  17. toomasio

    toomasio

    Joined:
    Nov 19, 2013
    Posts:
    166
    I tried making a node myself but it doesn't seem to pop up in the graph node menus

    Code (CSharp):
    1. using Runtime;
    2. using System.Collections;
    3. using System.Collections.Generic;
    4. using UnityEngine;
    5.  
    6. [System.Serializable]
    7. public struct Vector3Add : IDataNode
    8. {
    9.     [PortDescription(ValueType.Float3)] public InputDataPort Input0;
    10.     [PortDescription(ValueType.Float3)] public InputDataPort Input1;
    11.     [PortDescription(ValueType.Float3)] public OutputDataPort Value;
    12.  
    13.     public void Execute<TCtx>(TCtx ctx) where TCtx : IGraphInstance
    14.     {
    15.         var f0 = ctx.ReadFloat3(Input0);
    16.         var f1 = ctx.ReadFloat3(Input1);
    17.  
    18.         ctx.Write(Value, f0 + f1);
    19.     }
    20. }
    Is this made correctly or are custom nodes not permitted?
     
  18. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,397
    Also, we at least need "Drop Zones" for our Visual Scripts:

    upload_2020-3-31_16-8-51.png


    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.


    @Unity 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.
     
  19. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    187
    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
     
  20. createtheimaginable

    createtheimaginable

    Joined:
    Jan 30, 2019
    Posts:
    29
    So this drop is really confusing. What is the workflow we should be following?

    Screen Shot 2020-04-01 at 3.03.06 AM.png

    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!
     
  21. createtheimaginable

    createtheimaginable

    Joined:
    Jan 30, 2019
    Posts:
    29
    I agree with this 10000%, there needs to be something that guides the visual scripting workflow chaos to a structured concept! Chaos to concept is key here! It will also be priceless when we get to more complex visual scripts!

     
  22. WAYN_Games

    WAYN_Games

    Joined:
    Mar 16, 2019
    Posts:
    817
    Hello, how does all these nodes translate into code ?
    Does is work with entities archetypes ?
    Is the "generated" code jobified and multi-threaded ?
     
    createtheimaginable likes this.
  23. Grimreaper358

    Grimreaper358

    Joined:
    Apr 8, 2013
    Posts:
    787
    From what I can tell the input and output are used for things like subgraphs where you would set your input points to plugin data and the output. See this post


    Yea, this happened to me as well because I was thinking in terms of ECS. With the new drop you have to think in terms of working with game objects and in a scene. You setup code to act on an object and not systems.

    Script to Rotate an Object
    (This way will affect the object used and only work in that scene)
    The easiest way to get the object as a variable is to drag and drop it in the VS Graph.

    (This way allows you to use any game object and in any scene)
    Make a Local Variable in the Blackboard and set the type to GameObject. In the inspector, you add a Scripting Graph Authoring script to the game object you want to manipulate or an empty GameObject. Then you set your Graph as the Scripting Graph. The GameObject Variable you added should also be listed underneath and you can drag and drop whatever GameObject you want it to affect.

    upload_2020-4-1_3-45-48.png

    The right side just shows you what the node will look like so you have a quick preview if it is what you are looking for. It's been in the VS Editor for a few drops now.

    (VS Graphs are open based on current selection and not how you regularly open an asset with a double click)
    This goes back to the rotating cube example. If you have the graph on an object in the scene and the object is selected, you can add objects from the scene to it. If you have the graph selected as an asset in the project view you can't add any objects from a scene to it.

    As you can tell it's more of a GameObject based workflow rather than entities. So when you get your head around this, things become easier. Just not the ideal workflow for ECS currently.
     
    createtheimaginable likes this.
  24. createtheimaginable

    createtheimaginable

    Joined:
    Jan 30, 2019
    Posts:
    29
    Thanks, I got is to spin! I kind of like it!

    What I was missing was that I also had to add the "Convert to Entity Component" to the cube game object. Also, I had no idea that the "Scripting Graph Authoring Component" was needed too!

    When you say...

    Script to Rotate an Object
    (This way will affect the object used and only work in that scene)
    The easiest way to get the object as a variable is to drag and drop it in the VS Graph.

    When I do this it also gives me the option to add the object as a "Smart Object"? What is a Smart Object?

    (VS Graphs are open based on current selection and not how you regularly open an asset with a double click)
    This goes back to the rotating cube example. If you have the graph on an object in the scene and the object is selected, you can add objects from the scene to it. If you have the graph selected as an asset in the project view you can't add any objects from a scene to it.

    Still do not understand this double click vs selection thing at all. lol It just gets in the way of my creative flow. It should work open or work consistently just like all the other assets do in Unity. Changing this is confusing?

     
  25. Nathan2474

    Nathan2474

    Joined:
    Apr 1, 2020
    Posts:
    2
    I have two out of place questions:

    Does the package once I have it update itself or do I need to download the new one?

    One problem for me is, to read basic user input, like pressing a button other than "fire 1" that is on a keyboard. Does anybody have a script that solves my problem?

    Thanks!
     
  26. Grimreaper358

    Grimreaper358

    Joined:
    Apr 8, 2013
    Posts:
    787

    See this post, it explains how to set a key to the node. I hope the key shows up on the node in a future release. Having multiple nodes in the scene and having to click them to see what key they are set to won't be nice to work with.
     
  27. ans_unity

    ans_unity

    Unity Technologies

    Joined:
    Oct 12, 2017
    Posts:
    124
    Hi Nathan2474,

    Just download and install new the unzipped project on your drive. This experimental drop is not a package manager supported package.

    For the second part, it was mentioned a bit earlier in the tread: If you clic on the OnKeyDown node you should see a local inspector on the right with 2 selectors : KeyCode and EventType. KeyCode will list all available keys for you to select. Sorry if it's not well documented yet.
     
  28. davenirline

    davenirline

    Joined:
    Jul 7, 2010
    Posts:
    843
    I don't use this tool but reading this is disappointing. What was the reason behind the change? Is it because of the "clients"?
     
  29. ans_unity

    ans_unity

    Unity Technologies

    Joined:
    Oct 12, 2017
    Posts:
    124
    If it can help people get started, here is a basic two axis "character controller" mapped on the 4 keyboard directional arrows.

    upload_2020-4-1_13-13-43.png
     
    createtheimaginable likes this.
  30. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,397



    Thanks for that. It clarifies a lot. Sadly, this is exactly how I was thinking it would turn out... :(

    Blueprints spaghetti-code in the making there.
    This is too close to how current code "semantics" work. There is no sense of a subject, verb, or main idea in that graph, plus you're repeating yourself a lot (see the "Player" GameObject insertion, etc. 5 times?) -- Now ask an artist/designer to scale this system to multiple characters, with an input configuration system.

    You want to scare away artists? -- This is how you do it.

    (I don't mean you, @ans_unity -- I just mean general "you" -- as in anybody who goes this route. You're cool in my book.)


    "Hey! That looks straightforward!" is no artist/designer's initial reaction to that graph.
    Instead, we think -- "Hey, why can't that just be two or three nodes at most??"

    Is that code "hard" to understand? -- Nah. But when you need to understand it "at-a-glance" (like artists/designers need to be able to do) this kind of graph quickly gets painful.
    Not until you start doing this with ALL the controls for a single gameobject, then scale this code up to apply it to all the game characters (instead of just a single character), then add some slight changes or variations in the actions/buttons needed on a per-character basis, do you begin to understand why artists/designers typically HATE to code.

    What I just described is a set of systems.

    Getting a quick overview of the code is next to impossible with a "system" like the axis input character controller etc. etc. etc. etc. etc. etc. etc. etc. "system" shown above.

    Why?

    Because you're involving the logic of translation AND what gameobject to apply it to in the "system" itself. You're turning three bastard systems into one. You're wasting code, time, and our sanity as artists/designers who need a swift overview of what's actually happening in each level of our "input functionality" at-a-glance. There's no telling where the gameobject system or the translation system begins or ends without actually taking the time to decipher the glyphs on the screen and really paying attention to what lines go where. If there's a problem with your code, and the translation system has nothing to do with it, why worry about Time.DeltaTime or Velocity? If it is picking the wrong gameobject to send the input to, that's the "system" you open up to debug. Not the entire "two axis "character controller" mapped on the 4 keyboard directional arrows" system. There are so many things wrong with this approach I don't even want to get into.

    Local gameobjects and components don't do the "systems" thing very well -- ECS, on the other hand, does.

    Artists need a systems-level overview to approach code. As hard as it is to understand, this systems-level overview should be DEFAULT for artists. That means a system to handle vector translation, a system to handle deltatime, a system to handle axis input from the controller, a system to select the individual actions to perform by querying a system that tells it the kind of gameobject first. Wrap this in with an EditorWindow automatic UI generation script/system and you've got a badass development tool -- automagically.

    The graph you guys provided above is fundamentally complex and unwieldy simply because it is programmed like a nasty-looking Monobehaviour rats' nest of functions and variables glommed together into a spaghetti-monster nightmare. This is what code looks like to the (non-TD) artist.

    Whether you like it or not, the current way of programming (even in pure C# or C++ code) always devolves into a rats' nest when you look at it from above and try get an overview to make sense of it when you're just coming back to it. ALL programming "languages" seem to suffer from this. BUT it can be fixed! -- We artists/designers will help you with that!

    Artists/Designers NEED to have an overview of their design at all times.

    ECS actually prevents the rats' nest from ever forming because, at it's fundamental level, ECS is always 100% atomic and functional. At every level in ECS, in every system, what you see is exactly what you get. You can't just call an elephant a giraffe and expect it to function like as long as you paint it yellow. In standard code, call it a string, call it an int, "abstract" the interface, then call it a Cow. Whatever. In ECS, you've got to go way out of your own way to make something like that work. An int in a system stays an int unless an entirely different system (with an explicit purpose) explicitly integrates it and outputs something different instead. In ECS, an elephant is just too heavy and not flexible or tall enough to be a giraffe. You can't change the elephant into a giraffe, but you can go find a giraffe somewhere else if you really need one. It's much harder to half-ass things in ECS, which leads to clean code. You are forced to pick one over the other -- and build upon it logically -- with ECS systems.



    An elephant isn't a giraffe sometimes.



    In both ECS and in life, this is true.



    At any level, and especially from above, you will ultimately have a clean, logical, overview with ECS's systems-level approach. Not only that -- but it has a clear beginning, middle, and end to each system too. Something standard code "languages" rarely EVER have. So consider that too. I've written about this extensively, but there is plenty more about this to write.










    That's fair -- But, sadly, I don't have much to go on.
    There isn't much in the way of concrete information about the actual implementation plan (other than what I see) because (I assume, based on the differences between drop 6-8) it is not fleshed out, nor have I seen much in the way of the current plans in regards to ECS style code structure (outside of yes, one day, it is aimed at to be supported -- except I can't know for sure because this is entirely experimental), so I can only go with what I know -- and assume the rest will follow-suit with what I see.

    As you guys pointed out, drop 8 definitely was different, but I didn't expect the entire UX to be less-intuitive. I thought we had given ample praise to drop 6 that the UX direction would stay largely the same (outside of implementation details).

    Either way, as I pointed out, the drop 8 changes weren't entirely bad -- for example, I like how this build definitely appears more flexible, with the ability to output to other node graphs (as well as the awesome inclusion of states btw!) -- The issue I (and others) have is mainly with how straightforward the drop 6 build was to understand ECS code structure and systems implementation (even for artists/designers!) When compared with this one, I (and others) just notice a distinct lack of an easy, ECS systems-friendly, ECS-inspired, visual code flow/structure. We were getting away from gameobjects -- I had hoped Visual Scripting was the path to getting us there!

    This really bothers me because, historically, when something big like this is missing in Unity, it takes YEARS to get a functionally-equivalent implementation -- and then, when that implementation fails to be user-friendly (which it usually does for anybody except the largest studios), the entire system needs to be redesigned, and boom, even more years of waiting for basic features. In Unity's defense, at least you guys will go back to the drawing board. However, this wait is still excruciatingly painful for the user.

    I don't just throw this out there either. To support my claim about it taking years for a redesign, I point back to the Timeline Events implementation turning into Signals, which was originally a basic general-use Animation Events style events system (which everyone wanted and expected) being replaced in favor of something nobody saw coming -- Timeline Signals -- something that we quickly realized upon its release that nobody wanted either. It just wasn't compatible with the way we were wanting to work with Timeline, and it added a lot of clutter to our projects in a way that Animation Events never did. Remember how bad loading times were with assets? -- That was just increased tenfold with the inclusion of Signals, assuming we adopted it. Some people, including myself, tried. But it ultimately just got in the way, and I just adopted an easier-to-use system that was "close-enough" to the functionality I waited for. Unity is getting a hell of a lot better thanks to you guys making the effort. However, there is still some baggage over the years we both need to work together to get past. Hopefully my pointed comments aren't hurtful -- but they aren't intended to be any less pointy either. You guys are doing great. But feedback is feedback -- and I will give it honestly because there is no point to it otherwise. I would want to be proud of my work, and that sense of being proud, at least for me, comes with seeing my work used and valued by others. The very fact that I am passionate enough to share my negative feelings with you about your work means it is very important to me to see your work reach its potential. This is not "just a tool" to some of us -- it is a way to bring our creative and artistic visions to life in a way that can only be done (while maintaining "flow") with systems-level, tweakable, controls.

    Heavy is the head that wears the crown -- but you guys can totally be king of this Visual Scripting if you really want to.

    I've seen genius in you guys' work. So keep it up!
     
    Last edited: Apr 1, 2020
    PixelLifetime, Vincenzo, BYD and 5 others like this.
  31. msfredb7

    msfredb7

    Joined:
    Nov 1, 2012
    Posts:
    74
    One feedback I have right now would be to maybe make the orange line (the execution flow) stand out a bit from from the other lines.

    In unreal, that "execution flow" line is thick and white, while "data flow" lines are thin and colored.

    Looking at the character controller example, it took me a little while to find the essence of that script execution: On key press, we modify the player's position.
     
  32. JoNax97

    JoNax97

    Joined:
    Feb 4, 2016
    Posts:
    596
    God look at that spaghetti. This is a huge step down from the last drop, sorry. I agree with @awesomedata 's post. Also, ECS is a fundamentally different way not just to code but to think about how your whole game is designed. VS should ease people into that way of thinking, not try to hide it behind a OOP-ish layer. You'll just widen the gap if you go that route.

    Look I know probably a couple enterprise customers told you they don't want the learning curve for their artists and designers, but I hope you can see the clearly negative feedback here. If you're making a DOTS VS, do it the DOTS way. if I want OOP spaghetti I can go grab bolt or swap to UE blueprints.

    I was hoping this VS would be able to avoid some of these problems and be something different. I'm kinda disappointed now but I hope this is not set in stone yet.
     
  33. Canoide

    Canoide

    Joined:
    Feb 24, 2014
    Posts:
    11
    How do I do to show variable on the inspector?
     
  34. ans_unity

    ans_unity

    Unity Technologies

    Joined:
    Oct 12, 2017
    Posts:
    124
    Thanks for the feedback. About the example I provided, eventually Split and Make Vector steps would not be necessary making Get and Set Position much simpler (and way less spaghetti-like). It can also be divided in 4 scrips to keep it simple and atomic. I know it doesn't change the core issue you are pointing at but I just want to mention that there is still a lot of abstraction work to be done.
     
    landonth and awesomedata like this.
  35. tslancik

    tslancik

    Joined:
    Apr 21, 2019
    Posts:
    14
    I agree that it's confusing to suddenly switch from drop 6, don't even know where to begin (it even took me a while to be able to drag box into the Graph, since it was not attached to it), but that's probably also because I'm new to unity

    I believe a lot of negatve feedback could be eased or channeled into more direct constructive one if unity can provide simple example project to showcase the way of working in drop8 mindset, some small quick project like the 2D spaceship example videos in previous drops

    something that shows
    - the controller graph for the spaceship with canvas boundary conditions
    - graph for instancing entities for the bullets
    - update script for the bullets that affect all in memory bullet instanced entities (hopefully without for loop)
    - ...

    or any other example project that would showcase some parts in use to avoid too many assumptions about the new workflow
     
    createtheimaginable and msfredb7 like this.
  36. davenirline

    davenirline

    Joined:
    Jul 7, 2010
    Posts:
    843
    It looks like Bolt. I thought that this VS would be entirely different.
     
  37. tslancik

    tslancik

    Joined:
    Apr 21, 2019
    Posts:
    14
    meanwhile looks like Bolt 2 got some great design ideas from Drop 6, lol
    but I guess looks are not everything
     
    Gekigengar and TextusGames like this.
  38. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    3,246
    Anyone here who is using playmaker?
    I have been using it for 10 years and the way you can create actions and connect them togther is very easy for me.

    Also the way you can get and set properties on game objects is very powerfull.

    Is there a equvalent way of working in this new system, with statemachines?
     
  39. Virtualware

    Virtualware

    Joined:
    Sep 17, 2012
    Posts:
    75
    First, thanks for the effort in this stuff, it helps a lot in managing dots in a "read-able" way, we think this approach is fantastic!

    I have been trying to simulate the future use of this stuff as a package, and how to develop our own node extensions, using the interfaces you provide.

    We managed to create a custom node inheriting from IFlowNode, creating the files directly in your package folder, and it works, but if we try to work in a separate one, something like "Custom VS Nodes", we have this error

    upload_2020-4-2_10-23-20.png

    as the abstract class DotsNodeModel from DotsStencil is not defined as public.

    Code (CSharp):
    1. abstract class DotsNodeModel<T> : BaseDotsNodeModel, IDotsNodeModel, IPropertyVisitorNodeTarget where T : struct, INode
    2.     {
    3. ...
    4. }
    If we change that interface definition to be public, we get it working again in the mentioned custom folder and we have no error in the console.

    upload_2020-4-2_10-30-26.png

    It would be great if you make that change for us, so the community could extend this great system, now to test, but also in the future when it becomes an assembly package.

    Are you planning to make this thing extensible?

    Thanks!
     
    Last edited: Apr 2, 2020
    toomasio likes this.
  40. TextusGames

    TextusGames

    Joined:
    Dec 8, 2016
    Posts:
    424
    Bring back modern and clean vertical flow.
     
    Gekigengar, Vectrex, BYD and 5 others like this.
  41. TextusGames

    TextusGames

    Joined:
    Dec 8, 2016
    Posts:
    424
    Is visual scripting still planned for dots only or it can be used with GameObject without dots?
     
    JoNax97 likes this.
  42. Lhawika

    Lhawika

    Joined:
    May 27, 2015
    Posts:
    52
    Well, as a programmer, I wish I never have to work with this kind of visual scripting. I hated Blueprints in UnrealEngine.
    I think programmers in general have a hard time using visual scripting (at least I do). It's either to complex and messy for simple things (basic character controller) or to limited (and super messy) for complex things (procedural geneneration, complexe math operations). But at least some of them (for example PlayMaker) are pretty easy to tweak by a designer.

    One silly idea from the top of my head => A node "Math expression" that allows to, "inside of it", drag'n'drop variables, write values, operators, reorder omerands, etc... That way all the numerous nodes that just represent an operator could go away.

    And then assigning a variable will (almost) always be two nodes => The assign node, and the expression node (of course one could still want to use an "Add" or "Multiply" node to join two expression in order to improve semantic).
     
    tarahugger and brunocoimbra like this.
  43. ans_unity

    ans_unity

    Unity Technologies

    Joined:
    Oct 12, 2017
    Posts:
    124
    When you create varia
    Yes it's for DOTS only. That being said, we want to keep DOTS editing very similar to current GO editing. So even though you work in the editor with a familiar GO workflow, all is being converted to DOTS at runtime.
     
    TextusGames likes this.
  44. brunocoimbra

    brunocoimbra

    Joined:
    Sep 2, 2015
    Posts:
    640
    Wait, now I am confused, so we should expect the DOTS Visual Scripting to have that Object Oriented flow in the final revision (as it is currently), being it converted to DOTS only at runtime? Or having a Data Oriented flow is still planned, but as part of the low-level nodes?
     
  45. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    29,721
    I'm curious about if performance would be any better than a classic monobehaviour script or if threading will be an automatic thing.

    I couldn't see an answer to this so quoted.

    From what I see it's just really for artists so that Unity can generate code that works with DOTS rather than being high performance.
     
    BYD, awesomedata and brunocoimbra like this.
  46. ans_unity

    ans_unity

    Unity Technologies

    Joined:
    Oct 12, 2017
    Posts:
    124
    Very interesting feedback on vertical flows, we hear you. :)

    The reason why we went back to horizontal flows in this version is mainly because we introduced parallel execution flows. Parallel flows with multi input/output nodes are difficult to represent vertically. We hope to be able to bring the vertical representation back at some point but the horizontal representation enables us to work faster for the moment. Both representations have plus and minus and, with such a polarized audience, we may want to leave it as a user option.
     
  47. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    29,721
    People fear what is new but if you can explain something like "this is very very fast to execute" then people might understand. Because otherwise why bother with DOTS at all... if it's not fast to execute?
     
    Gekigengar and NotaNaN like this.
  48. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    3,246
    Yes please user option for horizontal / vertical
     
    TextusGames likes this.
  49. MyFault

    MyFault

    Joined:
    Aug 15, 2012
    Posts:
    11
    I think y'all could've saved yourself a metric ton of grief if you had paused for a day or two and put together some concrete examples to show people. Making such a radical change and just dropping it on the ground and saying, have at it, does not seem well thought out.

    I'm not trying to be mean but it's kind of worrisome that no one in your group thought, umm, since this is such a new direction maybe we should give them a bit of a start that they could run with. Remember, horse first, then cart :)
     
  50. ans_unity

    ans_unity

    Unity Technologies

    Joined:
    Oct 12, 2017
    Posts:
    124
    Artists and designers are indeed the target audience for visual scripting but we want a performant solution that can be used in production by everyone.

    We spent the major part of last year working on DOTS and performance and we know we can achieve it. We now shift our focus on user experience to make sure we can build a usable product for our community. This means that, for a moment, we set aside performance and optimisation concerns to gain iteration velocity. This is only a temporary shift, we will get back to performance later when we will work on the production release. Our intend is not to strip out DOTS concepts from VS but ease users in that new world and expose complexity as needed.
     
    Roni92pl, Tanner555, NotaNaN and 7 others like this.
Thread Status:
Not open for further replies.
unityunity