ECS or Why Should I Bother Making My Game Efficient

Not clickbait! Had a chance to play with ECS recently and wondered what people are thinking about it. Will you be Dropping MonoBehaviour and going FULL ECS? Perhaps a relaxed hybrid approach suits you?

I wanted to foster discussion so when Unity does come out with blog posts, people will be warmed up to talk about it. It's right around the corner so I hope everyone is as excited as I am. @superpig linked this, and I found it terribly interesting:

What's your take on it? Will you be using it and if so, why/how?

 

I am trying to wrap my head around where it may be useful. My biggest issue is loading engineering files with no ability to manipulate manually or run an editor suite of tools on prior. So I do not get any benefits from Occlusion Culling and this leads to at times turning the controller and looking at a wall with hundreds of pieces of geometry behind it that has no reason to be rendered which then slows the frame rate. Will queueing these up in a sequence, which is what I gather this basically does, help with my issues. Conversely can something like..if this geometry cannot see the camera do not render it..which is the reverse of OC and makes the object 'smart'..be accomplished with ECS?

 

I'm 16 minutes in, is there a part I can skip to?

I'm doing some ECS now in my project.
Similar to Caves Of Qud.
I've reviewed a few ECS systems people have built.
So of course I'm making my own for now, the frame is built and tested but not really a game yet.

 

I have played for fun with an ECS from a Unity user (@Spy-Shifty) but stopped because he is not actively working on it at the moment.

My take away: It’s a good match for me. I don’t even care about the potential speed gains. It’s more natural to me - I am self taught from the c64 assembler days and tried to use oop - but in reality it slowed me down and made things more complicated (at least for me) - ECS has data and systems separate and is pretty sequential- I understand better what is going on

So for me it’s good because it’s closer to how I think...

Edit: I put it on hold until Unity comes up with something, unless they takes forever

 

For anyone as uninformed as I am, "ECS" means "Entity component system."

 

Which is what I always thought I was doing. I had an entity - the GameObject - I added my Components - and it only talked to the System when needed. This compsci jargon ..I dunno - I do things for years in a certain way cause it bloody well works then find out it has some fancy acronym which i promptly forget because i have to make things work like a hot rod mechanic and memorizing it don't do a thing for the cause.

 

I think it's going to be a big deal in Unity land and is probably already a big deal for some studios. The hard part is thinking in that space and wondering how you'll be able to refactor your code for it.

 

ECS is something game developers should know about. It's been around for a long time. Every professional studio I've talked to developers are familiar with it. I actually bring it up in interviews as a way to judge how current a developer is in their field. If they do know it then I start asking them to decompose it. It's a great interview exercise because there are differing opinions on it and at the same time it covers some important design areas. So it's a subject that IMO is good for judging creative thinking.

 

@ippdev - yep, all this jargon makes it confusing. The thing is ECS is not equal ECS - so it even gets more confusing.

Unity current ECS - is something where you work component based, but typically you have data and logic mixed up in script components attached to your gameobject.

