ECS Development Status - December 2025

[EricDziurzynski]

Hi everyone, I’ve recently joined the ECS team for Product Strategy coverage and wanted to help provide an update here together with @joepl!

We recently updated our roadmap and shared it at Unite in Barcelona at the end of November. In this roadmap presentation we were excited to share more details about faster, incremental architecture updates and what we intend for that to look like over the next year leading up to the next LTS in Unity 6.7. The section focused on Entities can be seen at the 26:37 timestamp of the presentation on YouTube, embedded below this paragraph. Our team is creating this post on Unity Discussions to unpack this information for questions, discussion, and feedback.

The Unity Engine roadmap | Unite 2025

ECS as Core Packages

The Entities, Collections, Mathematics, and Entities Graphics packages are coming to Unity 6.4 as Core Packages. This means that they will ship with the Editor and allow us to more quickly make changes to integrate ECS into the engine. This will help us to do the work of supporting GameObjects with Entities in the future, as we work towards implementing the ECS for All initiative. It will also mean that we can ship the features to users faster and more incrementally.

InstanceID/EntityId changes in the Engine

Starting in Unity 6.4, we’re making some fundamental changes in the spirit of having ‘ECS for All’ in the Engine. Specifically, transforming the InstanceID int into a new EntityId type. EntityId will represent both GameObjects and Entities; and allow us to treat GameObjects as Entities in future Unity 6.X releases. Every GameObject will have the ability to have ECS component data attached to it and users can optimize performance-critical parts of their game with ECS systems.

This change does involve structural changes to our API that we are rolling out in the next couple series of releases. In 6.4 EntityId will become the preferred type for identifying objects in Unity and InstanceID methods will be marked as deprecated. In future releases InstanceID will be entirely removed as we turn EntityId into a type with the same internal 64-bit structure as the current ECS Entity type and allocate them with the same allocator.

Important:

Because EntityId can no longer be represented by a single int, there are assumptions developers should avoid. Notably the following are no longer guaranteed to work:

• Casting EntityId to and from an int. EntityId will not be represented internally by a 32bit int in the future.
• Relying on positive vs negative for checking if EntityId represents an asset-loaded object.
• Using Object.GetHashCode to get an EntityId.
• Using .ToString to serialize into a string; and using int.Parse by itself to get it back into the same type.
• Sorting by EntityId to sort by creation order.
• Storing state in the first bit of the EntityId (in InstanceID, this bit was unused).

FAQ:

Q: I’m still not completely sure how to think about ECS, where can I find an overview?
A: This webpage provides a great overview on ECS for Unity.

Q: What does this mean for getting new versions of ECS packages?
A: New versions of ECS packages will ship alongside versions of the Editor. Expect bug fixes in patch releases and more major features/changes to arrive in Unity point releases.

Q: I thought ECS For All required a new major version of Unity. Is that no longer true?
A: We’ve changed our plans with the intent to deliver as much as we can incrementally through major Unity 6 versions.

Q: What about Physics and Netcode?
A: Physics and Netcode are planned to join the current set of Core Packages in a future Unity release in 2026.

Q: Can I still change the package source?
A: Yes. You can still have embedded packages with local source changes in your project.

Q: Will the packages evolve with breaking changes during the Unity Editor life cycle?
A: Yes. The version of ECS packages will track the Editor version (6.4 in the next version). We will incrementally be rolling out changes with a staged approach of deprecating anything we are planning on removing first.

Q: What about using ECS packages with previous versions of the Editor?.
A: We will continue to support and fix bugs in the 1.x versions of ECS packages. These versions will work with the specified minimum Unity versions of those packages.

[joshrs926]

This is exciting stuff! In the future, will we still need to choose between regular MonoBehaviour style physics vs DOTS physics or will they be more integrated together somehow? I do a lot with Rigidbodies and I’m interested in the performance possibilities with DOTS physics but not interested in totally changing my MonoBehaviour workflow.

[Thaina]

Could entityId be serialized as long64bit or guid128bit or will it strictly must be string?

Also will it be permanent Id between session?

[jivalenzuela]

@Thaina

Could entityId be serialized as long64bit or guid128bit or will it strictly must be string?

For the foreseeable future, EntityId will fit in a 64-bit integer, but we aren’t guaranteeing that that will not change in some future version of Unity.

[PostEnot]

Are there any plans to solve the problem of the mess with math classes? At this point in time, we have:

1. System.Math
2. System.MathF
3. UnityEngine.Mathf
4. Unity.Mathematics.math

Similarly, we have:

1. System.Numerics.Vector3
2. UnityEngine.Vector3
3. Unity.Mathematics.float3

