Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

http://t-machine.org/index.php/2007/09/03/entity-systems-are...

ECS builds on top of some of the ideas of COM and GameObject/Component, but loses much of the baggage, takes it much further in a different direction, and has a lot of other advantages, like storing the data in separate contiguous cache-friendly buffers.

https://en.wikipedia.org/wiki/Entity_component_system

>In naïve ECS implementations, every system iterates through the complete list of all entities, and selects only those entities that are needed. The total iteration cost for all systems becomes too costly if the number of systems grows or the number of entities is large. In other ECS architectures, every component type is stored in a separate list, so whatever systems operate on a given type of component are only iterating over objects they care about by default. In this common ECS architecture, the described disadvantage actually becomes a major performance advantage, by more efficiently leveraging the CPU instruction and data caches.

http://t-machine.org/index.php/2014/03/08/data-structures-fo...

>Net effect: Contiguous memory is King

>If you store your data contiguously in RAM, it’ll be fast onto the Bus, the CPU will pre-fetch it, and it’ll remain in cache long enough for the CPU(s) to use it with no extra delays.

>NB: this is independent of the programming-language you’re using. In C/C++ you can directly control the data flow, and manually optimize CPU-caching – but whatever language you use, it’ll be compiled down to something similar. Careful selection and use of data-structures will improve CPU/cache performance in almost all languages

Also:

Entity–component–system (ECS) back and forth (skypjack.github.io):

https://news.ycombinator.com/item?id=19166910

Entity Component System Framework that is CPU cache friendly:

https://stackoverflow.com/questions/23473783/entity-componen...

Designing a cache-friendly entity component system:

https://cerulean-skies.com/index.php?article=1

Unity is rolling out a new officially supported entity component system that's a totally different stack than GameObject/Component. (But they interoperate, of course.)

https://docs.unity3d.com/Packages/com.unity.entities@0.1/man...

One (but not the only) fundamental difference between COM and GameObject/Component, is that you query for COM interfaces with an interface GUID, so you can only have one interface on an object for each GUID. But Unity lets you slap as many of the same component class on an object as you like. The singular Component GetComponent() method will just return the first one, but the plural Component[] gameObject.GetComponents() returns an array of all the components of the given class.

For example, it is useful to attach several different Colliders to the same GameObject (each with its own position/size/shape/etc). They all just work together as you would expect. A RaycastHit will identify which Collider was hit, as well as the sibling Transform of the GameObject it was attached to.

Another fundamental difference is that with GameObject/Component, each GameObject and component is always a completely separate independent object, but COM allows the implementation class to implement any number of different interfaces with the same instance (using C++ multiple inheritance, so each interface implementation has its own vtable pointing back to the same implementation class's different methods), or delegate to other sub-objects using "aggregation", or even make sub-objects lazily on demand with "tear-off interfaces".