DOTS Visual Scripting Experimental Drop 11

1. They removed some of those neon lines from the final version, I believe only the green flow starter nodes retained their neon green.
   
2. I can agree with that for the dark theme.
3. Same.
4. In my opinion it works fine as is. Adding a header wouldn't improve readability in any way.
   
5. Perhaps.
6. No idea what you're talking about here. Values are being fed in horizontally, flow flows vertically. Concerns are separated.
   
7. The colors were aligned with new Unity theme guidelines. Seems like most of your points are about colors so far. Not sure why some nodes should be visually prioritized when they're part of a single, linear flow and are read sequentially. It makes sense to prioritize flow starters, but beyond that you've lost me.
   
8. Not sure what the separate links in this case are.
9. You wouldn't confuse a group with an event node.
10. "Lesser" or "greater" flow starters don't make a difference visually. They all start flows so they're marked accordingly.
11. To a Bolt user colored connection lines make complete sense since each color represents a common Unity type. And as previously mentioned, they removed most node outlines in the final version, only leaving the green ones for Flow starter nodes.

Half of your comments are about colors and the other half is about operator nodes. Both arguments not related to Bolt 2 icons being on point readability wise.

The images I initially posted were the first theme reveal. It was adjusted later to adress some of your points.

Here's some of my actual graphs from one of the latest alphas:

Spoiler

 

Hello I think drop is a nice tool for coders to learn ECS and Dots. But I can't find the <Graph to Code> function any more.
I am so sad~~

 

What can we expect from the next drop?

 

I see your point -- and I mostly agree. However, one would (hopefully) have enough sense not to stretch your script out in two different directions across two different axes, and therefore, one could more easily visually organize it, since the overall script is still moving downwards, reading top to bottom, starting from left-to-right. Having it just floating wherever it wants as we currently do with ShaderGraph gets me distracted quite a lot, causing me to lose sight of my data flow very quickly. Being able to keep everything "on the same line" (horizontally, in the case of a script with a vertical flow) would make my scripts (and yours) a hell of a lot more readable.

This is a fair point, but I would argue that it would need to be changed because it is still, visually, way too busy (when considering the entire graph as a whole). The more "complex" your Visual Graph becomes, the more (visually) "complex" it becomes already, but that is also multiplied by the number of needlessly-complex bits of information contained in each and every node in the graph. This can be bits of information like colors, icons, styling, etc. that just needlessly takes up bandwidth in the brain when all you _really_ need is just a quick recap of the script's overall logic/purpose/action(s). In the case of the "minus" node I referenced (on the early mock-ups of Bolt 2), all you need to know is this is the "minus" node -- every other bit of information is simply not relevant. However, when you change the entire look of the node (compared to other nodes), the brain has to "reprocess" that node (in relation to the others), leading to wasted brain power and ultimately a visual 'slog' as you attempt to navigate your script with any sense of grasping the information your eyes are trying to pass along. This is why the "minus" node is terrible in the mockup -- and also why I don't care for it in UE4 either. While it is stylish -- it is still impractical when you're coding late at night, coming down from your caffeine high, trying to figure out what the hell is making that glitch in your player's movements deep within your physics engine for example.
Also, just to clarify what I mean by "difficult" to understand 'at a glance':
If you take longer than you should need to in order to understand a node, and a "glance" at your graph becomes a hard "look" -- this becomes a problem very quickly, as there's going to be plenty of subtract/multiply/add/etc. all across your graph, which unnecessarily increases time spent "debugging" your scripts. And when you factor in "debugging" your LOGIC despite your code being technically correct -- this adds a whole other level of tedium and frustration to an otherwise 'simple' task.

I actually agree with you entirely on this -- but my brain is fighting it. So yeah, I think the outside connections work, if I'm being objective. I think what bugs me about this is the dots aren't "solid" on the outside when they "connect" to the port -- but instead have an extra bit of "separation" between them and the port. That part is what's driving me nuts.

