ECS Purpose

Hi. If a game does not have a lot of objects(under 50 AIs or players) and they are not constantly instantiating/destroying new objects rapidly, maybe every 30 seconds, would there be a point in converting your game to use ECS for the sole purpose of performance? It seems that ECS is worth converting to if you have swarms of things spawning and dying.

 

It seems the ECS pattern also cuts down on allocations in general, so it might be worth it anyway. Many games end up being ticking time bombs of garbage to be collected

 

It's faster for small amounts of stuff too, just cache friendly I guess - and math aware compiler helps a lot... it's basically the future of Unity. I am slowly migrating over, just parallel tests atm.

 

So the old way will be phased out eventually?

 

Thanks for the info. Do you foresee some kind of auto tooling to help split out OOP classes into components and systems? Mostly because I have stuff in production that has thousands of lines of code and as time goes on I'm sure we'll be forced to use newer versions of Unity due to changes in iOS/Android requirements, it always happens. Then if ECS is the way to go, it would mean we need to re-write all the code to keep our game in the app stores.

 

Sorry I misread you post. But still would be cool to have some tooling eventually to help existing projects to migrate

Thanks again for Unity!

 

While I haven't actually switched to the new version yet (2018.x), it feels like after watching demonstrations of how the new ECS system works that developers will lose some feel of control of their instruction and be restricted to work within the bounds of a system on top of a system. While I am always for proven improvements to help promote a better end product, there's nothing wrong with OOP. I feel that Unity should investigate HOW to get their core architecture to use parallel programming and ditch the ECS system altogether. It almost feels like someone is forcing some version of the MVC pattern down the throat of development for the sake of being modular. I don't know, it just doesn't seem to fit... Why can't Unity Technologies modify their core technology to use parallel programming, and completely redesign and refactor from the ground up but using the existing architecture?

Apple did this very thing with their OSx product back in around 2009 where they completely rewrote their OS to improve the performance and yield a smaller, better product...

 

Maybe it's because the power is in the hands of the maker but not the tool?
Maybe it's because if we are tunnel vision then we fail to realise the potential of better things outside the tunnel?
Maybe it's because a better solution is not discovered yet?
Maybe it's because it simply just it can't be done. You cannot squeeze orange juice out of an apple.

Anyhow they are not phasing out Monobehavior, if not years of efforts and money into the entire existing Unity system will be lost. I think just experimenting on a new system and collecting feedback from the community and then iterating upon it is a great way to make sure we the user gets close to what we need, and I think it's a good thing.

I personally would love to dual-wield both ECS and Traditional OOP Monobehavior to see how they can work hand in hand. If I want power I can get power from ECS, if I want convenience and comfort I can fallback to Monobehavior.

 

ECS and core API parallelism is a completely different thing. You can have both. ECS does not allow parallelism but just a way we manage game data better and how to write a logic to pull that out better.

Related, the thread opener wants something similar to you : https://forum.unity.com/threads/why-not-make-unity-monobehavior-thread-safe-for-c-jobs.538169

 

In one of talks of conference (forgot which one), was mentioned at least once, that whatever Unity dev team has learning from ECS, they try put expertise into OOP of classic Unity system, to further optimize it.
So by all means, even if not using ECS, you potentially carry some befits from ECS.

 

As it matures it will make much more sense to people, that they can add and remove functionality from almost anything, so there's much more reuse than is possible right now. With OOP, you're always going to be sitting there mid-refactor at any given time and it's an accepted part of development. With ECS you can say goodbye to fiddling around with wiring (eventually).

So it'll end up being faster and easier to create things in. Not there yet.

 

I'm still confused. So is that to say, that for OOP developers who design things using inheritance modeling, use interfaces to have insurance, and so on, will need to shift their design to not use conventional OOP methods? If I am wrong in my understanding, perhaps I may need to go back and review my understanding of how ECS works.....

By the way, the maker's power IS bounded by the tools they use (going on a comment by a user). This is where creativity and design principles come into play...

 

