[November 2025] ECS Stack Review

[jivalenzuela]

@DreamingImLatios

I’m getting a bit burned out of this being a one-sided conversation, especially when it isn’t obvious which teams actually see these posts.

I want to thank you for myself and from the team for your posts. For what it’s worth we read and discuss them and I’ve long meant to respond in depth.

I want to thank you for myself and from the team for your posts. They are often a topic of discussion. I can’t respond to everything, but I’ll tackle a couple of things here and folks may chime in with some followup questions. Be on the lookout for edits as I correct my mistakes.

@DreamingImLatios

A lot of these were surprise drops.

Expect to hear more detail in the coming weeks. As a rule, though, we’re looking to show progress through action, not words.

@DreamingImLatios

• I don’t know the plans for parallelizing unified transforms

In the short term, we’re introducing more burst-friendly APIs for working with Transform data. Longer term we have talked about reworking the data design of the TransformHierarchy to allow better parallel processing with the scene hierarchy topology more typical of ECS games (you can of course use the traditional IJobParallelForTransform which processes entire transform hierarchies), but I can’t provide a concrete roadmap or timeline yet.

@DreamingImLatios

• I don’t know what the next step is regarding determinism, now that Burst supports it

We’re evaluating our next steps, so don’t have anything definite to communicate yet.

@DreamingImLatios

Custom job types are cool, but they have a lot of boilerplate to define, and lose a lot of safety factors. Right now, a lot of people (myself included) try to implement custom jobs as a generic job of one of the already existing types. This is kinda a hack though, and I’d like to see something supported a little better.

What are the safety issues? The one criticism with which I’m aware is that they aren’t particularly well documented.

@DreamingImLatios

The first issue is that IAspect can handle archetype-conditional logic. It isn’t perfect at it, but it tries to find optional components and can alter its behavior accordingly. Optional components aren’t possible in IJobEntity .

Have you considered using IJobChunk? It’s better suited for these more advanced cases.

@DreamingImLatios

The third issue is that IAspect allows scripting defines to redirect which components some type of data comes from.

I think IAspect has been an effective way to solve dependency injection and write a API interface that doesn’t expose too many internal details. I don’t however think it has to be the only way.

@DreamingImLatios

Yes, I am aware that IAspect is only deprecated, and it will still be supported through Unity 6.

I want to be very clear here: IAspect is not going to be supported through Unity 6. Deprecation will come in the Unity 6 timeline. The support schedule for ECS APIs is determined by the package lifecycle and decoupled from the Unity editor version.

@DreamingImLatios

My ask is that you have a plan to make SystemAPI and IJobEntity extensible, or kill those too.

We’re aware of the incongruity and working to resolve it.

@DreamingImLatios

If you start talking about lockstep determinism, not only are you going to need a checksum algorithm that can deal with nondeterministic entity references, but you will also need to watch out for blob assets and UnityObjectRef instances. I’m curious what direction you will take in that regard.

There’s a level of state for which we aren’t seeking to provide identical results across different runs or environments. Lockstep determinism is one of those things that is probably not part of the core “predictive rollback” simulation determinism we provide out of the box. For titles that require a level of state replication we can’t guarantee we seek to make it possible to extend ECS to get the results they need to be successful.

@DreamingImLatios

Being able to detect when an entity is created or destroyed, or when a component has been added or removed, without needing to use cleanup components for everything (which are prone to chunk fragmentation if they are tags), would solve a lot of problems.

Definitely aware of the problem but can’t discuss specific plans just yet.

@DreamingImLatios

What I’ve learned is that if you formalize a process for people to report these inconsistencies to you in the moments people find them, and you create a culture where people are incentivized to do so (provide feedback that you are listening), then and only then can you actually solve this problem.

Curious what you intend by “formalize” here.