Here’s something a little more complete, hope will either inspire or, at least, push you in the right direction and clarify some of the communication mechanics between the blueprints:
- Consider being the wHeart widget:
– it keeps track of its own state via the isFull variable
– the Set State custom event switches the images around
– widget is the equivalent of a single heart either being full or empty
- Another widget - wHealthBar is made out of many wHearts:
– Set Health creates the desired number of wHeart widgets, adds the to a wrap box and stores them in an array; the latter is done to avoid casting later on
– Update Health operates on the wHeart widgets and sets their isFull state according to the player’s health
– Increase Health Pool; each time it’s called, it creates and additional wHeart widget, visualising the now larger health pool
- And is the player:
– health is tracked with 2 variables: HP_Current & HP_Max; both set to 6
– we add the wHealthBar widget to the screen, store its reference; call SetHealth (see above) to visualise the starting health pool
The 1, 2, 3 represent operations on the health pool and would normally be called as the player interacts with the world, here to simulate those evets:
- 1 damages the player
- 2 expands the health pool
- 3 heals
We update the display after they’re called, feeding the widget with a new HP data.
Some things could be optimised better, refactored, wrapped in functions but I tried to keep it all as simple as I could.
Zipped project: