DOTS Visual Scripting Experimental Drop 8

Woo Hoo! I am at home because of the Virus all week! Guess what I am going to be playing with all day!

Normally I would be at work at my real job! lol

@ans_unity thanks for being on time! A lot of us are really looking forward to Visual Scripting in Unity!

 

Gotta say this definitley looks a lot different and I am a little confused. I am assuming we are supposed to build our own triggers and events.

Looks like I am stumped right away. How do you pick the key for the On Key Down node?

 

Do we also need to make our own Triggers? Not quite sure how to connect the triggers to other nodes and make them trigger something.

 

These trigger here:


I've made some input and output triggers but I am not entirely sure how they work?

EDIT: FYI and yes I know how to connect nodes together and do flow/state logic. I'm not that green at this .

 

wow very cool! Thanks.

 

Initial Feedback/Observations from a Non-Coder (I still keep up with ECS and do small amounts of scripting)

It seems like a completely different tool to what we've been using the past 6 drops.
I like the colors, how the nodes look, and some of the neat UI on some nodes (like the timer bar on the stopwatch and other similar nodes)

The rest of this might seem negative but I'm just kinda confused and need some clarification on what's happening with this drop.

This new version seems a lot more restrictive than previous versions from what I can tell. More like you are locked to a script per game object, rather than working on the systems that can affect a lot of objects/entities that ECS is known for.

Maybe I'm missing something. Is the tool being rewritten and functionality that was there isn't currently ready? From what's being said it seems that it just got changes and higher-level nodes but it doesn't feel that way.

Are we now only able to changing variables in the Blackboard and not the inspector?

Also, the Separate windows for the Blackboard and Minimap feels cumbersome. Maybe If I dedicate a monitor just to the VS Graph window I wouldn't mind but the way it was before Drop 6 I think, basically integrated like Shader Graph, or the VFX Graph seems better. I use one monitor screen for the Game View and another for the rest of the editor. I usually dock the other graphs (VFX and Shader Graph) in the game window to have a larger space to work with so using the Blackboard or Minimap for VS Graph just add Tabs to the left that are visible when you switch to any other tab.

Spoiler: Image

- Will the other nodes come at a later date? Currently, there isn't any in the create node menu and you can't find anything related to entities in there as well.
- With the new setup, how would you make a system that only works on certain/tagged entities as you would with an ECS system?

I really like the node UI changes in this drop, the other changes I'm struggling to see how they are beneficial over what was previously available.

 

Thanks for clearing things up.

The nodes that are close to the C# API for DOTS that are in the older drops, 6 and below. This is probably tied to when the graph starts to get back to an ECS like workflow.

Ah, alright.

Wouldn't this cause issues moving forward? Currently, it's more like working with monobehaviour and not like ECS. So further down the line wouldn't this cause performance issues that shouldn't be with propper ECS workflow?.

From my understanding for ECS you work on setting up entities with components (necessary data you want to work on) that systems would act on (use that data and manipulate only those entities)
The current VS drop is the complete opposite and makes you write ECS code like monobehaviour that is attached to one game object, as you would do with monobehaviour.

This part I'm not fully understanding.
How is this better, what are the benefits of working this way?
Is it actually taking full advantage of ECS/DOTS?

 

I'm seeing this as well -- I really liked the "non-UE4-inspired" direction Unity was going in drop 6, with the ShaderGraph output-style / vertical behavior approach. It seemed a heck of a lot more DOTS/ECS friendly than what I'm seeing now.

This approach is very localized, which is pretty offputting. I was looking to use the power of ECS to modify many gameobjects at once in an easier, more visual, way.

Definitely agree on this. The drop 6 ShaderGraph approach was much nicer and felt more comfortable to use.

The Triggers being underneath the Variables (rather than in a new tab or something beside "Variables") really makes things feel cluttered/cumbersome. Definitely not liking this so far.

I consider myself a real world client/user and I think the current node types are okay, but ECS is a new paradigm and it needs a new way of thinking (as well as a new approach) so why keep catering to old ways of thinking when users like me and the guy above are asking for a better UI to approach ECS features?


I can't see myself using this over Bolt or NodeCanvas if it doesn't let me work with multiple entities easily without bogging me down with the overhead that the old gameobject approach did. This is the kind of thing that needs to happen in the initial design stages -- not later on as a "tacked on" feature.

