1. 12
  1.  

  2. 1

    Be careful with ECS, you may be infringing on Unity’s new patent on ECS memory layouts: https://pdfpiw.uspto.gov/.piw?PageNum=0&docid=10599560

    1. 1

      I haven’t ever done anything with entity-component systems. I am curious about how broadly this could be applied.

      So I understand you having an entity and you give it a position, so presumably this component is like a property of the entity. So why not just give the entity a position directly?

      1. 1

        There’s a few reasons. On the software engineering side of things, it avoids a lot of issues where class hierarchies are too rigid or code becomes too tightly coupled, but there are also performance benefits which is largely why the game development universe is so into the idea.

        If you have a system that is calculating collisions, for example, perhaps you only need that position to do the calculation. If you “just” give the entity a position “directly” (assuming Entity is a class and you just jam fields in there), then you will also “just” give it other things directly, and eventually it grows to have a huge number of fields. So, your collision algorithm is scanning huge chunks of fragmented memory only to read a single position variable, which is extremely cache-inefficient.

        In contrast, with an ECS you can implement that so that scanning all of the positions is just a linear scan of a contiguous array. Depending on the data type it may even be vectorized. The way you realize this is to not make the component a property of the entity in the sense that it is stored “in” the entity, but to instead store the components by type, completely separate from entities, and associate them with IDs. In the simplest ideal vision, there is no Entity class at all, an entity is simply an integer.

        1. 1

          In contrast, with an ECS you can implement that so that scanning all of the positions is just a linear scan of a contiguous array. Depending on the data type it may even be vectorized.

          I definitely get this along with the cache argument.

          The thing I am not really sure about is perhaps more generally, outside of games. I don’t really do game design, but I do things with web applications (angular).

          1. 1

            It’s a technique that’s mainly for performance–it also is kinda specific to languages (read: C/C++/Java/C#) that don’t have an easy way of doing dynamic compositions/mixins. Like, in Ruby or JS I don’t think it’s as big a win.

        2. 1

          Its a framework that helps reinforce a good separation of concerns. You can mix and match any type of components across your entities, and your systems only care about their specific types of components. It’s a lifesaver in instances where you need an oddball case later in development. “Gee, I really need this Sword Item class to be able to talk to the player, but only the Character class has “Talk()”! Rather than trying to figure out how to shoehorn your Sword into a different class hierarchy, you would start by just adding a Talk component to the Sword entity.

          It flattens out the logic, any “thing” in your world has the capability to do any action.