Question Some doubts from someone who just found out about ECS

Hi, I've been developing games on Unity on and off as a hobbyist, and I have a moderate amount of amateur experience (~2 years making projects here and there). I've always developed with the OOP centered Monobehaviour/GameObject system that Unity always used.

Now recently I've heard about ECS, and it piqued my interest. In most projects that I've been developing, I've tried to emulate (a bit unsuccessfully) similar architectures (separation of concerns-wise) that helps with the scalability of the code (development-wise, not performance-wise necessarily). So I'm definitely trying ECS out and DOD to further broaden my knowledge behind programming and software architecture in general.

Now, that aside. I was wondering the pros and cons behind the Monobehaviour/GameObject vs the pros and cons behind DOD ECS since, based on what I've found out online, as I came to understand if you are equally proficient at both, ECS just wipes the other one across the board in runtime performance, code scalability, options, everything maybe except learning curve. Is this true? Am I misunderstanding? Are there situations in which I might favor Monobehaviour/GameObject over ECS?

There is another underlying discussion which is a bit more... "philosophical", lets say, behind the arguments about OOP being bad vs, say, Procedural Programming, but I find that discussion a bit too abstract for me, I just want to make good games

Thank you so much for your patience, I'm still learning this new system and I'm definitely not a seasoned developer yet

 

(assuming both are written properly)
ECS is a lot faster than gameobjects by a lot yes.
Scalability is better in a performance perspective, but from a code perspective this depends on your skill level and team.
I cannot comment on the iteration speed, for making small experiments ECS seems to be taking longer to get results, but iterations after the feature is already implemented might be better. Not experienced enough to say for sure.
Online assets are mostly not written for ECS, so less support and fewer cheap implementations.

The upside is that you can use both within a single project, so you can use ECS for the parts which need it

 

Isn't a game like 99% animations (skinned meshes, animated doors), particles and sounds? Well all of them are currently not supported in ECS, you'd have to write the implementations on your own. So you can only use it in combination with custom stuff or monobehaviour OOP stuff - until Unity adds those features for ECS.

 

Generally speaking, logic for your game is conditionals stuff, state machines and the like, perfectly suited to abstract classes and state machines governed by a few super singletons for management etc.

Where ECS really shines is things like particle systems. If you're thinking about some part of your game as being like a particle system, it's probably suited to, and will benefit greatly from, a DOD focused approach to iterating over everything in the particle system.

Don't need to think about ECS/DOTS until you have some part of your game that needs it. And most games probably don't need it. It was a bit of a fools errand, or zealotry that led trying to rewrite the entire engine around DOD.

 

There are third party systems available both free and paid. Here are the ones I can think of right now.

https://github.com/Dreaming381/Latios-Framework
https://github.com/gamedev-pro/dmotion

https://assetstore.unity.com/packages/tools/animation/rukhanka-ecs-animation-system-241472
https://assetstore.unity.com/packages/tools/behavior-ai/agents-navigation-239233

 

You really should pick one or the other. I keep seeing the bad advice that you can add ECS later or only use it for parts of your code. If your ECS code interacts directly with your MonoBehaviour at all you will not be happy. ECS has nothing to do with making your code like a particle system. ECS systems can interact with other ECS systems in a trivial manner.

 

If by "options" you include the various ways you could "do it yourself", this is true. Otherwise, you'll have far more options with MoneBehaviour/GameObject.

If you are the kind of person who is building a heavy simulation game or likes to build custom solutions tailor-fit for your needs and be less dependent on Unity, then ECS is a no-brainer in my opinion. However, most people aren't that way. For the majority, ECS is missing a bunch of features, and then it becomes a matter of how much appetite do you have for 3rd party shopping. There's not a lot of variety, but there's enough coverage out there to go full ECS if that's what you want.

There's also the mindset shift, but everyone is different in that regard. Some won't be able to function with the larger cognitive context requirements or amount of boilerplate code. Some will pick up enough of the basics to rely on "performance by default" to carry their project. And some will adventure out into new frontiers.

