I am putting the finishing touches on my engine and I have a question about whether or not is is useful (to the general gamedev population) to have the "entity" abstraction as part of the entity component system.

In the current version of my system, the entity is just an ID, components are stored in packed arrays, and components can be a member of more than one entity. The "engine" is just a collection of arrays for the different component types. All logic is implemented in systems that can each modify the contents of the engine in their update() method. I have a prefab system similar to Unity that allows instancing of premade collections of resources. Each prefab instance gets associated with an entity ID in the engine when it is created.

I am thinking about removing the entity concept because it would greatly simplify the bookkeeping and make the overall architecture much simpler. In that case, there wouldn't be any explicit mechanism for grouping components together - the engine would just be a big unordered collection of resources that are part of the current simulation. This seems like it would work for my use cases but maybe I am not foreseeing all common needs (since I'm mostly a low level tech developer). I can envision a scenario where a user script might need to access sibling components of the same prefab instance, is this a common need? Or should I just require the user to explicitly link components via resource references so that the script could later access them?

Binding different components together using an entity is almost the entire point of the system. It's about having different data and functionalities, and bundling that together in a way with minimal memory, runtime and abstraction overhead (the opposite of which would be huge inheritance trees).

In practical terms it's because too much code will need it. Have an animation system and a combat system? Well, if my character is hit (which inevitably ends up modifying that combat component somehow, which probably contains all the stats like HP, armor, damage, etc.) I'd like to use the animation system to set up a response for that particular character, which will in the end modify that particular animation component. Get the combat component and animation component using the entity... ez pz. Stuff like that.

If you're viewing this from a low-level perspective, it's easy to get the impression that you're mostly dealing with independent systems. A physics engine, that takes care of all its own stuff, a renderer that doesn't care about what happens on the outside, why would an audio system require outside components ever?? etc...

But that's not what ECS is really for (big IMO). It's about that part of the code above that which uses all these systems and bundles them together to make a game with it.

edit: Remember that a big part of the complexity of ECS is also requirements like being able to attach and detach components at runtime, being able to do data-driven stuff, etc... So in the end those users of your component system will just end up with similarly complex abstraction layers which tie this stuff together at runtime.

Thanks for all of the input. It's clear that I still need some way to group related components, and that hierarchies of entities should be allowed. I think I will use Hodgman's idea of treating entities as just another component type. This allows me to get rid of the cumbersome entity-as-an-ID approach, and also allows multiple entity types and hierarchies of entities to exist. It also fits well into my existing prefab system.

Then the systems that operate on entities can go engine.getComponents<MyEntityType>() to access the current entities of a given type in the engine, the same as any other component type. The entity is just a list of pointers to components in this case, so it is easy to access child components with a certain type or name.

If the compnents arent associated in some way, how would you know which transform component to get the position from when rendering the mesh component (or render component or whatever it may be called)

For example - many systems will probably need the position information for things in the game in order to do anything useful - would you store a copy of this in each component? If so, then why have "components" at all?

For this particular case, I do indeed store the transforms separately for graphics/physics/sound objects. Communication between the components is implemented using a data flow graph that is processed by the engine before and after each system update. Data flow connections can have various types (trajectories (transform+derivative), tensors (scalar/vector/matrix values), sound, image, etc.), and can be updated at a user-defined rate (e.g. 60Hz, 1Hz, or only at build time). For example, to control a graphics object using the transform from a physics object, the "transform" output of the physics object is connected to the "transform" input of the graphics object. After the physics simulation update, the physics object writes to the connection's local transform storage, then before graphics rendering the graphics object reads the transform.

What's the purpose of sharing components among entities? How do you track lifetime of the component?

I don't have a good answer for the first question. I guess I don't want to place unnecessary restrictions on how the components can be used.

Components are stored in an object called a ResourceSet that is a container of arbitrary resource/component types and is also the in-memory representation of my engine's file format. Components are loaded from disk into a ResourceSet, and can then be instantiated within an engine simulation context. The engine holds raw pointers to the components and doesn't care about the object lifetimes, components can be added directly to the engine, or a copy can be created (stored in another ResourceSet that contains only runtime instantiated data). If a component is shared among multiple entities, its reference count within the engine tracks the number of entities using the component. When the reference count goes to zero, the component is removed from the engine (but not deallocated). The object instancing system is higher-level and built on top of the engine and manages the lifetime of the ResourceSet(s).