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. Join us on Dec 8, 2022, between 7 am & 7 pm EST, in the DOTS Dev Blitz Day 2022 - Q&A forum, Discord, and Unity3D Subreddit to learn more about DOTS directly from the Unity Developers.
    Dismiss Notice
  3. 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

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. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 20, 2015
    Posts:
    8,752
    @awesomedata please, open a blog if you don't have one! :) My eyes are burning and my wrist has tendonitis like if I was 16 again... I appreciate if you link your blog posts here, no need to include them.
     
    Orimay, awesomedata and NotaNaN like this.
  2. Ofx360

    Ofx360

    Joined:
    Apr 30, 2013
    Posts:
    146
    They already said they’re working toward a query system (more ECS like), which will be a bigger part of Unity as a whole in the future. They have to work towards that.

    I’m not really sure what repeating the same OOP/ECS sentiment in longer and longer post accomplishes when they’ve seem to address the concern or at the very least give us a new talking point to go over.

    In regard to Drop8, i’m wondering if there could be an option to reference like-prefabs. So i would drag in a prefab to the VS window and be able to reference all prefabs that might be in the scene. That way if i were to make a door that opens with a key, i dont need to drag a reference in for each door in the scene. I guess thats just queries, huh?...but yeah, i’d love that!

    Also would like a way to get at authored/runtime components from the GameObject and Find GameObjects/Entities in the scene. Those are often triggers for events but currently, there doesn't seem to be a way to interact with anything not explicitly referenced In the inspector (ie stuff added to the scene hierarchy after the game starts).
     
  3. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,415
    Fair enough! -- I can do that! :D
    Sorry for the scrolling, everyone. I'll make it a point to be more mindful of your wrists!

    For now though, I've said all there is to say on my end of this point.



    I'd really REALLY like to hear what Unity has to say on their end.




    You're right -- but "ECS like" queries are not the same as "ECS based" queries.
    Unlike many people, I try not to assume. Besides, I've been burned in the past with assumptions like these with Unity. For example, I'm an animator, and looked forward to Timeline Events. However, we got Timeline Signals. Timeline Events != Timeline Signals. The community essentially asked for an Animation Event slider/tickmark equivalent for Timeline (because we were shocked when it didn't appear with Timeline to begin with, nor did Animation Events until a bit later.) So then Unity said it was coming. Finally, after waiting ~2+ years and a demo showing proper Timeline Events -- surprise! We got "Timeline Signals" instead. NOBODY asked for (or even expected!) signals. Now there's no going back. To this day, I'm not sure what happened, but we got something completely different than we were promised after a stupidly-long wait -- and we're stuck with it. Drop 6 was great -- amazing even! -- then suddenly the "surprise! -- gotcha!!" of drop 8 quickly triggered my PTSD. Sorry, but I seriously don't want to be stuck with drop 8 -- in any form. It's got too many OOP-related structural problems (outlined in my previous post). I prefer to have a nice, clean, structural project -- not the wild west node wrangling I'm forced to have in existing OOP language structures.


    Also:

    @theor-unity -- I wanted to apologize to you.

    Despite feeling very strongly against the new direction, I'm not meaning to take anything out on you. I respect that your opinion seems to differ about the importance of ECS to artists (and programmers alike), but I am dealing in fact here, and as such, I am just trying to ensure that you guys understand EXACTLY where I'm coming from with those facts.

    So please excuse my long-windedness in this thread (if you will.) This time I'm just making the desired workflow (and the intentions of that desired workflow) EXTRA CLEAR so that you guys can see the pros of my suggestions clearly, and work out what you think are the "cons" (and hope that you would share those "cons" with the community). I think asking the community for feedback (and using us as a sounding-board for any "cons" you think exist with what we're asking for) is something that I think can make things feel a little less volatile around here.


    As my most recent post in this thread makes very clear -- A simple query system is NOT enough (even when it is editor-wide).
    With a Visual Scripting interface, ECS has the capability to be a full OOP package.
    I know it's a lot to read, but my previous post outlines the hows and whys.
    I would appreciate your feedback on this.
    My main pushback is that OOP is not upheld in common (supposedly "OOP") languages.

    Precisely because ECS preserves OOP -- and even improves upon it -- I feel it should be given center-stage.
    ECS needs its own Visual Scripting space.
    As it currently stands -- ECS is the kind of language that lends itself to a visual workflow.

    ECS cannot be a "secondary" feature -- if anything, keep drop 6 and drop Blueprints (or make them secondary.)
    Sadly, the problem with the secondary approach to either Blueprints or ECS is that this will get back into the age-old "C# vs. UnityScript" territory again (with "ECS vs Blueprints" instead), with one eventually being deprecated over the other due to heavy upkeep. And I feel ECS might be the one to take the bullet for one inane reason or another, despite it clearly being the better language -- simply because people do not (yet) know how to wield it! D:As nice as it is for Unity to have the Blueprints for familiarity and "proven" technology, I have just "disproved" its reliability in my previous post, and although unfamiliar, ECS quickly becomes familiar with only two concepts to learn before learning practical OOP-oriented techniques that get you the rest of the way there, allowing you to program anything you want -- in an easy to understand way.

    I seriously feel that just tacking on an "ECS-like" query experience (rather than proper ECS queries) is a terrible betrayal to those of us who adopted the ECS mindset and want to use ECS for real scripting.

    On a good note though -- I would really like to use ECS queries for Editor Scripting... How fun would that be? :)


    Yep, this is why I'm pointing heavily at a more "transient" approach to gameobject components. Adding/removing them whenever you need to for certain bits of logic to take place.

    To solve your issue, it's important to consider the following:

    As entities have no name or reference, rather than query for a list of components, it's easier to query using a mask that asks for a particular group of components you need it to have or not (i.e. Player component and HitState component) so you know that this object is a player and is currently already hit (so you don't damage it again while in the trigger volume). Yeah, it'd be stupid if the player had an Enemy component alongside a Player component, but if it had both of these for some reason (a character creation system that does enemies too), you can always add a "double-check" component -- i.e. Player and PlayerInput components double-check this is really a player, since these should never be alongside Enemy and EnemyAI components in an entity. This is why a query / mask / wildcard system is mandatory with ECS entities.

    In my mind, the way it might look in Unity is something like this:

    1. You drag/drop a gameobject from the scene or project (with all its authored components) into the Visual Script, and "BAM!" -- You have an instant query using a scene (or prefab!) gameobject!
    2. If it's from a scene, the current scene name would be automatically included as an empty data component to the Visual Script.
    3. Additionally, if you hold (say) "Shift" while dragging the gameobject in, it pops up a temporary Editor Window where you can visually "mask out" certain components from your query with either a "wildcard" or a "not" for certain components in the query if you like.
    4. Using the wildcard in your mask, you can grab all gameobjects with an particular component from a particular scene. (A checkbox in the bottom-right corner of the EditorWindow that says "current scene" to ensure the "SceneName" component for the currently-active scene is included in the query might be very useful in a case like this. Clearly your scenes should be uniquely named, but this is the price you pay.

    Also, I think tabbed lists of components should be a think in this EditorWindow (i.e. each tab is a group of component data that relates to a certain data component -- i.e. PlayerData, SceneData, EnemyData, etc -- so you can quickly add tabs and heavily-accessed data to your "Quick-Query" menu.) Adding components to groups should have an Editor Window too and this should be lightning-fast (for example, you should be able to add an entire gameobject to a group if you like, masking away some of the data that you might not want to be stored when you drop it into the window).

    Just some thoughts.
     
    Last edited: Apr 24, 2020
    laurentlavigne and NotaNaN like this.
  4. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    187
    We tried something similar. Didn't work during user research/feedback from studios. In my experience, and according to the data we have, our target user is not comfortable with queries - "I will break something as I don't know what I'm targetting", "But I just want to operate on that object", etc. were common.

    As said previously: we have plans to cater to these workflows, but later. We're trying to ship a good solution first for specific references (let's call that "scripting" - which happens to be in the name of the tool), then we'll have a second look at system authoring, which will probably include some take on visual queries, which ideally would be reusable across multiple tools.
     
  5. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    1,528
    I guess when u start catering actual ECS workflows later, you need to provide tick checkbox that able to remove all the game object OOP related workflow to avoid confusion.
     
  6. createtheimaginable

    createtheimaginable

    Joined:
    Jan 30, 2019
    Posts:
    29
    Apple iOS developer here, that likes using the Unity 2019.3 & 2020.x betas...

    How about we keep it simple and elegant? Maybe have a Query based Visual Scripting DOTS project that kind of works like Drop 6 OR a Visual Scripting GameObject Project ( For those stuck in the past.. ;)) that need GameObjects? Just kidding! But you know what I mean! :)

    Apple's approach has been to give people what the need instead of what they think they need! In other words give people a Model-T car instead or a horse and buggy. Even though most people back in the 1800s would have still wanted a horse and buggy and scoffed at the Model -T car? For better or for worst Apple is not afraid to lead people into the future, even non-programmers by using a future based User Experience (UX) or even a new Developer Experience (DX) and putting it first!

    This is a great read on Developer Experience (DX) - Developer Experience (DX) Developers are People Too

    Anyway just my 2 cents! I don't mean to stir up the pot too much! I think Unity is doing a great job and I see how they are changing things based on the feedback in this thread about Query based Visual DOTS!
     
    Last edited: Apr 25, 2020
    hippocoder, awesomedata and NotaNaN like this.
  7. FastLady

    FastLady

    Joined:
    Mar 22, 2019
    Posts:
    1
    I can't have more than one Scripting Graph Authoring component on a gameobject, i get an error message

    upload_2020-4-26_6-35-55.png

    Is this just because it's the first drop of the new way of working? Will this be doable in future drops or am i just going about this the wrong way?

    I'm an artist just getting to grips with scripting but the best way of working seems to be reusable sections of code that can be dropped on multiple objects, with gameobjects often having multiple scripts dropped on them.
     
    awesomedata likes this.
  8. TextusGames

    TextusGames

    Joined:
    Dec 8, 2016
    Posts:
    424
    I think multiple graphs - like reusable components should be allowed to be added on one game object. I actually asked already about this but there were no answer.
     
    awesomedata likes this.
  9. Ofx360

    Ofx360

    Joined:
    Apr 30, 2013
    Posts:
    146
    I think the idea is, based on the default behavior, that each script would get its own game object that it lives on, separate to any gameplay relevant game objects. You would just then have to drag each scene reference to the relevant scripts. But idk, i’d love to hear about thoughts/directions on this one
     
    awesomedata likes this.
  10. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    187
    @TextusGames sorry I missed your question in the confusion.

    The limitation of "1 Component of a given type max per converted object" comes from DOTS. However, we'll likely implement multiple scripts stored in a list in a single VS component later
     
  11. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,415
    Thank you for the clarification. Your position makes A LOT more sense now!

    I can see how you might think the proper direction to go in is to toss the idea of queries entirely for now.
    Judging by your feedback, "queries are niche!" seems pretty self-evident.
    However, my gut tells me something's still missing here...

    Judging from the feedback here (from the wider community) and from my own experiences and initial thoughts on the proposed ECS workflow mirroring those sentiments/feedback from your test users (i.e. "I can't make games if I can't access an individual entity and do something with it!"), as was the case with me, it seems that your test users were also just as likely as I was to just not have been comfortable with ECS (in general) yet -- rather than any particular method of using it.
    There isn't much (up-to-date) information on ECS practices for game development to begin with -- much less how to use ECS queries in (real world) game development scenarios. Using queries, for example, is a basic part of ECS.
    Unity's technology (as a whole) suffers from this "no teaching" problem though. Get users to test new technology while offering them zero information on when, where, why, or how to use it.
    As a result, your tests and experiments are easily skewed.
    It's no wonder Unity misses the mark on so many things with its new technology. Its data-science sucks.
    On that note, I would put money down that your results on the desirability of queries in Data-Oriented Visual Scripting would have actually been wildly different had there been a few well-written pages of information on how ECS could be used in a fun and practical way by employing these general-use queries most of the time to most objects, and only drilling down to object-to-object level interactions when absolutely necessary (in special cases), such as stacks of specialized actions or states, and then, only with a data placeholder if possible. Simply making the case to your test users to explain how to make ECS help with day-to-day development using a query approach by default, and for special circumstances, work with specific individual objects (only as a secondary special-case approach that is preferably avoided whenever possible.) This gets users to think in systems and data (rather than object-to-object), and is critical to emphasizing the intended approach to your test users, leading them to advise on things that would have actually been helpful to them (given useful knowledge and perspective on your workflow intentions with ECS). Your users simply didn't know any better, and therefore responded with ignorance. Like me, many likely would have enjoyed at least a hybrid-query approach, assuming they understood the full benefits of a query-based approach to begin with.

    That's exactly the spot where a lot of users on the forum are now, and where a lot of the contention is between your "data-backed" direction and the direction I propose (which is also data-backed). In that sense, if anyone else agrees with me, please make it known -- I can only confirm my part in this, not yours.

    ECS is all about data-oriented mindset and techniques -- and not brute-force micromanagement.
    This needs to be reflected in the supported workflows.
    ECS is as good as OOP.
    But this has to be taught, as it is not obvious.

    Even if you used some specific "object-to-object" individualized code, your default way should be to encourage users to learn how to (begin to use) component queries and global systems as much as possible over a "GetComponent" or "FindGameObject" / "FindEntity" approach. After all -- Isn't this supposed to be Performance "by default?"

    It is clear the tool you guys tested with did not "teach" your users how to use ECS (as you already implied), but the "teaching" on ECS should have still taken place in some form during the testing process (not necessarily for the tool itself, but to confirm the test-group had a solid grasp of the [very practical!] benefits of using DOTS, which includes ECS queries). Without your test users/studios' familiarity with effective ECS use, there is no way you could have arrived at the conclusion that a queries workflow was at fault when you have no metric gauging the lack of familiarity with the techniques ECS concepts (like queries) that users require to use DOTS in an intuitive and practical way. This knowledge simply wasn't available to them. Additionally, the tool you offered was likely also very fragile (and very alpha), and me saying "I feel like I might break something" could actually be referring to your (extremely alpha) tool, rather than the process of using queries in and of itself. With graphs being corrupted even as late as drop 5, I can see why someone might say they feel like they might break your query tool.
    With these things in mind, are you 100% certain your "data" on queries is so thoroughly unappreciated by your target studios/users? -- As a user who was initially very skeptical about DOTS Visual Scripting for a long time "since I can't access individual entities", I ask because I can totally attest to the fact that I was initially put-off by DOTS-only Visual Scripting. However, when I really gave it a chance, and when I really started to imagine how it could be used, I quickly saw how I could make it not only improve my entire workflow for most tasks, but also improve my whole creative process, down the very way my code is written. It took me a moment to see this amazing and fun new world on my own, but I was sold when I realized I could write a simple (reusable) interaction system to handle pretty much any kind of data exchange I wanted -- without even needing a gameobject/entity to attach it to. The kind of flexibility and freedom I gain as an artist by avoiding all that OOP micromanagement is both empowering and motivating. You could write these general-use systems for me (i.e. states / action-lists that need to drill down to the scene-level), letting me later repurpose or modify parts of the systems as I gain experience, and letting you push ECS instead.

    I don't disagree with the gameobjects-first mentality (at least for the initial familiarity), but to obfuscate the importance and the necessity (to-avoid-spaghetti-code) of the ability to query, add, and remove components at any moment to multiple entities at once, hiding it all behind endless layers of outdated inefficient OOP practices -- is something I just can't stand behind.
    ECS is the future, and it needs to be embraced.
    I'm willing to bet, with the right knowledge on when and how to use it, most any user would embrace the query mechanism. While the purpose of this tool is not to "teach" users ECS, a tool developed specifically for ECS scripting will need to take into account (at some point!) whether or not users actually understand how to use ECS effectively in order for them to actually be able to use DOTS to its full potential. -- "Performance by default", remember?


    School may be out, but with all the talented people around here, it's never a bad time to actually get schooled.
     
    Last edited: Apr 29, 2020
  12. ProceduralCatMaker

    ProceduralCatMaker

    Joined:
    Mar 9, 2020
    Posts:
    108
    Not a bad analysis dear Awesomedata, expetially from an art guy!!! HaHaHa!
    Wonder what some "Professional Computer Scientists" at Unity have to say, rather than complaining for long posts,
     
    Orimay, awesomedata and NotaNaN like this.
  13. pcg

    pcg

    Joined:
    Nov 7, 2010
    Posts:
    290
    Thats the first post i've read from Awesomedata (I usually skip long posts) and for me he is right on the money.
    When you watch the tech demos etc we're told to think in terms of data and systems etc but this harks back to OOP.
    I'm a programmer so not really the target audience but as a long time coder I do sometimes get a bit fed up with bashing out code and I was looking forward to this as an alternative especially as the early drops spat out the code making it an excellent learning tool for DOTS.
    I would have thought that an artist does not have OOP ingrained in him as much as programmers so with some helpful pointers (ie some learning resources as Awesomedata mentions above) grasping DOD wouldnt be a problem.

    Just my two-penneth.

    Its early days and the Unity guys are working hard to come up with something using focus groups and feedback here so I'll continue to follow the progress of DOTS VS but as it stands my interest has dwindled somewhat.
     
  14. riffing

    riffing

    Joined:
    Jan 22, 2017
    Posts:
    1
    Longtime lurker here, checking in to say I also liked the visual scripting method presented in Drop 6.

    I followed all of Code Monkey's YouTube videos that covered the Drop 6 paradigm of visual scripting, and was truly excited for what it represented. I felt like I was learning ECS concepts better than through any other method I've tried. And, as a programmer, I was thrilled that I could look at the generated source code and use it as a stepping stone to create my own, more custom and complex ECS solutions down the line. I'm disappointed that Drop 8 moved so far away from these features.

    I understand the dev team needs to consider a broad range of developer/studio needs, and that they have priorities and constraints that I'm unaware of. But if part of the Drop 8 justification is "we need to consider all users, not just those on the forum," then by coming out of the shadows to express my opinion, I hope to lend credibility to the argument that "ideas expressed on the forum might actually be more broadly representative of users than we thought."
     
  15. needyme

    needyme

    Joined:
    Feb 10, 2013
    Posts:
    8
    First, clearly Drop 6 represented the direction many, I included, had hoped the VS project was heading... a tool that can assist developing more efficient and effective game programming and, regardless of intention, teach many non--coders how to better utilize DOTS. It will be well worth the effort to learn. From the limited description of your "target" user, Playmaker is a fine tool for non-coders to "operate on an object". Bolt is promising too. I don't think the "target" user you are focused on will care whether the tool follows the DOD or OOP paradigm, or uses DOTS or FSMs. I understand this is not at the finish line yet but I was very impressed with where you guys were with Drop 6 and sincerely hope that the path forward meanders back toward that again.
     
    Last edited: Apr 30, 2020
  16. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    5,751
    drop8 question and buglogs at random:

    no doc or inline help = send us a test project, whatever you guys testing this on will do, we can reverse it

    GUI feels is very sticky, like having a chewing gum under the shoe, when moving a node - someone's been abusing mouse move threshold

    drag a line from delta time and press space then type "sin" no sine comes up, even by hand so the node filter is broken

    zero visual feedback that the script is saved

    sometimes nodes scroll the view or arrange themselves when added, magic

    love the tracing timeline, how do i increase the length? profiler framecount is at 1000 so this isn't it

    how do I make a generic graph that takes whatever transform the graph is on?

    this graph doesn't move the sphere it's on, i might not be using it proper,
    upload_2020-5-3_18-21-0.png
    gives this:
    Object reference 48A4DAD521766BAA44525561F9A74CB / 5234549275835657130 307693201372378315 references a null object

    oh I figured it out: so when you drag and drop the object it creates a reference field in the script - weird
    upload_2020-5-3_18-34-31.png
    alright now it runs with no error but also doesn't move the sphere
    upload_2020-5-3_18-35-49.png
    this neither
    upload_2020-5-3_18-40-5.png

    not being able to select entities in-sceneview during play is a problem, fixed when?

    if you don't do codegen (huge mistake) at least make the script graph object text and not some funky unity custom soup so we can copy paste it between each other.
     
    Last edited: May 4, 2020
  17. Ofx360

    Ofx360

    Joined:
    Apr 30, 2013
    Posts:
    146
    You have to put an OnUpdate (i think its called that) in the Input of set position @laurentlavigne
     
  18. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    5,751
    @Ofx360 I see, so the execution flow input needs to be fed an event to do things. It must be very easy to program level logic. Is an On Event always necessary in a graph?
     
  19. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    5,751
    bug: I have 2 graphs systems running, I don't see their name in the entity debugger.
    upload_2020-5-4_1-44-34.png
     
  20. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    5,751
  21. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    187
    • no doc or inline help = send us a test project, whatever you guys testing this on will do, we can reverse it
    that's a very good point and something we should have done even for that drop, but we tried to get back to the "1 drop every 6 weeks" timeline.

    • GUI feels is very sticky, like having a chewing gum under the shoe, when moving a node - someone's been abusing mouse move threshold
    noted

    • drag a line from delta time and press space then type "sin" no sine comes up, even by hand so the node filter is broken
    already fixed

    • zero visual feedback that the script is saved
    • sometimes nodes scroll the view or arrange themselves when added, magic
    • love the tracing timeline, how do i increase the length? profiler framecount is at 1000 so this isn't it
    • how do I make a generic graph that takes whatever transform the graph is on?
    we have openend issues for that, all of these should be fixed next drop or the one after

    • this graph doesn't move the sphere it's on, i might not be using it proper,
    yes, you're missing some event to trigger it

    • not being able to select entities in-sceneview during play is a problem, fixed when?
    Known issue, but broader than VS, so won't be fixed by us.

    • if you don't do codegen (huge mistake) at least make the script graph object text and not some funky unity custom soup so we can copy paste it between each other
    Cross-graph copy-pasting will be supported. Btw, codegen would prevent people to ship code-less DLCs/updates. We might come back to it later, but it doesn't cover all contexts.
    We didn't ship any optimization on purpose in this drop. we want the runtime to be feature complete before we optimize it, as optimization slows down our iteration speed. now don't panick - we didn't pick a architecture blindly, we did optimize the heck out of it on a branch to prove it WILL be fast :)

    Thank you for your time and reply !
     
  22. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    Hippo is always watching. The fleet gazelle will skip the river :D
     
  23. needyme

    needyme

    Joined:
    Feb 10, 2013
    Posts:
    8
    With the announced Unity purchase of Bolt, does this imply that the DOTS VS can revert to be closer to the Drop 6 approach and Bolt will be a preferred path forward for non-DOTS VS? If so WIN + WIN!
     
  24. ans_unity

    ans_unity

    Unity Technologies

    Joined:
    Oct 12, 2017
    Posts:
    124
    This is basically the full realization of the strategy we announced last year when we moved the development of visual scripting to DOTS. We are very happy to work with Ludiq to transition development of Bolt and Bolt 2 over to Unity to support users of the current architecture.

    The changes we made to DOTS VS in the latest drop are intended to solve DOTS authoring workflow issues. These DOTS specific issues still exist even if we support the current architecture with Bolt. So to answer you question needyme, it doesn't imply that DOTS VS will revert to a Drop 6 like approach.
     
    Tanner555 likes this.
  25. steve_zeng

    steve_zeng

    Joined:
    Aug 6, 2019
    Posts:
    22
    I think DOTS VS and Bolt should be independent, one representing the present (in 5 years) and one representing the future.So, the two don't need to merge!
     
    awesomedata likes this.
  26. steve_zeng

    steve_zeng

    Joined:
    Aug 6, 2019
    Posts:
    22
    However, in some convenient operations, the two can be integrated with each other, so as to facilitate the later transition between them and reduce the difficulty of learning DOTS VS.Just like SG should learn the convenience of ASE, some operations of SG are more complex than ASE!
     
  27. aganm

    aganm

    Joined:
    Sep 25, 2019
    Posts:
    114
    Why isn't this downloadable through the Package Manager like other DOTS packages?
     
  28. UsmanMemon

    UsmanMemon

    Joined:
    Jan 24, 2020
    Posts:
    87
    Now with bolts aquisition VSDOTS focus might change to not be OOPish but be dotsVs(with authoring workflows and maybe a bit OOP) now the problem of turning away from OOP is gone and focus of development team will change ofcourse.
    they dont have to worry about oop people.
     
    Last edited: May 4, 2020
  29. ans_unity

    ans_unity

    Unity Technologies

    Joined:
    Oct 12, 2017
    Posts:
    124
    Because DOTS VS is too early and experimental to expose to a wide audience. It will be made in a regular package before official release.
     
  30. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    3,263
    My hope is that playmaker will still survive as I have been using it for ten years and I don't see how I can make things in unity without it anymore.

    Now that unity has bolt and its own visual scripting, playmaker may be bought less if people start using the native tools.

    It think it would be good for unity to give playmaker credit for being the first and still being the most supported finite state machine solution for unity. and to make sure they don't drown the the bottom of the well.

    I still have not been able to switch to unity visual scripting as it still feels less quick to make my gameplay interactions.
    Im looking forward to see where unity visual scripting is going and will keep trying the new drops
     
  31. createtheimaginable

    createtheimaginable

    Joined:
    Jan 30, 2019
    Posts:
    29
    Wow! This is almost as big as Aliens landing on the White House lawn! :)

    Is it too soon to tell us how this changes the Unity Visual Scripting Road Map?

    Unity Technologies acquires Bolt - https://ludiq.io/blog/unity-acquires-bolt
     
    awesomedata likes this.
  32. needyme

    needyme

    Joined:
    Feb 10, 2013
    Posts:
    8
    First, thanks for the responsiveness you and other Unity staff posting in these threads have provided. So where on the timeline/roadmap do you think the re-introduction of ECS queries mentioned in the excerpt above could occur? I understand this is a best guess. Thanks again.
     
  33. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    5,751
    Tell us more about that.
    Also anything about modding support? That is such a super killer selling point that even if you run 90 spheres at 20fps I'll be happy.

    Awesome!

    Cool.

    How will visual graph work with multiplayer? Is there a bytepacking + send [] like the excellent SNS PUN2?
     
  34. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,415
    This is fair, but I want to reiterate my thoughts from my previous post:

    @ans_unity:

    What do you guys think of the above-mentioned (general-purpose) "communication bridge" approach (in bold)?
    With such a general, data-driven approach, instead of nodes, the only thing you'd need to "abstract" from users would be the job portion, and perhaps a system to allow components to be added/removed from entities freely anywhere. As a by-product, this approach would improve general scene-and-project-level system and component authoring capabilities as well as user-level workflows.

    This route would shake the OOP bear off your back while now allowing users to modify underlying systems when a user needs to tweak them for their own purposes (which seems to be quite often for many). For example:
    The SceneView camera is a "system" I spent a LOT of time trying to modify. But with all the "internal" keywords and other aspects of the editor camera I was not allowed to override or rewrite, I had to reinvent the wheel and simply make that ALL from scratch again. With a straightforward system with minimal references (i.e. TWO references, to be exact -- the camera transform and the input system), I could have saved hours of work (and a couple of weeks of research!) digging into the source code for an undocumented API (at the time) just to find out I couldn't modify it at all and had to rewrite the whole convoluted system from scratch anyway. After all -- there was a reason it was convoluted. It needed to bypass the keyboard repeat rate for WASD flymode. This wasn't (isn't) straightforward either. Too many references to count to bridge these systems.
    All so I could have tolerable motion on the camera in the SceneView.

    How a "communication bridge" system works from an Input System to a SceneCameraController:
    With just one entity having a "CameraController" component on it, I could have plugged into the Input System via a "communication bridge" bridge system (i.e. CameraController) to find all entities with respective "communication bridge" bridge components (i.e. CameraController system finds CameraController components). This pattern then lets the CameraController look for an ActionMap -- CameraMovementW (or A,S,D) -- added to the entity independently by the Input System (bridging that to the entity with CameraController (and Transform) components via the CameraMovementW looking for entities with a Transform and a CameraController component, "moving" the Transform in the "Forward" direction, letting the Input System pretty much communicate directly with the CameraController entity -- all with very little effort.

    It's worth noting that the way you guys did it was some voodoo magic to get the kind of speed on WASD keypress that mere mortals like me could never hope to achieve when we simply want to avoid the keyboard repeat-rate issues.


    Beyond that, I have two things I am questioning here:

    • I truly believe your approach should not be focused on abstracting the individual "node" level for the sake of a (very subjective) workflow ideal --

    • I believe your efforts should instead be focused on providing general-use intermediate "systems" (and job-level abstraction) that pulls different (user-made) systems together.


      In other words, you guys should provide the tools to pull together (for example) a user-tweaked state system with a user-tweaked behavior tree system and any custom-user system, using the ECS programming ethos that enables a user to write ANY system and query from ANY OTHER system to know about that specific system's component data (via loosely-related components). Entities who have this loosely-related component tag -- a "communication bridge" component -- lets the entity to loosely "register itself" via the "component" with any system who knows about this component, meaning it can look for any entity who dons that particular special component (which can be added or removed at any time to enable a "communication bridge" between systems for the duration of that component on the entity (whether temporary or permanent.) There should be a generic system for linking together these special "bridge" components with their respective systems so they know about (and can quickly reference) one another.

    To understand what I mean by a "communication bridge" system in a practical example, see my description above on the SceneView camera problem. This should be the default way you guys think about interrelated systems in Unity already!


    TL;DR:

    To simplify the above spoilers/systems so anyone can understand:

    1. The entity broadcasts "I have THIS data for you!" (by having a component another system knows about)
      EXAMPLE: The entity might have a "GetPoisoned" component added (by some "projectile" system).


    2. The system responsible for "bridging" that particular data says "I need all entities with THAT system's bridge component to now have THIS action component!" (which can be temporarily or permanently added to the entity)
      EXAMPLE: A bridge system might be responsible for removing the temporary "GetPoisoned" bridge component and adding a proper "Poisoned" action component to the entity who is now "actually poisoned". As long as this component exists on the entity, another system will ensure the displayed model will be purple.

    3. Finally, the system acting on that entity data says "I need all entities who have THIS (bridge) and THAT (action) component to do THIS very-specific action.
      EXAMPLE: A system that handles status effects would add a "DecreaseHP" component to the entities who have "Poisoned" components, and a particular value would be set for that entity's poison damage via the component.

    To simply "subscribe" to different systems like the example above (by adding a particular components as "levels" of data drill-down to get to a specific action) should pretty much be how people program heavily interactive systems. That system (even with its back-and-forth) is simple to understand -- and easy to write! This is essentially (dynamic!) breadcrumbs with parenting (AND inheritance), simple abstraction (AND encapsulation) -- all rolled into one nice, amazingly-performant, package. And a simple query (or two) gets you to ALL of that data (and behavior) -- instantly.



    Which brings me to my main source of frustration with this discourse:

    How does "make abstract nodes" equate to a "user-friendly" DOTS Visual Scripting solution?



    -- It's just data.



    Input and Output.
    Years of rigid-thinking and OOP indoctrination tend to drive a need to make data more complex than it needs to be!

    You simply need to manage it better. -- That's IT.



    EXTRA CREDIT: Timing and Coroutines in ECS!
    You don't need special language-based things like Coroutines when your systems run in parallel (and across all objects/entities) anyway, but if you DO somehow need to control your code flow (breakpoints, timing, etc.), I don't see why a system can't be setup to handle those sorts of things and change data when "tagged" to do so by a (TEMPORARY) component being added to let the system find it and act on it. States should work the same way.

    If we're being real here:
    What is there not to love about using "communication bridge" systems to cover tedious code behavior and workflow?
    If a node or system needs to be jobified, let the user check a box on the node or graph (to have a system automatically add a component that lets a hidden-or-buried system generate "jobified" code for the particular node or graph to use at runtime.) If a node or system needs to know about a scene or project reference, just let the user drop the reference, and "tag" it to a particular GUID or GameObject, then at runtime, load the relevant assets or systems. I'm sure you're already doing this right?
    I don't see how hard it is to see this obviously user-friendly ECS workflow (which works for new and old users alike!)
     
    Last edited: May 7, 2020
    Orimay and landonth like this.
  35. landonth

    landonth

    Joined:
    Dec 3, 2018
    Posts:
    137
    @ans_unity I'm curious, will this be because Visual Scripting Graph will adopt an intuitive built in split / join widget for vectors on any given node like Visual Effect Graph already has?

    I'm hoping that this will be adopted by Visual Scripting Graph and Shader Graph, to improve not just functionality but greater UI/UX consistency across Unity Editor's node graph based development tools. I get that some things will be unique or domain specific to each graph type, but wrangling vectors is a perfect use case for something that by all means can and should be largely consistent Editor / Engine wide.

    The way Shader graph currently handles this has similar issues, but I haven't gotten any inkling from anyone at Unity via Customer QA or the Forums as to what the plan or vision is exactly, or if it hasn't been determined yet (which is fine, too.) But what you are saying leads me to believe your team may at least be approaching a solution convergent with at least one of the other node graph packages, intentionally or unintentionally.

    You can see some marked up screenshots here comparing the disparate node graph user interfaces to see exactly what I'm referring to: https://forum.unity.com/threads/swizzle-node-usability.752291/#post-5726695
     
    Onigiri likes this.
  36. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    187
    We already have an issue for that ! We're aware of the disparity too.
     
  37. Z_Kir

    Z_Kir

    Joined:
    Apr 9, 2017
    Posts:
    9
    It happened week ago. I think we'll get more information soon.
     
    createtheimaginable likes this.
  38. Ofx360

    Ofx360

    Joined:
    Apr 30, 2013
    Posts:
    146
    Glad to hear!

    If it matters at all, to me, VFX Graph is the golden child so far. I hope Unity is looking to that for the direction of this and future graphs
     
    landonth and createtheimaginable like this.
  39. jayanam_games

    jayanam_games

    Joined:
    Jul 9, 2013
    Posts:
    44
    Can we use it with Unity 2020 Beta? Can we just import the package?
     
    createtheimaginable likes this.
  40. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,415
    I think we already did:





    That said... I'm still curious of my earlier question about workflow:

    Rather than focusing on simplified nodes as your entire approach for DOTS Visual Scripting, why not simply go with a bridge system approach (as described above) to enable a sort of "loose data-swapping" between independent systems by using special (perhaps hidden?) components (and data) as well as their respective bridge systems (i.e. a system that will index all the entities in the scene view or project view so that you can "tag" a particular scene or entity index with one of your own logic components -- i.e. like GetPoisoned -- so you can execute your own systems via any intermediate tags you place on them (i.e. all entities with GetPoisoned now have Poisoned component, and the PoisonSystem can start damaging these Poisoned entities when its ready after a certain number of seconds/frames.) The timing of the seconds/frames would require a "bridge system" (i.e. TimerSystem) that would "tag" a specific entity with a hidden Timer component that is a special "bridge component" used only in the TimerSystem (which is a "bridge system"). The Timer "bridge" component's data was set to a certain value via a WaitTimer node in the user's PoisonSystem when a GetPoisoned tag was added to a particular entity (i.e. the entity with the Player component tag). The PoisonSystem could simply check the particular entity for a new (public) WaitComplete tag to deal that poison damage to the respective HP data and the Visual Script graph returns to / flows back to the WaitTimer node again which adds the "Timer" component again. A side note: the WaitComplete tag was generated by the hidden TimerSystem "bridge system" on the entity as a convenience for the user. The user can check for this new "public" tag component in their own systems (via an ECS query) to perform the next action (or damage sequence event) in the PoisonSystem.
    And so on and so forth.
    This could easily be extended to a StateMachine's "bridge system".

    This would easily allow for "drill down" parenting and inheritance using component tags (rather than complex if/then/else networks with for loops) while also allowing less spaghetti-code, which enables an OOP workflow (both from a stupidly-specific scene-reference angle and from the incredibly-general ECS query drilldown angle -- assuming you've written the respective bridge components/systems), leading to both kinds of reference mechanisms being easily-supported in the same DOTS Visual Scripting package. In other words, why not have "simple nodes" and "simple architecture" as well as "simple inheritance" alongside "simple references" -- to enable either of the afforementioned OOP workflows (whether super-specific or super-general) with the correct underlying architecture. With the "bridge system" approach I have outlined over the course of this thread, this result is both possible and easily-attained.


    I would like to know if this kind of "bridge system" approach is being considered -- and if not, why not?

    If you are considering the feedback from drop 8 (which I hope you are!), it seems to me that if a "best of both worlds" approach to both workflow styles (local and global) can be achieved so succinctly, it's a no-brainer to go this route rather than just ignore it and continue hashing out "simplified nodes" (which is clearly not working for reasons I and many others have pointed out.)
    If this is what you guys are planning already, I will gladly stand corrected and take my leave. I simply would like some idea on your direction. I would really like to be happy about DOTS Visual Scripting in Unity, so to help you help everyone, I have proposed a technique (above) that can be used to satiate both the wider user-base as well as your internal feedback team's workflow requirements.
    If there is a problem with the bridge approach I've mentioned, please respond and let me know what I'm missing.

    Thanks!
     
    Last edited: May 11, 2020
    landonth and NotaNaN like this.
  41. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    187
    Just to be sure I understand: a wait node in a graph would add a Timer component to the entity ? allowing only one wait per entity at the same time ?
     
  42. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,415
    To keep the length of my posts down, this was a very stripped-down example of how a "bridge" system and component interaction could work for a Wait node. But since you asked, a Wait node could just as easily tag the entity with other (possibly hidden) user-accessible data components relevant to the Wait node's needs to bridge it with as many other systems as it needs. TimerSystem was just one system/component interaction with the Wait node, but more complex nodes probably need one or two more systems to achieve a particular desired behavior, which would be standard practice. In general though, a system only requests the data / entities it needs, and modifies them from inside that same system based on what components are used in the entities in question. If each script were a system (which is what I am suggesting), combining them would be as easy as letting a character controller system do its thing, an enemy system do its thing, and so on and so-forth with animation and physics too -- no need for a central gameobject except for use as an "in-scene" reference -- while everything else, such as the Wait node, adds/removes only components that are relevant to the relevant systems the node needs in order to process its respective data.


    A system to handle many timers at once could, for example, simply require a Timer component that holds an array of ints that determine both how many timers the entity has, as well as which "tick" the timer is on (set to an initial value for the entities via the Wait node in the system graph). The WaitComplete tag would also hold an array (of the particular timer indexes that are considered "complete") and each timer could be "cleared out" in the systems that use them (i.e. by letting the PoisonSystem set the Timer "tick" value to -1, indicating to the TimerSystem that it can remove the Timer component if there are no other Timers in the array that are not -1). This means that a TimerSystem eventually removes the WaitComplete tag too after either all indices in the Timer array are set -1 or after WaitComplete contains all indexes of the particular entities' Timers -- whichever is more useful to the particular system graph. The great thing is that the user can go modify the TimerSystem system graph (Visual Script) if she/he doesn't like this timer behavior.


    A system graph (or in other words, a Visual Script, like the PoisonSystem for example) could simply stay on its Wait node until its Timer index (decremented by TimerSystem until it reaches 0, then adding its index to a WaitComplete component on the same entity). At this point, the node could either transition to the next node (i.e. deal poison damage) and reset the timer by looping back to the Wait node so it can eventually deal poison damage again after a short while.
    The node (since it is not a system in and of itself, but is instead a collection of systems/components bridged together), could also cancel early if another condition (provided as a secondary input to the Wait node) arises, which immediately tags, for example, the entity with a TimerAborted component, which the TimerSystem uses to immediately set the Timer for the particular Wait node's timer index to -1, and removes the TimerAborted component without generating the WaitComplete component, allowing the TimerSystem to handle removal of the Timer component automatically (depending on whether there are any outstanding Timers on the Entity), letting Wait node to take an alternate path from its node position in the system graph when it is interrupted (for example by a GetCured component).

    As an alternative to continuing from the Wait node on the next frame, the graph could simply start execution from the very beginning of the graph the next time it is executed (i.e. OnUpdate vs Coroutine), depending on how the user wants to treat the system graph. Both methods are handy, and both have different implications (and uses) for what form the node should take in terms of how it proceeds (or not) to the next node in the system / graph. Ideally, it would be smartly enough designed to know which style graph it's sitting in to know how to handle itself, but that would ultimately be in the discretion of the logic surrounding the systems/graphs/components the node associates itself with. A coroutine would better serve a Wait node in most cases dealing with a StateMachine system, but a "parallel" wait node could be handy too to "gate-off" logic in certain cycles depending on what components are added to a particular entity. In other words, as an alternative (possibly more ideal!) implementation, the PoisonSystem (now AilmentSystem) could now use Wait nodes for _every_ status ailment simultaneously (i.e. Sleep and Poison), and until a Poisoned component (or Sleep component) is added, neither effect would be active, stopping at the Wait node. However, with a Poison component, the graph would continue executing past that particular Wait node. Though, it'd be more akin to a "WaitForComponent" node in this case I suppose, and would be faster to query than a specific group of components.

    Overall, a graph could easily be full of state nodes, input nodes, specialized nodes (such as a Wait node), or simply component query nodes that enable data changing or component adding to the entities-in-question all-at-once.
    The overall idea is that a node (like the Wait node) would be built up from the same, simple, data-oriented components and systems as all the other systems users use to build their logic. The critical difference is that, with nodes, data is "translated" via logic (passed around via "bridge" systems and components), rather than "converted" via very discreet data references (passed around and modified from object-instance-to-object-instance).

    In other words, instead of constructing webs of meaningless references, you'd be constructing logic.



    As an example of how powerful this can be -- Timer data/processing in the example above could (in theory) even be done with entities themselves (i.e. a set of Timer entities) rather than as an array attached to a component. Assuming there was a hard limit on NativeArray resizing/etc., this could be handy. I don't know how performant an entity version of that node would be, but the important thing is that you could. This is because you are designing meaningful, high-level, logic -- and not empty references.


    Some extra credit (and food for thought):

    "As above, so below." -- It's kind of a natural law.
    Logic doesn't govern hierarchies; it governs endless fractals and mathematical beauty that defines nature itself.
    As everything can be reduced to numbers and patterns, numbers and patterns can also be extrapolated to logic.
    We've been working backwards with OOP using references (as default).
    The approach I am trying to convey covers the whole spectrum of data, from numbers and patterns all the way up to logic and reasoning -- something that is sorely missing from computer science these days (IMHO).

    The translation of data into logic rather than passively converting empty data into empty data references (to ultimately become meaningless spaghetti-code) could be used in other ways. For example, a single entity could be used as a global "control" system (rather than just a "bridge") just as gameobjects sometimes are to govern all entities needing very complex interactions using loosely-related component data. This could be the equivalent of a global "gamecontroller" object. But with a set of "bridge" system and component interactions, you can (more easily) get that kind of behavior with a single system or two, so I wouldn't recommend going out of your way to manage data in this way with ECS.
    Most systems NEVER need this level of micromanagement (except in very special cases -- i.e. when referencing scene data from multiple scenes or specific project assets from the hard disk). Usually only two or three (perhaps up to five AT MOST) component levels can be stacked to define how deep your system logic goes. This is because, beyond 5 layers deep (some would argue 3), you are no longer dealing with the same level (or even the same order of magnitude!) of data anymore and need a very different method of managing and controlling things than you had before.

    Below 5 layers deep would be like defining the logic of how a set of protons/neutrons should operate an aircraft. A human (composed of protons and neutrons, which you don't care about) operating an aircraft would be MUCH easier to define the logic for. Unless you're a quantum physicist, you likely don't care about protons and neutrons, much less how they operate an aircraft. We tend to naturally use the lowest-level data (protons/neutrons) as the base level of operating logic to define how one system "talks" to another system when we are first coming to understand it. In my case, I would rather define how the human "talks" to the aircraft controls instead of how the human's protons/neutrons "talk" to the aircraft's controls' protons/neutrons. That's just me. But the way we program now, if you screw up on your "order of magnitude" on how you access your operating logic at the lowest-level -- your whole system network is screwed. With ECS, this doesn't have to be the case. In ECS, operating logic is whatever order of magnitude you need it to be at any given time.
    Without this flexibility and control, authoring scripts leads very quickly to what I am pointing to when I emphasize how much I HATE "spaghetti-nightmare" code.
    The moment you add just one more layer of complexity to an already "complex enough" (non-ECS) system (which, by the way, by its very design, is what every OOP reference does), you will have stumbled upon a spaghetti-nightmare monster in the depths of your newfound complexity (your operating logic) that will never stop chasing you.

    Be warned.
    Without the sword of logic of the highest level to vanquish the spaghetti-beast by cutting-off its many serpentine heads of evil spaghetti-references, its steel-plated scales forged by the souls of the hoardes of undead-zombie programmers it has claimed to will be your undoing.
     
    Last edited: May 13, 2020
    NotaNaN likes this.
  43. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    187
    You can't store arrays in components - C# arrays, NativeArrays, won't work. A buffer element might work, but the cost of adding/removing anything to an entity is prohibitive, so I don't see how that would work
     
  44. schovan

    schovan

    Joined:
    May 24, 2016
    Posts:
    4
    I opened this project in Unity 2020.1 and got 689 errors. How do I fix this? Or how do I start Visual Scripting project in Unity 2020.1?
     
  45. ans_unity

    ans_unity

    Unity Technologies

    Joined:
    Oct 12, 2017
    Posts:
    124
  46. Ashkan_gc

    Ashkan_gc

    Joined:
    Aug 12, 2009
    Posts:
    1,089
    I was checking this to see how it looks like for our designers.
    If you might get rid of codegen then what are you going to add? some system which makes the graph as simple as possible with its own byte code to execute at runtime? The bytecode could essentially be some visual scripting internal components processed by a set of systems processing visual scripting but are going after that? how custom node development would be done in such a scenario? Forgive me if i'm getting ahead more than what I should and you'll deal with these later on.
     
  47. Vectrex

    Vectrex

    Joined:
    Oct 31, 2009
    Posts:
    251
    But, it IS a major use for it. I'm a coding teacher for 15 years.
     
  48. Vectrex

    Vectrex

    Joined:
    Oct 31, 2009
    Posts:
    251
    [QUOTE="we need to remember that Unreal Blueprints are widely accepted by the artist community[/QUOTE]

    I disagree. People who use Unreal are used to it, whereas the industry as a whole is vertical (for good reason). Nuke, Houdini, Scratch etc etc. If Unity are just a half baked copy of Unreal, why would anyone use it? It needs to be BETTER and copying Unreal will never make it better.
     
    landonth, TextusGames and NotaNaN like this.
  49. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    187
    Kinda. we're using a different graph representation at runtime. I have a prototype of that representation being burst compiled at runtime.

    Custom nodes are written the same way we write nodes (see INode/IDataNode/IFlowNode)
     
    Ashkan_gc likes this.
  50. aabrownjr

    aabrownjr

    Joined:
    Apr 22, 2017
    Posts:
    4
    Is there a Ongui node? If not ow do i call the OnGui method from the visual scripting engine??
    Also, on a unrelated question,is there a node for UGUI (Unity'ss Canvas UI system)?
     
Thread Status:
Not open for further replies.