DOTS Visual Scripting Experimental Drop 11

Hi all,

My name is Laurent, I am jumping in this time around to publish this post about the latest drop of DOTS Visual Scripting. You may have seen me in discussions related to Bolt like this one. The reason I am joining the party over here is to help progressively define the necessary synergy between our Visual Scripting solutions.

Many questions have been asked about the next steps for Visual Scripting, how will DOTS Visual Scripting and Bolt play a role moving forward. We are working at defining this, so no definitive answer today, but be aware we understand this is an important issue, and we are committed to provide clarity as soon as possible.

In the meantime, we are happy to share a new drop of DOTS Visual Scripting.

Disclaimer
We are providing this work-in-progress version of DOTS Visual Scripting to engage in an open discussion with the community, collect feedback, and use it to build a better final product. This version may contain issues and unexpected behaviors, and as such we want to remind you that:

• This version is not ready for production,
• The workflow and user experience will change,
• The data compatibility with future drops is not guaranteed.

What's new
We are now using Unity 2020.1 since it has been made available.

• Placement tools
  • Alignment tool
  • Node snapping tools
    • Snap to grid
    • Snap to port
    • Snap to node
• Mouse position + Normalized position nodes
• Load Scene node
• Blackboard variables in searcher

Known issues / Limitations
Using custom input action assets will throw errors at runtime if there is no MousePosition action.

How to get started

• Unity version: 2020.1.0f1
• You can download the sample project, load the 00_Example scene and hit Play.
  
• To get DOTS Visual Scripting package in any project add the following line to the project manifest:

  "com.unity.visualscripting.entities": "0.4.0-preview.1"

Thank you in advance for your feedback, this is critical to build the right product.

 

What a pleasant surprise, let's test

I liked the new type of alignment, but it could be automatic, right? as in photoshop where we can align a certain image up or down (But here we would align with the nodes)

But it's really a good addition


I don't know what is written there, because the text is simply invisible (Light Theme)



Note that the buttons on the bar are almost invisible, you can't understand what they are for (and the map also has the same problem)

And I still don't like this white one on the right side of the screen, it is only used on some nodes, and it takes up a lot of space on the screen. I don't know what you plan to do with it in the future, but for me now, I don't consider it very useful.

This area is wasted here because it has only 1 option at the top


It could be something simpler, as in the shader graph where there is the property window, where it would be much better

Another idea would be to appear this "window" only when we are using something that actually uses that window, (It appears when a node uses this window) or that we can activate / deactivate the appearance of this window at any time (like the blackboard or minimap).

Or even better, making these options appear above the blackboard options, it would be even more practical that way



I'm still going to test more, but I'm finding this drop very cool.
Then I'll try to play a test game with him.

Great job.
And sorry my english

 

That was exactly what I was talking about. Thank you very much

One thing I noticed this week is that VS Dots is a lot lighter, I don’t know if it’s because of 2020.1, or if you changed the VS backend, I don’t know how to explain it, it seems much lighter to use now. (Comparing to drop 10)

 

Is it possible to do sub graphs or smart objects without having to attach them to a gameobject? I am starting to see a lot of organization smells having to attach all my modular functions to empty gameobjects...unless I am missing something.

 

So I just happened to stumble upon the option to create Subgraphs. Might more intuitive if we could create subgraphs in the right-click create menu in the project window. Also an option to highlight a bunch of nodes in the default graph and convert them to a subgraph would also help.

This build is definitley a lot smoother than past ones though. I am actually seeing the potential of node based coding as we don't have to wait for the engine to compile "script" changes everytime we tweak something. That is a big plus for me .

 

I have run into this error twice, where if you change a custom node's class name via script editor, and if that node is in the current graph, it corrupts the whole graph forcing a re-do. So if you are making a fairly large visual script while creating custom nodes there is a good chance it will get erased.

Code (CSharp):

1. Unknown managed type referenced: [Assembly-CSharp] Runtime.TestNode

 

Hello ,I can't see any code in the code viewer~~

 

