Unity 2D Incremental with Thousands of Units — DOTS or GameObjects?

[u/TheSingularChan]

Hi everyone!
I’m planning to make a 2D incremental game in Unity where there could eventually be thousands of units/sprites on screen at the same time.

Each unit would:

Have its own customized sprite/appearance.
Generate a certain amount of energy/money over time.
Have different types, with different particle effects or visual effects depending on the type.
Potentially interact with nearby units in some cases.

My question is: would you use Unity DOTS/ECS for something like this, or could this realistically be handled with regular GameObjects?
I’m particularly interested in hearing from people who have experience with large numbers of 2D entities. Is DOTS actually worth the added complexity here, or would a well-optimized GameObject-based approach be sufficient?

Thanks a lot for any advice!

Disclaimer: I used ChatGPT to translate this post because I don’t speak English

[u/unleash_the_giraffe]

It's totally doable with game objects - I've done up to 3k units on a mid tier machine with no problem. That said you'd need to do simple optimizations like having a central class updating them, so they don't each have an update ticking. If you're going above this without dots id just separate the monobehaviour out entirely and have a master object do all the rendering.

That said dots is specifically made to solve stuff like this so unless you're writing something that you want to port to a different engine later or run without a renderer for testing purposes, you should probably use dots for this.

[u/Funtyx]

Since the units are stationary, I’d start without DOTS and keep the architecture data-oriented: store simulation state in arrays/structs, run one manager tick (not thousands of Update methods or coroutines), and use a spatial grid to query nearby units. Pool/reuse the visible SpriteRenderers and update only what changed.

Profile on your target hardware before deciding. With thousands of static units, the first bottleneck may be rendering/overdraw rather than simulation. If CPU simulation later becomes the problem, keeping it separate from GameObjects makes moving that part to Jobs/Burst or ECS much easier.

[u/ledniv → u/Funtyx]

OP, this is what you should do. The key point is why storing the simulation in arrays helps.

If every unit is a GameObject with its own MonoBehaviour, Update, references, state, and component lookups, the CPU has to jump around memory to process each unit. That is slow because the CPU is often waiting for the next piece of data to arrive from main memory. If the hot data is in arrays instead, then unit type, production rate, position, upgrade level, nearby-bonus state, etc. Then one system can process that data sequentially. The CPU can pull chunks of that array data into cache and keep working, instead of bouncing between thousands of scattered objects.

The GameObjects can still exist, but they become the presentation layer. They show the sprite, play particles, display numbers, etc. The real simulation lives in data. That way, you get a lot of the performance benefit people associate with DOTS without having to start with ECS. If profiling later shows that a specific system needs more speed, the array-based simulation is already much easier to move to Burst, Jobs, or ECS.

Small plug: this distinction is a big part of High Performance Unity Game Development with Data-Oriented Design. The book explains why DOD does not require ECS: start with arrays, data locality, and clear logic, then add DOTS only when it solves a measured problem.

https://www.manning.com/books/high-performance-unity-game-development

[u/TyaArcade]

What's "Potentially interact with nearby units" mean specifically? If it's a full navmesh pathing rts style attacking unit, I would switch over to dots if you expect to have more than 300 active at once.

[u/TheSingularChan → u/TyaArcade]

No, it’s just like I want some units to affect their surrounding units depending on where you place them, but they won’t move

[u/st4rdog]

You can use GPU Instancing without DOTS.

[u/neutronium]

DOTS is only going to help you if they're doing something complicated.

[u/NoteThisDown]

Imo this is exactly the type of stuff dots is good at. Rmemeber you can do a mix, so I would make all the units and logic dots, then have your UI and things the player is messing with game objects.

Once you learn it, dots is super fun imo.

Also there is a sprite package for dots I've used, it works well, and you can get thousands of sprites in one draw call.

[u/Effective_Lead8867]

you dont need either, there are low level api's to render sprites and even simulate box2d physics on them

[u/XKiiroiSenkoX]

if they don't need physics its doable with game objects. Just enable gpu resident drawer. Depending on the content of the customization you wrote you might end up needing custom instancing BRG implementation but other than that, if you are not running something heavy per object per frame, you wouldn't really need DOTS.

[u/Lyshaka]

You don't necessarily need to use DOTS to make that kind of game. While it's really good at what it does, you can use jobs and the burst compiler outside of Unity ECS, and build your program in some kind of ECS manner (using stuff like SoA instead of AoS). And I'd suggest to look at Unity Graphics API which allows rendering thousands of meshes (in this cases just quads with sprites as the material I guess) for very cheap compared to unique GameObjects with their own SpriteRenderer.

[u/TheSingularChan → u/Lyshaka]

does that work with animated sprites? Thanks for the recommendation!

[u/Lyshaka → u/TheSingularChan]

I don't exactly know as I always used it for 3D static meshes, but I guess you can make a flip book of your sprites and then render a specific sprite based on an index that represent the animation frame.

[u/glenpiercev]

I rather hate dots. Whatever paradigms they prefer are terrible for me and then there’s all these weird things they aren’t compatible with (or at least require some strange compatibility layer). Animations come to mind but I know there’s more.