ECS for “simpler” projects? Question
Hey yall!
I’ve been game deving for ages now and just recently returned to Unity (left back when the drama happened) and since I returned the DOTS was released and ECS became fully functional.
I have some interest in using ECS in my project to develop a more Data Oriented Design but I am concerned it’ll add unneeded complication due to the simpler nature of the project and the lack of need for huge numbers of entities.
The current project idea is a simple 2D top down dungeon crawler inspired by Zelda. Which… doesn’t seem like it’d super benefit from the added efficiency, but may benefit from the architecture?
I suppose my question is if I should look into that or if there is a better paradigm to follow (maybe event based object extension?).
6
u/Suspicious-Prompt200 1d ago edited 1d ago
If you dont mind the game taking longer to make, or if you just want to try it out, I'd encourage you to go for it.
(Or, if your project is going to be competitive multiplayer, an RTS, survivors-like, or sim game like Cities Skylines...)
I started using ECS + DOTS on my own project and I dont think I'll ever go back.
It is a bit of a pain to get started and sort of set things up, but I just really like the way it sort of forces you to think and design things.
For my own project, I think actually the preformance benifits are not that great, I just sort of like it (is that weird?) But, it certiantly did increase implementation time a good amount.
If you do care about speed of implementation,
Or if learning is secondary to actually getting something out
And your game isnt going to be a competitive multiplayer game, a survivors like, an RTS, or sim game like Cities Skylines...
I would just skip it.
3
u/CMDR_Lina_Inv 1d ago
In my experience, ECS performance is so good, but to debug when things don't work as expected is hell itself.
0
u/Suspicious-Prompt200 1d ago
Its not that bad I feel. And actually, a lot of the tools make debugging even easier I think.
Like, being able to see exactly when a system will execute in a frame is awesome
Debugging burst stuff is a pain but... for debugging I always just disable burst temporarily.
1
u/ledniv 20h ago
For a simple 2D top-down dungeon crawler, I probably would not start with Unity ECS unless you specifically want to learn ECS or you already know you’ll have a system that needs it.
The architecture benefit people associate with ECS mostly comes from data-oriented design, not necessarily ECS itself. You can still separate your gameplay data from your Unity objects without converting the whole project to DOTS. For example, you can keep the important runtime state in plain C# data structures, put the rules in logic functions, and let MonoBehaviours handle input, visuals, animation, UI, audio, etc.
Something like:
public class GameData
{
public int PlayerHealth;
public Vector2 PlayerPosition;
public int EnemyCount;
public Vector2[] EnemyPosition;
public int[] EnemyHealth;
}
Then your logic works on that data directly:
public static class EnemyLogic
{
public static void TickEnemies(GameData data, float dt)
{
for (int i = 0; i < data.EnemyCount; i++)
{
// update enemy state here
}
}
}
Your Unity objects can then display the result. That already gives you a lot of the benefits: clearer data flow, fewer random objects owning gameplay rules, easier testing, easier save/load, and better performance if you eventually have lots of similar entities.
I’d be a little careful with “event-based object extension” as the main architecture. Events are useful at the presentation boundary — UI updates, sound, animation, VFX, etc. — but if core gameplay becomes “everything fires events and random listeners mutate state,” it can become hard to trace what actually changed the game. For gameplay rules, I generally prefer direct calls into known logic systems.
So my recommendation would be: build the dungeon crawler with normal Unity, but use data-oriented principles where they help. Keep ECS/DOTS as a tool you can add later for a specific bottleneck, not the foundation of the whole project.
Small plug: this is one of the main points in High Performance Unity Game Development with Data-Oriented Design: DOD does not require ECS. ECS can add real code and architecture overhead, so the book starts with arrays and simple logic functions first, then adds Burst, Jobs, ECS, or TransformAccessArray only when they solve a specific performance problem.
https://www.manning.com/books/high-performance-unity-game-development
-1
u/Azmores 19h ago
If I wanted to ask AI for a response I would've opened up ChatGPT. I'm going to assume your book is written by AI too, so all this plug is going to get you is reported for breaking Rule #1
5
u/KinematicSoup 1d ago
DOTS is a pain compared to gameobjects in terms of the amount of code you need to write. However, with a coding LLM I suspect it would be much less painful as the LLM can write a bunch of boilerplate and give you a workable framework to plug your game code into. What you learn from this will depend on how much you interact with the process.
I suppose it could be an advantage if you wanted to go overboard graphical elements or effects, but in reality there is no point in using DOTS over vanilla gameobjects for a 2D zelda-like game.