Search Unity

  1. Get the latest news, tutorials and offers directly to your inbox with our newsletters. Sign up now.
    Dismiss Notice

Unity Visual scripting roadmap update - September 2020

Discussion in 'Visual Scripting' started by LaurentGibert, Sep 28, 2020.

  1. Timps

    Timps

    Joined:
    Jun 23, 2017
    Posts:
    11
    Is there an ETA on this at all Laurent?
    Bolt needing scripts to talk to the input system is maddening.

    I completely understand it's a complex roadmap but it feels really odd that input is completely unsupported by Bolt.
     
  2. kodagames

    kodagames

    Joined:
    Jul 8, 2009
    Posts:
    546
    • We’re preparing improvements to variable management, addressing referencing through magic strings, strong typing, in order to consolidate and better align with the Graph Tools Foundation data model.
    • This along with higher level nodes for non-programmers is enough to bring me back
     
    Kennth and LaurentGibert like this.
  3. LaurentGibert

    LaurentGibert

    Unity Technologies

    Joined:
    Jan 23, 2020
    Posts:
    140
    Yes I agree this is a major gap. I can understand the desire to hear a date, but we can't give you one. The only thing that is possible to say is that were working on this right now, with a mindset of ASAP.
     
    Timps and Kennth like this.
  4. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    2,985
  5. banan1234

    banan1234

    Joined:
    Mar 31, 2018
    Posts:
    124
    At least this time they said they will focus on the performance and might implement code generation If the snippet solution won't be enough. Another thing, they postponed DOTS VS until the base architecture for mono will be complete. Plus we are going to get a real product roadmap like with graphic tools.
    The only bad thing about the whole decision is that bolt 1 is still going to be a terrible tool until at least 2021.

    Right now, the biggest question mark is this whole Graph Tools Foundation and the concept of unifying. It is really nice to see that all of the tools are going to work under one API. I hope, since then, all of the graph tools are going to have the same features.

    The more important thing I hope Unity will do is redesigning all of their graph-based tools. Bolt 2 gave us many UX improvements, vertical flow, features that previously existed for programmers, better organization of big graphs with classes and functions. Overall the developer of bolt 2 tried to make visual scripting look cleaner, especially with the bigger graphs. Both the shader graph and VFX graph should be redesigned with some principles bolt 2 has brought to us.

    And also, what about multithreading? Even if the upcoming visual scripting is going to be noticeably slower than the code, then at least it could be saved with multithreading.
     
  6. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    2,985
    The concept of Graph Tools Foundation is great, I hope that the UI will be customisable for users, for example setting a custom color of the graph background from the unity preferences.

    Right now the black background is too dark for me and I would like to set it to a shade of grey.

    I also have one request, let the user set a custom background image per graph, and pin this to the graph anchor position. this will let users make easy to identify graphs.
     
  7. patrickf

    patrickf

    Unity Technologies

    Joined:
    Oct 24, 2016
    Posts:
    54
    @fherbst It is a bit early to discuss GTF. Our main focus right now is to address internal needs; the feature set of GTF may evolve significantly over the coming year.
     
    stuksgens and LaurentGibert like this.
  8. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    779
    I would like to just have a sneak peek of it. Does it develops based on DFG?
     
    LaurentGibert likes this.
  9. patrickf

    patrickf

    Unity Technologies

    Joined:
    Oct 24, 2016
    Posts:
    54
    No it is a UI framework.
     
  10. fherbst

    fherbst

    Joined:
    Jun 24, 2012
    Posts:
    755
    @patrickf well, since GraphView seems to already be kinda deprecated as foundation for user graph tools, I think you can understand that there's a desire to understand more about where (and when) GTF is going.
    Or can we assume that GraphView stays and keeps being supported? (It's not very helpful for people trying to get stuff done that Unity is hopping from one experimental thing to the next.)
     
  11. Ex-Crow

    Ex-Crow

    Joined:
    Aug 14, 2020
    Posts:
    111
    Correct me if I'm wrong, but the roadmap doesn't seem to mention anything related to Bolt 2's Graph Search functionality. Is that or something similar still in the cards?
     
    banan1234 likes this.
  12. LaurentGibert

    LaurentGibert

    Unity Technologies

    Joined:
    Jan 23, 2020
    Posts:
    140
    We need more time to come back with more details on Graph Tools Foundation. We'll make sure to include updates about it in future communications.
     
  13. xandragames

    xandragames

    Joined:
    Jun 11, 2019
    Posts:
    8
    awesome, thank you :D
     
    LaurentGibert likes this.
  14. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,296
    Also let this image have the option to be zoomed in/out of too (if you don't mind) -- Definitely necessary in some cases.
     
    LaurentGibert and Lars-Steenhoff like this.
  15. Kennth

    Kennth

    Joined:
    Aug 11, 2017
    Posts:
    59
    Does this mean that Bolt will always have reflection as a means to get all third party coded assets to work together ?
     
  16. LaurentGibert

    LaurentGibert

    Unity Technologies

    Joined:
    Jan 23, 2020
    Posts:
    140
    Yes reflection is a critical part of the visual scripting workflow to ensure proper support of custom/third party API, or simply APIs for which we don't have a high level node available yet. Does this answer the question?
     
    Kennth likes this.
  17. AndrewKaninchen

    AndrewKaninchen

    Joined:
    Oct 30, 2016
    Posts:
    149
    I'll ask again, shorter this time, as it seems like my first post has been ignored:

    What are the current plans regarding class-orientation features? Is it all in the trash for now?
     
    Stexe and LaurentGibert like this.
  18. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,296
    Fair enough -- I was talking about combining both DOTS and Monobehavior-land in a single, end-to-end, workflow, which is similar (at least visually) to how UE4 Blueprints' class structure interacts with Actors.
    UE4 Blueprints essentially have more of a Bolt approach (i.e. nested graphs nested inside even more nested graphs) though, so I can see why this doesn't appear that similar to you.

    That being said:


    @LaurentGibert:

    I just want to point out that the nested graphs nested inside even more nested graphs is a terrible UX pattern, and will end in ruin for users if not taken seriously.

    Additionally, this method of 'abstraction' is workable in theory only -- that is, if you want performance too.

    As someone else mentioned in this thread, there is always a step after using Blueprints in UE4 where everything node-related is eventually converted to C++ (for performance reasons), which is why most of us want codegen so passionately. "Interpreted" code is generally not so performant. We want something on-par with (or better) than C#. D:
    I don't want to argue against codegen, but rather than @Unity or @LaurentGibert blindly saying "Sure! -- In 5 years, we will add codegen!", I just propose the codegen 'solution' be re-evaluated. The root of the problem (performance) clearly dictates that an alternative answer is needed (by Unity) to grasp the holy grail of both intuitive and performant. Everyone wants an intuitive VS solution as soon as yesterday -- but to make that performant would require some wild programming, excluding some features/options in order to include/satisfy others. But despite the popular opinion that VS needs concessions, either to performance or intuitiveness in order to achieve ECS-like performance, I am arguing against that notion.

    After studying all the options myself, I've established that the only viable approach to a scalable, (performant) designer-friendly (sensible) UX, would have to revolve around using DATA and SCOPE as the key "language" for the tool in question. It has nothing to do with whether we use an ECS or Monobehaviour approach -- The DATA itself, as well as the SCOPE of the data we use, needs to be as fast/easy/efficient to both get at -- and modify -- from both a hardware and user standpoint.
    This means we need to get as close to the metal as possible with our scripting for performance, as well as getting as close to the LOGIC as possible for intuitive, designer-friendly, usability. The nested nests of nodes inside more nested nests of nodes "for abstraction purposes" approach is 100% against intuitiveness and usability.

    The way to do the latter (with performance as key) is make the UX as much about the data as possible -- meaning that most things are going to be performant (by default), if we use ECS-style concepts combined with user control over scope (i.e. gameobjects are not enough -- dataless "Tags" and a "Page" concept are better for building the scope of queries). This, combined with only accessing data when/where we absolutely need to (and in as widespread of a way as possible -- i.e. all at once) by default (by using actual data queries that simultaneously perform update modifications to all the data at once OR buffer and write that data on the next cycle or frame all at once, to update that specific data when the data is extremely specific, such as with the FireMario example). This invisibly coaxes users to drill down only when absolutely necessary. This is how AAA studios handle their frames/CPU cycles for performance -- so why not us too? -- Performance-by-default, remember?

    Don't you agree, @LaurentGibert?


    This should be the workflow standard -- which is why that UE4 / Bolt 1 / Monobehaviour approach is something I've fought against since its inception in drop 8.

    Granted, it's familiar -- but @Unity is promoting terrible habits for new users w/Monobehavior-as-default -- habits that took me YEARS to break when I started playing with GameMaker in the mid-90's. That software's strength was its flexibility, but that free-form flexibility was also its curse. Everything was (game)object-specific, and I only later realized my games wouldn't scale without some special thinking/techniques I didn't understand at the time. I eventually came to Unity to escape that aspect of it -- and now it drives me mad that Unity is just repeating history for me. You guys won't get away from gameobject-centric programming even though I (and many others here) have been telling you that we're not okay with this -- and why.


    That being said -- where UE4 fails me (and why I choose Unity over Unreal -- and still do), is that, although their "class" structure and nested graphs are close to my own systematic thinking, they are also too "Actor"-specific. While yes, I can see the allure of programming for ONE entity -- and only one entity -- you lose the benefits of the one thing that makes something like NestedPrefabs so powerful -- That is, you lose the ability to choose between changing many things at once, or only a single thing at a time. With NestedPrefabs (or my VS approach), this is a choice. With a class-structure (and backwards, C#-like inheritance), this is an obstacle. I feel like I'm fighting the language / syntax when all I really want to do is just write my LOGIC.

    When this trickles down to a Node-based approach -- without the "Tag" system implemented in the way I explain, I now have to know what the hell the node itself is doing behind the scenes. Unless you get super-granular with the syntax, you can't know this. With existing node-based approaches, you have to drill down forever just to see what's going on. However, when, instead of abstracting away the syntax to make high-level "logic" of nodes easier to understand, you use high-level logic itself as the syntax (using the Tag system) instead, letting that logic be separate from the behavior itself, it is clear to see that things suddenly become very easy-to-understand. You are no longer endlessly drilling down into your nodes to see what the hell is happening; Instead, you are only drilling down into the systems you actually intend to modify! When you can "Tag" an object as a "Player", but later decide to turn him into an "NPC" or "Enemy" (i.e. for story purposes), and all you have to do is change a "Tag" -- You just saved one hell of a TON of "if" and "then" statements (and other convoluted gameobject hierarchies, etc.) that weren't necessary to begin with! -- And this is a level-specific or story-specific change. These ECS-like OOP practices are just freaking amazing for your codebase.

    So it might be worth it to listen-up, and take heed of this methodology -- instead of pigeon-holing your thinking (and your solutions), @Unity guys.

    It might even save a bit of work down the line for you too. D:
     
    dre788 and stuksgens like this.
  19. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    171
    Reflection has to be used in the editor as a mean to discover third party assets, but not necessarily at runtime. A potential solution would be to codegen nodes for used 3rd party APIs. Those wouldn't use any reflection during execution.
     
  20. Timps

    Timps

    Joined:
    Jun 23, 2017
    Posts:
    11
    Thanks Laurent.
    Most of us know this is a big project with a LOT of parts.
    Knowing you guys see the gap and want to close it is great news. Thank you.
     
    awesomedata, Kennth and LaurentGibert like this.
  21. LaurentGibert

    LaurentGibert

    Unity Technologies

    Joined:
    Jan 23, 2020
    Posts:
    140
    Sorry @AndrewKaninchen, we didn't mean to ignore that question. I interpret "class-orientation" as a scalable data model, both for workflow efficiency and project scalability. So in that regard, yes. The work on variable management, including addressing referencing through magic strings, strong typing, or scoping, as well as the work on delegates and events, are all fitting in our consolidation of the data model similarly to the concept of classes. This is work in progress to finalize the model, so more details to come.
     
  22. davincilab

    davincilab

    Joined:
    Aug 8, 2017
    Posts:
    15
    (This is probably discussed earlier but I didn't get it due to unfamiliar technical terms)

    I am wondering is there anything in plans for improving the performance of the graph. Meaning, the performance of the editor drops as the graph gets bigger.
     
    LaurentGibert likes this.
  23. Ex-Crow

    Ex-Crow

    Joined:
    Aug 14, 2020
    Posts:
    111
    That is in their plans. The whole UI front end and back end will change, eventually. And I believe some short to medium term optimization is also happening. Bolt team members have stated in Discord that they'll do an optimization pass on every aspect of current workflow from authoring graphs to generating units for custom types, etc.
     
    Last edited: Sep 30, 2020
    Kennth, davincilab and LaurentGibert like this.
  24. LaurentGibert

    LaurentGibert

    Unity Technologies

    Joined:
    Jan 23, 2020
    Posts:
    140
    Yes definitely, this is the shortest term performance gain item in our work in progress:

    And then later on, even more performance to expect with this:
     
    davincilab likes this.
  25. stuksgens

    stuksgens

    Joined:
    Feb 21, 2017
    Posts:
    135
    Well, the Graph Tools Foundation seems to have solved this problem, but for now we will not have this implementation, but when it arrives, I think performance will not be lacking

     
    Kennth and davincilab like this.
  26. davincilab

    davincilab

    Joined:
    Aug 8, 2017
    Posts:
    15
    Something I miss after using Bolt 2 for a while is the variable renaming feature. When I rename a variable later in the process, it automatically updates all the instances of it being used. Is there going to be a solution to this in the next releases?
     
  27. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    4,950
    I see no mention of FSM, will that survive from Bolt v1?
     
    L82093 and Lars-Steenhoff like this.
  28. jarbleswestlington_unity

    jarbleswestlington_unity

    Joined:
    Dec 6, 2017
    Posts:
    23
    It's good to hear you are respecting Bolt's depth as a programming tool and not just low-level scripting for beginners. To that end, do you guys have a timeline for when you are planning on integrating functionality for multiplayer networking?


    I've made multiple attempts at getting networking to play nice with Bolt (the closest I got was using PUN networking) but I believe myself and every other bolt user who's tried this has hit a dead end. I feel if you can make a visual scripting system capable of versatile multiplayer networking people will really start talking about Bolt as a serious contender as an alternative to traditional coding.
     
  29. Kennth

    Kennth

    Joined:
    Aug 11, 2017
    Posts:
    59
    Yes and thank you. Many third parties don't can't keep up with all the changes at the same time as well, plus some
    don't get updated .. etc.

    Thanks so much.
     
    LaurentGibert likes this.
  30. Kennth

    Kennth

    Joined:
    Aug 11, 2017
    Posts:
    59
    Thanks, in theory, if your stringing 3 or 4 different assets, weather, water, wind ? AI etc.. you would only need a few
    nodes of Bolt, since most of the level would be run by the Devs code. So in theory no real slow down.
    This could be a way also to show a programmer kind of what the artist may want or are thinking as an idea. Then let " real " programmers do their thing.

    All good here, thank you both for your replies. :)
     
    Last edited: Oct 2, 2020
  31. AndrewKaninchen

    AndrewKaninchen

    Joined:
    Oct 30, 2016
    Posts:
    149
    Thanks for the answer, but sorry, I wasn't specific, at least this time. What you said was already in the topic's first post, I believe. I meant specifically the definition and use of classes in Bolt, and, even more specifically, class inheritance. Here's my original post regarding my concerns with that last part.
     
  32. fherbst

    fherbst

    Joined:
    Jun 24, 2012
    Posts:
    755
    @LaurentGibert I think I mentioned that a couple times in the past – I highly recommend you look at https://vvvv.org / https://visualprogramming.net/ for how a great, stable, fast, production-ready and loved visual scripting solution can look and feel like. These guys solved it all. I've used a bazillion node-based scripting tools but this is the only one where you can drive mission-critical apps from that must never break, run butter smooth, and scale. Please learn from it :)
     
    cecarlsen, GliderGuy, Stexe and 7 others like this.
  33. JasonJonesLASM

    JasonJonesLASM

    Joined:
    Sep 5, 2012
    Posts:
    225
    Ooooh, I've never heard of this. Been searching every now and then for years, for something visual for C# and standalone. Looks very well thought out. This is definitely getting much closer to a concept I always wanted. Developing full applications purely live with more emphasis on the VISUAL part, not just in GUI, but in user experience.
     
    Kennth likes this.
  34. bugfinders

    bugfinders

    Joined:
    Jul 5, 2018
    Posts:
    208
    Out of interest then why does my 2020.1 still say 1.4.12 is the latest? I see it says .13 on the asset store but the package manager (which Im so not a great fan of) doesnt recognise theres a newer version...
     
    LaurentGibert likes this.
  35. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,296
    If you've seen my post above discussing the "Tag" concept for user-determined scope and semantics-free (syntax-free) logic, I really hope something is being considered in this. For example, while Nested Prefabs are a great and powerful concept -- they need a little extra "push" to become behaviorally-flexible -- i.e. rather than NestedPrefabs be linked to the behavior itself, delegate behavior to a ECS systems-like concept and let the gameobjects / NestedPrefabs be linked only to hard-reference asset hierarchies (to which they are MUCH more suited) instead of behaviors. Let your dataless "Tagging" handle the scope and behaviors, rather than hard-coded gameobject / NestedPrefab hierarchies.

    How does this sound, @LaurentGibert?



    Not to deflate your enthusiasm, but I don't agree that this has "solved it all" in any way. While this does do vertical nodes and even has a really great (lightweight-looking) interface, it is still not quite as 'lightweight' as it may initially seem.
    There are still numerous issues with its approach that are not immediately obvious.
    The major issue is that its performance (and UX) would still be slowed down by C#'s own inherent problems -- i.e. its backwards approach to data-handling and parenting of behavior, memory-heavy references and unnecessary pointers (compared to a full-on data-oriented approach akin to ECS), spaghetti-like abstraction quickly taking over as the low-level code needing to be hidden away becomes more and more necessary as it increases in length and complexity, independent of user-intentions or logic (promoting syntax-as-king rather than user-as-king), etc., etc.

    To be fair, its shortcomings are the fault of the C# interpretation (and C#'s approach to OOP's four-pillars) though, and not necessarily that of the tool itself -- but the tool design is based on that interpretation and approach, so, no matter what, at the end of the day, what the tool's capabilities are get shaped by these inherent design limitations. So, in a way, it really is the tool's fault for keeping them around. And thus why the "solved it all" doesn't apply here.
    That being said, I do like the minimalism in the UX -- if Unity did something like this, the "ports" should really be hoverable to temporarily display the "argument" nodes / logic in a popup like a magnifier-like tooltip (but only when hovering over the node ports). Ports, should really be viewed as arguments to begin with -- and to have these "shrink" away from the main logic branch into a loose "dot" representation could be pretty nifty (for readability purposes) -- Just food for thought. :)
     
    Last edited: Oct 1, 2020
    LaurentGibert likes this.
  36. LaurentGibert

    LaurentGibert

    Unity Technologies

    Joined:
    Jan 23, 2020
    Posts:
    140
    Yes this is in the plan. You might have seen some of the themes for our 2021 series of releases, and both visual scripting and networking are important pieces we wanted to figure out properly. We're working at making sure all of those work great together (and of course including graphics).
    https://blogs.unity3d.com/2020/08/13/the-road-to-2021/
     
    Kennth likes this.
  37. LaurentGibert

    LaurentGibert

    Unity Technologies

    Joined:
    Jan 23, 2020
    Posts:
    140
    Thanks for sharing!
     
    davincilab and fherbst like this.
  38. LaurentGibert

    LaurentGibert

    Unity Technologies

    Joined:
    Jan 23, 2020
    Posts:
    140
    Hi, Bolt is still an Asset from the Asset Store. It doesn't get updated with the Package Manager, but you could see the latest version in the Asset Store integration in Unity when you browse "My Assets".

    To upgrade Bolt, you will have to remove it from your project, and deploy the asset again.

    This workflow is not ideal, and will be solved when Bolt gets integrated as a core feature.
     
    Kennth likes this.
  39. LaurentGibert

    LaurentGibert

    Unity Technologies

    Joined:
    Jan 23, 2020
    Posts:
    140
    Hey sorry if it feels like I'm not engaging on those very advanced design question, I am actually trying to not get too deep on this front as we have experts in the team responsible for this. So hopefully they're reading and reviewing your suggestions. Thank you so much for being very engaged in this topic!
     
    awesomedata and Kennth like this.
  40. fherbst

    fherbst

    Joined:
    Jun 24, 2012
    Posts:
    755
    @awesomedata with "solved it all" I mean that this is one of the few visual programming solutions that survived many years (15 by now I think) and is production-hardened on any scale of production. I speak from experience, not enthusiasm :), we used it almost exclusively for many years and only moved to Unity for broader platform support. Still, for rapid prototyping, this is 10x faster than anything I've ever seen in text-based code environments. If the Unity solution ends up resembling this in terms of production value I'd be very happy.
     
    Kennth and Lars-Steenhoff like this.
  41. majorgrubert

    majorgrubert

    Joined:
    Jan 13, 2013
    Posts:
    6
    I didn't know it either. Looks very neat, and the way it reproduces visually the structure of code.
    Just as another reference, one that comes to my mind when I think about node-graph based engines. Never tested it but looks interesting, its implementation of node graphs throughout the engine, Snowdrop:



    Edit: typos
     
    Last edited: Oct 2, 2020
    Ex-Crow, ericb_unity and OCASM like this.
  42. bugfinders

    bugfinders

    Joined:
    Jul 5, 2018
    Posts:
    208
    err but you guys moved the asset manager to be part of package manager. So it’s now all one system.
     
  43. Adam-Blahuta

    Adam-Blahuta

    Unity Technologies

    Joined:
    Jan 29, 2020
    Posts:
    8
    We're still weighing options for data consolidation, graph interfaces and polymorphic behaviors through some kind of inheritance/composition relationship. So it's likely that you will be able to emulate OOP class definitions and get the benefits you're looking for.

    However, we don't want to make OOP-like class definitions mandatory to every application of visual scripting.
     
  44. AndrewKaninchen

    AndrewKaninchen

    Joined:
    Oct 30, 2016
    Posts:
    149
    I'm sorry for insisting on this, but my original post isn't much about wanting the benefits per se, it's more of a worry on the possible effects of implementing it in the currently most obvious way (which would be the way Bolt 2 did).

    Yes, it would make very little sense in cases like simple, very specific event graphs which would arise pretty much anywhere a UnityEvent exists today. I imagine class definitions using VS mostly as gameobject components, really (and GameObject derived classes, in an "ideal" world, in my opinion).
     
  45. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,296
    Not a problem! -- I'd like to hear from them, if at all possible.
    I really want to set my mind at ease again.



    I like that you guys are considering making the style flexible -- My biggest fear is that you'll pigeon-hole us with a solution that doesn't work for me, for example.


    Some considerations

    I really think an approach that is more general (along the lines of my above comments about a dataless "Tagging" system) would be more generally-useful to programming logic flow.


    Tagging System

    The tagging system (explained above in a few previous posts and below) ticks a lot of the boxes for you guys:
    1. Can be expanded to an OOP / Class-like approach by Unity or the user (if desired)
    2. Gameobject-centric compatible approach using "Tag" or "Data" components as literal "components" (if desired)
    3. ECS-like workflows by default, that have more flexible OOP roots than C#'s 4 pillars of OOP explained here (if desired)
      -- but ideally, this (dataless) Tag-based approach to DOTS and ECS should probably be the default option (for performance reasons).
      Ideally, it would let the user "drill-down" to the data they need -- i.e. on the scene-graph level, for example -- that any system will need -- i.e. for object-to-object interactions.

      A shortcut in the scripting interface for that kind of data-interaction via a set of generic "bridging" systems (that can also be edited in the Visual Script editor themselves)


      The Visual Script editor / Unity Editor should accommodate this "shortcut" that simply "bridges" the Visual Script nodes with "scene-graph" system, for example, via auto-generation of certain "nodes" into a "grouper" node based on certain "Tag" component configurations.


      For an example:

      Say I have an "Attack all 'EnemyFighter' Entities" node.

      This node has 'complex' behavior, but 'simple' logic -- i.e. "Attack all 'EnemyFigher' entities".
      A single node should do it, right? -- Game development in general should be like this. But it isn't. This is thanks to syntax semantics. So we need to fix this -- NOW.

      (Dataless) "Tag nodes" and "Tag identities" are the answer.

      Internally, user-generated "nodes" should NOT have their own "nodes" -- but instead should simply function as gameobject-based behavioral orchestration based around (dataless) "Tags". This is done by way of a group of (dataless) "Tags" tied to gameobjects/entities in the form of "Tag identities" -- entities with particular Tags that later get referenced by particular ECS Systems (for example, a "RuntimeSceneGraphSystem" that processes all 'EnemyFighter' entities in a scene when they're 'tagged' as alive/dead).
      Most user-created nodes consist of a series of (dataless) "Tags" that should be added/removed at a particular moment in the script. This would, ideally, just be a series of on/off binary logical operations that are evaluated at a global sync" point in the cpu cycle (or frame), depending upon what level you are scripting (and if you need the evaluation to be "synced" at all -- which sometimes isn't the case). A set of options at the top of the script editor would be enough to determine this on a per-script basis.

      This structure allows user-generated nodes to be simple to create (skipping syntax-heavy code for beginners), while focusing on the ability to act as high-level "Logic" and "State" flow mechanisms -- rather than as syntax-overlords (like other scripting systems force upon its new users). The only time you need to 'code' is when you need functionality that you don't have any ECS System 'module' for. For example, as long as you can access the Transform 'module', you can write any System that you want to 'bridge' with Unity's default TransformSystem -- and perform some behavior with (or upon) its data, which happens automatically at a "sync" point in the CPU cycle / frame.
      A generic bridge system would be great for this sort of thing -- alongside a system that describes the moment in the cycle (or multiple moments in the frame) where specific "Tagged" data synchronizes (again, using dataless "Tags"). This so-called "Sync" System is a Visual Script that describes the "Data" Tags that should update, and in what order these "Data" components should update (by way of data-less Tags -- again, in the form of nodes).


      Since we're usually working with ECS Systems (as a concept), in order to make user nodes work like that (and give users the ability to quickly "drill-down" into their logic, faceless entities (and their respective nodes) must be given temporary "Tags" by other ECS Systems that act as a quick "call" to other Systems / VisualScript graphs (such as by way of a newly-added 'DestroyObject' Tag) which is usually removed when an operation completes (i.e. the entity is destroyed.) At this point, the RuntimeSceneGraphSystem would process all entities and destroy entities with a 'DestroyObject' Tag, or create new ones with a 'CreateObject' Tag.

      Some considerations for a 'CreateObject' behavior:
      • Assuming a user's System wants to create an entity, a "Tag identity" value is used (editor-wide) alongside the 'CreateObject' Tag in the Visual Script graph for the ECS System that creates the entity.

      • This "Tag identity" is nothing more than just a sequence of bits/bytes that flag particular "Tags" as being on / off, depending on the chosen Tags' particular bits in the sequence. This can let "Tags" stay extremely small while (internally) kind of acting like Unity's "layermask" system (except being a "Tag" mask).

      • The user can create his own "Tag identity" for his gameobjects that define the 'kind' of gameobject/entity it is talking about and recall it later in any node or ECS System -- (i.e. The user would create a "Tag identity" such as: Character > Player > Movable > UseInputSystem -- and name it "PlayerCharacter" so that nodes can reference this particular set of tags (without any hassle) in any system. This "Tag identity" can quickly be edited in a System to keep or remove certain behaviors / system "subscriptions" at any time.
        In other words, to make the PlayerCharacter immovable for a moment, modify the PlayerCharacter tag inline in the Visual Script to remove the "UseInputSystem" Tag. When the cutscene is over with, add that back to all "PlayerCharacter" entities (i.e. entities with Character > Player > Movable > xxx "Tags").


      Regarding UX (and Tag Sorting):

      Most of these "Tags" are exposed to the user (i.e. on the gameobject or visual script blackboard -- in the form of selected keywords (something akin to how ShaderGraph does with its variables in the Inspector when not in the ShaderGraph tool itself).
      You would need to have "groups" of these "Tags" of course (for readability purposes), however, these can still be processed internally as a flat list. Though, it might be useful to be able to "partition" these lists and have one small list (projectiles, etc.) and one large list (npcs, slower objects).
      Other "Tags" are hidden away for simplicity -- i.e. "Tags" that are Unity-specific underlying systems (i.e. scene referencing behavior) and underlying bridge systems (scene origins transferred to gameobject Transform locations when a created entity is spawned at the start of a scene) might useful to be able to "subscribe" to one another, but might not be necessary for the average user, so letting the user show/hide these systems as they desire (and remember their settings) is very useful.


      Finally -- The example.

      The "Attack all 'EnemyFighters' Entities" node adds a series of (dataless) Tags to the gameobject/entity (if they don't already exist). These "Tags" do nothing more than "subscribe" to various systems that act upon the gameobject/entity at this point in the System / Frame / CPU cycle.

      Let's say a screen-filling attack happens when the "SpecialAttack" button is pressed.

      You'd need 3 nodes:
      Check InputSystem > Check SpecialAttack button > Execute "Attack all 'EnemyFighters' Entities"

      You need data from the InputSystem, so you await the "Sync" (ECS System) Visual Script's "go-ahead" before moving forward with the Visual Script execution. Now that you have the data you requested for the Sync Point, during the Sync Point, you check the "SpecialAttack" button's data -- if it is true, then you proceed to execute the addition/removal of whatever "Tags" are necessary (in the rest of the CPU cycle -- or the next cycle -- whichever is closer). This allows you to execute the next instruction as quickly as possible. Since game logic isn't actually very complex (shoot this guy, kill him if health < 0), this should allow for tons of logic to be executed per cycle.

      Essentially, in this example, you apply a "GetDamaged" to the "Tag identity" of 'EnemyFighters', which damages all fighters.


      In Conclusion:

      You might have to wait another cycle to apply the actual damage for all the fighters (since you might have to reference the 'PlayerFighter' entities "AttackPower" -- but this isn't usually mission-critical code, and one or two (half) CPU cycles should be nothing to most processors.

      If you're doing geometry-heavy logic, you need less "Tags" and more performance -- but even when you need them, they are usually only necessary at 'junction' points in the logic (or during data-retrieval), which, like with structs, should only be called for (ideally) at the very beginning -- and rarely at any point afterwards.
     
    GliderGuy and landonth like this.
  46. Alienmadness

    Alienmadness

    Joined:
    Sep 6, 2012
    Posts:
    106
    Bring back Bolt 2. deal with the different silos. need a fast/good VS tool that can generate good c# code.
     
    Kennth and Stexe like this.
  47. Zebbi

    Zebbi

    Joined:
    Jan 17, 2017
    Posts:
    521
    UNode
     
  48. Stexe

    Stexe

    Joined:
    Feb 2, 2014
    Posts:
    189
    Sure, if every single person who bought Bolt 1 for Bolt 2 got a free copy of UNode. And UNode redid their entire UI. Then we might be talking. :p

    They really should give everyone Bolt 2 where they left off. I only bought Bolt 1 to get Bolt 2 and when they canceled it they essentially made my entire purchase worthless. It is false advertising for someone to say "you will get Bolt 2" and then change it to "NOPE!"

    The least they could do is give us what was left of it.
     
    awesomedata and bugfinders like this.
  49. Zebbi

    Zebbi

    Joined:
    Jan 17, 2017
    Posts:
    521
    TBH, Bolt 2 was rushed, buggy, unstable and generally unpleasant to work with. Bolt 1 isn't the best, but at least it doesn't throw red warnings and exlaim crashes after moving making a successive number of connections or adding new nodes. Bolt 2 had a great idea, but it was poorly executed, and I think what Unity are trying to do it put stability first and incorporate as much of what made Bolt 2 great as possible into Bolt 1.
     
  50. davincilab

    davincilab

    Joined:
    Aug 8, 2017
    Posts:
    15
    I purchased Bolt 1 with the same idea as you to get hands-on on Bolt 2. I tried Bolt-2 for a while and I really liked it. It was better than Bolt 1 in many aspects for sure. But, it was incomplete and need a lot of work to be done to be used further.

    I don't think you will find it very useful to work on an unfinished tech for a long time.

    To your other point of being cheated on by false advertising, I can't comment on that. I am with you on that, but I am also fine knowing the current direction of Bolt, and eventually, you will find something better.

    As far as I understand, the roadmap on VS with unity is going in a good direction, meaning, Starting with bolt 1 and eventually transforming it to something better with things they have learnt from Bolt 2 and DOTS VS experiments.

    Of course, I would really like these changes and transition to happen faster. But, I am sure the teams are doing their best. :)

    Ps: If I am not wrong what the Unity team is working on will make it easy for us to transition into the DOTS tech without a lot of rewiring our brains. (At least this is what I understand.)
     
    Kennth, theor-unity and SenseEater like this.
unityunity