Yeah, that was my take as well. The "standards" need to change imo, as Unreal's Blueprints do this too, and their icons are much more subdued, though still entirely _too_ "visually-stimulating" to my brain.
In my opinion, the names alone should be enough to distinguish the nodes from one another.

A lot can be said about restraint.

In fact, Blender did this restraint thing really well in regards to how it uses colors. They 'pop' -- but only where they need to.

 

I would argue that a graph needs colors to get less busy, because when everything had the same shade of grey no connection is easy to follow

 

I can agree with that -- but the key is in restraint.
For example, I think Blender did a great job with "grey" imo, with the colors it does use only acting as a highlighting or logic mechanism (rather than a separator), allowing things to be much easier to read overall.

I agree that DOTS VS really was barebones with that "all-grey aesthetic" -- but it's nowhere near 1.0 as far as I can tell.
Sadly, the early versions of Bolt really overdid the color thing, which turned me off to it badly (and so did UE4 Blueprints -- but to a lesser extent), giving off a vibe of giant wooden blocks painted in primary colors, pink and blue toys, multicolored balloons and teddy-bears (Bolt 1) or a night-club / red-light district, which wasn't as bad, but was still quite busy (Bolt 2). Looking at the latest Bolt 2 screenshots that were posted above (since I'm not as special as others here to have access to Bolt 2), I'm not totally against color -- I just want it to be used sparingly. That is -- when stuff actually _needs_ to stand out in order to understand the flow (at a glance) -- and there is no other way.

Color should not be relied upon as an end-all "if this is this color, it has this meaning" -- color should have meaning only locally (to where it is used) -- which is why it should be used sparingly. The more you use that color, the more "meaning" you try to assign to it -- and then that "meaning" is no longer simple or intuitive -- it is muddled and lacks the potency it had when it was only used in one or two -- up to three -- different places / contexts.
For example, when you define a node with a color, its output line with that same color, the input of another node with that color, then why does that color change to something else when it goes to the next node? -- The consistency was lost because it got overused and wasn't local and "context-specific" enough to have a clear meaning.

Just my thoughts on the matter.

My responses are in italics.

1. They removed some of those neon lines from the final version, I believe only the green flow starter nodes retained their neon green.
2. I can agree with that for the dark theme.
3. Same.
4. In my opinion it works fine as is. Adding a header wouldn't improve readability in any way.
   
   This was only a suggestion on how it could be 'improved' in some way if everything else stayed the same. The 'header' was simply to make the 'minus' node consistent, which would help it to stand out less for visual flow.
   
   
5. Perhaps.
6. No idea what you're talking about here. Values are being fed in horizontally, flow flows vertically. Concerns are separated.
   
   Visually, I was simply pointing out that the ability to visually discern logic -- i.e. "This thing" + "Does this" = "This happens as a result" -- isn't easily derived at a glance (like it is in DOTS VS).
   This relates to what I wrote about Data-Oriented Visual Scripting (and some of the stuff I said back in drop 6).
   As far as I can tell, despite its clear improvements over Bolt 1, Bolt 2 is still not at all Data-Oriented at its core, and inherently has the same problems as all OOP-based languages (since it was written/designed around Monobehaviour, not ECS concepts). The approach to data flow should be as easily-readable as a sentence and as easily-accomplished as writing a sentence as well. The problem I stated has nothing to do with the flow in particular, but it has everything to do with the fact that you can't use logic to directly define the scope of your scripts (i.e. through tagging the particular entity without having to access or change its actual data directly.)
   
   
   