Unity future ECS (or let's say any of the more pure ECS systems) - completely decouple data (component) from logic (system) and attach data to entities (i.e. "gameobject" in unity world or just an entity id) and run systems across entities.

I think different people will react different to it in terms of personal preference and ease of use. "The pure ECS" is much more atomic with many components that only do one thing (i.e. 3 floats for position data) and one system only updating this data for movement. What is undeniable is that this has a speed advantage due to CPU cache (which only makes a difference if you need that extra speed). What it also does and that is were people will either like or dislike it, it changes the way you organize your code - as I stated above, the speed advantage is something that I do not really need, but for me, I like the way the code is organized.

You might have very well already organized your code in Unity according to this, if you took things in your hand and have 1 magic unity Update method and strictly separated data classes from logic classes. Check out the ECS from @Spy-Shifty - I have looked at 3-4 different ones and found his to be the closest to Unity / simplest to get into. I think others might be more robust, but if it is only to play around a day to understand it, it's a good start.

 

IMO, classic ECS is a fundamentally flawed concept. The main problem is that various components need to coordinate their behavior which adds whole layers of new complexity in object design. I don't like ECS at all.

 

It also makes a difference if you want to save power, or potentially if you want to make things more scalable.

Yonks ago when I was writing my own engine it was all ECS, but Unity came along and I started using that instead of chipping away at my own thing.

More recently I was doing a project where we needed to simulate huge crowds on modest hardware, and for that we basically did our own ECS stuff inside Unity. The performance difference was massive between that and the next fastest approach we prototyped (more than 15x performance increase if the numbers I remember are correct), but that wasn't the only difference between those prototypes so I can't say how much was due to that (we didn't test further because that blitzed our performance targets, so we rolled with it rather than experiment more).

I've heard this but (due to lack of experience with ECS) haven't had a case where it was a problem in order to have a go at solving it.

My gut feel is that I'd want to use ECS where aggregate things can be treated as large data sets, and use normal Component Oriented Design (ie: the way Unity mostly does things at the moment) where detailed communication/coordination between individual entities is required. The reasoning behind that is that the communication/coordination makes those individual entities less ideal candidates for bulk data processing, but there will also be a relatively small number of those, so it makes more sense to me to treat them as special cases outside of the main high-performance stuff. But... I have no idea how that approach would pan out when applied.

 

I only experimented with it a little and it can get a bit more complicated if you have reactive systems / events for component interaction. But the good thing is that you do not have to do everything in ECS, you can mix and match. It's nothing new nor ultimately better (as there are many dimensions to judge)...the only thing that seems clear is that it is the fastest way to transform data (which you might want to rather trade in for another form of organization that you like better....unless you run out of frame time and it's the only option left).

I think the tread is not about if it's better than anything else but if we plan to use it and how... I do!

 

AFAIK, ECS works well with CPU cache. This means that it's good when you have to apply LOTS of operations on LOTS of similar objects. This is typically needed in high-end AAA games which are based upon hardcore simulations where millions of objects are alive during each frame. In Unity you will hit a bottleneck just trying to transform this many Game Objects. Using classic ECS in Unity is stupid. That's because in Unity you already have something similar in the form of Game Objects and their components. IIRC in C# there is no clear way to optimize for cache hits. In raw C++ it might be worth the effort but in Unity it seems futile.

 

Ya that's basically what it comes down to. I can't stand ECS as a design, but if I stopped using every piece of software who's design I didn't like, I wouldn't get anything done. So where ECS gives me something useful I'll use it.

The biggest blocker right now is simply that ECS alone won't give you much over already well optimized code. Add jobs that changes. But until we get more api coverage Amdah's law is going to kick in a lot for quite a few people.

 

We already have a composition over inheritance take on our domain so it will be fun to see how easy we can move to the new system.

 

I know i link this a few times already but if you didn't have a look yet, Entitas is a pretty well made ECS framework. Whether or not you want to use it, it's an interesting framework with some nice video explaining Entitas and ECS in general.

The devs are also very responsive on the gitter chat if you have questions / concerns

 

That sounds like a personal opinion. It is promoted by Unity as a key performance enhancement, so one has to hope that they implement it in a way that it brings something to the table. We shall wait and see.

I believe that even the current 3rd party systems like the mentioned Entitas are increasing performance over standard Unity approach, but I do not know that for a fact.

I understand that you do not like ECS from a design perspective. Fair enough.

 

Is ECS an optimisation strategy or a game development style/architecture?

If it's an optimisation strategy then the 80/20 rule apples and you should only apply it when you find your games performance is slow and only where profiling finds that actual code causing the problem.

If it's a game development style/architecture then what advantages/disadvantages does it bring, for improved performance is your code more complex and harder to maintain?

OR are there styles of games that will just need ECS e.g. larger unit count games?

 

good questions! I do not consider myself an expert or anything and this is my personal opinion...
1) is ecs...? ---> both
2) 80/20 ---> also my opinion
3) style/architecture ---> this is were opinions will be different and I think you have to try it and decide for yourself
4) go back to 2)

edit: in case you have not seen this
https://forum.unity.com/threads/eta-on-c-job-system-and-new-ecs.512032/#post-3349526

 

Or we could do an ECS challenge?

 

Hmm, sounds like this is something I need to take a look at. I have a program which is not a game, but does involve simulating thousands upon thousands of agents usually of 2-4 different types. The max I've ever really done is 1 million, and that's because it takes 1 full second each iteration to process all the agents.

 

You might find it's not a magic wand. It can help you multi-thread the simulation for massive gains. However you really need to think of ways of pre-processing and batching the processes that act on the agents.

e.g.
A component based agent/NPC might have a number of states.

1. Resting
2. Moving
3. Pathfinding
4. Acting/Reacting
5. Hiding
6. Attacking
7. Defending
8. Eating
9. Healing
10. Thinking

Some of these might be in different LOD/LOC* categories depending on player proximity.

All of these functions, actions and processes will be taking place across multiple components from a central NPC component, e.g. Health, Navmesh, Animation, Audio, Physics, Transform, Collision, Weapons, Mood, Drives.

