How do you define a component on an abstract level

Hi

Just wondering - im getting to the part where I have to define my components in more detail/more carefully and got to wondering: Does anyone here have any experiences to share as to how they define their components ? I’m thinking about wether components are mostly considered ‘the ability to do X’ or ‘has attribute X’, a combination or a completely different scheme applies.

In my tower defense game, i’ll have an attack component (which is inherently an action containing radius, reloadtime and a few other fields) - but also a health component (which is an attribute - passive data so to speak). I’ll also be doing some ‘modifiers’ such as big/fast/strong (in a sense the modifiers you see on bosses in the Diablo series).

Also: Developing an attack component, would it make sense to split it up into components for each of ‘damage’, ‘reload time’ instead of having one component that contains all those specifications.

Edit: I guess health component could be abstractly described as ‘the ability to loose health’ - wonder if that applies everywhere.

Kind regards,
Asser

Generally, it depends on what your systems need or what you think they will need. For example, if you determine that any system that uses component X also always uses Y and Z and nothing else uses Y and Z then those probably should be collapsed. If even forward-thinking doesn’t produce any reason to have them separate then there is no particularly good reason to keep them separate.

Also, something to consider is that sometimes a component is not just attached directly to a particular entity but is actually part of an entity that is attached to that particular entity. That’s probably confusing. Damage is a good example of where this might come up. Many things might damage an entity in a given frame. This makes it hard/impossible to just attach some damage directly to that entity. So often, you create damage entities and then link them. Then you have some damage system that loads all of the damage entities and cumulatively applies that damage. This way an attack can damage an entity, fire can damage them, a trap can damage them, poison can damage them, etc… all within the same frame without stomping on each other. (In theory you could even do cool things like have fire damage and ice damage cancel each other out or something… if your damage keeps track of its element.)

In my Monkey Trap example, I do similar to this though it isn’t fully fleshed out yet. There will eventually be a damage component and damage entities as I describe above… with a second stage that is basically a “negative health buff”, ie: an instant effect applied to an entity that reduces its health. The “health system” handles this. Health increases are handled the same way and the health system determines death, and so on.

Any object that can be damaged/destroyed is handled by the health system (monkeys, ogres, barrels, chests… anything with hitpoints.)

So, the entities work as a sort of event list - with no regards for order (right?). Where they occur at one point in time, say a damage entity is created (1) because a bullet entity hits the mark and in the next frame the damage system picks up this damage entity (2) and processed it - creating a health entity (negative) which is in turn picked up (3) by the health system.

Would there be any way of ordering the entities in the processing without too much overhead ? This would sove a lot of the eventing I’ve been wondering about.

@asser.fahrenholz said: So, the entities work as a sort of event list - with no regards for order (right?). Where they occur at one point in time, say a damage entity is created (1) because a bullet entity hits the mark and in the next frame the damage system picks up this damage entity (2) and processed it - creating a health entity (negative) which is in turn picked up (3) by the health system.

Would there be any way of ordering the entities in the processing without too much overhead ? This would sove a lot of the eventing I’ve been wondering about.

Why would you need to order them? That is an indication that something is wrong.

@pspeed said: Why would you need to order them? That is an indication that something is wrong.

I’m not entirely sure that I do yet, but was wondering about the idea of one damage type being applied before another type - would result in a combo-bonus or the like.

I guess I could overcome that by defining combos as being over multiple frames (so if the target had a attack type A applied in frame 1, and attack type B in frame 2 - a combo-entity would be spawned and processed in frame 3).

Edit: Perhaps not frames but update-loops :slight_smile:

I could also just let the combo apply if two related attack types are applied in the same frame. Haven’t gotten the specifics down yet so its not writte in stone.