DOTS Visual Scripting Experimental Drop 8

Fundamentally, good UX is teaching the user how to operate in the environment they are executing in. You're teaching people how to use the tool. I argue this is teaching the user to use the tool ineffectively.

See this is where Unity's ECS direction is lost on me. You don't want to rely on magic to write jobs, but instead you want to rely on magic to convert GameObjects to Entities? Sounds like a huge waste of engineering time that could be spent making a hard break. It feels like most of the Unity engineers are already working on ECS. Other engines have successfully made hard breaks and as a result have iterated tremendously fast by not looking backwards. All I can hope for is that I'm wrong before Unity runs out of money/users.

 

I can't help but agree with this notion -- After the positive feedback drop 6 got, (then the "secret" drop 7), this sure did take a vastly different direction.


-----

Clearly, neither is yours.

Almost everyone in this thread disagrees with your (being Unity's) definition of the visual scripting UX direction.


If you listened to feedback AT ALL, then you'll have seen how (when referring to drop 6) so many people kept pointing out how "easy it is to understand!" -- which is EXACTLY WHAT YOU WANT when you're dealing with ARTISTS / DESIGNERS. And this further supports @Ferazel's point on the UX being used for teaching, and mandates that it is considered as part of this discussion.


-----

Also, @Ferazel -- please don't bother. The fact is, your point is very valid -- Just because it implies things "bigger than visual scripting" doesn't mean it doesn't also have relevance to this particular visual scripting drop -- because it does.

He's just brushing you off.


These guys have done this to me before (SceneVis), and (to be civil) I took the bait. -- Not planning to do that again.



-----


Back to a more civil discussion about the direction of "simplicity" in this tool:

Indeed, and I also like the way Marnel Estrada put it in his ECS polymorphism tutorial:

"Honestly, verbosity is not a steep price to pay. I get to have code that could be as fast as it can be without switching to another more complex code like C++, which is verbose by itself."​

I think Visual Scripts can easily be the bridge to this boilerplate "complexity" (which is really just "verbosity") that holds people (including me) back from going full-on ECS all the time.

A visual scripting solution would be ideal to handle the majority of the boilerplate verbosity for you (without watering-down the concepts!) by providing a separate graph view (as described in my previous post about Polymorphism!) while you toss your systems and components around like a tossed-salad. THIS is how games should be made. But sadly, it is not how they currently ARE being made.




Also:



@Joachim_Ante --


If Unity needs some help on a more robust ECS tooling design, you can totally contact me.

Data-oriented tool designs are what I do. This UX design is broken since drop 8, and doesn't look like it is going to be fixed. I can also address ALL your most fundamental ECS scripting concerns within one month or less, given proper insight to the social issues and internal social hurdles holding you guys back. I can make multiple badass tool designs for Visual Scripting (and others) if you'll let me, but this kind of thinking exemplified by the team above has to go.

Why? -- Because...

And you're letting it slip through your fingers.

 

Once again, I wholeheartedly agree with @awesomedata.

Ok this uncovers a larger and deeper issue. You're basically telling us that your Data Oriented Tech stack is not being designed to be used in a Data Oriented way. Worrying.

Also sorry but I don't understand why you're being so defensive. You and your team were the ones who opened these drops to receive feedback. So, do you guys honestly want feedback or not?

 

Seems like a majority of users is failing to understand that this Visual Scripting is being created for artist/non-programmers, we still is going to be able to "use DOTS in a data oriented way" by coding.

Also, it was mentioned already that while it is object-oriented when authoring, it is still going to be converted to DOTS optimized code, so just the authoring part is object-oriented (again, as it is aimed at non-programmers).

I was really happy with drop 6, it was the first time that I liked a visual scripting tool, but I understand why it took a different path in drop 8, as I am not their target audience for that tool.

 

Not true -- the majority of the users who are complaining (like me) are artists / designers / non-programmers.

Which is why this is an issue.

The problem with that is that the "authoring in oop" is just as convoluted (if not moreso) in the longterm!
(Thus the spaghetti-code dilemma!)

Rather than dealing with hard-to-understand "spaghetti-code" (with the anxiety of having no idea what each "magic" node is really doing to their data under-the-hood), Artists/Designers/Non-programmers will look back to Unity for a silver bullet or another "magic" node to do "this or that" for them. Artists/Designers/Non-programmers will not be any better-off than if this tool had never been made to begin with! -- They still will not want to program. And understandably so -- programming is needlessly complicated.
ECS is very simple to understand (in contrast!) -- which is why so many artists/designers want it.
We mainly just want an easier way to deal with (and visualize!) the relationship of our components/systems!
We need to understand things AT A GLANCE.
It's just how our brains work.

Outside of that -- Artists/Designers/Non-programmers don't give a damn about "optimized" code.

We want something that is easy-to-understand. (Which is why people like @Ferazel (and others) keep hinting at drop 6 being great for learning this new way to code!)
If we can get extra performance out of the process too, why not? -- Just as long as it is easy to understand.

Strangely enough, ECS is more-accessible to non-programmers (and apparently programmers too!) than some convoluted garbage like C# or C++.
See my post above about inheritance -- C# does it backwards. ECS doesn't even need a concept of "parenting" as long as it has a good tool to organize your components and systems in a way that logically affords a "parent" style relationship! With a good tool to put those easy-to-understand concepts together in a visual, user-friendly, way (without sacrificing any of the performance gain with the overhead of an OOP layer, learning curve, and further complexities [read: spaghetti-code] further down the line when you start writing your own "magic" nodes) -- who wouldn't want a tool like that?

If I can design a tool like this -- why can't Unity?

If you're still uncertain (or unconvinced) about what the deal is, I went into great detail about each and every thing in my above responses. Seriously -- Read some of my posts above. I know they're long, but if this post didn't do it, hopefully those will explain why so many artists/designers are bothered by this change.


To put it simply:

Artists don't hate programming -- We just hate the programming experience.
It's convoluted nature drives us nuts.

 

No. It is an issue, because it is not ideal. No matter who says it. I'm a programmer for example.

I can say the same about art-related workflows. And I'm usually saying it, but no one cares.

But, let's stay with the real issue, the problems (and the good things) about the VS they'are creating.
I understand why they're trying to go back to the GO-based creation and all, the non-VS DOTS is going in the same direction. And honestly, I don't like that either, but I understand that it is necessary. Otherwise it would be a long time and too expensive to develop a second tool-set for the same thing: setting up scenes but this time with entities.

What I really don't like is the switch to the spaghetti-style and the dropping of the code generation. I have my concerns that both have very dire implications. Although as a programmer it's not a necessity for me, it was just interesting. I can go back to my code.

 

@awesomedata while I do agree with many things you said about the potentials of that Visual Scripting tool (and your other thread about readability, which It's really awesome!), we need to remember that Unreal Blueprints are widely accepted by the artist community, and are real proof that this drop 8 may be in the right direction now.

Currently, Unity doesn't offer a proper way for artists and game designers to prototype their ideas without the help of a programmer or the need of buying multiple assets for that, so I can see why Unity would prefer to take something "already proven to work" instead of taking chances into something that they don't have a clue if their target audience will take full advantage of (however, I may be wrong about my assumptions of Unreal Blueprints being an influence over their design decisions in drop 8, but by just looking into it is felt very obvious).

I just hope to Unity also fix Unreal Blueprints major flaws along the process, like the code-gen part (which seems like will be brought back in the future) and making it easier to communicate back-and-forth between normal code and visual scripting code.

Having said that, I would love to have back the drop 6 stuff at least as an option for anyone wanting to do some data-oriented stuff with visual scripting, but I can accept if that doesn't happen due to the increased workload (but that won't prevent asset authors to create that for us, so who knows...).

 

A lot of feedback here but it also seems some things aren't fully understood.

This isn't entirely true with the way this is split from the code ECS workflow.

- With the ECS code workflow, you also author with Game objects and either use the convert to entity script or sub-scenes (DOTS Editor package) to convert game objects to entities, the code is still all written ECS. It's just the editor interaction that is still the same that we are used to. This makes sense to me and I have no problems with it.

- With the VS Graph Drop 8 workflow you still author with game objects and convert to entities script or with sub-scenes, same as the code workflow but now the "code" part which is the visual scripting nodes are also object-oriented. So this leaves whoever using the VS tool and the programmers working with ECS code using totally different mindsets.

In the end, the code it generates will be ECS, but if I don't learn/know ECS code (which is why I would use VS) then the generated code wouldn't mean anything as I still wouldn't be able to edit it. If we all knew ECS code then we would skip VS entirely. Even if we got a programmer to edit it after the fact, would we be able to get all those changes parsed back into the VS graph?

So yea the "code"/node part being similar to object-oriented programming currently changes everything.

If this is the case I would be stuck in limbo. I took the time to understand how ECS works and all that but I just don't actually write code/learned the syntax and further complex boilerplate code. So with that knowledge and how Drop 8 is this leaves me and people who did/know the same with a tool that feels backward/counterintuitive.

Code Generation didn't technically get dropped, just delayed to a later point. I don't have a problem with this as I wouldn't have any use for the code while using VS as the graph is what I'd want to work with. Code gen can come after it's solid.

Yes, but the difference is UE4 Blueprints isn't using ECS nor is it data-oriented on the back or front end.

--------

@theor-unity @ans_unity This might sound off but it came to my mind so I wanted to see if it was the case.

Is VS Graph being made to be a bridge rather than a fully fledge Visual Scripting tool? You would just do simple things with it (Open door, enable trigger, etc) and connect nodes programmers made from the game's main codebase. Which is when you'd get to do some heavier work.

Is this the intent of the tool and we are looking at it as a tool that could fully create a game in the future? Is this why the target is Artists and Designers as they wouldn't be doing anything too deep with it as programmers would be the ones writing the main logic and codebase?

These are actual questions I'm asking since if this is the case then that would totally change the perspective of the tool. We would have been complaining about something that wasn't intended in the first place.

 

Will the asset store have a section for vs nodes that people can use?

 

Moderator notice:

1. Please don't belabour your points. If you've made your point, don't keep making it. It's a shared space for many people, and they are allowed different views.

2. Don't make useless comments like "3 years, soon" because that will lead to thread bans / deleted posts. Be constructive and smart.

Posting here is a privilege to be able to help shape Unity's future. It is not for disrespecting others, thanks.

 

The question this brings to mind is will this "framework to quickly author nodes" be setup to program in an ECS-oriented way, or in a blueprint-spaghetti-code-OOP-oriented way? -- Because the current drop (and commentary) implies the latter. If this is the latter direction, does noone at Unity (besides maybe @ans-unity) see that by going OOP in visual scripting, to artists, "thinking in the ECS-oriented way" will suddenly become a "bad" or "impossible" practice in Visual Scripting and, at least to artists, ECS will eventually become a relic in favor of the "new and improved!" OOP?

I'm sorry, but if this is the way we're going, this is enough to literally make me vomit.

This is exactly the problem -- Unity used to be all about "taking chances" with its tools/ideas.
ECS is a great example of this risk-taking! -- That is what makes good companies great!
Fail once and a while, but learn and improve! -- Not hold fast to "safe" ideals.
What I'm seeing is a lot of complacency here -- "Yeah, we'll deliver a great tool!" -- but for WHO?

Artists, Designers, and Programmers have all voiced concerns about the OOP nature of this tool -- Yet, we're all good with it suddenly? We're not upset that its fundamentally OOP-nature is against Unity's own standards!
In reality, the whole premise of a Blueprints-inspired tool is based around OOP (not ECS), yet Unity has said themselves (and proven!) with MegaCity that OOP is not performant!

"Performance by Default" was it? -- Not this time.

You get a subpar tool for a subpar coding experience.
Why? Because you're an artist. And artists are too stupid to learning new ways to program.
Go buy your tools -- and give Unity 30% while you're at it.

This is the boat many of us are in right now.

I don't want to purchase nodes on the Asset Store every single time I need custom behavior in my scripts. I'll deal with a damn text editor before I go that route.
Beyond that, I want to throw around functional systems and components, not just singular nodes having specific bits of repeated code to change back-and-forth between vectors and ints and strings as I helplessly try to keep tabs on what my game is actually doing underneath the hood.

This is what worries me deeply about this current drop/direction, and why @Ferazel pointed out the fact that Unity is blowing its chance to teach new designers "the ECS way" instead of the old OOP way. Without visual scripting to ease them into the ECS mindset (which is very different than the programming mindset), it is possible no user will feel compelled enough to bother with ECS if Unity themselves won't even bother with it.

The worst part is -- ECS can easily work with a gameobject-oriented approach!

See the early Project Tiny as an example of how this was done right! The authoring of mini-systems with component tags can be done with no problem using an ECS-oriented approach alongside a visual layout tool to author the logic for how the data is changed/moved around. Why can't that be workable in Visual Scripting too?


Please, @theor-unity, tell me you guys are doing something substantial to seriously bring back the ECS mindset into the programming of systems/components, and providing a quick and easy way to design and lay them out. Blueprints, overall, are NOT the way to go for this. You would almost need an entirely separate node network -- or at least a node conversion system. Some form of a hybrid system may be possible to bring the best of both worlds -- but this is very sketchy. That said -- I think anything that brings back ECS component/systems design/layout in a visual way is better than what we have in drop 8...

That being said...

I don't guess we have much of a choice. I am really hoping you wont stick hard and fast to the "it's been proven (for OOP) so it's automatically bettar (for ECS)!" approach you seem to be sticking to. This is not logically sound. You seem like a smart guy, so please use that sense to understand when you're better-off just listening for once -- Yeah?

 

Did you saw that reply?

 

@awesomedata it is time to let others put their points across - you seem to be dominating the thread. This is not a bad thing but I think everyone got the memo so far

 

The others who are interested in this VS tool had already wrote their points. And vast majority of repliers dislikes the OOP change(Does this means anything? Will it be taken into the account?). He is just last one standing who is trying to communicate and justify it. Apparently he believes he can change unities decisions... From my experience it is almost not possible..

Nevertheless thank you all for shaping the VS future.

 

I can not find something that will allow me to create reusable functions (private preferably) that will be reused only in that graph.
1. Are local reusable functions(a group of nodes with inputs and outputs what are saved inside graph asset and are reusable and has its own sub workspace) planed?
2. Will multiple graph layers be supported? For example I have some logic in on start event and I want to edit it in separate workspace because it can be some havy logic, I would like to concentrate on this and only this logic at time. It will be easy to just select OnStartLayer or OnUpdateLayer or SoeCustomEventLayer from list and work in that scope without distraction. On the other side if someone wants to mix and match events in one graph he can do it to. But for me encapsulation is a key and one of the most important programming concept.

Both things are used in unreal Blueprints. You can create graph functions and graph layers in one asset. And you can easily switch between them from a list of created functions and graphs. For me it its an important and pretty strightforward things. Will this be supported?

Overwise we will end up with messy huge spagetty graphs.

3. Are multiple reusable component-like graph asset executers on one gameobject will be properly supported?

 

I actually came in with here thinking, "there is no way this drop warrants this level of response." But after using the Drop8, i kinda get the complaints

I liked the idea of using VS for creating systems. The old drops had bad UI/UX issues that made using it a pain, but i figured that'd be ironed out when things got closer to alpha/beta and ECS was refined. Didn't expect you guys to just ditch the systems workflow entirely! I personally don't feel like the ECS system was the sticking point for the old drops. It was more that the nodes and their usability was ROUGH. It felt like you guys were trying to write word for word, text based code, but with nodes. It sounds like you guys saw that would be an issue and switched that mindset for a more designer/artist friend node approach, which is great! But maybe taking too far with removing the ECS based workflow entirely?

Will the systems workflow be coming back to VS in anyway? Being able to work with whole sets of entities rather than working on a per gameobject bases was clean, imo. Maybe you guys can change up the terminology so that it lines up with the authoring side of things? Like GameObject Groups and you build those groups from authored/runtime components?

That said, i'm not as doom and gloom as the rest of the thread because i do see the merit in working in the none ECS way, especially for quick things, and i think most people will be just fine with it. But being able to create systems and work with entitiy groups was a pretty powerful and unique feature for this VS, i thought.

Though, even with the break from an ECS workflow and switching to an artist friendly mindset, I feel like you guys could at least line up the naming with Mathematics. Also, when reusing nodes, like a gameobject reference node, it gets split into multiple nodes, instead of just creating two edges - can that not be the default? I feel like i'd rather choose how i organize my spaghetti than the graph choosing for me.

 

Oof. I must agree with those not liking this very much. It...doesn't really seem a good idea to go the blueprints route for ECS, it just adds confusion and removes clarity, when structuring it ECS in the first place would be both easier for nonprogrammers - and more intuitive.

I understand that VS is not originally intended as a learning tool for ECS/DOTS but... I would call that the fundamental design mistake with this direction. I'd say it should be a learning first, because if it is that, then *it is usable by less programming inclined people* by design. It would force you to stick to that goal, and right now, I think you're diverging.

Right now, it's really just a pile of spaghetti, and doesn't really offer all that much. I've shown the nice four-direction graph from page two to two artist friends, and both called it a complete mess right away. Yeah, if one looks into it and follows each line carefully, it makes sense, but at that point, you've really devalued the point of a VS tool...

I'm sorry, I can't really be more positive on this drop. It really feels like a huge missed opportunity.

 

I was an early adopter of uframe ecs and was teaching it to my students with a lot of help from nick back in the day. Creating systems, components, events for coupling the systems was so easy to understand for everyone after a very short time. The thing everyone, me included, struggled with the most is to forget the old way of doing things. I strongly agree on the points made here based on my empirical insights.

 

tools that promote systems level approach to designing a game are the only kind of visual scripting that actually needs to be made. If this tool is designed to make game programming accessible to non programmers, then it has to be designed to satisfy those users once they've been onboarded. If the tool really is successful at turning non coders into functionality creators, then they too will eventually understand the benefits of the systems level approach and will only be disappointed by the abstraction limitations imposed by object level interfaces. An object level interface is well suited only as way to satisfice - to get coding "out of the way", allowing non coders to accomplish some appropriate minimum of success to keep moving forward. You're not going to achieve die hard fans that way, just a lot of lukewarm acceptance. Without the die-hards, making VS successful will always be an uphill battle.

The challenge of how to make a systems level approach accessible is a better problem to be solving than how to make an object level approach as performant and powerful as a systems level approach.

 

Imagine when people start asking unity for OOP functionality eg. Polymorphism in VS.

 

I think the OOP horse had been ridden down a dark road... Here is a good read... "Goodbye, Object Oriented Programming, I Was Told That There Would Be Benefits" It talks about the fall of the OOP promises of Inheritance, Encapsulation, and Polymorphism.

https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53

That is why we are so excited about ECS and DOTS and hopefully Visual DOTS. It is a bold and aggressive step forward from Unity!

 

I am really struggling here..
How do I get data from the component inspector in to the visual script ?
it would be highly appreciated if one of you can explain it.
Maybe just to screenshots of unity component inspector and one of the visual script.
I really hope someone can help me,I have used many hours trying to figure it out,without any luck. Thanks in advance

 

Could you post a picture of your Visual nodes and their connections? What do you mean you are trying to get data from the component inspector into the visual script? What are you trying to do exactly?

 

I didn't work on any specific action just trying.
It could be changing a Boolean in a component..

this is from the release note but I can't find them

• GameObject / Component Node: Get Component Data
• GameObject / Component Node: Set Component Data

 

Thank you for explanation.

 

OOP Paradigms in Systems

This is not quite the issue...

The issue is with using OOP paradigms inside the systems we're programming.
OOP paradigms prevent systems from being generally useful across the board.
Beyond this, it promotes creating spaghetti-nightmare monsters when mixing systems with other systems *inside a single graph.

i.e. Vector to int to Vector to int conversions anyone??
Artists don't enjoy (or appreciate) that.



Gameobject Representations

As an aside...

The "GameObject" representation I actually like a lot -- I just think it just needs to be a little less of a "permanent" structure. In other words, you should be able to add/remove components instantly, at will, and have a new type of gameobject be generated from this. Here's hoping this is possible under the hood.

The physical abstraction of a component in the gameobject representation is still a great thing -- To be able to make an inspector that populates systems and components (at runtime) at the click of a checkbox (in a general inspector) is definitely a great asset. Think the Physics Shape component -- This is great.



Looping Entities

Another consideration is the fact that querying all entities at once is a more general (and a much better) workflow for individual systems than popping in a random ForEach at various points in a script.

Generally, when you involve a "ForEach" in a loop over some things, you are better-off just writing out a new system in ECS. It is likely whatever you're doing in that loop should apply only to certain things anyway, and a system (with the right data components) would be ideal for that.

I'll touch on this when I have time, but I've got some ideas that might help you guys out with this.

I'm curious what direction this would take? -- Are you looking at making a bit more of an integrated approach to doing a flowmap of systems/components sort of like I suggested in a previous post, or is there something else you're looking at?

 

...but everyone could be on this forum and could actively say anything about that - so I think UnityTech should listen to the people, who trouble about this things. I mean isn't that the reason, why everyone is here?

 

I don't see it necessarily promoting more spagetti, it just needs smart nodes and also it's up to user to build smarter graphs, you can make spagetti out of everything so looking at unnecessarily tangled graph that was presented and taking it as a basis is misguided
for me it's more about power the nodes provide, I'm not too happy with being only able to affect individual game objects currently, but once game object input on nodes also takes entity queries it will be fine, so let's see what future will bring
It's just a graph, I don't see why one day it wouldn't be able to do both, isn't the current system sort of like heavily narrowed entity query just to a specific game object?

you can't expect everyone writing the feedback in a single public thread, where it gets easily lost or doesn't get proper attention because of some more active individuals
I'd expect that customers that pay considerably more than average unity user deserve more support and their voice would be heard during roadmap planning, the least they can get is private channels of communication

 

My personal suspicion is that this use case is over represented because it is the most likely to be reported when working with an incomplete toolset. If a user knows that there is a "ceiling" to what they can implement, they will naturally confine their ideas to what they consider the "floor", and then they will naturally respond that they can "not even" implement what they consider as a base level of functionality.

In other words, I suspect that some artists/designers have trigger/response level needs from a VS system, but the use case will be over reported due to a lack of trust in the current VS tool.

A final way to express this thought: VS is currently a toy system, so you may be over representing toy use cases.

 

Actually, considering this further, I have a simpler conclusion. This use case, which they consider principal, represents the concerns of artists/designers in large or very large teams. We here on the forums are typically both implementers and product owners, so we have the authority to design games comprehensively, from a foundation level. Artists/designers in large teams typically work in smaller scope to divide up the effort. An artist/designer is likely working on the gameplay of a single level at a time and certainly does not have the authority to change the way things work for every other artist/designer on the team. They'd have to submit an RFC for everything they wanted to do.

As small devolopment team game owners, unfortunately, we will have to wait our turn. The tool we want would help us become competitive with larger game companies through the ability to wholistically manage our games, reducing our overall effort and go to market time with our ideas. However, the larger teams represent the revenue that keeps Unity moving forward, so the tools they develop have to make sense for a team with distributed effort.

I'm sad about this conclusion, but I think I sympathize.

As a final thought, I would like to see this conversation become less about artist/designers vs programmers and more about "product owner-implementers" vs "large team contributors" (or perhaps, simply "broad scope vs narrow scope contributors"). the former dichotomy is a bit misdirected, and likely caused a lot of frustration.

 

This tool is really getting amazing, I can't wait to use it in production.

My initial impressions DROP8.

Using this drop 8 I really enjoyed working with him, and working with objects individually, and in my tests, I really saw that he has great potential. I did something very basic on it and in a few minutes I had already got the hang of how Dots visual script worked. (and look, I never programmed in DOTS)

workflow

I made a rotating cube, and the famous hello world ... it's really easy to find the nodes when you type them in the search. But something nice that could have in the search is an icon showing something related to that node, for example: if it is something related to math, it has a math symbol, and so on. It would make it easier when I was researching.



Nodes

Horizontal nodes are really interesting, I didn't have the opportunity to work vertically, but horizontally I felt more free for some reason, and even though I can't look at my code as a whole, I can still understand how it works. So it is a very positive thing to have this color in the nodes, especially in the main nodes of START and UPDATE.

Negative points.

Is there an area on the screen that is almost unusable, except when we want to change the keydown? It is hardly used at all, so why is it there? Maybe it will have another use in the future or it already has now and I didn't see it, but for now, I didn't understand.
I saw a lot of people here talking about the code spaghetti, but I don't believe it can happen here, there are several ways of not allowing that to happen.

It really is incredible, and I am looking forward to the next DROP.
Sorry for my bad English

 

Hey, I only started looking into this project now and started going through the code, it's looking very interesting!

To give a more positive spin to all earlier comments, I think it's great the team is not afraid to make big changes along the way to get a product out there.

I like all the new nodes that came with the new drop and want to experiment with this latest version. However I'm missing the code compilation compared to the previous version. It's interesting to see the graph getting compiled into an ECS system, it gives a better understanding of performance implications and such.

Is it possible to easily enable the codegen solely for inspection? If not, no big deal.

Edit: Looking at the differences in code between the two versions, this seems sadly off the table.

 

This visual script feature in DOTS will arrive in 2020.1 as in preview?

 

Hmm... I have read a lot of comments here. I myself have been spending the last couple weeks learning DOTS and Unity Physics. I guess you might call me a programmer, but I do find the DOTS/Physics system hard to work with. Although I certainly see its power which is why I've continued working with it.

So I was interested in the idea that VS could do a lot of the job for me and save me from figuring out code like this:

Code (CSharp):

1.     void Start()
2.     {
3.         manager = World.DefaultGameObjectInjectionWorld.EntityManager;
4.         blobAssetStore = new BlobAssetStore();
5.         GameObjectConversionSettings settings = GameObjectConversionSettings.FromWorld(World.DefaultGameObjectInjectionWorld, blobAssetStore);
6.         bulletEntityPrefab = GameObjectConversionUtility.ConvertGameObjectHierarchy(bulletPrefab, settings);
7.     }

But after reading the comments I sort of feel that VS would not embace the DOTS paradigm, and if I try to learn it, it will just be learning a new system on top of DOTS that will have its own problems and complexity.
So I guess I'll pass.
But maybe I'm not the target audience here.

Also I do feel that if you are trying to make it easier for novices by making it look like OOP and then taking care of sort of a transition to ECS under the hood, thats a problematic approach. Hard to do that without running into some of the headaches that made Unity decide to switch to ECS in the first place.

I think better to accept that the user of ECS will have to learn these new concepts and deal with increased complexity.

 

Honestly, I couldn't care about which approach VS takes. Games aren't too complicated (it's the organisation and mental model that is), but I know I need these pieces to make one:

- Polymorphism (ability to be more than one thing (currently via Inheritance/Interfaces/GetComponent)
- FSM (split code into chunks that can switch on/off and clean up after themselves)
- Events (respond to things that happen locally or globally)

Without these, any tool will be a pain in the ass, whether it's ECS or not. I hope the finished VS tool is taking these concepts into account.

For example, Bolt 2 looks impressive, but has no support for interfaces/inheritance, so making an 'actual game' in a non-starter.

The reason I found the previous drops hard to use is because I couldn't see how to do any of what I listed. So, I end up with a rotating cube, then quit.

The current drop is the same, except it's dumped queries.

I'd be happy with Bolt 2 + Polymorphism + Events + FSM.

P.S. As a bonus, it would be good to be able to create classes/components in editor, just like we could do with queries.

 

Something like the FSM would be interesting, with the FSM you have control and logic in front of you, and it works for both programmers and non-programmers.

So what I think is that everyone needs something that is simple and practical, something that at a low level (simple nodes) everyone can use at some point, and that using these basic functions, we can do more complex things, we cannot ask for unity create a complex node that will do just one specific thing, but simple nodes that can do many things in various ways. That's the idea of all VS. use simple nodes to form more complex things.

sorry about my English

 

Polymorphism can be replicated in ECS. It's just a different model but more flexible. You should be favoring composition over inheritance anyway which ECS encourages.

 

You can do composition in plain old Unity. I don't see what it has to do with Unity's ECS system.

 

I'm replying to your "I know I need these pieces to make one" in which you enumerated Polymorphism which I disagree. I assume you wanted a more OOP approach to VS which is just moving away from how ECS works.

 

I just got these errors when I switched to the Android platform.


Library\PackageCache\com.unity.entities@0.8.0-preview.8\Unity.Scenes.Hybrid\LiveLink\LiveLinkPlayerSystemGroup.cs(32,59): error CS0117: 'SceneSystem' does not contain a definition for 'GetBootStrapPath'


Library\PackageCache\com.unity.entities@0.8.0-preview.8\Unity.Scenes.Hybrid\LiveLink\LiveLinkPlayerSystemGroup.cs(53,48): error CS0103: The name 'bootstrapFilePath' does not exist in the current context

 

Gotta say -- This is my case in point. And I'm an art guy.




But rather than continuing to point out the problems with the general OOP approach, maybe I will take a moment to point out why ECS is a better way of programming in general -- including how it is better at "Object Oriented Programming (OOP)" than any other language in existence.







ECS: The better OOP.

ECS is very simple -- it has two concepts, components and systems. They act on (or are attached to) 'entities'.


Easy, right?

Under this veil of simplicity hides a real beast of a programming language.
A beast that, if unleashed, can topple the giants of modern-day Object-Oriented-Programming (OOP).
Am I exaggerating? -- You be the judge. -- But hear me out.

To new and old programmers alike, ECS does appear to have some "limitations" at first glance.
One could say the same thing about the seemingly-fragile human body.
But as (the tiny-but-badass) Bruce Lee once said -- "Make no limit [your] limit. Make no way [your] way."
This is the rule of nature.
Like the human body, by using it smartly, ECS can be both powerful and flexible -- There really is "no limit".
There is a lot of subtle badassery awaiting you underneath its seeming "limitations" (just by way of the sheer number of techniques you can employ to your component and system organization. You can not only make these seeming "limitations" completely disappear, but these organization techniques can also even improve so-called "OOP practices" in a way that no one ever saw coming. We used to think the biggest guys were the strongest -- until Bruce Lee showed up. Now meet my pal, ECS. He's the spiritual equivalent of Bruce Lee for OOP programming.



ECS's OOP -- "The four pillars"

Let's see how ECS is actually better at "The four pillars of OOP" than any other language (claiming to be 'OOP'):

• Encapsulation
  
  ...doesn't need complex rules (nor endless levels of 'abstraction') to exist in ECS.
  
  In fact, with the help of a Visual Graph showing the relationship of component queries to a particular system, any encapsulation can (and should!) be kept contained within the script graph itself -- Each script graph can (and should!) be standalone and complete, with all required component data (and changes to the components' data) happening within the scope of a single system.
  Drop 8 went the opposite route (and went wrong!) by not doing this. Drop 8 is full of simultaneously executing bits of logic of systems referencing other systems referencing other systems while never referencing components or data explicitly (i.e. the wild west), while drop 6 scripts were nice, self-contained systems that only referenced the component data they explicitly needed.
  By removing the verticality (in other words, the idea of the self-contained "system") in drop 8 in favor of parallel, heavily-referential (and heavily-dependent!), execution of other systems within systems (in a single graph!), true OOP encapsulation was actually removed in favor of all the things that make traditional 'OOP' slow.
  
  OOP systems (and/or the data they rely on) should never have to be referenced!
  
  An encapsulated "object" should be a single, self-contained, unit (of functionality):
  See the first result in google -- https://www.google.com/search?q=OOP+encapsulation
  
  
  "Encapsulation is one of the fundamental concepts in object-oriented programming (OOP). It describes the idea of bundling data (and methods that work on that data) within one unit, e.g., a class in Java."​
  
  
  This is kinda exactly what ECS is for.
  
  Before drop 6 was "dropped" entirely, I actually described a state machine system like this in great detail, hoping Unity would take a hint that we needed state machines. To their credit, they totally did -- but to give us these state machines, they removed the ECS component query mechanism entirely, leading us all back to the (non-encapsulated!) spaghetti-code stone-age! Now we get state machines in drop 8, but to get them, we can no longer use ECS data-oriented (non-spaghetti-code) approaches or methodology in (Data-Oriented!?) Visual Scripting at all.
  
  Now, true OOP encapsulation in ECS is doomed for the ability to "maybe someday" query ECS components.
  
  This is a problem to me.
  
  "True OOP encapsulation" does not mean "the way OOP encapsulation is sometimes used" -- because that usage can be (and very well is!) entirely wrong (for all the reasons and justifications explained above and below).
  
  For example, a "state machine management" system should always be a singular, self-contained, SYSTEM (i.e. a separate, encapsulated, object of data and functionality) -- Which, by default, means it should NOT be a NODE -- or even a group of nodes -- because without this self-contained functionality, the state machine management system is not a separate, independent, (and therefore encapsulated!) object, consisting of its own data and functionality, to use to further define a program. In other words, this is not an object, and therefore, it is not considered true OOP).
  Furthermore, individual "states" should be separate systems too, each managed by their own internal states of component data queries (and component data transformation methods) -- which essentially define this particular thing as a system that has a state (rather than just as a group of systems/components that kinda sorta make a new system/component). A true state should manage its own state internally anyway, including whether it is an "active" state or which state it needs to eventually become next. The "state machine manager" system assigns a new component that marks the new state as "active" -- and away the "new" state goes to manage its state too.
  
  "But what if the current state doesn't yet know what "new" state it should become!" you ask -- and I say: That's when a new system is built to handle that particular case. In the case of controller input, you add a component called "InputTransitionActions" and viola -- your state adds this component (maybe alongside a group of other components to trigger other systems) and your "state machine management" system prioritizes this component as a way to get a new state (to set to active) for the entity, which would add a particular "ActionState" component and let the "state machine management" system set it to "Active" to trigger the action state. But if you're in a cutscene (with a "Cutscene" component), the state machine manager waits until the Cutscene component no longer exists before it sets InputTransitionActions to Active (by adding an active tag), letting you finally use input again.
  Believe it or not, as you can see above, this type of separate-but-"loosely-dependent"-system can not only easily be authored without referencing other systems or component data from other systems (meaning it is true OOP encapsulation), but it is easy (and natural) to follow as well -- even for someone who is new to your code! The simple and easy-to-understand rules of encapsulated components and systems tell you exactly where you need to look in the code for that next bit of component data or system logic! As long as you know what sorts of components are referenced in a system, it is easy to understand what they are for -- Meaning documentation will be easier (and more straightforward) too!
  
  
  
  
  
• Inheritance
  
  Shouldn't be backwards or hard-to-manage like it is in 'OOP' languages like C#. Backwards "inheritance" further muddies your ability to "encapsulate" your data/functionality by disallowing its right to flow naturally and effortlessly from a single, easy-to-manage, point of origin into one or more destinations.
  
  In ECS, inheritance is done by stacking components in a sequential way that flows naturally through separate (but logically consistent) systems, which allows for both the lineage (and specificity) of data inheritance in any system that requires it. A certain series (or mask sequence) of components can progress a system (or many systems simultaneously!) in a particular direction at any given moment. With the correct question (posed naturally with ECS, rather than if/then/else statements), you easily determine which animal is an elephant or a giraffe -- and even better! -- that data is only as specific as you need. You never need to ask for more (or less!) than you need in your system.
  
  So no more "if (animal == elephant) {probablyNotGiraffe();} else if (animal == giraffe && animal != robot) {notRobot();} else if (animal == elephant && animal != robot && animal != tall) {notGiraffe();}" etc. etc. -- You can speak in plain language with ECS systems -- i.e. "Do "GiraffeBehavior" animation in your system with "Animal -> Giraffe" entities. Do "ElephantBehavior" animation in that same system with entities having "Animal -> Elephant" components. No ifs/ands/buts or thens/elses either. You can always ensure the following:
  
  "An elephant is not a giraffe sometimes."
  
  
  OOP is currently the wild-west, and ECS is understandable (civilized) code. Yes, an Elephant is an Animal, but is the Animal you're asking for an Elephant? -- ECS keeps that answer easy with queries consisting of a few sequential logical components (which is the ECS version of inheritance.) Judging by code like the above if/then/else/ifelses, other OOP languages still (constantly!) struggle with this. ECS has no problem with it.
  The component data tagging lets systems further specify and/or define explicit behaviors for the "type" of animal or behavior association you're after through simple sequential component tagging (or "inheritence".)
  For example: "Animal -> Elephant -> Tallness" components == "Tall Elephant" and the "Animal" system that handles what both tall and short animals can do must be able to easily-reference whether this is an Elephant or a Giraffe, as well as what other properties (read as: components) they have attached to them.
  ECS makes it very clear you can't assume that if "Animal -> Tall" components exist that a system is referring to a Giraffe or a Dinosaur (or in our case, a very tall Elephant).
  Thanks to ECS's sequential logical components, inheritance is easy. In fact, the very sequence of logic you use dictates what animal you apply your changes to. Yes, ECS requires explicit components, but this can protect you from sweeping (and unintentional) changes. On top of this, this sequence of logic can be added/removed by systems (on the fly!) to define exactly what an entity is capable of at any given moment! Yes, it is as powerful as it sounds -- and if sequences of logic are added/removed creatively, you will rarely need more than three or four components for any system. See the "state machine management" example way above.
  
  The 'sequential component inheritance' concept is extremely powerful, but it doesn't properly exist in Unity's currently-implemented gameobject-based workflow.
  Right now, you get "gameobjects ~= entities", which means entities' components are treated as "static" (and mostly immutable!) in the workflow, causing "on-the-fly" component queries like the above to be obtuse and difficult to create, especially when these component masks/queries need to be simple and fast to create -- on-the-fly -- while authoring our systems in our Visual Graphs...
  
  The DOTS Visual Scripting design is destined to be premature without this concept. Without proper inheritance, you're stuck making thousands upon thousands of explicit (and avoidable!) references to outside systems and data (like this):
  
  
  
  Which leads me to my next point:
  
  
  
  
  
  
• Abstraction
  
  WILL NOT SAVE YOU (from 'complexity')
  
  Because of encapsulation-heavy approaches in most "OOP" languages, references to external systems / objects will (eventually) crush you with the weight of their "complexity". See above graph.
  That graph is not very "complex" -- yet it's still hard to read.
  Its apparent "complexity" comes from endless references to external systems, external data and external functionality -- usually (falsely) justified that it was written this way "for abstraction purposes"
  Oh yes -- it really does look very abstract -- But, somehow, the graph still doesn't look all that "encapsulated" to me. "This is impossible," you say. "Look at all that encapsulation!"
  And this is where we run into a fundamental problem with our current OOP approaches.
  Abstraction was meant to make things easier to understand, not harder.
  Using abstraction as a "feel good" way to sidestep carefully planned encapsulation is kind of what we do these days -- and languages like C# and Blueprints are designed to help us do that sidestepping more easily.
  
  This is where it all goes wrong.
  
  "Abstraction" should never be used as (or equated to) encapsulation in OOP.
  
  EVER.
  
  This applies to any "OOP" language -- which includes ECS.
  
  
  
  From now on -- I will kindly refer to the above practice as an abstraction-encapsulation "circle-jerk".
  
  Why?
  
  Because what we currently do in OOP languages isn't actually "abstraction" anyway.
  
  Abstraction was originally intended to reduce the amount of irrelevant data that a human had to interpret so that the human could have a better overview of his code's core behavior, leading him to better-understand what his code was doing from moment to moment, letting him/her modify the relevant parts more easily. What Unity is doing right now in Visual Scripting (in terms of abstraction) is the exact opposite.
  
  By simply hiding the spaghetti-monster deeper and deeper, under layers and layers of code, we are shooting ourselves in the foot in every step forward.
  We are no longer "abstracting" or "encapsulating" our code -- we are obfuscating it.
  It is no less complex or difficult to understand without the obfuscation (in fact, it's arguably harder to understand.)
  As a result of said obfuscation (i.e. via nodes), instead of making it easier to get a better view of what our code is doing, it actually gets harder and harder to modify it intelligently as we move forward (in our abstraction-encapsulation "circle-jerk") because the crux of our functionality is buried beneath layers of friendly-looking (immutable) 'object' references. Not only does this mean our code is harder to understand; but it also means our code is inflexible too.
  
  The very moment you try to change how that object behaves (or where particular properties are derived from), you end up going down a rabbit-hole of nightmares you can never escape from. The object is immutable, remember? -- So your only choice is to dig into all the other various properties/classes littered throughout your big (potentially enormous!) project to change one thing about your object (or where it gets its properties and/or behavior from).
  Abstraction (for the sake of encapsulation) just makes this object-decoding nightmare exponentially worse.
  
  Visual Scripting -- to add insult to injury -- makes encapsulation a NECESSITY.
  So, rather than carefully-designed encapsulation focused on the pillars of OOP, we mindlessly "abstract" our code away by what some of us call "encapsulating" it.
  This is of course circular logic.
  This constant abstraction-encapsulation "circle jerk" causes us to forget that the abstraction was meant to make our code easy-to-understand (and easier to modify), but not all "abstraction" is good "abstraction". The more methods and objects we "abstract" behind other objects and methods -- the less "easy-to-modify" our code naturally becomes. Which means that, even on a moderately sized project, at some point, you will eventually want to tear your eyeballs out rather than willingly traverse a nightmare-web of dependencies you've (inadvertently) created (aka: the spaghetti-nightmare monster).
  
  So what do we do? -- This is just how OOP code works, right?
  
  After all that "circle-jerking" to try to "simplify" our code (to no avail), we never stop to wonder if our problem isn't actually with code at all. We never stop to realize that acting with instinct or learned behaviors (rather than with our brain) is causing us to miss something important. Something is causing these small problems and headaches. We just don't see that we've ultimately forgot that code is still a language. And in the end, the whole point of a language is communication with others.
  
  But, unlike body language, some languages just aren't designed to communicate simply.
  
  ECS however, is.
  
  I wrote an article (on Data-Oriented Visual Scripting) entitled "The Structure of a Language" which, in the second part, I explain how "methods/functions" (in the sense of programming for artists) are actually bad for the intended purposes abstraction in code. Abstraction is for providing a quick understanding of our code, leading to an easier understanding of what's happening moment-to-moment -- without requiring a dictionary to look up each variable or relearn every function/method you wrote when you come back to your code after a month! What if the director of every movie you watched made you pull out a slang dictionary to understand every other word those actors spoke for each and every scene? -- I would bet you'd quickly give up watching movies. Artists are about communication with their designs. Why can't programmers be the same?
  The article is worth a read, but if you don't like reading (you really should!), just know that what we are working with currently in OOP is a poorly-designed system for a natural flow to what I call "communicative abstraction".
  
  Communicative Abstraction is just a fancy way of referring to "abstraction (without encapsulation) that communicates clearly." When using the common OOP "abstraction" pattern of simply plopping a complex piece of reusable code into a function/method and forgetting about it, you are effectively using symbolic "slang" when you call a function/method from someplace else than where it originated. If you don't know what a particular slang word means (or maybe you've forgotten?), you have to look it up. But when it's legitimately code (as in the undecipherable kind) -- and you've got to figure out the meaning of long-forgotten words/phrases yourself each and every time you come back to it -- you might as well get out the reading glasses, a blanket, then a warm cup of tea (or cocoa), and settle-in for the night... It's gonna be a long one...
  
  Or... you could just use ECS. Then you could do "abstraction" in a different way.
  
  See, unlike in C# (or most other OOP languages) -- the beautiful thing about how ECS does "abstraction" is that it is a top-down approach using mutable components (rather than bottom-up, with immutable objects and interfaces). Because you can start at (and even change!) the top-level of your concept (at any moment!), you can also easily abstract your data down the chain in a linear, easily-understandable, way and change not only your behavior, but your entire concept. For example: "Animal -> Elephant -> Tall == TallElephant" or "Robot -> Animal -> Giraffe -> Short == ShortRobotGiraffe" can automate entirely new abilities or behaviors or automatic component additions/removals (when combined with systems) simply by using the combination of components on an entity at any given moment, inherited from the top (high-level) logic, going down toward specific, low-level logic. Your systems just interpret that topdown data based on specific component queries, sometimes with a wildcard * masking approach, leading you to quickly change what the hell is happening in your code/systems almost anytime you want (while within a system). You only care about Animals and whether they're VeryTall, but not whether they're Robots, Elephants, or Giraffes? Create a mask of that data query and call for it in the system that needs it.
  "Communicative Abstraction" is done for you (automatically!) by simply arranging your data components (and designing your systems) with certain components while also giving them a purpose! You don't have to worry about syntax, functions, or methods -- You just create explicit component data designed to be used as a mask and your systems interpret that data (specifying its own masks), changing anything that matches its data criterion (and mask) -- all at once. You simply filter it, then create behavior for it -- as is standard in ECS. This is your entire VisualScript. You're good to go.
  
  
  Spoiler

  As an example:
  Slap a fancy name on the "object" if you want -- i.e. while the logic sees it as "Animal -> Giraffe -> Short", you can still nickname it "ShortGiraffe" if you like (and even use the GameObject workflow). You can also still reference the odd blackbox data (like input state from the hardware) i.e. to make the ShortGiraffe move, but if you can apply changes across the board to all the components you need (i.e. with a simple mask/query like. "InputSystem -> Player -> MoveAction" + " * -> Animal -> * -> * "), a short program describing how that behaves on your data (" * -> Animal -> * -> * -> LocalToWorld", grab the Z component from the LocalToWorld on the entity, *= the entity Zposition based on MoveSpeed / DeltaTime") -- then why the hell would anyone EVER want reference another gameobject directly again?? -- If each "reference" was a masked series of data components (or a nickname for an explicit series of masked components), this would be enough to apply communicative abstraction in a way that would keep your systems small, compact, and easy to understand from moment-to-moment. You want to know how your animal moves? -- Look at the folder for AnimalSystems -> AnimalBehaviors -> AnimalLocomotion. There all your animals' unique locomotion for tall/short elephants/giraffes (including the robot versions) would be stored.
  
  
  Spoiler

  And if you need a properly "abstracted" Finite State Machine (FSM) state system?
  Easy.
  Just pull in a nice " StateMachine -> *ActiveState -> *MovementState " series of components.
  The "StateMachine" component would indicate you're using state machine entity data to the state machine system. The state machine system would essentially look for whether you have an ActiveState component or not, and if so, it would do nothing (letting the ActiveState's system -- the MovementState system in this example -- take over.) That system's logic would continue to be called each cycle on the entity until the MovementState system itself removes the ActiveState component from some entity. On any entities without an ActiveState component, a NextState component is added by the StateMachine system. The NextState component is consumed by the next system to execute. This system is determined by the component mask "StateMachine -> NextState -> * ", indicating that any entities with the NextState component uses the very next component as the name of the state system -- i.e. StateMachine -> NextState -> *MovementSystem. In the MovementSystem, this NextState component is consumed/removed immediately, and an ActiveState component replaces it. Now, for behavior, let's assume the MovementState system has a clause that it checks for an "InputSystem -> MoveAction" component mask to exist in the entity (to see if the movement action is still being performed), and if that component is not there, the MovementState system removes its ActiveState component. It then adds an IdleState component (which will be picked up by the StateSystem, which adds the NextState component for the IdleState to check for to know if it is the first moment it is executing its IdleState or not so it can remove the NextState component). If the "InputSystem -> MoveAction" exists in the "MovementState" though, the MovementState adds an "ActiveState" component to itself again, since it doesn't exist.
  
  See?
  
  Doesn't this kind of abstraction (without the need for encapsulation) feel a lot better and much more suited to your specific tastes (and personal needs) than that gross and impersonal "circle-jerk" you had before?
  
  
  
  
  
• Polymorphism
  
  "What?? ECS can't do polymorphism!" You say. "It doesn't even have a 'poly' to 'morph' to!!"
  At first glance, it might appear to be the biggest "con" to ECS due to the fact that ECS clearly has no concept of "class" and makes you "spell out" your data and systems, with lots of components and systems (which gets tedious, time-consuming, and eventually impossible to manage, right?)
  
  Actually... Polymorphism is easier (and more flexible!) in ECS than any other language.
  
  An object is simply a specific "set" of data that can be referred to someplace else (or inherited from), but above all, this data is typically immutable. In ECS, a "set" of data doesn't have to be specific -- in fact, data "types" are actually just a specific series of components that can be added/removed at any moment by any system. A data "type" in ECS is a lot more transient. Rather than having a to define the data type into a static reference derived from many other static references to ints/floats/other-imported-data-types you throw around and convert all over the place, you can instead simply refer to an exact data type at any point in your code and in any system, attaching or removing any desired or undesired components. This typically forms a specific series of (generally-named) components (i.e. Animal -> Elephant -> Tall = TallElephant), allowing any specific entity in the system to be referenced or even become another kind of entity. As systems add or remove components, they are able to fundamentally change properties (components) and behaviors at will. This is a kind of flexibility with data types you cannot have in traditional OOP.
  
  The beauty of this is that if I wanted to change my Animal -> Elephant into an Animal -> Giraffe, I could (in theory) have a system drop the Elephant component tag, then add a Giraffe component, then my system that processes the behaviors of an "Animal -> Elephant" would no longer do that (since there is no more Animal -> Elephant) because the one entity now has become an "Animal -> Giraffe" and the system only processes the behaviors for the "Animal -> Giraffe" entity. That means "An elephant is not a giraffe sometimes." -- It is always either entirely an elephant, or entirely a giraffe. You can't guarantee that with standard OOP class structure, especially with backwards-facing inheritance.
  More importantly, to touch on the flexibility, if you want an angry giraffe, and you don't care how tall it is, you can make something like "Animal -> Giraffe -> Tall", add the "Angry" component to it (so now you have "Animal -> Giraffe -> Tall -> Angry") and the system that controls his behaviors will look for "Animal -> * -> * -> Angry -> * " so that anything it finds with an "Animal -> Angry" component (regardless of whatever other components it has on it) will behave like an angry animal when your animal behavior system finds it.
  
  This opens up a lot of creativity (and flexibility) when designing your games, giving the possibility to more easily create "emergent games" (and gameplay!), naturally making games -- and the creative process! -- much more fun!

"There is no way ECS can do all this!" -- yet it can.



With the right interface...


...and technique.


For such a little guy, ECS is a beast as it powers through the OOP machine!

But... for new users (and old users alike!) to realize the kind of ease and power a tool like this would bring, you have to "teach" them the strengths and characteristics of our underdog, ECS, in the tool's interface, which shows (intuitively) how users should handle themselves in this new ECS/DOTS world -- and in the future you've created for them.

If Unity doesn't take that risk -- who will??

So yes -- the purpose of this tool (and any groundbreaking tool) really IS to teach.
Or at least it should be.
Trying to create an interface before most users (including plenty of experienced programmers -- which probably include some of Unity Team too!) even really understand OOP (and now, ECS) is just setting up yourself for more work later on!

ECS is the obvious winner in being a clearer, easier-to-understand, and more-efficient OOP language -- and the target audience, artists and designers, like and embrace it! --Yet the particular Unity Team in charge of this tool (as far as I can tell) seem to believe a simple ECS query-like command will solve all of the issues Blueprints (and even entire languages like C#) have with their take on OOP. After this post, there should be no reason to continue to deny ECS's abilities in bringing a better Visual Scripting tool into the world than just a weaksauce Blueprints rehash -- with (possibly!) more performance. :/


@Joachim_Ante ...

I totally believe ECS is the future.

But this drop makes me wonder... Is Unity really aiming to make the Unity Editor future-proof?
With the direction it sounds like we're going with Visual Scripts all of a sudden, you guys might be succeeding...

 

@awesomedata Dude I'm sorry but I think you should move the long posts to your own thread. I think you're right but it's kinda drowning the rest of the conversation :/

 

No way! @awesomedata is the man to get our point across! I understand you have the rest of the community at heart with your request. But what you're suggesting is like saying: "Hey, guys, I got an idea. You know how our anti-tank artillery is really ugly? Well, let's move it near the shoreline where there definitely won't be many tanks so that we don't have to see it! Also, look out for boats."
I don't think that's how you win a war, my friend!

That being said... I have to agree that the size of your posts @awesomedata are truly colossal (and I only mean that in the best of ways, mind you). Luckily, I'm a man of compromise, and I believe you are to.

I know it isn't the best sure-fire battle tactic—but perhaps, @awesomedata, you could enclose large majorities of your posts in spoilers (like you have already partially done)? Doing that should keep complaints down to a minimum and still keep our artillery going strong! ... But... Just concealed in the bushes, instead.