For ECS you want to be able to minimise the data for these actions/states and probably you will need to have sub-states/actions that only do small atomic actions quickly e.g. Line of Sight tests could be a separate sub-task.

Or more simply anywhere you have branching logic you might want to sub-batch the processes to improve performance and reduce data size.

*Level of Complexity, simulated or available actions depending on player proximity, simulation load.

 

Also maybe you should know that 18.1's job system does not use the Burst compiler coming out in 18.2...

From Here: https://forum.unity.com/threads/job-system-not-as-fast-as-mine-why-not.518374/#post-3397587

Interesting post where developer compares Parallel processing with Unity Job version and finds the Job system to be twice as slow!

 

This is true. But the job system will be awesome to drive the FSM for example and the Behavior tree. Where you have to tick one step, this distributed system will be good even if you trade some tight cache hit for more flexible decision making.
And if you can put your data to the low level (like the decision making will be if the FSM is in the state X the next step always state Y) then ECS and the job system will be pure gold. Maybe you will handle more data, but much quickly. And your job will be to decide if in your system it does worth it or not.

 

Where can I read up on this "new ECS" thing? I feel like a moron, people keep talking about it, but all I've been able to find is the Unite Austin Joachim Youtube video. Are there any examples projects / code snippets / docs / blog posts?

I downloaded 2018b9 and all I can add to a scene in the Editor appears to be GameObjects and MonoBehaviors -- my best guess is the new ECS is code-only and not (yet) easy to use in all the cases the old component system covers?

 

It’s interesting how we are essentially regressing back into C++ core principles. C# has the beauty of helping you along the way, but I also see it lure people into a false sense of understanding that hinders them from making “the jump up”.

I’m excited to see Unity stepping up their support for large-scale projects; this should eliminate some of the headaches that Unity posed in the past.

 

Unity ECS not out yet but @Joachim_Ante will have a better idea when!

 

https://www.mcvuk.com/development/e...ncipled-step-into-triple-a-performance-at-gdc

Why Unity is the only engine that makes sense.

 

Seeing this in Austin was pretty impressive. Not only the demo but the suggestion of entirely changing the way that you design and structure your code. Basically it was 'stop using inheritance if you want to go fast'. It made sense the way it was explained and the examples while they looked foreign at first seemed like something that you could definitely get on board with by the end of the talk.

It's probably going to take a couple of years to really see this make the splash that it can make but it definitely looks like a good way forward and is worth supporting.

 

Reminds me of the old C/C++ discussion about arrays of structures vs structures of arrays.
Keep in mind that the guy in the video is developing for consoles where performance is key.
Working with fat C++ code bases I can also understand the sense of simplicity this pattern promises. Just understand that this simplicity must be gained through knowledge, meaning you fully have to understand your data flow.
This will happen if your game is finished and all problems are already solved or else you will choose a path of no return.

If you don't already know what your game does, you cannot use it. It's performance optimization only. Pretty usable in specific cases, but replacing Monobehaviors? Would be Unity's death.

A nice thing would be some kind of precompiler step in Unity, where you can give some usage hints and it automatically uses ECS for some calculations.

 

Don't take offence - but I doubt you know much about Unity ECS and their plans, but that's not your fault obviously. That's something Unity will do a lot of documentation for. For a start a lot of studios use ECS because it is more flexible and faster. Blizzard for instance, uses it in Overwatch.

Unity's offer more benefits: near automatic networking and threading, and this code time saving alone is worth ECS IMHO. That is so much code you don't write because it's the right format by default and code you don't need to optimise much.

Also, Unity plan on hybrid ECS, full ECS and of course component-friendly ECS. Currently it's very work in progress so check back from time to time and you might very well be surprised. Also I think Unity really needs feedback and criticisms, they starve for it really.

 

If anyone is wondering and wants to try it, or learn more about Unity ECS go here: https://forum.unity.com/forums/entity-component-system-and-c-job-system.147/

 

The Unity videos I have watched so far make it look great for fast code that applys operations to a long list of items - particles, flocking, simple npcs etc. Making best use of cache, threading etc.

But in terms of general coding of larger projects I have seen nothing useful in ECS and it only looks to make things more painful. Am I wrong?

 

There are a lot of tech changes going on at Unity which is exciting for the future. But none of these in-progress developments have much in the way of tutorials or even easy to understand explanations as to what they are better or why people should go through the pain of early adoption. I guess it is all too early for that... but still I'm finding it difficult to wrap my head around ECS and what applicability it has for me.

 

My current project, a simple horror-survival-mystery game will use monobehaviour only because 1. it is pretty far along and 2. it has very simple systems in place, fixed inventory where items are either collected or not for use like keys and books. So it is a simple dictionary of objects with either true or false on whether you possess it in your inventory or not.

