Question What is unity ECS? worth it?

Need to learn it?

Worth it to take few or few ten hours input it?

or can just neglect it and forget it and time save?

 

Why do you need to ask us? Unity has lots of information about it starting here: https://unity.com/ecs

It's a completely different way of developing games. Thought not every game needs it. It's up to you to evaluate whether your project should use it.

It's important to know ECS is one part of the larger DOTS stack: https://unity.com/dots

To use it you would also want to learn to use Burst and Jobs.

 

It's an interesting question. If you need thousands of simplistic objects roaming around then it might be easier and wiser to learn C++ and OpenGL or Direct3D rather than learn Burst, Jobs, DOTS and ECS.

I've never tried ECS, but the thought of running a game engine within a game engine doesn't really appeal to me. I'm hoping they'll eventually move it all into its own engine and editor and then I'll probably give it a go.

I suspect as we add more complexity to the entities then the performance gains over game objects will start to diminish.

 

Been there, I can guarantee C++ is NOT easier than Burst/Jobs. You wouldn't believe the sheer amount of work Burst and Jobs do for you that you'd have to do manually in C++: create and manage a thread pool, manually synchronize threads, learn to write SIMD intrinsics (of which you have multiple instruction sets depending on your target hardware, eg AVX, NEON, etc), deal with memory alignment issues, etc.

If you want to dive into multithreading / parallelism / high performance stuff, DOTS is by far both the easiest and more robust framework I've ever used, and I've used dozens - including my own C++ framework, which took years to write.

Not so much a "game engine within a game engine" but a different approach to processing the same data. It's worth it, imho.

Quite the opposite: as you increase complexity, the gap between ECS and GameObjects widens, and by a lot. Not because ECS gets faster the more complex your entities are, but because GameObjects get a lot slower. This is because the impact of inefficient memory accesses and zero parallelism you get with GameObjects becomes more pronounced the more data you need to juggle.

Don't want to sound like a fanboy, but if there's a piece of Unity I wish I could take away to other engines it would be Burst/Jobs. No doubt.

 

Yeah, as I understand, it's primarily a new programming paradigm. Data-oriented as opposed to object-oriented.

I've only played with the learning stuff but it's definitely a bit of a mind-f when you're so used to the way object-oriented works. My current project doesn't probably need DOTS as a whole, though might benefit from Burst and Jobs in some places.

But even outside of Unity I feel like more studios are taking the data-oriented approach. When I see the trailer for Monster Hunter Wilds showing 20x the number of monsters on screen, you wonder... are they doing some data-oriented stuff?

 

jobs and burst arent ecs, but ecs uses them, and can be used with game objects so you can use almost as much or as little as you need So yes, its worth it

 

The data-oriented approach has been around for ages, in fact it predates OOP. For instance most particle systems have used a data-oriented approach for as long as I can remember (late 90s). However the current trend is "hey, if this stuff is so efficient at handling large numbers of things, why not apply it everywhere"?

Imho there's a time and a place for data-oriented, same as there's a time and a place for object-oriented. The problem with the object-oriented approach is that it is comfy for the programmer, but very awkward for the computer. If you want your system to eventually scale to large amounts of data you need it to be as computer-friendly as possible, so in these cases going data-oriented is a no brainer.

Combining both is also practical in many cases: you can have an object-oriented abstraction for high level stuff in your game (managers, input, etc) and then go data-oriented for performance critical areas.

 

And this here is why OP needs to assess it for themselves.

Are they going to be scaling into large data? Yes... then start picking up ECS. No... stay where you're comfortable and make games.

Though at some point you probably will want to pick it up, as you grow as a developer. But that really hinges on your path.

 

I saw some ECS based system from youtube that codes is written at 0.5 ECS time.

So now many of them occurs errors now. (newest unity version, just before installed ECS by UPM name.)

So its completely not stable and low of resources when stuck?

I am afraid my time consuming how much amount to put it from 1 man dev learn new system that is not essential and no related, no helps, no meaning to end users.

 

Yeah I understand the general idea behind ECS. I've even created my own basic ECS system in C++ and OpenGL but I never got around to doing any multithreading. I suppose it could be argued that my system wasn't truly an ECS/DOTS system if it didn't have multithreading, but it still gained the benefits of using arrays that sit nicely within the CPU's cache and so the performance was obviously much better than Unity's game objects.

But I could see that if added more complex behavior to my entities that the performance was going to drop off. My system felt more like a programmable particle system more than a system for making interesting and intelligent characters, and so I can't help but view ECS/DOTS in the same way.

I'm sure I'll try it eventually. Your post gives me hope!

 

Yes! I started programming on the Commodore 64 (6510) and Commodore Amiga (68000) in assembly language. Everything was DOTS back then.

 

