iOS How to make Heart meter side-scroll with player (in 2D platform)?

A

Andrew Simms

Guest
So I'm building a 2D platformer, and I have three heart objects with full and empty sprites that represent the player's "lives" variable. (ie. Heart 1 = visible if "lives" = 3, Heart 2 visible if lives = 2, etc...)

However, I just implemented a scrolling camera, which is great, but now it's an issue that my heart objects were fixated in place as they stay behind as my character progresses. I really like the coding behind the sprites and don't really want to do away with them, is there a way to facet them onto the top right corner of my camera?
 

rIKmAN

Member
So I'm building a 2D platformer, and I have three heart objects with full and empty sprites that represent the player's "lives" variable. (ie. Heart 1 = visible if "lives" = 3, Heart 2 visible if lives = 2, etc...)

However, I just implemented a scrolling camera, which is great, but now it's an issue that my heart objects were fixated in place as they stay behind as my character progresses. I really like the coding behind the sprites and don't really want to do away with them, is there a way to facet them onto the top right corner of my camera?
Draw them in a DrawGUI event instead of the regular Draw Event.
 

TheouAegis

Member
You don't even need objects. Just put drawing code in the player's GUI event. (0,0) in the GUI is the same position in the game window at all times until you resize the window or GUI layer.
 

kburkhart84

Firehammer Games
About fixing the GUI not following the player, the DrawGUI event is indeed your friend. But.....

I generally understand it is better practice to get used to keeping things separate, instead of having the player draw the GUI. It works...but the player should only be responsible for the player...it shouldn't even know or care how many lives are left. You should have either an object, or even a set of global variables that track the "stats" of your game. Then you should have a GUI type object that has no control over what the lives are, but DOES draw them. The player at the most would be alive and destroy itself along with the movement and action, etc... Then the controller object would detect if the player gets destroyed, respawn it, and deduct a life.

The reason for this is so you can easily change things in the right places. Big changes are harder when objects do multiple things. As you make bigger more complex projects you will get the experience and understand how it goes. It goes with organization as well. I only have one GUI button type object. This one object is just that, the button. It handles the events like being clicked, does the animation for it, any sound effects....but it DOES NOT actually have code for anything else. I put that in separate scripts as needed. I don't make multiple button objects, rather I put multiple instances of that button in a room, and then I tell each one what picture or text it needs and what script to call when clicking. Now, if I need to change the graphic, sound, animation, whatever on my buttons, I do it just for the one button, and it affects all of them. This applies to the controller object as well. If I need to change the max lives, I just do it on the controller, and the player doesn't care either way, and the GUI just looks at the controller to know what to draw. Anything that needs to know about the lives can then look in the same place.
 
  • Like
Reactions: Yal
Top