I read that, in an ECS, the components an entity has basically define what that entity does and is capable of doing through data. But I'm unsure as to one detail in the implementation. Say, for example, that an entity, in this case, a character like a monster or the player, can float if it has the Floating component. Should I give entities this Floating component only if they ought to float, and remove it when they shouldn't float, ie. when a buff is applied that grants the 'Floating' status effect, the component is added to the entity, and then when the buff runs out, the component is removed? Or should I give all entities that could possibly float (in this case, all the entities that represent characters) the Floating component, and use a bool inside the component to determine whether that character should actually have the floating effect applied to it or not? It seems like both could work. But which one would be more appropriate?
Entity component systems
If you're following the principles of data-oriented design, which is somewhat associated with entity-component-system designs, then you would add the Floating component only for entities that are currently floating, remove them if the entity is no longer floating, and avoid the bool flag altogether. I've seen this referred to as "existence based processing".
Should I give entities this Floating component only if they ought to float, and remove it when they shouldn't float
I'm sure some people disagree with me here, but I'd say very strongly "no" to this. Micro-components are a pain in the butt. You don't need one component for each boolean or tweakable value. Floating is a behavior of physics in that the gravity is turned off (or way down) for the character. Just give your Physics component a GravityScale or the like and then adjust that as needed from buffs.
There's a balancing act in a sensible, maintainable, featureful engine between components that are too small (requiring you to write tons of boilerplate and coupling) and components that are too big (with all the usual disadvantages of non-modular code that components are supposed to solve).
When people talk about "ability based" components, they're talking about _code_ abilities, not character abilities. e.g. things like "collides" or "has physics" or "has AI" or "takes player input" or "has a renderable mesh" or "plays a sound" or so on. Think about how code things work, not how real-world or game-world things work.
It really depends on the style of ECS that you want to use. "ECS" isn't a formal term -- many studios mean it to mean many, many different things.
Sometimes the whole point of an ECS is that you can very easilly add temporary buffs and other micro-components / tags / etc onto game objects, to get complex behaviors through emergence.
Sometimes, ECS is just a knee jerk reaction to realizing that inheritance-addiction is bad, and it's just an attempt to move over to composition (see "composition vs inheritance").
Other times, ECS is about improving performance through OOD / cache oblivious algorithms.
Depending on what the purpose is, the resulting "ECS" system that you build can be extremely different. If you want to use lots of short-lived components for things like buffs, you can design your ECS so that this use-case is implemented optimally. If you use someone else's ECS design, then short-lived components may or may not work well...
