I want to notice that performance is not main ECS advantage, main advantage of ECS is flexibility and scalability, due everything is data and you can easily change how data flow is working.
i dont get it ... is entities like data/metadata components basicly like methods or actions and system is more like a la "MovementSystem" "SpriteSystem" "TileSystem" "AudioSystem" etc.. for example... im trying to learn this thing... and doing research, what i have to learn and know to build a browser game,... Basicly i want to build a webbased tick or ws game.. like planetarion and darkgalaxy years ago.... i kind of liked these "background games" u could play if u dont have much time.. or on the side when you have 10-15min time and nothing to do at work... also seems Vue is very interactive and 2way databinding is supercool in that frameworks, was thinking of that... but it somehow feels really weirtd to use a web freamework for a game... (eventho those type of games almost aare like basicly websites where u just push tables and data haha, they're not that complex you know... my goal is to make more complex and "lively" one.... an inspioration to me is that game -> www.landsoflords.com i love how the map is... and how there's some RP elements in the game, wich reminds me of CK2/3 .. characters, coat of arms, hierarchy/titles etc....
Thank you so much for explaining this concept. For a while now i have wanted to start creating my own game and every couple of steps I come across a hurdle that makes me want to redesign the entire system. The largest hurdle has been the fact that inheritance just doesn't always allow for things. as explained, a duck is both a mammal and a bird so it makes sense to inherit from both of them, but an interface doesn't allow for me to define any code so I would have to write the same code twice in two different classes if i was to implement an interface so this method seems super logical in a game development environment.
Storing an entity's attributes all in the same place is *not* more efficient. It all depends on the access pattern. If you're not always going to access all attributes (highly likely), you waste cache lines for unused data and hinders vectorization. It is better to split up the data in a way that matches the access pattern. For example: You're doing a lot of checks on entity positions? Store all entity positions in a giant array.
Can you make a series on dialogue? I always wondered how developers make such advanced dialogue systems. For example night in the woods, Oxenfree or any visual novel game, how do you manage so much text, different choices and outcomes? I imagine you don't type everything out in the inspector. There are ZERO tutorials on this. Ty, and great content as always.
As a hobby I've begun scripting such a system. I've been heavily using Scriptable Objects to do so, however a full on database or Excel sheet is more appropriate for large projects. I'm focusing on how player dialogue choices can affect gameplay and are only presented as dialogue choices based on previous gameplay. Difficult to architect in a way that is loosely coupled.
You should check out ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Qsiu-zzDYww.html, it's the Night in the Woods devs talking about their dialogue system
Regarding the example brought up at <a href="#" class="seekto" data-time="205">3:25</a> (and revisited again at <a href="#" class="seekto" data-time="276">4:36</a>), I don't see how this is an inherent advantage of ECS, it seems like it is just a difference in how the components are modelled using each approach (GameObjects vs ECS). If the Transform "component" used on GameObjects is bloated with all these additional fields, couldn't it just be replaced with a lightweight one modelled like the one shown in the example for ECS?
i've been trying to understand entity component system, so from what i understand 1. entity [A]: an entity can refers to an game object in our scene, and this entity holds components ( attachComponent( entity=A, component=B) ) 2. component [B]: a component has no method, only provide set of data, think of a "struct" in c language 3. system [C] : system acts on components, they provide methods that can alter entity's component in expected manner, ex: so a system "C" that may increase speed attribute defined in component B can be used as follow : applySystemOnEntity(entity = A, system = C)
This is kinda random, but your infographic has told me more about the 'flyweight' pattern than the Wikipedia page for it and any explanations I could find by googling.
The Only Thing I Needed for "Entity-Component-System" is The Description The Thing That You Playing The Game and The NPC That Destroys You Player is Protagonist NPC as Enemy is Antagonist That's The Thing I Wanna Know
I think that thing about memory is not about the storage of the entity but about the fact that you are doing all the logic in order. Like, first you do all your rotation transforms then you might do all your draws and so you get better performance because you are doing many similar operations in a row. I may be wrong though, I'm new to this as well
The memory layout of your data has massive implications on CPU performance. It has nothing to do with the similarity of sequential operations, but with how those operations access your memory. The classic OO approach and even most ECS mostly concern themselves with readability and the organization of code rather than performance. If you care about performance then you want to think about data-structures and algorithms first, including memory layout.
@@clickrush When we're talking about memory layout, I assume it's always best for the data to be laid out sequentially in the order it is accessed? Also, I don't know if I'm missing something, but it seems like caching is always done automatically by the CPU and we don't really control how that works right?
Thank GOD! I’ve long been frustrated with the overhead of the GameObject-Component system that’s been the hallmark of Unity. I wish I had this ages ago.
Can someone explain the tag thing? How can i dynamically know which components exist or are valid for each entity? Also i don't understand how that solves the issue of whether a component exists, given it is stored in a separate array.
As an aspiring Unity developer who got into programming 2 years ago, I am ready to start learning ECS. If Unity devs insist that ECS is just flat out better than OOP, than let's use the better way to write code! It looks to me like no one has a ton of experience with ECS, not even seasoned developers. That means that people will be motivated to start making lot's of tutorials for it, it will be a hot new thing, everyone will be googling it, and every RU-vidr will be covering it. Exciting time to be a beginner programmer. 😃
A lot of gamedevs already have experience with it. This is not some new thing Unity invented, ECS and job system are already common in game development. Even Unity already had an ECS library, Entitas, which some game studios have used.
For ten years, I could not code. I always imagined how code must work, and in my mind, I always imagined an ECS system. OOP to me has never really made much sense. It always seemed so inefficient. I can code now, but still, I am always trying to make ECS like systems, (such as the AI I am working on). Part of that may be because I always imagined making strategy games. I never, have ever imagined making games with only a couple hundred entities calling the cpu/gpu at once.
He explained that ECS still integrates OOP in some ways at the early part of the video. However, it seems like you have to choose one way or the other if you want the whole project to be consistent.
OOP isn't compatible with ECS, literally. OOP uses vtables which contain references to instance structs, which means your memory still isn't centralized and you'll get cache misses.
It's worth noting that it's common practice with component based design in object oriented programming as well! Not all OO designs are great huge inheritance hierarchies.
Very true - it’s basically what the original GameObject/Component architecture does in an OO context. It’s just being taken to the extreme for optimization purposes now.
@@BoardToBitsGames And I think a certain distinction is that the Object owns it's data _and_ behaviour, whereas the encapsulation is opened up in ECS with behaviour in the system and data in the components, no?
