DOTS Visual Scripting Experimental Drop 8

Sorry for sounding negative before. It's just the current design of 8 seems to be anti pattern so I had to ask.

 

Feedback: I won't say anything about horizontal or vertical (I don't care to be honest and I haven't tested the other drops so I can't say any meaningful), but for me it seems to sit somewhere between GO-workflow and dots and does neither really "right".

It seems really hard to do the entities-workflow as the "foreach"-node I have seen in some screenshots is missing.
Furthermore, instancing of prefabs only works sometimes (instantiating a cube and rotating it will work, instantiating a cube with a dots-physics-body won't).

But on the other hand it seems hard to do the GO-workflow, too, since there seems no way to get the gameobject the graph is running on (to rotate itself, for example…).

 

Hi, I really like the new look and specially the colors, which makes it easier to read, but there's a big problem, if it goes little bit complex.

Have a look at this two screenshot. Both do the same. Just move an object from left to right and back in a loop.

The first screenshot is from the last drop, which is truly just gray in gray with a cyan lines, but it's much much more compact, because it's top down.

I'm not sure, why it's changed to the way Blueprint works (which is really the best visual scripting out there, but horrible to read if it goes complex).

PLEASE don't make the same mistake.

Drop (last)



Drop 8




Have a look at BOLT 2 (alpha) how beautiful easy it is to read






Another important thing:
Please don't make an extra node just to split a vector!! Add an option to all nodes to split it directly on that node like in Blueprint. Sooooo much easier for everyone, and it saves a lot of space and makes it much easier to read.

 

The lines should get different colors for x, y, z - it is horrible to read.. so much cyan lines. It takes to much time to figure out what happens in complex flows.

 

SO TRUE!!

 

Soooo easy to read ..a dream!

 

+1

 

is there an switch node that doesn't have Execution port?
it's pretty common to use ifs or switches to just compute the value based on conditional or index value and feed the result to a single Set Position for example

 

- I agree with Vectors directly allowing for split components inputs/outputs
- Conditionals >, <, =, <=, ... should be handled with a single node type with different modes, curently each seems to have separate node type so it makes switching among them very inconvenient
- Math nodes don't seem to be able to adapt to the incoming type and require user to switch to correct type, if I connect Vector to Multiply node, Multiply stays Float, Float, instead of Float3, Float with additional options to choose from Float3, Float3, etc...
- also everything is lagging for me a lot, trying to just click and drag on nodes doesn't work most of the times and either lags and then shows the node in inspector or just lags and draws selection rectangle, occasionally it works and drags the node, but something seems to be constantly evaluating behind the scenes every time I try to interact, is there a way to turn that off and just edit the graph without it trying to update inspector etc?

 

Thank you for your answer, that did work. I had to remove the physics body, references worked after that.

Some thoughts with that: subgraphs are only possible if you have never selected a gameobject with a graph authoring component. Otherwise, the last selected graph will stay open. If there is a technical distinction between a subgraph and a graph (probably not?), it would be nice if you could put it in the "create asset"-menu, too.

Small things you probably know already:
- references to prefabs or objects in the scene get sometimes doubled in the blackboard
- The sidebar inspector for key-events sometimes does not work until you select or deselect it
- using portals almost always lead to nullrefs and broken graphs

The positive side: it really feels fluid. I had no problems with the UI being unresponsive at all.

 

I very much prefer Vertical layout too for sure (because in reality it's both vertical for execution horizontal for math, like VFX graph, and horizontal can be packaged into subgraphs so it can be super clean and even stack in the single execution block for fast rearranging)

I however think that you overspagettied yourself in here

I tried to create the same graph in Drop 8 also and it looks like this, not the cleanest, vertical execution and reduced need for split nodes would read better
but definitely less spagetti

here is again the same with a bit more Vertical Execution Graph layout

 

I really hope the tool's focus isn't solely on simplifying the user experience too much towards OOP for "Artists/Designers" (I am in this group/target audience Artist side) and goes back to OOP mentality but using ECS. This kind of undersells the value of the tool and makes it seem like a toy for the kids and the grown-ups write the ECS/DOTS code that actually matters. As this would just be used in a minor part of the codebase. (You don't want to be flying an airplane with the controls of a car. If you are used to driving a car then gets to fly an airplane with the same controls as a car then you will want to control the plane like a car. It would be best if the plane's controls are just simplified plane controls and not geared towards a car) This is currently how the tool feels to me if this makes sense to you. But I thought it would just be ECS simplified.

This eases the worry on that and I'm looking forward to seeing this evolve back into the ECS/DOTS workflow without being hindered by the current OOP style simplification.

I also hope this isn't going to fragment the tool into OOP style ECS and a proper simplified way of dealing with ECS. If that happens it seems one will eventually lose focus and get deprecated.

Currently, I'm not worried about the vertical/horizontal flow, giving us the option to choose would be great though.

 

Hey man
what the error by build game?
hlep me

 

tried to simplify this for personal clarity and got this:


However I'm missing some of the options of Drop 6 like being able to directly choose Combine Mode on Set Position
also missing some Description on the node of important setiings, like On Key Down I want to visually see which key is chosen (I know this is WIP and maybe all that is planned, but have to say it anyway to be sure):

 

Im on Windows 10.0.18362, Unity 2019.3.7f1
it lags mostly when I click on or off of any VS Graph related node or even the Graph asset itself, it takes a while for Inspector to show something

 

Visual scripting is for visualizing logic without having to learn syntax which you did well in drop 6 in dots case and you should have improved upon drop 6 btw ecs is not that difficult to understand.

 

This is pretty much my entire line of reasoning.


At first (like the Unity probably is), I was hesitant about a DOTS-only Visual Scripting tool, but drop 6 really proved to me how capable Unity could be with a data-oriented (and therefore systems-oriented) visual scripting tool! -- With a tiny bit of formatting help (i.e. the concept of those "Drop Zones" or a "Magic Line" like I mentioned in earlier posts and in the drop 6 thread), it was so easy to see how my tiny artist-brain could finally understand everything at-a-glance.

Yep -- I own (and have tried) Bolt and NodeCanvas/FlowCanvas and Playmaker, but I don't use any of these because they've got the same flaws as any other OOP-based approach with regards to "bastard systems" the moment you try to customize them. Sure, you can make your own actions/nodes/dillydabfunctionamabobs, but the moment you do, the nicety and value of the visual-assistance of nodes instantly disappears. You're suddenly faced, yet again, with a pile of spaghetti-nodes, or staring back at that text editor in hopes of maybe gathering some kind of simplicity.



Seriously, I don't want (or need!) a watered-down ECS implementation of an OOP approach.
I want the real-deal with DOTS -- I want to approach my scripting, visually, in the DOTS (data-oriented, systems-oriented) mindset -- as was expected by me and a lot of other people.

For example:

Like you, I was seriously looking forward to DOTS Visual Scripting because it was such a radically-different (and highly efficient!) way of thinking about my game's overall design. Visual Scripting was meant to ease me into that way of thinking about my game while I programmed it. The more I thought about it, and the more I saw the DOTS' systems-based approach, the more excited I got about working with DOTS. Even vanilla DOTS / ECS code was much more straightforward than gameobject-based code, and that scaled exponentially when I started thinking in terms of systems rather than code. But my brain HATES text editors. So when I saw drop 6's vertical stack of systems with data import from left to right, top to bottom -- I realized how great of a design this was for designing data-oriented / systems-oriented logic through Visual Scripting. I was totally stoked about what was coming our way. It was so easy to visualize and understand at-a-glance and my artist-brain deemed the overall approach as great! It was hard to wait to see what came next! -- And now, I kind of regret that I did. That build-up of excitement was totally crushed with drop 8.


The only reason I can see to take this approach is to cater to the old way of thinking about code in the context of game design -- which has always been a poor way to code to begin with. Plus, saying that Unity "supports" this OOP way of thinking is just completely discounting the power and awesomeness of their DOTS system in favor of the old/bad coding practices (fostered by both old and current coding languages). Those ways of thinking about systems in a game/application require too much localized logic/variable grabs to be useful. To create a game, I have to learn a new system nearly CONSTANTLY in Unity. As an artist/designer, why can't I learn just one more system that will totally change my life so I can start making my own systems? Help me change how I think about programming my games! Let Unity finally be the visionary it claims to be.




This new drop is partly why the current direction is such a huge letdown for me -- Its design basically says "UE4 Blueprints are better!" -- And I call bullsh*t on that one. If Unity is mimicking Bolt/Blueprints (as this drop implies), it means Unity plans to "go with tradition" and create a spaghetti nightmare too -- and I can't abide by that.

See below.




This image of a "system" is exactly the manifestation of what artists/designers HATE in a tool -- yet anybody working with Visual Scripts will eventually have to create an impossible MESS like this at some point using OOP -- and, yes, this definitely does include Artists/Designers too!


Unity can't program ALL our "custom" nodes/actions/dillydallyfunctionamabobs for us to keep us safe from the spaghetti-nightmare. But it can provide us the tools to keep ourselves safe from it. DOTS is the sword and knowhow we need to protect ourselves. Artists/designers eventually need to design systems (not just graphs!) for ourselves! Our need for atomized nodes outweighs Unity's ability to give them to us and protect us from the spaghetti-nightmare monster -- but a DOTS-based design approach would provide just that!
So teach us the proper way to defend ourselves!
Give us the data-oriented, systems-oriented, tool we not only want, but the one we also need -- The old adage goes: "Give a man a fish, feed him for a day -- TEACH a man to fish, and you'll feed him for a lifetime."
While you can't "teach" us to like code or text-editors, you can definitely "teach" me why DOTS is SO much better than OOP by showing me a compare/contrast of that "system" (in a VisualScripting context) above or alongside an actual data-oriented, systems-level approach to the same functionality in Visual Scripting. At the end of the day, I know the one I'd choose -- The one that's easy to understand at-a-glance. The one that's simple to change or build on top of or scale, as my needs change throughout my project. That's DOTS, my friends. Simple by nature. Which means it's also simple to Visualize too.

This is great! -- Please push for this. Hard. Please.


I get that some of the issues with the ECS side of things are beyond your particular team's control, but it needs to be pushed up to the higher-ups that Visual Scripts should be following the systems-design approach inherent in a proper DOTS (data-oriented) design workflow. This will automatically reduce (or eliminate!) spaghetti-nightmare monsters for most people due to the atomic way that data-oriented systems must be designed.

After all, Artists/Designers don't give a damn about "code limitations" or "proper programming practice" (if there is such a thing) -- they want their designs to function.


In design, even DaVinci followed the old adage that goes like this:

"Form follows function."

A spaghetti-nightmare monster script doesn't have a form that's actually functional to help artists in any way.
We just tend to run away or find a pre-programmed system someplace else by somebody braver than us.

Artists need a smaller beast to battle. Like "atomic" -- but not this brand of "atomic":

This version of "atomic" has the exact same functionality of a standard "function/method" call in OOP.

Yes, this is bad.

The whole goal of a function/method (or a "node/action" in the Visual Script case) at one point was to help with code repetition (and thus to save memory!) But now, with an abundance of memory, they are simply used as a crutch.
Now we make a bunch of tiny "abstracted" calls (to decrease the amount of code you have to type or digest at any one point in your script), but this becomes painful when you are first trying to come to grips with your code after a long time (or when you're trying to understand others' code!) You are writing a spaghetti-nightmare monster in any of your more complex scripts -- whether you realize it or not!

Let's take an example (standard) spaghetti-script:

Code (CSharp):

1. void HandlePlayer () {
2. direction = MovePlayerInADirection();
3. Jump();
4. PlayAction();
5. ValidateDirection(direction)
6. }

Looking at that script, do you have any idea what it does? -- Moves the player? Nope. MovePlayerInADirection() simply gives a direction the player might move later. What about Jump() -- Does it handle player jumping? Wrong again. It "jumps" to the next action in a list (defined further up the script, near the class definition). PlayAction() definitely executes the current "action" in that list, right? Wrong again. It defines the current action that will play in a different method (defined further down a monster script) that will eventually be called in the ValidateDirection() method. What about the HandlePlayer() method? That is supposed to actually move the player at some point in the ValidateDirection() method, right? Nope -- Wrong again. It just "handles" where it might move. The actual movement takes place in another completely separate method that calls the method in an Update method.

WTF -- Right?

Yet, this is a standard implementation pattern of a simple C# class in a standard game.

The suggestion about "atomic" nodes easily lead to the same damn problem -- just with a spaghetti-nightmare monster hiding beneath the surface of the otherwise innocuous-looking node!!

The system itself is the root of the problem.

This has nothing to do with the amount of nodes/functions/methods/actions/whatevs!!

I'd rather open up a text editor than edit a Visual Script like this!! -- text is much faster/easier-to-understand!

For artists, the OOP form (even though its form is still visual) STILL does not follow the function artists/designers need. By that metric -- the very possibility for artists to even accidentally create a hard-to-visualize spaghetti-nightmare monster (to begin with!) is empirically considered "a bad design" -- Of course, this is assuming Unity's goal really is to create a visual scripting tool that is functional to artists/designers. That may not be the case.

Because, with standard OOP practices (like the ones illustrated above) -- That's not happening.


The spaghetti-nightmare monster comes not because you're using too many nodes -- It comes out because the moment-to-moment functionality of your infant node-beast can suddenly become ANYTHING -- without a moment's notice -- when programming in OOP.

With data-oriented systems-level approach to your technology, that's not possible.

To further the weight behind that notion, please refer to a part of my previous post:

"An elephant cannot be a giraffe sometimes."

With OOP -- at any moment, an elephant object can totally function as a giraffe object. Sure, the object might not change, but how you reference it can. You can always make a class that picks and chooses the properties of an elephant to make the instance look like a giraffe. After all, both giraffe and elephant have a size/shape/color -- the only truly defining difference between the two is the weight of the elephant and the tallness of the giraffe. But if you're not considering those factors in your system, you can totally have a giraffe if you happen to color it the same color as an elephant. The size, supposedly a defining feature, relies on the weight/tallness to be clear, but if you ignore those to keep it simple (i.e. a "big" size and a "yellow" color == a "giraffe" object), you've (at least by the factors you're measuring) got an elephant that is a giraffe, regardless of its tallness/weight. With DOTS, since an elephant entity must have a reference to a totally different dataset than a giraffe entity has (i.e. size/color + "weight" rather than "tallness"), you will always know your system is performing its operations on an elephant entity by default. You never have to check for it. This is guaranteed. So your system to paint an elephant yellow will never try to paint a giraffe yellow, because it can only reference the one dataset it knows. Therefore, in DOTS, it is impossible for an elephant to be a giraffe sometimes.



This leads me back to the issue with the functionality of the OOP-style systems design being non-functional for artists/designers.

( First, please note: function != functionality )

For proper function of a visual-scripting solution (for artists/designers), we ("dumb" non-programmer simpletons) need to understand the functionality of our code at-a-glance. We need a visual tool whose form serves the function of that need by the tool allowing us to both create and digest our own fancy functionality in small (atomic) doses.

Guess what? -- DOTS' data-oriented "mini-systems" approach is designed to do exactly this!

But again -- this is "atomic" in the DOTS "mini-systems" kind of way, and not "atomic" in the "abstraction / obfuscation" kind of way.


If all an artist/designer needs to learn is how to think in data/systems -- why not provide them the framework to easily author those data-oriented systems to begin with? Why go back to the stone-age with OOP? -- At one point, it was "easier" to work with objects. But now, as games have become much more complex, we're working with (and tweaking) systems more than we are individual objects. More than anything else -- we're integrating and evolving all of these systems as we develop our games and projects.

Overall -- a game is nothing more than a database with a fancy interface.


To hide behind OOP-ish tendencies is a terrible way to move the DOTS technology forward, but it is even worse to also advise new users (and artists/designers alike) to perform the same mistakes you (as programmers) now know is wrong. This should burden you as the heralds of this new technology. The practices OOP brought about during years of stagnation and bickering that hid behind "proper code practices" blinded a lot of programmers to the data-oriented future, and now Unity is putting that misguided OOP methodology to describe the amalgamations some actually call "systems" on a silver platter, offering them up as "the gold standard" to users who either know no better or who those who are simply too afraid to change. If this keeps up, you're inadvertently digging the early grave of DOTS when you could have pushed it further, both to artists / designers -- and the world.

Just my two-cents. Take it or leave it.

 

I am the most curious about this. Would love to create my own graph tools or simply make my own flow nodes/actions so they show up in the main node menu!...please.

 

Wow.
@awesomedata has some of the longest posts I have ever seen...
But! They are absolutely spot-on to how I feel about this topic. Never before in my entire life has someone else voiced so clearly and to such a profound degree how I felt inside... It's terrifying, but also impressive.

Anyway, I'm with awesomedata for this subject! Personally, I think we should elect awesomedata as the supreme Artist/Designer visionary master-guy—because he really knows what he's talking about.

#10/10 would read the text walls again.

 

Thanks for clarifying. I pretty much only care about it being fast, I'm sure nodes in any form can be massaged visually, it looks like you've hit all the points: optional horizontal/vertical, great performance etc...

Only thing remains is when it can be used for production

 

Thank you And the colors and bigger lines are the right direction.

 

It is funny, but than I first tried to use dots I realized that I can not use Normal events generics, polymorphism, Interfaces. And than I fought I was put in stone age


And without interfaces I encountered a situation called "combination explosion" then for each new data type you need manually create new system to support all combinations. What was easily made in oop with interfaces and generics via handful of classes turned out in 1000s of unique systems. And in that particular case DOD was not acceptable at all.

In general a feel like in OOP I can do Anything but in DOTS only a specific fraction of things.

 

Hello. Wondering if someone can help me. I have the files unzipped. Made a new project. Do I just drag these files into the project window? I cant get the packages files to go into the packages in the project tab.

 

@sinjinn add it to unity hub and open it with 2019.3.5f1 and wait for dependicies to install if you dont have'em

 

Thank you very much!

 

I'll be playing around with this drop while waiting to see how things evolve down the line. The ECS code side of the authoring workflow isn't fully finished yet, so there might still be some changes that will shape things differently for both. I'll have to wait and see how things are especially when the ECS parts start to come back in the VS Graph

 

That's a fair point -- but as I'll explain below (and sorry about the length of this), the number of data types doesn't have to correlate with the number (or nature) of combinations of your data types.

Data and Systems are the most general and flexible form of any system's design or evolution. I think it's important to understand that the approach you use to get the same functionality you're used to is the problem in this case, not the flexibility of DOD (data-oriented-design) itself.



C# interface is like backwards parenting -- and nobody really wants to parent like that, do they?

The whole idea of an "interface" -- at least functionally -- is to provide a workaround for inheritance. The "parent" classes (in C#) are barred from any possibility of having its own children. Instead, their children "adopt" the "parent". Interfaces are literally reverse-inheritance. To put it another way -- the way C# inherits is "backwards" (and totally wonky, IMO). The purpose is to allow an "interface" to different functionality than solely the functionality provided from the origin type. In these "new" bits of functionality (passed on to the "parent"), it is an attractive option to easily re-implement the specific functionality -- but in a slightly different way -- that a parent needs, leading to lots and lots of equally "attractive" opportunities to repeat or contradict yourself while you inherently convolute your codebase with more and more interfaces. After all, think of how "attractive" it would be to totally change everything you didn't like about your own parents?

Inorite??

While interfaces are nice to have for items/spells/etc., I think a DOTS-based visual scripting tool can provide a much better/easier and more performant/easier-to-understand set of tools to accomplish the functionality this task affords using DOTS -- all without the exponentially-increasing burden of convoluted, hard-to-understand, code as you write your systems. This, to me, is the real hidden beauty of DOTS.

Yes, interfaces are convenient to have "on the fly" with an OOP "system" that has the "flexibility" to suddenly become anything at any moment, but this is still terrible practice when it comes to understanding the overall functionality of your code in an easy way. Writing an equivalent implementation in DOTS with pure datasets and systems (especially when assisted with visual tools and UI) could easily be just as simple -- if the immutable nature of the DOD is embraced.


Inheritance -- the DOTS way!

In the DOTS world, rather than an "inheritance" or "parent" concept, you instead have a combination of proxy systems and datasets that handle your needs for behavioral and property variation simultaneously.

This process can definitely be assisted by a visual scripting tool that makes the "inheritance" of datasets/systems more intuitive and easy-to-read / understand at-a-glance than a huge text file full of classes of items inheriting from an "IItem" base class. This kind of visual scripting tool would need to definitely introduce some Entity-based / Component-based node flows/schemes to help with inheritance and auto-population of systems based on certain tags to assist in a valuable way with our data-oriented-designs. Currently, it's not perfect -- but it's easily doable even now.


So the basic idea is as follows:

Using the "elephants can't be giraffes sometimes" concept (described in my previous post) as an example, let's say you actually still want an elephant to also have the property of tallness (that the giraffe has) -- sometimes. By its very nature, DOTS discourages one to go this crazy "anything can be anything whenever it wants!!!" route that C# (and drop 8) tends to advocate, but there are very real circumstances where this is the only route you can reasonably go. Like items, for example.

With DOTS, instead of the (dataset1) + (system1 + system2 + system3 ... ) = item1 , (dataset1 + dataset2) + (system1 + system2 + system3 ... ) = item2 , etc. (repeated exponentially for each new data dimension or item you want to have), you would instead need a (dataset1+system1) = itemBase , (dataset2+system2) = itemType , (dataset3+system3) = itemDetails ... for whatever level of complexity you're looking for.

To give a more concrete example, the first system is a base "shape" for the data -- i.e. an "Animal" component -- and has all the properties and can do and manage everything an "Animal" can. Following the original example in my previous post, an "Animal" dataset has size/color properties, and the corresponding "Animal" system might have "walk / laydown / die" behaviors, but it's "eat" behavior is determined by its "tallness" factor. We'll call this dataset1 and systemset1, with "1" being the first level of the "hierarchy" of data-based behavior. For any "entity" marked with an "Animal" component, the corresponding "Animal" system(s) interact with any entity with this component data. The Animal entity now contains its size/color properties, but we don't know what kind of Animal it is yet, so a new "Elephant" or a "Giraffe" component (which provides its respective dataset at hierarchy level 2) can now be added to the "entity" to determine which one it prefers to be.
With the addition of the Giraffe component to the entity, a "tallness" factor now exists for the giraffe because the Animal system recognized it needed a HasTallness component too (so it can EatWithNeck). For the Elephant, a separate "weight" factor now exists, but since we only need two animal types, our Animal system assumes it can EatWithTrunk if it has an Elephant component. The "EatWithTrunk" / "EatWithNeck" behaviors can be applied through the "Animal" system depending on what the Entity's components are, but another system would be best to automatically select (and forward execution of) the proper eating behavioral systems based on the entity components (system hierarchy level 3), though we'll assume this happens in the Animal system for simplicity. Finally, if you want an elephant that also has tallness, you simply add a new HasTallness (dataset hierarchy level 3) component to that Entity -- meaning you now have Animal, Elephant, and HasTallness components on that Entity. The "HasTallness" component could be more general to allow for other properties to be handled by a single system, but for this example, I'm keeping it simple. The HasTallness component generates the tallness factor of the Giraffe component's dataset (which doesn't actually include anything since the Animal system handles the tallness factor inclusion now). Now the "Animal" system can look for the "HasTallness" component on the Entities with the "Animal" component to see if it needs to worry about its "tallness" factor. (NOTE: A Giraffe might automatically generate this component itself when added, since HasTallness affects how the Animal eats, but I'm assuming the Visual Scripting tool doesn't help with this kind of use-case, so I'm putting it into the Animal system's realm of responsibility to handle transcendent properties like this.) If the Animal has this HasTallness component, the Animal system would automatically apply a CantEat tag to the Giraffe if its tallness value is very low (because maybe only tall animals can "EatWithNeck"), so if it is a short giraffe, it just goes hungry.

Beyond that depressing thought, if you have a Robot component to the Giraffe or Elephant, and the Animal is now a Robot and no longer needs to eat, but needs to charge instead, you simply move the "EatWithTrunk" / "EatWithNeck" to a system that ensures a Robot component doesn't exist on the animal -- If it does, the system does nothing anymore. The Robot system (respective to the Robot component dataset) allows the robot to charge. However, the Animal system allows it to still "walk / laydown / die" -- except perhaps the Robot system can set it to "walk" behavior if the charge is above a value that would activate it again.


In closing... just remember "atomic" data is very flexible!

The approach I used above is nothing more than using the flexibility in implementation details that small systems and component combinations provide, rather than relying on complex "parenting" and rewriting components entirely!

Ideally, you should be able to quickly break a system apart and reintegrate it into another system (i.e. the HasTallness portion) depending upon what you want to do with it ultimately.



With that last sentence, I think I've provided you with all the tools you need to address pretty much any issues with inheritance in DOTS that an interface might be capable of providing you.

Creatively structuring data the way I described above allows one to have the best of performance and flexibility from both worlds. Yes, this method isn't immediately obvious, since it is a different way to look at what you already know, but it helps to simplify your concepts into systems that can still provide the same functionality in order to see how they can be improved. This is a bit of a learning curve, but hopefully the community (and Unity itself) can help offer ideas on this.

Overall, it is a given that your data's basic structures are immutable and can never be altered in DOTS (accept this! -- it is a good thing!) -- You can simply design your non-spaghetti-nightmare-monster systems in an atomic and easy-to-understand way that accounts for that atomic nature using your systems and components as the backbone for your flexibility -- instead of always changing the structure of your objects to achieve that same "flexibility" (which is really just hidden complexity and obscurity that hurts you in other ways, much farther down the line!)

Visual Scripting tools are ideal for the process of making data atomic and easy-to-understand at-a-glance.

I really hope Unity takes note of this process and use-case (see above @ans_unity and @theor-unity!)
This is pretty much the suggested way to write a visual tool for someone like me.


Take note, Unity guys:

Outside of simple node-flow, Unity's visual scripting solution for DOTS should keep in mind (and visualize!) the flow of component--system--entity flows as well so they can stop relying on gameobject componets to do this for them!! Doing this directly in the Visual Scripting tool is the most ideal way to integrate complex systems/entities/components since the node flows are perfect for that sort of thing!!

The rest is up to your creativity in what data you use when/where, and how you assign that data to your systems/entities!

Now go have fun! -- A new world awaits!

 

How to handle polymorphism?
Let's say there are 100 different animals and one man. The man comes to each animal and states: "Make some noise".
In the classic unity approach:
I create component NoizeableBase or interface INoizable. For each unique object i just create new child of NoizableBase component and override void MakeSomeNoize or just implement INoizable in any unique component and override Noize behavior there.
Then man object just gets NoizableBase components or INoizable and calls MakeSomeNoize void.

How would you handle this in dots code?

 

This looks like a good read on ECS & Polymorphism. What would be really cool is if this could be handled visually. Hopefully they have a User Experience (UX) person looking into things like this?

Replicating Polymorphism in ECS
https://coffeebraingames.wordpress.com/2019/09/15/replicating-polymorphism-in-ecs/

 

You would make a "Noizable" system that handles an output whenever that noizeable component is attached to an entity. When the players trigger hits any object with a certain tag component, the noise component is added for one frame. The Noizeable system plays that sound during that frame then removes the component from the entity. Events can be handled by creating whole entities that carry certain components...along with the systems that handle those components on the entity. The "event" entity is created for one frame, then removed when the "event" is over.

It does seem sloppy at first, and is extremely hard to make it designer friendly...hoping for this visual scripting solution to solve those problems on a designer level.

 

Thanks this article helped. Basically polymorphism ~= adding component as event and then remove it.

 

Or you can hack you way through it: https://jacksondunstan.com/articles/5494

 

Hello, main puzzling thing in DOTS are line between GameObject/Entity, MonoBehaviour/IComponentData, etc.
"what's about allow using ONLY ENTITIES in project" - GameObjects, MonoBehaviours, GetComponent not exists now!
ONLY:

• Hierarchy > Entity Debugger
• Inspector - MAKE EDIT CHANGES AT RUNTIME!!!
• Scene - make entities controllable by conrols for gameobjects like "Move Tool", "Rotate Tool", etc.

 

How do I view the converted source code?
How to import one graph to another?

 

Thanks!

 

How do our own custom or function nodes fit into this pattern? I expect we'd just have some inputs and outputs but to deliver effective custom nodes we would probably want to have access to the source of your nodes in an easy to find way.

 

To clarify, the current polymorphism-ish workflow in ECS goes like this:

You can add the "MakeNoise" component tag to get an "Animal" base system to make the "Animal" execute its respective "MakeNoise" system (i.e. a Giraffe may have a different system than an Elephant -- i.e. "MySpecialNoise" -- but both need "MakeNoise" component tag to execute this "MakeNoise" system). Then, when a "Human" entity with a "SayMakeNoise" system calls to all entities with an "Animal" component, the "SayMakeNoise" system applies the "MakeNoise" tag to all Animals at once -- except for "Animals" with "MySpecialNoise" tag. Since the "Giraffe" needs a special noise, a "MakeSpecialNoise" component tag is added instead by the "SayMakeNoise" system, allowing the Giraffe to make its own special noise execution. The "MySpecialNoise" component would likely hold the data pointing at an audio file for a special Giraffe noise (rather than a default noise). This could be duplicated for any animal with a non-generic noise.



HOWEVER.


The ideal workflow for Polymorphism in ECS would be like this:

1. Use a Visual Scripting tool that can make visual authoring of data/system dependencies on a per-component and a per-system basis easy.
   
   You might call the authored data a "Component Template".
   
   
   This "template" should have two authoring options:
   
   a) A (simplified) node-graph to link up components and system dependencies logically if you need more control over logic/data to guarantee certain data is available when certain components/systems exist (or whether certain components or systems need to be added when they don't).
   
   b) The second, more preferable, (main) authoring option is a reorderable / searchable list to automate this add/remove components/systems process (when you don't require a deep level of control over the "ifs and whens"). This authoring solution could also be referred to as a "Component Template Query" -- if you allow this query to be used at runtime. In most cases, this is not needed, so this is best left as default to be called a "Component Template" when it only exists in an authoring session (to build up your entity data/system requirements). If needed in a runtime system, you can "Convert to Component Template Query" in the VisualScript tool so that this query can be precompiled and/or optimized so that these could be used to sort of "execute arbitrary events" as described above.
   
   
   
2. Also, Visual Scripting tool must be able to do two things to make Polymorphism easy:
   
   a) Allow named Entities to obtain their components / datasets from a user-scripted system (that can be easily-associated -- or associate itself -- with relevant components that it may OR may not use at-will) and let this association created in the Visual Script tool (optionally) persist into runtime (in case of more dynamic needs).
   
   b) Individual named Components (with or without being specified in a system) should be able to specify automatic inclusion of the following options:
   • A) a particular set of systems and/or components to automatically be included with the component, and/or
     
   • B) a particular system to dynamically add/remove other systems / components at-will (at runtime)
   
   
   
3. Lastly, Visual Scripting tool should be able to differentiate Editor Authoring component data from runtime data (which should be as simple as adding / removing an "Editor" component to "tag" it during an authoring session.)
   
   
   
   With those prerequisites, the REALly easy WORK begins!

1. Use Visual Script tool to author the base "Animal" (Animal datasets + Animal systems) and rig these up (or simply identify them) as a new Component Template.
2. Author the "SayMakeNoise" system. This system will check for all entities with an "Animal" component and adds a "MakeNoise" component that incites execution of an existing "MakeNoise" system (embedded in the Animal component template) to play the default noise audio file.
   For any Animal entities with "MySpecialNoise" component, the "SayMakeNoise" system instead adds a "MakeSpecialNoise" system on the Animal entities that plays the noise file associated with the entity name and/or its component tags -- i.e. Giraffe name or tag plays "giraffe" sound file, etc. (A separate system isn't necessary, but works for example purposes.) Both components remove themselves from the Animal entity when done playing a sound, and the systems do nothing when the components don't exist (and can probably be removed too).
   Now attach the "SayMakeNoise" system to an entity named "Human".
3. Give unique names (or tags) to 100 entities and add the new Component Template to automatically populate the required datasets and systems for an "Animal" entity on them. Author special components (using Component Templates where complex "special" behavior is necessary) for any or all 100 animals. You're done. Hit Play. BAM! -- All 100 Animals are playing all their different exotic noises at once, blowing out your earholes!

 

I've only been following this visual scripting stuff very casually, and I'm an engineer, which I'm sure will flag my feedback as unimportant. However, I agree with what @awesomedata is saying. You have an opportunity to teach an entire new generation of game developers to think with a data-oriented mindset and more specifically closer to the way that the hardware and subsystems work behind the scenes. Yeah, I'm sure users had to jump through some more hoops in prior releases to get up and running, but what it seems like here is you're sheltering the user from reality at a huge expense.

How is the user going to debug this script with the Entity Debugger? How is the user going to understand the terminology when they try to search for things on the forum? How is the user supposed to manage and modulate components that are shared between systems? How is the user going to make the leap of converting one of these scripts into a system when they need it to do that extra custom behavior?

There are a lot of cons to this approach and I don't think you're thinking ahead with this decision.

 

I feel the need to chime in and support what the people above me are saying.

When I first saw the screenshots for the visual scripting system I got really excited. It looked so innovative and easy to follow. I loved the separation between vertical and horizontal. And I also liked how it fully embraced the ECS workflow. But this... this is really disappointing to put it bluntly.

 

So, do I understand this correctly? From the cool DOTS-based visual scripting idea, which translates to actual code we went to a Blueprint-inspired, (game)object-oriented glorified state-machine? How did this happen?

 

The cynic in me thinks that this is the result of previous drops testing poorly with focus groups or receiving bad feedback from partners. I can imagine someone up in the corporate ladder telling the team that "X big company says their employees already know blueprints. You gonna do blueprints now."

 

Unity should lead here! Visual ECS gives Unity a competitive advantage over just about every other game engine! All they need to do is hire 1 or 2 User Experience (UX) people and work with and listen to them everyday.

I hope things get back on track in the next drop!

When is the next drop?

 

I think UX for it is good and it's just this one drop that flipped things in the opposite way. We'll have to see when the ECS parts start to come back to the tool but I'm sure it's still in everyone's mind that this won't change much since this drop would be irrelevant.

Drops are usually 6 weeks apart.

 

Another worry with this is that programmers and designers/artists or whoever using the tool will be in a totally different mindset as well as their vocabulary while both are working with ECS. Sometimes you get stuck on something or looking to do things differently/optimize etc and you could ask a programmer something or even watch a code tutorial to get some info.

With how things are looking that would all be useless since the nodes have Object-Oriented friendly names and terms. So we would probably be looking at a separate scripting doc for VS Graph when we should be able to use the same concepts just more compact/simplified.

I can't say things will be set as there are still changes being made and will be made, so I'm also waiting to see how things progress.