Hi everyone, we have an important update to communicate about our visual scripting roadmap, please see this new thread:
https://forum.unity.com/threads/visual-scripting-roadmap-update.951675/

Laurent

 

Which makes this thread feel pointless now...

 

Nice.

 

Okay -- I guess I am totally confused now.

Was that other thread discussing _just_ Bolt, or DOTS Visual Scripting too? -- I got the impression that DOTS VS was being tossed to the side in favor of Bolt 1 integration.

Seems like others had that impression too.

How long are we looking at keeping DOTS VS around, now that it seems like eventual vaporware?

 

From my understanding, it seems that Unity VS (Bolt 1) integration will also have this (DOTS VS) integrated at some point. But this will also live as a separate DOTS only VS.

So the way it's worded makes it seems like DOTS VS would be integrated and this version would be no more. Still not sure why there will be two DOTS integration though. Although it seems they will be using the same code base and maybe even the same UI.

Actually it seems some packages are doing a core integration as well as a preview package so is that what this is? DOTS VS will be preview package to get the latest and Unity VS with DOTS integration will be the stable core version?

 

They're unifying all VS tools into a single tool that'll cover both mono and DOTS. It's not one or the other, it's both and integrated into the engine by default instead being separate package donwloads. Perhaps animation state machines (Mecanim successor?) will also be part of the tool as they're talking about unifying all VS workflows.

 

This is just having all the graph tools know about each other so you could use them in visual scripts rather than having to switch to C# because that's the only API they are exposed to. This way those who want to use visual scripting can do so without reaching a roadblock and having to go to C# to code functionality for those things, they can just do it in the main visual scripting tool.

 

Right -- which is why I said this thread seems pointless now, as I was under the impression that since Bolt 1 is going to be the flagship product, then obviously DOTS VS would be nothing more than vaporware now.

Though, thinking on it a bit more -- I think my biggest curiosity is that, if we're keeping DOTS VS, will _any_ of the work these awesome VS guys are doing actually matter? Or will it all be thrown away too?



A bit off-topic, but kinda still _on_ topic:

The one thing that concerns me most about this new change is that "regardless of workflow" bit.

Workflow is _extremely_ important!

Mecanim, Shaders, and Gameplay should _not_ share the same node workflows and/or graph structure -- at least with how they're written now.
You're BEGGING for trouble if you go this route, guys.
Gameplay and Utility systems are already like oil and water. If you try to mix these two without understanding exactly what you're doing, nothing will come of it except an enormous raging garbage-fire.


@LaurentGibert

EDIT: To be clear, the following is _not_ a "job application" lol -- just a semi-sarcastic rant. See follow-up post!

Please please PLEASE let me help you guys with this! -- I know the history of the Unity UX in terms of graph tools, and I know shaders, animation, visual scripting, and a LOT of other stuff extremely in-depth. I've both used and studied game-making tools and UI for nearly 20 years, yet I still wake up at night with cold-sweats when I think about Mecanim. Please let me help keep you guys from yet another massive UX mistake! You need a jack-of-all-trades guy like me around who is familiar with UX -- and Visual Tools, in particular -- who can educate your teams in what users are _really_ looking for. Just saying "Bolt 2" is not enough. Even Bolt 2 has its problems in UX design -- but it is a hell of a lot better than what we have in the industry now.

Just my two-cents.

 

Bolt 1 is not the flagship, it's the part that handles mono. They should be equally balanced, eventually. They're not integrating Bolt 1 as is. Announcement mentions a stuff like snippet nodes which Bolt 1 does not have at the moment. I'm sure the backend will be completely different once it's integrated into the engine so it can support both DOTS and mono.

 

My dude, could you please send your application through the proper channels, it's bordering on annoying reading your plea to basically get a leading roll in this features development in every single thread.

Giving detailed feedback is fine. Having the attitude of straight up knowing better than anyone around is ok, it's the internet after all. But the forums shouldn't be the place to repeatedly ask for a position. Devs are aware of your interest by now. I guarantee it. Just properly apply for a job and see where it takes you.

 

Fair enough -- I probably should have put the /s at the end there. I would have, except I was partly serious about some of it -- (in particular, the "wanting to help" part.) My bad.