As for mix-and-match, there are a few ways it does work, and lots of ways it fails to deliver. For example, if you are comfortable with your dynamic presentation objects being addressables rather than scene objects, than using ECS for simulation and GameObjects for some presentation aspects is very reasonable. If you just need some heavy simulation logic, then skip subscenes and use GameObjects to drive entity lifecycles. However, subscene entities and systems are very bad at communicating with scene GameObjects, and that causes lots of pain.

 

Monobehavior/GameObjects are much more matured than ECS. If you are using ECS you are on the bleeding edge side. There are still enough bugs, memory leaks, crashes and the like around. I work with ECS approximately 3 months now and I surely found a dozend bugs in ECS and related packages and reported most of them. Working with Monobehaviors/GameObjects ensures more stability.

Also I think it is easier for humans to think object-oriented than data-oriented. So you may find the familiarization with DOD difficult. Someone may say: "Entities with components, Objects with components, what's the difference?". In OOP a class is responsible for its data and separation of concerns can easily be achieved. But no one particular is responsible for the data on the Entities. Every ECS system may write or read the data. You can still mitigate this with an appropriate design. But at the beginning the lack of experience with DOD and how to design and work with data will be a factor. I realize this within my first ECS project.

 

It is true. Once you've experienced enough - you wouldn't want to go back to OOP.

Pros:
- DOD makes you re-think what you were coding prior.
E.g. was it MonoBehaviours with data and logic mashed together? Infinte amount of components that basically do the same thing? Spaghetti of events to bypass Unity's native marshalling overhead (see as Update 10k issue)?
ECS provides better solution for all of that. Even if you don't use Entities in everyday work projects, learning DOD will make your code better.

- Better code maintainability without falling into business application trap of injections.
- Better code re-use ability due to data <-> logic decoupling. Copy & paste logic between projects with test coverage.
- Better feature integrity (see as feature matrix).
This is due to the fact that you can take out or add logic anytime you want without changing data layouts or authoring. Stacking features is as simple as setting order of execution.
- Better performance & ability to perform more complex simulation.
E.g. A part of it is the fact you've got access to multithread out of the box. Want to do something complex? Vertex manipulation on CPU? You can do it. City building simulator? No problemo. Something is too slow to perform on main thread? Schedule a job for it. Or better yet - push everything of the main thread to have more features with no performance costs. It goes beyond that.

Previous MonoBehaviour simulation restrictions do not apply anymore. That applies to the mobile platform as well, because mobiles have lots of cores nowadays. Burst is a miracle on its own. List goes on.

Cons:
- Learning something new is hard. Take your time.
- Editor stability. Its not the Entities issue actually. Its overall editor stability that is the issue. DOTS just tend to push it to the limit. LTS means nothing nowadays.
- Potential of shooting yourself in the foot. Lots of things can be done in unsafe manner (such as writing native containers without mem debug allocator). Which will result in hard crashes that may be hard to track down.


Hybrid approach is also possible (that is MonoBehaviours + Entities).
A bit less convinient now that conversion is gone, but still a valid strategy to cover all missing features. Such as visualization layer of the application (rendering, VFX, etc).

Otherwise some pure feature re-implementations already exist (as mentioned in the thread), or even native API is available on its by default (e.g. Particle System jobs).

 

Thank you everyone for the amazing replies!

For now I'll be learning DOD and ECS to further get into it.

I like the possibility of hybrid approaches, this means that all learning I'll make can be used in more contexts beyond ECS (although it does sound quite confusing to be mixing these in the same project, surely in very distinct systems as it was proposed with presentation vs logic)

I had heard of some 3rd party apps that extend ECS and DOTS by filling the necessary features (hi Latios!), but I also find the idea of having to implement some of the systems by my own a fun idea, since I dont have any time restrictions with my own personal projects.

However, its quite clear that If I were to make a new professional time-gated project on Unity, I'd probably stick with the old way since time would be quite needed (relearning many things, changing ways of thinking, lack of resources online all would take too long)

 

Disagree. ECS shines in many things other than particle systems. I have spent some months working on a comparision between ECS and OOP to see whether my team should use ECS for the next project. The result is so impressive that we don't give a second thought.

And since we uses the hybrid approach, I have a better view on both systems. I can say that if you don't plan to do things the ECS way from the beginning, your only choice at the later time would be rewriting everything. And when a large part of the game is already written in OOP, the tendency to avoid ECS would be too great.