Chill is a bit of a stretchy definition for this one, (e.g. Celeste might be a cozy adventure but rarely chill gameplay, Owlboy is also very hype)
but they are at least generally in the chill-comfy-cozy zone for much of their runtime
entity: a unique id and a collection of components
component: a data container
query: a way to gather collections of entities that match some criteria, for use in systems.
prefab: a pre-defined collection of components and even other prefabs to quickly build entities
event: a message to an entity and it's components
This library is heavily inspired by ECS in Caves of Qud. A true ECS library with entities only being ID numbers
One of the advantages of an ECS architecture is that you are running your systems over only entities that those systems apply to which helps support a large number of entities at once.
If you're putting everything into an ECS system you'd still expect most of your walls to have very few components. For example they may have a render component, materials component, and a position component. Meanwhile a lot of your systems would apply to components that walls don't possess, like an AI component, a velocity component, etc. So if your ECS system stores components in a way that either caches a list of entities with that component or stores the component information in way where iterating over all entities with that component won't iterate over entities without that component you shouldn't see significant slowdown in that respect.
That said where you would see slowdown in this example is in doing things like calculating collision or computing line of sight. If your look-up for whether a tile is blocking is get all entities at position -> check each entity for a 'blocks sight' component then you're doing a lot of legwork for something that's already computationally expensive. If you have to do that every time an entity is trying to answer a question like "can I see x tile" or "can I move to y tile" that's going to sink your performance.
I think what you'd need to do in that case is plan ahead for this type of work build structures on top to help. For example you may build a component for static collision blockers (for entities that don't move or disappear often) and whenever an entity gains/loses that component or is added/removed with that component you recalculate a base collision map as a 1d/2d/3d boolean (or enum) array. That way you'd have that data already computed and when you need to do something like pathfinding you can use the pre-computed data structure rather than having to query a lot of information from the ECS system every time. Then if you need dynamic collision on top of that (for entities that move often) you could use a second component for that but it would be a much smaller amount of entities that you'd be looking at to incorporate that data.
FoldFold allExpandExpand allAre you sure you want to delete this link?Are you sure you want to delete this tag?
The personal, minimalist, super-fast, database free, bookmarking service by the Shaarli community