Honestly -- I simply wanted it to be clear that there are some fundamental misconceptions about Unity's overall view of the toolchain/pipeline, and the 'powers that be' need to understand they seriously need a one-on-one with somebody who knows the whole process, who actually has _time_ to talk and explain things (and who probably should be _paid_ for it). However, since that latter part isn't likely to happen (like others here who actually _make_ games, I do already have a job I enjoy after all, but that means my time is very limited, and Unity needs somebody on-staff at all times). That said, I do still honestly feel they should probably start investing in people who have an _actual vision_ (rather than just in college grads who have no idea how to make games, or "in-the-trenches" programmers from different game companies who are _not_ game or tool designers, but who are shoved into that sort of 'design' role anyway). I definitely still want to contribute to that vision somehow, though a "job" would probably be a bad idea for reasons I'll mention below. Anyway, the potential applicant's vision should clearly be consistent with both their customer base _and_ their shareholders (but whose vision should weigh more toward the customer base, for business reasons) -- and it should extend _beyond_ just Visual Scripting or any particular tool -- especially with the new "unifying tools despite their workflows" bit, because _workflows_ are the first step in what drives users insane to begin with -- (like the insanity in my rant you quoted above).

So while, yes, I wouldn't mind working for Unity in this capacity -- I still didn't mean it as a "job application" (because, otherwise, yes, I totally would put in an application to the "proper channels" -- assuming a job title like that existed). Instead, I simply meant it as a "call-to-action" for Unity to point out that there is a more fundamental flaw in their current plan than they apparently realize -- and it can _only_ be solved from the inside-out.
Also, I don't think Unity's current directional mandates and I would get along, since I would push whatever person who is in charge to improve the, more subtle (but extremely important), things that are causing problems -- which would probably get me fired anyway.
So, clearly, "working for Unity" is probably not a "realistic" goal for me -- thus the "/s" I mentioned at the start.



Thanks for pointing this message out though! -- I definitely needed to clear up some things!

 

If we're on the topic of constructive feedback, I really think you'd have better results if you worked on your communication skills. I've read through every post in these visual scripting threads EXCEPT yours because I just don't have the patience to read through your essays.

You might have great ideas but you're a stranger on the internet and to be honest I don't know if your long posts are worth reading because I have no idea what your level of expertise is.

You might have better results if you focused on communicating your BEST idea as simply and concisely as possible. Then if your idea gains traction introduce other ideas and build from there.

 

Hi everyone,

DOTS VS is playing a key part of the convergence of our graph based tools in the short term. Bolt technology is being integrated in Unity so that we can incrementally deliver visual scripting updates in the direction of merging this with DOTS VS, and provide a unified UX for both monobehaviour and DOTS projects.

We understood there are elements of our original communications that are not explicit enough for you all in terms of how this will all play out together in technical terms. We are currently analyzing all the responses we got from the latest roadmap update so that we can update you all with meaningful information.

So all in all, this thread is still important, because DOTS VS is still the only technology to provide visual scripting for DOTS. Bolt technology is also important because it is still the only technology providing visual scripting for monobehaviour. Our next steps include to progressively merge the workflows of both DOTS VS and Bolt, using components of both technologies when it makes sense.

Does this help?

Thanks,

Laurent

 

Do you plan on having "high level" nodes that will work essentially the exact same for both mono and DOTS projects? So the fact that the project being Mono or DOTS is pretty much invisible to the user? Basically a checkbox option for Mono or DOTS project. If this is the case, will there be some sort of transition stage where you guys gradually shift all low level layers under the visual scripting to DOTS only? If this isn't the case, do you plan on having "Mono Graphs" and "DOTS Graphs" which will function differently and have different nodes depending on which type of graph you choose?

I would love to open a DOTS only editor in 2022 onward. The current state of trying to please both Mono and DOTS is looking exhausting.

 

Fair enough!

