0
\$\begingroup\$

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)

\$\endgroup\$
4
  • \$\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\$ Commented Apr 23, 2017 at 13:45
  • \$\begingroup\$ Yes I know, that's no the problem. It's more about communication \$\endgroup\$ Commented Apr 23, 2017 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\$ Commented Apr 23, 2017 at 22:12
  • \$\begingroup\$ So the third option? \$\endgroup\$ Commented Apr 24, 2017 at 6:26

0

Reset to default

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.