7. The colors were aligned with new Unity theme guidelines. Seems like most of your points are about colors so far. Not sure why some nodes should be visually prioritized when they're part of a single, linear flow and are read sequentially. It makes sense to prioritize flow starters, but beyond that you've lost me.
   
   Haha, no worries. The colors themselves weren't the problem. It was their brightness.
   Honestly I was just kidding about the colors to some extent -- the "NEON! - NEON EVERYWHERE!!!" made me chuckle so I was just being overly exaggerated and obtuse about it in order to make a point.
   In reality, to me, the real culprit here was just how 'intense' everything was -- as if a huge electrified rainbow just threw up all over the place -- but in NEON.
   
   That being said -- The new alphas really did address most of my points, so I'm actually cool with them as they are now. Unlike you, I wasn't fortunate enough to be privy to getting to play with Bolt 2 -- I only had so much to go on.
   
   
   
8. Not sure what the separate links in this case are.
   
   I was referring to the noodle connection points to the node -- the "links" that "link" the nodes together.
   
   
   
9. You wouldn't confuse a group with an event node.
   
   At a glance, with many groups with event nodes and isolated event nodes, my eye would definitely be in competition between which one to look at first, causing me to have to take a hard "look" at my graph, rather than take a quick and simple "glance".
   
   
   
10. "Lesser" or "greater" flow starters don't make a difference visually. They all start flows so they're marked accordingly.
    
    This is one I admit I was probably wrong on. I'm not sure why I pointed that out, but I think it was because I had assumed lowly "functions" were displayed on the same level of visual intensity as events.
    Even if I were right then though, I can clearly see the "flow" of the graph in the new Bolt 2 graphs wouldn't be too distracting in terms of functions standing out like that.
    
    
    
11. To a Bolt user colored connection lines make complete sense since each color represents a common Unity type. And as previously mentioned, they removed most node outlines in the final version, only leaving the green ones for Flow starter nodes.
    
    The "color" part makes sense to me too -- but as stated above, the intense "NEON" spewed everywhere was a bit less understandable for me, and thus the commentary.

 

Hi. I am just catching up. Can someone clear up for me the Bolt 2 situation. On page 1 and then on the visual-scripting-roadmap it sounded like Bolt 1 was the stable choice and that Bolt 2 was not compatible going forward. But the tail end of these forum pages then start sharing screenshots of Bolt 2 suggesting Bolt 2 is alive and well and what should be used. Perhaps some of dots vs drop 11 used the Bolt 2 UI changes? I am unsure what to use to begin my visual scripting work - is it still Bolt 1 and then those graphs eventually work on DOTS in 2021?

 

Bolt 2 was in a feature complete alpha state meaning you could fully use it editor's Live mode but you couldn't get functional builds out with it as the C# gen part was still pretty unstable. It was around 6-12 months away from a stable release before its cancellation. Bolt 2 screenshots are being shared as a good example of readable icons, but the asset itself is not happening anymore.

They are going back to Bolt 1 and working on updating that instead. That said, Monobehaviour based Bolt graphs have nothing in common with ECS based DOTS VS graphs. While they are combining the tools in Unity 2021, each one will probably have their own graph type with some specialized nodes that’ll enable some level of communication between them. At least that’s my assumption.

The only actual option for a beginner is to use Bolt 1 (or one of the asset store alternatives) since DOTS VS is not feature complete or production ready and Bolt 2 is discontinued.

 

VsDots is dead or alive?

 

It's very much alive. More info here: https://forum.unity.com/threads/visual-scripting-roadmap-update.951675/

 

@Ex-Crow Thanks for all the good info. If I could bother you one more time. I am trying to find out the state of UI for DOTS and then this morning I began wondering if we can even save yet or persist the game world in someway. For UI with DOTS I've gathered that was planned for UIElements and now UIElements is rebranded UI Toolkit - but nothing DOTS yet.

I gather the UIToolkitUnityRoyale demo was the best place to ask for a DOTS UI sample so I asked there.
https://github.com/Unity-Technologies/UIToolkitUnityRoyaleRuntimeDemo/issues/2

Anything else I have missed?

The relevance to this thread being Visual Scripting data into the UI.
It does seem like Visual Scripting and UI are the next big features needed to begin gaining more interest in using DOTS.