Etc. As for the structures, in general, it is still not so critical, since each of them is aimed at its own needs (except for System.Numerics.Vector3, which is generally not used in the framework of Unity), but there is complete trouble with math classes-utilities. I understand what the point of UnityEngine was.Mathf at a time when we only had a System.Math, but at this point in time, most of the methods from there have lost any meaning and are just a wrapper like: float Method() => (float)Math.MethodA();. The fact that Unity.Mathematics will become part of the engine very soon, foreshadowing “amazing” times when any beginner who decides to calculate the cosine will discover an amazing zoo of utility classes.

To be honest, this is the most absurd situation, and what’s worse, I’m afraid that it won’t be solved in any way, since all the solutions that I see now look as critical and breaking backward compatibility as possible - and we’ll just have 4 mathematical libraries in parallel.

[AndreaGalet]

So Happy to hear these news! 2026 will probably be the most important year in years for Unity.

[jGate99]

Any plans for 2d Support? Sprites etc

[nickdollahz]

I think the best we could hope for is that only 1 is included by default. Once Unity has ported all their engine code over to use one of them. Then you can import the package you need for legacy code as an optional step. This is probably years in the future though.

I suppose they could build some sort of thin layer api that can redirect calls from the other APIs to use the main one they plan to use going forward.

[PostEnot]

ECS Development Status - December 2025

I think the best we could hope for is that only 1 is included by default. Once Unity has ported all their engine code over to use one of them. Then you can import the package you need for legacy code as an optional step. This is probably years in the future though. I suppose they could build some sort of thin layer api that can redirect calls from the other APIs to use the main one they plan to use going forward.

In fact, I see another acceptable solution - to develop Mathf, making it the only true solution for working with mathematics. The only problem is that then you will need to standardize a huge number of methods, because even such simple methods as UnityEngine.Mathf.Min and Unity.math.min have different behavior. And what to do about it is a huge question.

[jivalenzuela]

@PostEnot

Are there any plans to solve the problem of the mess with math classes? At this point in time, we have:

Yes, but no specific timeline to share just yet.

[thelebaron]

Will EntityId eventually be replaced by the actual Entity struct or kept as a side by side detail? Just curious what the final api will look like.

[Laicasaane]

@EricDziurzynski

Relying on positive vs negative for checking if EntityId represents an asset-loaded object.

I guess there should be a way to replace this?

@EricDziurzynski

EntityId will represent both GameObjects and Entities;

I think it should be clear whether this is applied to GameObject specifically or anything that is UnityEngine.Object?

[RichardFine]

@Laicasaane

I think it should be clear whether this is applied to GameObject specifically or anything that is UnityEngine.Object?

You’re right, it’s any UnityEngine.Object - not only GameObject.

[JohnPontoco]

Great work all around, excited for this stuff. Can you share a little more about how the packages will be handled going forward? One of the awesome aspects of the Entities packages is that you can tweak them to optimize for a specific game or fix bugs. (See some of tertle’s great work).

1. My understanding, based on the Graphics packages, is that we’d still be able to patch in a custom version of any of the packages by copying the code from the PackageCache and overriding the path in package.json. Is that going to be the path going forward?

2. Is there any chance that you all could set up the entities packages with the same Github mirroring tool you use for the Graphics repo? I know this sounds like a minor ask, but when a bug really comes down to the wire, having that level of documentation is incredible.

In general, I love the integration of Entities For All, but I want to make sure it doesn’t get so deeply embedded that it becomes hard to customize, or browse the source. That would be a real loss!

[tertle]

@thelebaron

Will EntityId eventually be replaced by the actual Entity struct or kept as a side by side detail? Just curious what the final api will look like.

I’m assuming (hoping) at some point the entity struct will be replaced by entityid

[JesOb]

@RichardFine

You’re right, it’s any UnityEngine.Object - not only GameObject.

Does it mean Textures and ScriptableObjects will be Entities in Unity 6.6+
Does it mean we can add components and EcsComponents to ScriptableObjects in future?

[arkano22]

I guess the goal is to eventually treat GameObjects in an ECS fashion internally, engine-wide?

I mean, the way you expose data to the user in-editor can (should) be decoupled from the way the engine actually processes it. GameObjects could just be an ID internally and their components just be like entity components. The code we write in Update(), FixedUpdate(), LateUpdate() etc could be executed in parallel for all GameObjects having the same component combination (archetype) since update order between components of the same type in different GameObjects is currently undefined anyway. Most often, components store value types and in the cases where they store references (for instance to a scriptable object) they could be moved to a blob asset. References between components would cause dependences between jobs.

Don’t know, at first glance hiding away any ECS implementation details away from the user and convert everything to data-oriented while keeping the usual workflows unchanged seems doable. If at all possible, that’s certainly the approach that makes most sense to me.

[Nuveenjones]

All Concepts Clear Now Regarding ECS Development. thanks

[davenirline]

How will this affect current projects that are majorly using ECS/DOTS? (Or does it have an effect?) I just want to know if there would be breaking changes for these projects.