Though, to be clear -- My "essays" are generally intentionally long (in order to cover the subject-matter fully). I don't typically care to share my thoughts with people who lack the patience (and sometimes the decency) to properly read (and understand) what I am sharing with them. It gets really hard to criticize an essay without understanding it on some level. So, in a way, this was kind of a mutual-benefit thing. I think this is also a relic behavior built in response to when the whole internet was full of 12 year olds, and long posts scared away the people who found it difficult to read above a 2nd grade level. So yeah -- perhaps it isn't the most healthy social habit to have. But I guess neither is being pissy with (or criticizing) a person because you only half-understood (or mostly-ignored) the other person's ideas.

So I guess this has just been my own "healthy balance" to that notion.

You're probably right on that on some level.

Honestly though, I'm not sure it's as much my "skills" in communication as it is the issue of decreasing the sheer volume of information and ideas that I share.
I can definitely see that being a pain in the ass for anyone consuming it.
You've essentially confirmed that with your whole post -- but I appreciate the clarification regardless.

Yep. This is a great suggestion! -- It's definitely something I'll make more of an effort to keep in mind!

In fact, if you had read my earliest VS posts (which were, sadly, just as long), you might have seen they _did_ gain a bit of traction. So in response to that, I shared more ideas each time. To the point where I shared a few too many (too complex) ideas. And thus, here I am, with too many "overly-long" posts. However, reducing the number of ideas I share at once could definitely help decrease their size -- Thanks for the tip!
It definitely gets out of hand trying to convey a lot of holistic information at once without structuring it a bit more carefully. So I'll definitely take your suggestion to heart!

Thanks for taking the time to share your thoughts with me.


Lastly, and for what it's worth -- _I_ think my long posts are all still worth a read. After all, I wouldn't have spent the time typing them out if I thought otherwise.

 

Seconded. This sounds like what Unity is going for, but my god this seems like such a pain in the ass all-around. D:

I understand this part -- but for how long?

Are the drops going to reach 1.0 and then disappear? -- Or are they continuing on afterwards, eventually culminating together into a new shiny "Bolt GFX + DOTS VS" editor window in Unity?

 

This is just my opinion: base the UX off of Bolt. It's nothing personal against the developers at Unity, but whomever designs your UX or makes the final decision isn't very good at it. It's like they are designing things for the early 2000s.

 

Hey guys! Tried out for a week now the Drop 11 of DOTS VS, very nice content! almost all majors are here, I know Bolt but I love (maybe prefer?) the UX from DOTS VS actually, its sober and well designed, Im a bit curious about how the content of both Bolt and DOTS VS will be merged, there will be an impressive amount categories of functionnailty for users who got both mono and ECS in the project., lets see in a moment!
Ah another thing, is that normal that DOTS VS create a build error when present in the project? I can build without but..

 

Got it working for the build, i've made the the DOTS VS package local (it's nasty ikw) and in Runtime\Interpreter\Inputs\ScriptingGraphInputSystemConversion.cs comment the line 24

// DstEntityManager.SetName(entity, "Input System Package Mouse Position");

I grabb the value by converting mono to entity ref so don't care of a "SetName" here anyway

 

Wasn't DotsVS compatible with mono as well?? I mean it was possible to write nodes for GameObjects(Actual GOs) as well so why there's any need to merge'em both?. Bolt is just ruining everything.

 

I get your sentiments. Honestly, with gameobjects becoming entities anyway upon hitting "Play", I really don't see any reason to distinguish between the two.
Add a special component to gameobjects that let them take a Visual Script that uses ECS systems, and automatically assign them via a "bridge" system to the particular system that "special ECS component" references the behavior from.

Perhaps automatic "tagging" of entities can be handled this way, giving users a fast way to create gameobject variants using a gameobject-based workflow. Essentially your gameobject simply references a system -- and "tags" itself with that system's behavior.