Using flat arrays to store data and zip trough them in a cache-friendly way is something you can do in any language, no need to use C++ for that. This is generally known as AoS (array of structs) and it can be viewed as a barebones data-oriented approach. However there's so much more stuff you can benefit from once your data is laid out this way.

One of these benefits is using vectorization/SIMD (single instruction, multiple data), which allows you to process your data in groups of 4, 8, or more items at a time, in a kind of single-core parallelism. This often requires your data to be laid out in a very specific way (aligned to multiples of a specific amount of bytes), and each CPU has its own set of SIMD instructions. Done right this gives you a x4 - x8 performance boost, even without any multithreading.

Then you add multithreading on top, and again if done right we are looking at another x8-ish performance boost. Put cache friendliness, vectorization and multithreading together and your code is easily over 50 times faster than a naive object-oriented equivalent, and much better prepared to deal with complex/large amounts of data.

GameObjects however are rather cache unfriendly (as data is scattered around and the system needs to follow a pointer conga line to access it), and make use of just one SIMD lane of one of your CPU's cores, leaving most of your computer's capabilities unused.

All this stuff -and some more- is what Burst/Jobs automatically does for you. If you have the time to look into it in the C++ side of things, I'd encourage you to. it's good knowledge to have under your belt!

 

That comes with the territory of writing code and making videos for software that was not yet marked ready for production. The API was in flux before they solidified things for 1.0. After that point, following semantic versioning, they don't [generally] make breaking changes, so code for 1.0.x should work on current 1.2.0.
There are some starting materials from Unity itself at the EntityComponentSystemSamples repository. Those are generally kept up to date.

If you don't have a problem with the technology you're using, it's probably not worth learning a completely different paradigm. Entities can solve scaling and design issues when used correctly, but it's not a magic bullet and it shouldn't be treated as such. I'd say just try going through the material in that sample repo if you're interested enough. It's usually a good idea to experience and mess around with something yourself so you get familiar with benefits and drawbacks before making a judgement call (know your enemy potential future toolset). The forums and especially the Discord (dots forum channel) are good community resources.

 

Yeah I agree. It's just that C++ has the best compilers.

 

Yeah fair cop. Not sure why I snuck that 'new' in their, considering I know it's the backbone of lots of old games.

As other folk's mentioned, it's up to you to evaluate if you need to learn it. It's not necessary to use the DOTS stack in either it's entirety, or its individual components, for a lot of games.

There are released games using DOTS, such as V-Rising and Hardspace Shipbreaker (and plenty more I imagine, those are just the two I know about), so to some capacity it's production ready.

And no surprise learning off old resources isn't going to work. Why didn't you look for current and up to date resources?

 

500+ games on Steam at least have the Entities package installed. More than I expected...

https://steamdb.info/tech/SDK/UnityEntities/

 

Unity recently ran videos info on dots as a whole, and are planning apparently to do more. Even they say, use what you need ..

https://learn.unity.com/tutorial/dots-bootcamp
there was another last week, but i cant find it...

 

Neglect it, like creators of ecs neglected it. (or fired-resigned idk)
Learn Data-Oriented Design, Job System, Burst, Compute Shaders, if you want to optimize your code or became a better programmer.
But stay away from Unity ECS.

 

It's been around for ages, but it didn't have a name until like 15 years ago when video game engine developers gave it the name "Data Oriented Design" and provided principles to define it.

This is the earliest article about it that I know of (dated 2009): https://gamesfromwithin.com/data-oriented-design

It's not a current trend. data-oriented design has always been very very useful beyond just performance. This is the biggest misconception people have about data-oriented design that it is just meant for performance. But it goes beyond that. For example, Blizzard used ECS for their 2016 game Overwatch to make their multiplayer game more deterministic and easier/simpler to implement compared to OOP. They go into detail about it at this GDC talk 5 years ago:

 

I was taught DOP at the university in 2004 (by the name “data-oriented programming”) in the context of web architectures, so I highly doubt the term was coined in 2009 by game engine developers.

Here’s an article on it from 2007, which refers to even earlier literature:
https://community.rti.com/sites/default/files/archive/Data-Oriented_Architecture.pdf

Here’s another article from around the time I learned about it:
https://adtmag.com/articles/2004/08/05/data-integration-a-little-dop-might-do-you.aspx

 

Citation needed

 

Oh wow. I stand corrected. Going to geek out on that first link you sent. Thanks for sharing.

 

What is the purpose of the image? I said "neglected it" not "abandoned it".
And inexistence of animation and audio solution should be enough of proof I guess.

 