Preaching to the choir my man. I totally agree -- out with the old, and in with the new.
Just not this (drop 8) new.

I wish more of the Unity Team would get out of the rut of "thinking like a programmer" and think more along the lines of data management. This is not a hard idea to adopt -- except when you've been doing it for years and are resistant to change. Most artists/designers are totally open to a brand-new way of thinking about code. I know I am. Why not give it to me? -- I am not about to be okay with sloppy memory-management overhead when I have a tool that can help me manage my data the right way.

Unity Team, by default, needs to go the way of the Data Oriented programming style -- so give us a tool to do it right.


That being said, I don't hate everything about this release -- the node list isn't terrible, but it definitely lacks of any ECS-inspired efficiency. Unity got me worked up about this one with its "Performance by Default!", and now it's letting me down. The "default" in Visual Scripting seems to be "not so performant" because I've now got to add individual object management to my setup, which is a TERRIBLE way to program a game. The more you can abstract, the better (and more "performant") your design (and its scalability) will be.

DOTS Visual Scripting should definitely allow me to scale from an "object-based" approach seamlessly into an ECS-based (multi-object) approach with minimal effort.

Right now, this looks to kill me with heavy object-level micromanagement (rather than system-level tuning) of my cool design, which totally disheartens me about the whole thing. As a designer, I wonder why do you hate ECS so much that you would burden me with such a huge amount of tedious garbage-work that could be simplified by giving me a systems-level overview of my visual scripting? I should be able to write a system once -- then easily (and intuitively) plug it (visually) into a different system. With that "shader output" or "stack-based" approach in drop 6, this was easy and intuitive. It hybridized the vertical and horizontal visual-connections, minimizing spaghetti-code. In this drop, that is back -- and in full force. I would never be able to easily-visualize my whole system in a "REAL" project with this. So far, the kind of intuitiveness in drop 6 escapes me in drop 8.


As a plus, I don't hate the colors -- I'm just worried that with the direction drop 8 took, it's probably going to look like a disco / rave / neon-laced-drinking party if we're not careful since there is no real reason why the connectors need to be colored. This kind of non-utilitarian color promiscuity harkens back to the UE4 color-vomit I can't stand to look at, much less code with, which is why I don't use UE4. Please don't go UE4 / Blueprints color vomit. PLEASE don't... Keep what made drop 6 unique and easy-to-understand. And PLEASE take my feedback into consideration. This drop just isn't working for me so far. D:

If you have any questions, I will not hesitate to explain my reasoning to the best of my ability.

Just don't write me off.

 

I have to agree. The 2-axis design where the time flows vertically and the data flows horizontally was a stroke of genius. I also liked how it felt like the data going through a pipe with transformations being applied in each stop. I'm not a fan of the direction that drop 8 has taken.

 

Been playing around with the sub graphs and made a Vector3Add subgraph to test. Is there a way we can script our own input/output nodes through C# so we don't have to do this trigger in and out approach? It works, it just kinda makes the flows messy. Unless I can accomplish doing calculations without doing the triggers?

 

I tried making a node myself but it doesn't seem to pop up in the graph node menus

Code (CSharp):

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

Is this made correctly or are custom nodes not permitted?

 

Also, we at least need "Drop Zones" for our Visual Scripts:




See my article about why this is important here.


Drop Zones are the areas labeled "subject" and "main idea" in the image above.

Ideally, these "Drop Zones" could be auto-organized.
In these zones, you are either setting up your data, converting it, outputting it, or converting it to be output, but you are never changing or utilizing it. This happens in the "verb" portion of the script.
The "Visual Script" should happen in the "verb" portion of the script, keeping everything you're doing (functionality-wise) easy to understand at-a-glance.

I feel like the vertical "blocks" of "main ideas" and if/then/switches in the previous drop (drop 6) was a great way to organize script logic, and having that verticality to separate different portions of the script was indeed "a stroke of genius", which was well-put above by another user. I was quite impressed by this and really surprised to see it go. We at least need some kind of a "Drop Zone" area for the beginning/end of our scripts if nothing else.


@Unity Programmers

