Official DOTS forum changes

Uh, so where do you fit SystemBase, or ISystem and its jobs?
Or other combinations.
This is not just ECS, or jobs, or burst, They can live in them separately and in conjunction with each other.
Systems can run without jobs, or without ECS.

I think changing DOTS to ECS brings more confusion that proposal. It makes no sense to me.
I see more mess across various topics and decoupling, than it think it may solve.

Now we may end up in that IJobForeach will be asked in jobs Forum and IJobEntitites/ IJobChunk in ECS forum.
I see complete mess coming to town.

This is completely wrong



What DOTS Dev Blitz Day 2022 does in ECS in this case.
See, you already introduce mess, not knowing the own structure.
DOTS Graphics is not mandatory to use ECS. It is possible to disable hybrid rendering and render without ECS, while still supporting jobs and burst.
We had good example of such use cases.

 

I, for one, like this change in forum structure because the ECS workflow is significantly different from just using Jobs. The types of jobs you use in ECS are also different.

 

Where do Collections go?

 

I don't like structural changes

 

Seems nowhere

@UnityJuju
-1 to that changes, they're really bad on will confuse people more than help.

 

I'm not against a réorganisation of the forum but...

Planing that at the same time as the dev blitz day on DOTS was a mistake.

I've been navigating this forum for year now and now I'm lost. I can't even navigate to the sub forums since they don't show at the top of the parent forum anymore...

These change were obviously planned ahead since the post is from mid November, even if it wasn't visible until now.

Next time a little bit of head up would be nice...

 

It was kinda nice having the "Unity for the new era of nerds" under one umbrella category "DOTS" and the packages using DOTS technology under that. I felt safe and cozy.

 

The rename is definitely weird for me. This forum is the one stop shop for all things DOTS. I reserve one tab for it when I open the browser so I know all about DOTS updates and answers. Now, I have to look for other threads, too? Can we no longer ask about jobs and Burst here? I'm just used to it. This forum is like my home.

 

This seems counter intuitive with the "DOTS is the stack. ECS is a part of it." idea. Why not have a DOTS section with:
- Burst
- C# Jobs
- Collections (and could you please move blob assets into this)
- ECS Core
- ECS Animation
- ECS Netcode
- etc...

This change feels pretty weird and feels like a step away from the idea of the DOTS as a stack. Also, in a more practical point, it's not great that I can't look in a single place for all things DOTS and instead have to move around the forum to get a complete picture of what is happening in this environment.

I'm all for reorganizing things every now and again, but it should really make things easier to find and understand --- not spread information all over the place.

 

Burst and Jobs have had their own forums for a long time. You probably should have been using those forums all along.

https://forum.unity.com/forums/burst.629/
https://forum.unity.com/forums/c-job-system.829/

 

Jobs, Burst, and ECS are very intertwined. When you're using ECS, there's very little point to not use jobs and Burst (at least in 0.51). So what is this forum for? Strictly only for ECS?

 

The unfortunate bit is that the tagline for the old DOTS subforum was "Discuss all matters related to DOTS, including the Entity Component System (ECS), the C# Job System, and the Burst compiler." which overlaps with the Burst subforum ("Discuss anything related to the Burst compiler.") and the jobs subforum ("Discuss Unity's C# Job System for use with GameObjects and Entities.").
I don't really like the top-level "ECS for Unity" name especially with the fact that the Entity Component System subforum still reads "DOTS forum to discuss ECS, C# Job System and more." - eh? That tastes like reversing the hierarchy. From rauiz's suggestion, it would be great to just nest the existing jobs and Burst Scripting subforums under this one and title this DOTS again. That, or just give up on DOTS branding in the forum altogether and leave Entities-specific Burst / jobs talk in this subforum (but explicitly specify everything is in the context of ECS) and preserve the Scripting subforums as-is.

 

Yeah, putting ECS name at the top level is wrong. Should be DOTS > (ECS > Entities Graphics, Entities Network, Entities Physics etc), Jobs, Burst

 

Job system and burst are directly related to scripting, so it makes sense to have them as subforums of scripting, whereas ECS is more than just scripting. However, there are a lot of overlaps with other forums here, so it is actually quite difficult to make a classification that everyone is satisfied with.

E.g. Would it also make sense to move "Physics for ECS" to the Physics forum, but that would distribute all ECS related forums throughout the forum.

 

I think you need to consider a couple of things:
- The practical question is "what information is most likely to be useful for someone in this forum subsection?" That is the practical way of organizing information (likelyhood of usage and utility). Physics for ECS info is much more useful in cases where people are building in the DOTS environment. It is also much more likely that other DOTS posts are useful for someone that is just using Physics for ECS and it's APIs (maybe there's a Collections question that is useful or a burst one, etc...). Forum section discoverability, however, is quickly solved by google and forum search features.
- DOTS is marketed as a technology stack that contains Burst/Jobs/ECS/Collections. So you can also say Burst/Jobs are directly related to DOTS. Btw, I don't think you can just use Burst/Jobs without thinking about data in a non-OOP way. Not to its fullest potential at least.
- Semantically separating information is always better than separating based on names. Just because they are named Physics, doesn't mean their information is relevant within the same context and semantics. IMHO, that's an easy trap to fall into (and, rather interestingly, very common in OOP code bases too hahahaha)