Yes, you need to stop thinking in OOP methodologies otherwise you're going to get very stuck working with ECS.

I'm pretty confident with it now, but it took me 1-2 months to really start understanding how to utilize it and to adjust my way of thinking when tackling a problem.

 

OOP was never a good design for game development, and given I've typically avoided OOP most of my coding existence, I'm happy to get rid of it.

OOP was hard for people to understand first. Imagine if you started with ECS? It would have been easier and made more sense (it's much more like real life to just put lego together and pull it apart, and make new worlds).

OOP requires you worry about accessing the data stored somewhere in a particular class. You would have a hard time adding functionality. You would spend all your time messing about changing existing code just because you need to add functionality elsewhere. It's senseless and a waste of time. ECS fixes all that nonsense while speeding it up 10x.

 

Once you get a hang of it, doing ECS becomes much easier to reason about than doing OOP. It feels natural.

The biggest advantage for me is that since the data is decoupled from the logic, I never think about "where should I put this data", "who owns this data", "which class does this piece of code belong", etc. It all just "clicks". I remember spending hours on paper for this problem alone when I was doing OOP.

 

That's what OOP is, just designing these mobile homes with everything built in, and when you want to add more functionality you have to mess about with everything else to make room. Or you try to be clever and build a complex arrangement of inheritance and interfaces...feeling smart for a moment...

...before realising you blew maybe 90% of your programming time messing about with that instead of actually doing more real development.

ECS is more setup work and seems a bit fiddly, but it pays off big time once you get deeper into development. Then you realise all these other little machines for ECS you made, they're sooooo resusable! your code base becomes progressively more powerful and capable and can operate on almost anything, quite unlike what you would be doing with refactoring and messing about with wires in OOP land...

To summarise for me...

OOP = you spend most of the time figuring out how things fit together and are left with very little time to define the actual behaviour.

ECS = you spend most of the time figuring out how behaviour is defined and spend a little time figuring out how it fits together.

I know I'd rather be focusing on how my game behaves, not how I put it together. Of course when a game is in prototype or early stages regular OOP C# is quicker and easier. It's only when you are on the path of making a real game, something that needs content do you realise how much OOP can hold you back. ECS doesn't suffer that, it gets stronger the further you are in dev, while OOP gets weaker.

 

I have watched number of Unity conferences on ECS and Job System. I read multiple articles, forums and tutorials. I am quite excited to get hands on ECS with Job System soon. I have many objects, so I see massive potential there.

Only thing holds me back, before I start doing it, I must finish one part of my project, so I am clear, where I am standing. Then I can start porting it. Or at least major part of my core. I was writing the code in decoupled manner. So should help a lot already.

 

Thanks for the input and feedback guys. I'll give it a shot when its time to start learning. I'm very comfortable using OOP style development and love its features like inheritance and polymorphism which allows for so much code reuse and base class references when calling methods. Makes things super easy.

 

ECS Is a something that you need to get used to, a specially when you have several years of OOP. But when you take a grasp of it it is very satisfying to work with. A simple example I needed several things with a countdown. So I wrote a system that works on components with a countdown component on it and decreases its value. When the countdown ends just adds CountdownEnded component. Now other systems know what to do when the countdown ends for this particular Entity. For example, there may be a component DestroyEntity with a target entity as a field. Then a system that expects entities with that component and CountdownEnded component. Those systems may also just attach tag component DestroyEntity, and you may have a system that is only responsible for destroying entities. When you start doing stuff with ECS you will see how satisfying it is to work with and you will think how you can organize your date so that you can archive your goal using as many systems you already have as possible.

 

I understand ECS, I am using ECS, but I would never say it's satisfying to work with in its current state. Maybe in two years from now, but at this moment it is something like a pill I have to swallow to be healthy.

 

Maybe ECS indeed in 2 years, will get close to where is current Unity OOP UI interface.

On one hand I spent quite a bit on certaing things and made me so much frustrated. On other hand, when I saw my first systems working and communicating, it was quite satisfying for me. I started to visualize structure and benefits. Even tho in OOP I could code same in blink of eye.

But thing is, optimization never came with easy hand. Specially when you try squeeze most of it. You may provide lots of good tools, but if they are missuses, you kill your performance gain. Just like having OOP with instantiating and destroying GameObjects in Update, either because of laziness, or because lack of knowladge. All need time

 

I was writing to people who say that Unity should ditch ECS as a bad concept.

I agree that it is harder to use than it could be, but it is a preview. Nevertheless, I am using it in one of my hobby projects on mobile because it will allow me to add more enemies on screen and consume less battery and I will get used to it while it is in the preview state.

 

I think parts of what makes the ECS 'hard' to use is not going to go away for a long time for the average unity programmer, while the jobs system makes it easier to get threading 'right', it's still a fairly complicated model. Combine that with things like everything being structs, hard to hold reference types on entities, and all of the other advanced concepts such as barriers, command buffers, etc.

While I understand the reasoning behind all of this (performance, essentially), and I'm experienced enough to make use of it (even though it is cumbersome and convoluted currently), I still feel like Unity took the wrong route here a little bit.

An ECS implementation more similar to Entitas (reference types, etc.) which is easier to work with and probably easier to integrate with the rest of the engine would have been better IMHO. The jobs system could have existed as it is, but instead of tying it to the ECS it could have been a more general/generic threading system which makes use of structs and memory alignment to speed things up.

Just my .2

 

Entitas is ok I was using it for some of my work, but making Unity's ECS like Entitas makes no sense. You can still use Entitas and I think it will use threading at some point (maybe JobSystem). Reference type would cut of a benefit of good memory layouts and it is a place where most of the performance benefit lays.

 

Absolutely, but something built by Unity would be much tighter integrated into the engine itself, and offer better performance (even if it was reference based) than Entitas.

Well, most of the performance benefits lay with the job system. Absolutely cache friendly memory layouts help, but the big thing with 4+ core machines becoming more common is the Job system, and the job system could exist without the ECS.

The main reason to use the new ECS is the Job system, not medium improved single core performance due to cache friendly memory layout. But the new ECS is really cumbersome to get anything done in.

 

I agree, the hype has been on ECS but it seems like the more I look at it I find that the real value is in Jobs/Burst. The ECS architecture is more like the icing on the cake and improves everything overall but it's not integrated into the rest of the engine yet which makes it very cumbersome and fairly impractical to use in comparison to classic.

 

Cache misses are costly, L1 and L2 caches are blazing fast compared to RAM.
Here is a speed comparison between caches,ram and hard drive.
https://imgur.com/X1Hi1

L1 is 4 times faster than L2, L2 is more than 15 times faster than RAM. You can fit 8k floats into L1 cache of i7 processor and 64k floats into L2. An additional benefit of good memory layouts is SIMD. I think that those benefits greatly surpass multithreading.

You said that ECS is hard to grasp for beginners, but OOP is also hard to do right and I think it is easier to make bad OOP solution than ECS one.

But Burst requires non-reference types.

 

ECS as a pattern is great, it's just that the current implementation is so cumbersome to work with, and I dont think that is ever going away with the way it's architected.

 

Yes we know that L1/L2 is faster than RAM. But if you're expecting the entire game to be completely cache coherent you are going be jumping through hoops like no other. I mean even now with the ECS if you use shared components for rendering different meshes the cache locality breaks. If you need 100 unique player characters then you're going to have 100 entities in different locations in memory already.

 

The biggest benefit is of course all together. But not all parts are equal. Concurrency is by far the biggest value. Once you get main thread time below 16 ms, further optimization usually carries far less value. At that point it's going to be cases like features which try to maximize cores or heavy logic that needs to complete within a frame or less where you will bother optimizing more.

I'm also seeing good gains from burst even when not using ECS. Although I generally use data layouts that while not as strict as ECS, are still moderately cache friendly. Honestly it's not really that difficult to get there the rules are pretty simple.