The visual clarity of a tool is KEY for artists/designers.
Many of us could code all day long -- we're not stupid -- yet we artists/designers keep being treated as such.
However, this thinking that "artists/designers = simpletons;" is just fundamentally wrong.

Without code having that visual clarity we crave, code just drives most of us nuts. Yeah, maybe we're picky, but that's why you programmers love us -- It's a huge part of the reason why we take time to learn how to draw stuff besides stick-figures. It drives us nuts when things aren't how they're supposed to be. If things are to break the rules, then they had better do it in a really interesting way! -- Which is partly why we loved the drop 6 before. I hate to say it, but your "internal" team of "real world use-cases" suck at figuring out the majority of artists and designers. That -- or they're too nice to you guys and don't want to hurt your feelings because you worked so hard on this. I'm sorry, but I appreciate you guys more than that. I can't be okay with you going the wrong direction with your work when I know it can suit your goals so much better. You previous work, drop 6, was vastly superior to this. So please take my criticism with the utmost love and respect for you guys. I appreciate all of your hard work.

 

So this drop is really confusing. What is the workflow we should be following?



1. What are the input connectors for? Are the input connectors for Events or something totally different like Flow?

2. I spent the last 20 minutes just trying to rotate a cube, that should only take less than a minute.
A spinning cube is like the "Hello, World!" of visual scripting. Could someone post a simple example of a simple spinning cube?

3. The menu that comes up when I hit the space bar is confusing also! I am guessing that the right side is just for documentation in that menu but it looks like it has nodes and connections I can click on?

4. What does this message really mean, it is not clear? Warning: When editing a project asset and not a scene object, scene references cannot be edited. ( Technically I should not have to worry about whatever this message is telling me. It should just work! )

Is there a User Experience (UX) person on your team? If so they need to speak in a louder voice!

 

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

 

Hello, how does all these nodes translate into code ?
Does is work with entities archetypes ?
Is the "generated" code jobified and multi-threaded ?

 

From what I can tell the input and output are used for things like subgraphs where you would set your input points to plugin data and the output. See this post

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

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

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

Spoiler: Node setup for Rotating Cube

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

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

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

 

Thanks, I got is to spin! I kind of like it!

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

When you say...

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

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

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

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

 

I have two out of place questions:

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

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

Thanks!

 

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

 

I don't use this tool but reading this is disappointing. What was the reason behind the change? Is it because of the "clients"?

 

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

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

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

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


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

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

What I just described is a set of systems.

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

Why?

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

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

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

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

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

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

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



An elephant isn't a giraffe sometimes.



In both ECS and in life, this is true.



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

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

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

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

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

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

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

I've seen genius in you guys' work. So keep it up!

 

One feedback I have right now would be to maybe make the orange line (the execution flow) stand out a bit from from the other lines.

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

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

 

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

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

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

 

How do I do to show variable on the inspector?

 

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

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

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

or any other example project that would showcase some parts in use to avoid too many assumptions about the new workflow

 

It looks like Bolt. I thought that this VS would be entirely different.

 

meanwhile looks like Bolt 2 got some great design ideas from Drop 6, lol
but I guess looks are not everything

 

Anyone here who is using playmaker?
I have been using it for 10 years and the way you can create actions and connect them togther is very easy for me.

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

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

 

First, thanks for the effort in this stuff, it helps a lot in managing dots in a "read-able" way, we think this approach is fantastic!

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

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



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

Code (CSharp):

1. abstract class DotsNodeModel<T> : BaseDotsNodeModel, IDotsNodeModel, IPropertyVisitorNodeTarget where T : struct, INode
2.     {
3. ...
4. }

If we change that interface definition to be public, we get it working again in the mentioned custom folder and we have no error in the console.



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

Are you planning to make this thing extensible?

Thanks!

 

Bring back modern and clean vertical flow.

 

Is visual scripting still planned for dots only or it can be used with GameObject without dots?

 

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

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

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

 

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

 

I'm curious about if performance would be any better than a classic monobehaviour script or if threading will be an automatic thing.

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

From what I see it's just really for artists so that Unity can generate code that works with DOTS rather than being high performance.

 

People fear what is new but if you can explain something like "this is very very fast to execute" then people might understand. Because otherwise why bother with DOTS at all... if it's not fast to execute?

 

Yes please user option for horizontal / vertical

 

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

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