This is all to say... IMO, just keep DOTS stuff together as the most common time where that information is useful is when working with some combination of the technologies inside the stack.

 

Could we have a similar forum structure on the official Unity Discord server as well (for dots)?

The current dev-blitz day forums on the discord channel make it a lot easier to follow questions and topics compared to the chat channels.

(just to be clear, not to replace the dots chat channel, but rather in addition)

 

since this thread is about the forum changes and since I have some brain damage with such sorts of things let me ask you @UnityJuju:
From where comes the need to add the "for Unity" suffix to the "ECS"? This is the only subforum dedicated "for Unity" so that means that for example "Input System" isn't?

I know that this sounds absurd and not critical, sorry about that

 

Other entity component systems exist that can be used with Unity.

 

Same argument would be valid for Multiplier forum.
Why not to put Unity Multiplier, or Multiplier Services. Shouldn't it be Unity Multiplier Services instead?
There is ongoing inconsistency with naming convention across whole board of Unity, from the forum to C# API.

And if anything, ECS or Unity ECS brings confusion already. Specially still having DOTS Blitz thread hanging there.
Naming DOTS instead and putting right sub forum there, would clear all tihis debate about changes.

Now there is DOTS and ECS. O hold on. There is no DOTS anymore. There is Unity ECS, scripting jobs, and scripting burst. But hey, burst is not just some exclusive API to Unity.
So what is DOTS anymore?

 

Yes, and? Other input systems exist (ReWired) that can be used with Unity. Other multiplayer systems exist (PUN) that can be used with Unity. But here we are. This changes nothing about the suffix being (rather, seeming) superfluous.

From the perspective that the ECS concept isn’t an architecture Unity Technologies invented, having “ECS for Unity” does make sense. It still seems out of place, though.

 

In my opinion it would be unhelpful because DOTS is not a monolithic stack at this point.

DOTS is very unspecific. If someone says, “how do I do this in DOTS” no one is going to understand what they mean. It is a term from before Bust and Jobs became part of the MonoBehaviour ecosystem. I don’t think that anyone at Unity expected Burst or Jobs to become part of the MonoBehaviour ecosystem but that is what happened. It would be best to just drop the term DOTS.

I made a poll earlier and many people are only using Jobs with MonoBehaviour. 20 people are not using ECS correctly or only using Jobs. 44 are using it correctly. So 31.25% of people are not leveraging ECS.



see
https://forum.unity.com/threads/poll-how-are-you-using-dots-ecs.1364736/#post-8607267

 

That's not true. If you search DOTS just enywhere on the intheret. You will land on pages and even Unity blog post and main DOTS page. Each explains exactly what it is. What includes and what it is this tech stack purpose. Which goal is he performance.

Does scripting burst alone means anything? Does jobs? Or even ECS?
It will not. They alone make no sense to anyone besides very norrow low level group of devs and it is unclear, that they are highly compatible, to gain performance.

If I would see them for the first time in such form, I probably wouldn't even bother with burst, or jobs. I wouldn't even know, these are compatible.

ECS alone doesn't mean it can be multithreaded. Unreal has ECS too. It is just way of data and systems handling. So now Unity basically steps down to equalise with Unreal.

People will not be clearly able to connect dots, how to build performant code, if Unity forum structure will be in such mess. It will lead to alienate DOTS performance focus devs, from the rest of Unity community. Just because all is now fragmented all over the place.

As fro MB with ECS, why it is a problem?
It is not like people will try to run ECS, without jobifying them and without burst, just for little gain and so much additional effort.
So what is the point here?

 

People are for sure using the job system without ECS. At this point why insist despite all evidence to the contrary that many people are doing this. You may not understand why this is the case, but it is the case. Since ECS tends towards far greater changes to your code base then just multithreading a few parts using the Job system.

The ECS user is fundamentally different from the Job system user.

 

The point is, that we discussing this just because DOTS brought this community together. It brought us here. You, and me and others.
If not for that, we wouldn't even be discussing it.

Consider this. You joined this community because of capability of DOTS, of how it was promoted and which is fruit of a cumulative work both Unity and our community.
Yes jobs can exists alone, so it is burst and ECS.

We have Entitias. It was even paid, before ECS was announced few years back. But it was very narrow group of people who used it. Very specialized one. And not because of the price tag. Entities was for years. And other ECS APIs. Most of current DOTS devs wasn't even aware what ECS was before DOTS. Nor burst.

Again, it is DOTS, which has have built this awareness and community knowledge. Not individual components / APIs.
Now we are patriating it. That what worries me.
This is how I strongly feel about it. And that is why I continue to defend my stand.

 

I do not use those features myself, but don't the forum features "watch forum" and "follow people" allow you to set focus on what you are interested in? I guess there is no one static structure that would satisfy everyone.

 

https://forum.unity.com/threads/wha...-use-for-the-parent-of-this-subforum.1377912/
A good number of people seem to think going with DOTS is the most appealing.

 

Me included. I liked the old way better and would not be surprised if most early adopters feel this way...we can consider ourselves lucky to spend time on such trivial concerns...Merry Christmas.