I'm making a kind of entity component system framework and I have a doubt:

I have two components 'health_damage', 'physic' (which contains position, weight,...) and 'sprite' (position, dimensions...).

When this entity takes damage I want to reduce its dimensions based on health percentage (50% life -> 50% original size) and I thought that I need to create a new system 'change_dimensions_on_hit', register the entity and on hit send a message to it which will update the dimensions (and weight) based on health. And that's, in my opinion, it's fine.

The problem is: imagine I create an item which increases the dimensions of the entity when it's picked up. It would increase the size of a fixed amount without knowing it's original or not (maybe it's at 10%) and when the entity regains health it will become huge Ex. Health = 10; MaxHealth = 100 ActiveDimensions = 10 (original is 100); I take a +20 size object and then a full heal item: ActiveDimensions would be (10 + 20)/0.1*1.0f = 300 (and not 120)

These are the solutions I found (but I don't really like anyone of them):

  • storing for each 'mutable variable' its current and max value like for health, so I can always calculate the current percentage and change correctly the original size. I think that's not a good idea because really few entities would have this behaviour and so I would waste a lot of memory.

  • make the physic component aware of the existence of the health component and (if a flag is set) look for che percentage when it is modified. I think it similar to the first and it also forces a tied relationship which I think it's even worse.

  • (the one that I think it's the best) I'm using a message system to handle things such as damage on collision, creation of entities... I still need to figure if it's the best way but I'm pretty sure of this. I can use it to handle everything possible and so also the changing of sizes: the item picked up sends a message to the entity 'grow up/shrink'; the entity spreads it to all the systems which is registered to and they can modify the message data before it's handled by the 'base components' (physic, dimensions,...). So it will be received at first by the change_dimensions_on_hit which would adjust the amount of growing based on current health. At the moment I handle messages in a very specific way: 1) it's handled by the systems which will modify them directly (ex.'double_growing_items') 2) by the ones which need to read other components to perform the change (ex. 'Change_dimensions_on_hit') 3) by the base components such as dimensions. This solution seems the best to me, even if has its own limitation (I have a specific path for each message and I'll face problems such as 'I need that this message, in this case, is handled first by this system and then from that, and not the opposite') and relies entirely on a message system which isn't the best solution performance wise (but I don't think that's a real problem).

Any advice and suggestion is welcomed. Do you think message system is the right way? Or maybe the firsts methods with slightly changes? Something totally new? (I can't change too much because I need to finish this project in one two month for the high school's final exam)

  • \$\begingroup\$ If you want to make health change size, and have size bonus, the size modifier is not 20, or 0.2. It should be 1.2f perhaps. Assuming the original size is 100f, and health is 10%, then: 100f * 0.1f * 1.2f. This becomes 12f when the player is at 10% hp. But becomes 120f if the player is full health. \$\endgroup\$ – rvalerio Apr 23 '17 at 13:45
  • \$\begingroup\$ Yes I know, that's no the problem. It's more about communication \$\endgroup\$ – Liuka Apr 23 '17 at 17:02
  • \$\begingroup\$ Calculating the health percentage would come in handy for other things as well, like health bars or any other health-related mechanic. Otherwise you could just have a component that manages the relationship between health and the sprite. The component keeps track of how much it's changed things by, and it only has to be applied to things that change size when their health is damaged. The component exists for as long as the health and the sprite component. \$\endgroup\$ – Pharap Apr 23 '17 at 22:12
  • \$\begingroup\$ So the third option? \$\endgroup\$ – Liuka Apr 24 '17 at 6:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.