Ultimately a DOTS VS would essentially be a system that objects can reference.
And any "tags" you tag the object with allow you to "tag" with data _and_ without data (if you want to simulate a data hierarchy, but with indexed "tags" that a system will later evaluate to "tweak" behavior.

Just an idea -- Am I missing something under the hood that would prevent this?

 

I know plenty of people are loving the colorful Bolt 2 theme, but I thought the exact same thing -- but about Bolt. D:

Honestly, I love icons as much as the next guy. But I think they're a bit overkill in Bolt 1. They're definitely a lot better in Bolt 2 though. However, I always fall back to practicality. The less visual distraction when _actually coding_ something, the better. It's just less taxing on the brain.
And when coding a game -- you really do need your brain sometimes.

That said, a little more color wouldn't hurt DOTS VS -- as long as it is done in a less distracting way than Bolt tends to go for. I mean, not everybody was raised in Unicorn and Candyland, and some find that kind of saturation of hues generally just a bit distracting. Decrease the saturation though, and I'm okay with it. It's the eye-burning pinks and blues I get distracted by -- not the fact that you use color. Just to clarify.

 

No worries! -- I thought as much!

Everyone's been griping about the colors, but I want to beg you guys not to put _too_ much color. I genuinely HATE the UE4 visual scripting color-vomit (I mean, the nodes themselves are colored?? -- for what purpose??), and as such, I really enjoyed Unity's more "subdued" grayed/desaturated approach (as it made the important information stand-out really well.)

So please don't change things _too_ much, yeah? D:

 

I hope this new theme will move fileds inside of nodes in shader graph haha

 

How do I define a system to process entities, add components etc... in this new graph?

 

ok thanks, eager to see whats coming

 

I like Bolt 1 UX as well, but I do agree that the icons were a bit overkill. I think icons should generally have a clear description with visual scripting, or at least show text when hovering over the icon, which if I recall correctly isn't the case with Bolt 1.

There should always be a balance in design, but the problem is Unity's UX is so flat and bland that they really can't supplement visual scripting in a nice way in my opinion. It is visual scripting after all, careful use of colors can communicate what is going on and break up some of the monotony that you may experience with nodes. They could certainly cater to both types of people by implementing themes such that it's powerful enough to support bolt's arrays of color and dots more sober ux.

 

I agree, the DOTS VS UI is very clean and blends well with the unity interface.

But I like the icons in Bolt 1 (even though it is a bit exaggerated) but a combination of the two interfaces would help that. (nodes clean but with icons in between)

A nice option is to show or not the icons, or even change the colors of the node lines. it would be a very useful resource.

 

Back in the day, Ludiq hired a designer to do 250 new icons specifically for Bolt 2 and the new Unity's flat theme. In my opinion, those were really on point.

 

Yes I love the bolt 2 icons and colors, keep those please

 

This minus the space between node and link point
Those are incredibly readable icons.

 

They're also compliant with Unity's official theme guidelines as far as colors go.

 

it really helps a lot to identify the data flow. This is a feature that we should have in Visual Script

I like the text and the nodes of Drop 11, but looking more closely now, the icons chosen for drop 11 are not so interesting in comparison. we have to remember that we program in something abstract, something visual, (that idea that "a picture is worth a thousand words") seeing an image helps to assimilate the content of the graph much faster, so it would be of great help to implement icons "more straight to the point, "or easier to understand. (Shader graph is very good, but it’s not so good because it doesn’t have icons)

Still, as all UI's will eventually be unified, having a consistency of icons should also be a priority as some tools (for example shader graph) do the same things as others. (For example, vector node 1, 2, 3 and 4 in the shader graph is in one way, in the visual script in another) They must be consistent, not different.

I know a lot of people have said that, but another point I would like to mention is these vertical nodes. In DROP 6, this was sensational on several levels (literally), and bolt 2 also came with this vertical idea because, in a way, it greatly reduces the chance of people making a mess of your graph (known as spaghetti).
I like the idea of working in the vertical flow, because in it you better understand the code on a more general level. And it can adapt data flows (such as If, else, loop and functions) while dealing with parameters and adverse conditions coming from the sides.

I'm following this project closely, because dots is something I'm very excited to apply to a real project, and DOTS VS will certainly be a more viable way to do that. So I will keep an eye on the next Drop, as possibly we will have the first view of what the Unity visual Script will be like.

 

I'm a bit split on the "if" node (and nodes like it.)


I think there should be an option to use both vertical _or_ a horizontal versions, depending on the context in your code.

For example, if I'm writing a "data sentence" and I want to keep things on the left, center, or right, I would prefer to have a vertical "if" node (input from left -- output to right), but if I want to visually separate some logic in a big way (without need to use a comment box), a vertical "if" is really useful. Really though, _any_ option / node to "split" the data flow should have vertical _and_ horizontal versions of the node.


From a usability standpoint, there are still a few things I can't help but _dislike_ about this UI:

• Too many "neon" colors fighting for priority
  
• My attention keeps being drawn to the most neon-"saturated" area (i.e. the Comment / Group boxes)
• Comment boxes need to be subdued (for reasons stated above)
• The "-" node tries to be too much like Unreal's
  
  Actually -- it ends up failing being at all readable as its most distinctive feature "hides" amongst the three giant circles for in/out ports which surround it.
  It just needs a header bar so it can be visually-consistent w/other nodes
  A special color to have it be more noticeable is welcome (as long as it's not "too neon")
  
  
• Some less-important icons are "too neon" (the "TweenPosition / TweenCallback" icons, for example)
  
• No way to delineate different parts of the script visually into "Data Sentences" (no Subject/Verb/MainIdea separation).
  
• Things like operator nodes fight for visual priority due to ALL THE NEON COLORS OMG (lol)
• The separate "links" to the in/out ports aren't terrible, but when combined with the giant circle icons....
  ...It just becomes extremely busy and drives my brain nuts.
• Groups boxes visually _compete_ with Event Nodes (such as Start, OnCollisionEnter, etc.)
• Major events (i.e. Start, Update) aren't visually-prioritized compared to "lesser" events (OnCollisionEnter, etc.)
• Too many differently-colored lines that aren't immediately-obvious what they represent (in that OCEAN of NEON)
  
  

Some things I LIKE about this UI though:

• "Grayed out" (disabled) code blocks
• Single-color "comment boxes" that have background filled-in
• Event Nodes (i.e. Start) are clearly marked (although they still compete with the Comment Box, etc.)
• Group boxes have a little (bold) "Title" in the upper-left corner
• Vertical Flow (duh)

 

This would get confusing in large graphs quickly. The point of flow bolt 2 dev has implemented is to be centered around one, easy to find and understand road. Separating flow of visual scripting into both the horizontal and vertical way (or any part of it) would mean stacking up different parts of flows but in two different fashions. This wouldn't benefit anyone while at the same time force the team to set up pointless rules to make sure everything will look clean and easy to read.

Just because you haven't guessed at the first glance in your life what the sign means in minus node doesn't mean that It does have to change. It simply should have the possibility to quickly check the name once selected/ hoovered over. Even If there would be no such feature, that's not a problem because any person that has created this node a few times would remember this sign, especially when they haven't guessed It first time.

I had the same issue with boolean operation. I needed a few seconds to understand what the sign for "AND" node is supposed to mean. But then, after a few seconds I guessed It's whatever and It's probably easier for people that don't even know what boolean operations are.

I saw people complaining about it but this is another really smart idea that should stay inside of the DOTS VS and even possibly research the possibility to have it in other VS tools.

While at first it may be confusing because It's different from what we are used to (people hate drastic changes after all). It's a much better solution. The fact that the connection icon is outside means the nodes can be smaller, the smaller the nodes are, the more of them you can see on your screen. The more readable stuff you can see on your screen, the faster you will understand what's going on in the script without dancing with your mouse.

Now the thing is, If you are going to look at how any beginner starts working with nodes, you will see they know naturally to keep the distance between nodes. The true intelligence that comes from the idea of separation of connections is that It doesn't make you feel like you need more space between nodes. Which means you can pack even more nodes on one screen.

The circles icons were probably made to follow standards. Every node does have an icon and the developer clearly didn't have an idea for basic ones.


But I agree on colors. The developer of Bolt 2 has mindlessly followed unity standard and made a huge mistake because they were designed for small icons near components. Something that a beginner would definitely look for and memorize easily. More advanced users don't pay attention to them. Once mashed together, they are annoying to look at.