To show they say they’re working on it. That they have plans indicates they work on something in the sphere, it’s not fair to say they’re neglecting entities overall. No excuse for audio, but they keep reiterating that things are happening for animation.

 

More up to date videos exist :

https://youtube.com/playlist?list=PL6ubahbodJ3OMKeICEIfVE268GGzGLkoU&si=Nvqz7zQuBtq76Cpr

 

Whenever I use Unity 2022 LTS and Entities 1.x I get plagued with warnings. I'm sure it has no impact to the stability of everything but its incredibly annoying.

With Unity 2021 LTS and Entities 0.51 I get no warnings. Everything just seems to work without issues.

There were some fairly major changes from 0.51 to 1.x so I'm guessing they are still ironing out all the issues.

 

Yes I first saw that guy's 0.5 ECS based [Buff System] video, so trying to adopt it and met 10 over errors when import his code into current newest ECS environment.

So then it means I should also learn what is wrong and what code should be revised from 0.5 to 1.0 now other than ECS system itself.

It feels it requires quite time to learn and debug his code...

So I just want to know normal RPG's buff system, of course I can implement it without knowing ECS, but I started to search new possible another system, to know ECS finally, this is disease of programmer.

 

Then I recommend to have a look at

 

Why did you not just start learning from an up to date tutorial? Why did you try do an old tutorial and then apply that to a current version? Why did you think any of that was going to end well?

 

ok, thats the one thing I forgot, so learn from current tutorial, then apply it to my own or that guy's Buff system...

How many hours it will take me?

Already I implemented my own Buff system with just normal class, list, startcoroutine within 2 hours.

So here come my original question... do I need to learn the ECS system? to make re-invent Buff system or other system?

 

And we've told you multiple times, you need to evaluate that yourself. ECS solves particular problems. Do you have those problems? Do you understand what problems ECS solves?

 

And to add to this, do you also understand where ECS is suitable, not all build targets work well

 

No, I don't know what ECS can solve what problems.

 

And so you've come to the forums to get a quick summary of the potential issues and you wisely posted outside of the ECS forum to avoid the ECS evangelists and possibly get feedback from people that have tried ECS and given up. But you got shunted over to the ECS forum where you're now being given a hard time..

I sympathize!

 

So you're looking for solutions to a problem that you don't have?

My advice would be to just get your game running using whichever method you're comfortable with. Once you find a problem (be it a performance problem, ease of maintenance problem, whatever) look for solutions to it. Shoehorning a specific paradigm / architectural design into your project just for the sake of it is bound to frustrate you, slow down development, and just create problems where there were none.

If you want to learn ECS/Burst/Jobs just to have another tool under your belt, go ahead. But use a small test project to get a feel for them, don't start refactoring your main project just yet as you could end up finding they're not good tools for whatever you're working on.

 

ok, fine.

I used not to know well and adopt URP at past few years ago, unity invented some good graphic system, and few years later they changed something fundamentally at URP and my URP game F***ed because it can't be upgraded or updated to newest unity because URP core code changed, my game's graphic does not shown at all.

Unity provided some function that update URP version, but it did not worked, so I given up.

Maybe similar principle at this time too? I am afraid to adopt new tech now.

 

This can (and likely will) happen to any software you use, things evolve over time.

This is why you should stick to a specific Unity version for the duration of your game’s development. It is generally a bad idea to migrate mid-project to another version of basically anything your project uses, at best you risk introducing new bugs, at worst you risk the need to refactor or rewrite large chunks of your codebase. If you’re a large company this is doable, if you’re a solo developer this can end up killing your project. So do yourself a favor and stick to whatever works, for as long as it works.

Every project I’ve ever been a part of that decided to migrate stuff to a new version (regardless of engine/middleware used) ended up requiring way, *way* more work than anticipated.

 

You can't avoid that. The general concensus in software development is that major versions can introduce breaking changes. Otherwise they will be stucked in the ever growing pile of technical debts.

Even the ECS team has hinted that we should anticipate many breaking changes for version 2.0.

 

I think this is bad advice. The last big project I worked on was upgraded around 17 times throughout development. (This only includes full-team upgrade attempts that made it to the repo. There were also countless package upgrades.)

To me it seems very likely that sticking to a Unity version from 5 years ago would have either killed the game, or forced us to cut features.

I think people are irrationally afraid of upgrading Unity every few months. Staying on a recent version requires very little time investment, unless you procrastinate for a few years and then find yourself trying to upgrade 20 packages in a move from Unity 2018 to Unity 2023.

 

Are you currently able to make games without it? Are you running into any major issues that could be solved by having your code run faster? Because that's what ECS is for: high performance.

 

2021 unity URP graphic based game does not shown any graphic at newest version now. All URP graphic UI, monsters, characters, stages F***ed.