I’ve been playing BloonTD 6 on both mobile and PC. It’s a tower defense game with MASSIVE entity count.
IMO, the devs should have had already implemented some kind of ecs already. Otherwise they should not be able to squeeze this much performance out of the game.
Another one is the popular POE with its various forbidden builds lol
Any game is good fit with ECS. When they are done the worst case scenario is/will be/should be that you get the same performance (or slightly higher, since a lot of subsystems will be more efficient) than in GO world. And then depending what you’re doing, you can get more efficient than in GOs.
For example, Visual novel games or games like VRChat, Among us, where you don’t have to worry about performance much, the added complexity and overhead of ECS is not worth it imo. I doubt Unity could make ECS as easy and as intuitive as GO/OOP world.
Okay, so then for the 1000th time: ECS isn’t (just) about performance. It’s a nice effect of it, but it’s not solely about that. It’s about how you organize your data and how you plan your data flow. Every game is a good fit, because all games are software. Software is a tool to transform data, create data flow. ECS is excellent to create great data flows because it was made for that. Modelling data organization to maximize data flow and minimize clutter.
There is no complexity and overhead. It’s only in your head. It seems complex for you because you haven’t used it much. When a newbie sits down in the front of Unity, the GO workflow is just as scary and complex and seems unnecessarily overengineered as ECS seems for you. It’s just a matter of experience and practice. Also, we’re humans. We tend to resist change. Change is strange for us and something we want to avoid at fairly high cost.
If you want to talk about overhead though, just look at game objects and the overhead of every single unnecessary data transactions you are making while you’re working with GOs. ECS is about minimizing those transactions.
For you maybe. But you really need to think about it, why.
Easiness and intuitiveness are highly personal and subjective concepts. And if you don’t believe in that they are capable of making it right for most use-cases and most people, then we really don’t have anything to talk about.
Why did this thread suddenly turn into you trying to educated me on ECS? 
Some people just don’t like to think like a machine you know? People can have preference. There is no need to be condescending.
You also don’t need to convince me on the product that is not out yet. I will evaluate it myself once it’s finished. 
I’m sorry if you feel that way. But I don’t think I was condescending and my intention wasn’t that for sure. You made a couple blanket statements what gave me the impression that you don’t really understand what ECS is and isn’t about.
Obviously you can have preference, but then it’s not about the tool we’re talking about, but it’s about your taste. Discussing people’s preference or taste is not really interesting or produce any interesting results.
Again, sorry if my answer offended you.
Hi, I’d like to weigh on that. I originally learned C++ by myself (with some friends in high school), making small game engines for fun. When I discovered Unity in gamedev school, I felt overwelmed by all the UI as I was so much used to do everything in code and data files. It did felt unnecessary at the time and I went on using my own “all code” engine for my personnal project for a long time. GO workflow is complex and scary. Now off course I’m used to it and it’s DOTS that’s scary to me (as I haven’t had enough time to discover it), and I hope to change that once ECS is more “ready”.
Having implemented a small c++ ECS framework (to actually understand ECS), I am convinced it is adapted for any game you’d want to make, even more if you consider you can actually mix ECS and classical OOP, or DOTS with GO.
Also, I’d like to point out something I think is important. It is that performance is not only a matter of player experience.
I think the people behind AmongUs might be happy if their server would get more performant (with or without DOTS), since it might mean a decrease in server hosting costs.
And last but not least, there’s the energetic efficiency. From the point of view of mobile battery, but also for the general usage of electricity. Computing stuff costs A LOT of energy to our societies.
From an energetic and environmental stand point, it is utterly stupid to use an algorithm using up, say, 1 second to produce a set of data, when it is “easily” possible to use another algorithm to produce the same set of data, using up only 100ms. Yet we all do that on a daily basis when we implement suboptimal algorithm.
I dont try to offend anyone, just to give a another proposition for look on this topic
That parcially true.
Yes how you write your personal hobbystic project is only to you to decide BUT:
-how many asset can work witch dots?
-how many other programmers that work on this project can understand ECS?
-is actual version of dots had alll necessary mecahnics for this game to work (for example TD how effective do det. of enemy in range?)
You must answer this questions before decide if this game will work good witch ECS/DOTS.
This question can be correct if you ask what is NOW WORTH doing on DOTS (or where dots will show greatest growth and power)
Saying ‘Every game is a good fit, because all games are software.’ you can use not only for ECS but also for assembler or C language and effect will be better but not time coefficent.
Better than putting this topic to trashcan is giving idea for projects that are possible (and not much time consuming) on DOTS and showing how great power it had (even if you will not earn from this project you must find a way to show others how great power is hiding by coding that way).
I will clarify my statement; ECS added complexity because the way it work and how you organize data is different than how human think(we need to think like a computer). By overhead, I meant dev overhead(you assume I meant performance overhead which I was not, but this is sadly a miscommunication on my part ), because we need to implement a lot of common game engine features or even a language feature like “event” ourselves. Unity might be able to solve it in the future with their DOTS and prove me wrong which I will be very grateful for. As it is right now? People are never going to adopt ECS. Unity even admit it themselves and it’s probably the main reason that they delay it for so long.
What is this thing about how we think, as far as I’m aware there’s not some specific ways humans think. Machines don’t think at all, they just run through whatever code you give them according to the compilers rules.
Personally I find OOP difficult to think in, especially when trying to define abstract things in that have no obvious object equivalent, and even when there is I find it difficult to define the exact boundary’s of those objects.
How would we have even written code in assembly originally as its supposedly not at all how we think. Or maybe its like the brain is extremely malleable and can think in many different ways, they just take patience and practice.
There’s two things at play here. First, there’s the core Entities package. While it still has some rough spots, it is very usable. People who think things don’t fit well with it are typically struggling with the paradigm shift. People are wired differently. Some people really struggle, and some don’t struggle at all. Some people use a “guess and check” methodology when writing code (which lends well to GameObjects) while others like myself try to understand everything before writing a single line of code (which works much better in ECS). People who get stuck on this part need to do some self-reflection about what they want to be and accomplish as a programmer.
Then there’s the higher-level features such as rendering and physics and animation. This is much rougher waters, and it is where a lot of experienced devs stop and re-evaluate. A lot of your mileage will depend on how many custom engine-level systems you are willing to write, and how many community solutions you are willing to bring into your project.
Right now, animation, AI, and audio are lacking. But there are a few solutions out there for animation and AI (especially pathfiniding) and I personally have made an audio solution available.
Based on all that, high action games which don’t require complex animations map really well. Aerial shooters and bullet hells fall into this category. Also simulation-style games work well, especially ones involving agriculture (very specific, I know).
I blame the 90-ies and the mainstream emergence of OOP/OOD and the gang of four. (Okay, not them personally, but the monster they unleashed) Unfortunately people started to follow paradigms religiously and started to look down on methods, techniques and paradigms which isn’t canonical.
And then they teach programming through the mindless, valueless method of “take animal, make chicken a descendant of it and voila’ OOP”. In actual schools where they supposed to teach development and programming.
You end up with single-minded people, who take offense when someone propose a different algorithm, let alone paradigm.
It me! That is how I thought myself C64 Basic back in the days in the 80-ies. Served me well, although since then I’m employing more mindful methods as well.
And, just to be sure and all that: whatever I write on these forums is just my opinion. I’m not a programmer-god who can tell you what to do and I don’t want to do that. Just sharing thoughts. So imagine an IMHO next to all of my sentences.
Also, do not think that I don’t use OOD at all, I’m advocating against any type of separation of DOTS/GO. I think it is important to these two remain together and interoperability should be a thing. There are things easier to make that way and really don’t worth to implement in DOTS-way. One always choose the right tool for their problem.
Can you give an example of solution that is usually solvable by design patterns but should be done by non orthodox way ?
I agree that schools are bad at teaching practical things. But even I had to transition from an OOP mindset to a DoD one. I made that transition fast, because the way I reason about problems involves being able to ingest a large amount of context at once. Some people aren’t able to handle such a large context at once, so the abstraction and encapsulation that OOP provides allows them to reason about things without being overwhelmed. Some people transition quickly, and some slowly. And some don’t transition at all. In no way can I blame the education system for that.
The only blame I can put on anyone is if you are single-minded and unwilling to learn a new thing at your own pace, yet simultaneously blame others for your problems, then that’s your own fault and a red flag you are incompetent as a developer (I’m not implying anyone in particular).
But in general, it is good practice to use the right tool for the job. And familiarity, comfort, and personality are factors worth considering. The good news is Unity is offering options.
I had the exact opposite experience - c-64 assembly = first programming experience and DOTS was the first time, I felt home again…I have to admit, I only toyed around with dots the first few months and now only follow the forums…I feel I have not missed much and look forward to picking it up again, when it’s just a bit more mature…
Personally I would put the blame on teaching, at least in the UK. Generally they aren’t about teaching you how to learn. They don’t encourage, it they, almost actively disincourage learning, they almost make it painful at certain points, they make you rote learn pointless facts, they make you learn to the test, which is the antithesis of programming in my opinion. No wonder after going through that people become unwilling to learn.
Not necessarily a lot of the ‘entities’ are probably particle systems e.g. bullets/swarms.
Also although there are a lot of things on screen (in the games you mention) I think there are probably < 2k none particle entities and GOs and a Batch based approach.
Running in Editor (so very low numbers compared to native PC).
I wrote a quick benchmark to compare Update vs Batched vs Jobs and as you can see < 2k cubes gets > 140 fps using individual GO components with their own Update() method. A bit better performance with a Manged Batched approach (one update updating an array of entities data) and the overhead of using Jobs does not kick in Until much higher entity counts.
The biggest performance factor is the rendering process as other have stated the instance-ing and Graphics.DrawMesh API calls ensure the rendering pipeline is not the bottleneck.
Or think of it another way our CPUs run at 2-5 Ghz that’s 2-5,000,000,000 operations a second or 2-5 million per a millisecond so moving a few thousand things in games within a 4ms time window is very easy.
It’s not about how many ops a second you can do when the traffic lights are red and you’re waiting for the memory train to go by.
Good point so it’s more memory/ram bandwidth to cache efficiency.
My point is how many games max out modern CPUs?
It’s much more likely that the graphics and rendering is the bottleneck even on high end games especially with higher and higher resolutions >4k and refresh rates >200hz. The only games that probably push the CPU really hard are huge entity count or complex simulations.
It is actually quite easy to max out the CPU if the code is inefficient. That’s often the case with classical Unity games. But it also happens in AAA in C++ engines. However, if you have efficient CPU code, then you are almost always GPU-bound. And you should be thinking how to use that extra CPU power to reduce the GPU load.