I have a total of 3 other projects (4 if I include a dream project of mine), two of them would benefit from ECS. One is a hybrid RPG/Strategy/Horror game and another is a Gritty Fantasy RPG.

They both could use ECS for better structure and performance. The other could also simply be monobehaviour as it is simple in game play and scope.

 

Personally, I really think it is possible to completely replace Monobehaviour, and using ECS for a player controller or GUI elements.

At first I was like a lot of people, didn't understand ECS, how and why use that design. But it is just a new way of thinking Easy to say, I know.

This GDC talk is good to see how to use ECS for small things :

Code wise, sure you will end up with a lot of files I think, but small files, doing only one thing, totally decoupled.

I don't pretend to understand 100% of ECS ... For example, I can't figured out how I can make something like a State Machine, and have an entity responding to state changes, etc.

 

Isn't a state machine (SM) just a struct with an enum set of possible states?

e.g.

Code (CSharp):

1. struct StateMachineNPC {
2.    enum eNPC { wander, chatting, hiding, fighting, fleeing }
3.    eNPC state;
4. }

You would then write a manager that takes the SM and other state related components e.g. health, sensors, weapons and updates the state.

 

Yes sure But I was thinking of something more fancy, with transition conditions, action when entering or leaving a state, on each update, etc.

 

@hippocoder: Please don't hate me, but I think I pretty much understand how this works. Following your link and reading the article about Survival Shooter reimplementation pretty much sums it up.

I'm looking forward to this in regard of performance critical tasks. I think it may be important here. And having the right tool set in these cases will be valuable.
It also may improve bad designed code by demanding a better understanding of what you do.

But Unity should not sacrifice its flexible GameObj/Component/Monobehavior system for it. As an addition to Unity, I'm looking forward to it. Let's see where this will lead us.

Actually I'm fumbling around with a tile based game where this might come quite handy...

 

Unity isn't sacrificing their existing system. ECS is just being provided as a way to achieve more from the engine. You're not even forced to choose between them as they can work together in the same project.

 

You could cover that with more states and code in the manager, think about it all those pre-post transitions are code triggered to run which can be done via function calls or in a managed approach via state changes. e.g. The trigger function adds a struct with an FSM link and the trigger type to a list that is managed by the FSM.

It's just another way of thinking about it you want to be processing batches of data for maximum throughput.

 

Thats good to hear, thx.

 

Yep fully optional. Unity would *love* you to have performance by default but it's understandable that a lot of people love how Unity works now and there's no danger or anything that of that being removed. Don't worry. The simple straightforward way you love to use Unity will be with us for a while yet, I'm assured!

I expect people will first start using ECS slightly, maybe hybrid to squeeze a bit more perf out. Or maybe full jobified for a very specific task like hundreds of little bullets or tanks in an RTS. It's not all or nothing, and you are in charge.

 

That approach is like wiring additional gigabit ethernet(ECS) together with megabit ethernet(MonoBehaviour).

Would MonoBehaviour get upgraded too?

 

You don't always need the most optimal solution. Just as an example you can still purchase motherboards with the old IBM PS/2 port which has an insane transfer rate of... 2KB/sec. Just to put that into perspective that's 20,000 times slower than USB 2.0 (which is itself over 60 times slower than a modern USB port).

Upgrading MonoBehaviour could very easily break a lot of games.

 

I'll fully admit that I may be missing something here, but:

Performance by default is a nice marketing term, but as @andyz said, it seems to me to be more accurately "Performance by default (if you do operations to a long list of items - particles, flocking, simple npcs etc)".

If you don't do those things (many games do, others don't, at least not extensively), it feels like it's more "add a ton more boilerplate code for similar performance".

I don't want to sound negative. I like that they're adding ECS. For certain types of games (very systems driven ones, with many interactions between them), it looks that it will add a ton of performance, and I like performance.

But overall, it seems of limited use.

Or I could be missing something.

 

In most games the 80/20 rule applies. 20% cares about performance 80% doesn't. And performance almost always comes at the cost of developer productivity. I'm talking about overall size of the codebase here.

In practice this is why rigid design patterns applied globally in high performance applications are almost never a good idea. You need a mix that takes into account both performance and productivity.

 

Missing everything since it's intended to even replace editor code one day... But that's great you mention this - it's Unity's job to convince us and show us why.

What helps is to head over to the ECS forum (link in first post) and tell them what might be confusing to understand so they can better make API choices or better see how to demonstrate the worth of it to you.