Hi i have an UI text that displays the current health the person has. Im trying to figure out if i should update the text every frame or if i should just update it when they take damage what do you think?
I would push the health data to the UI text when it changes. Do not have the UI text check for what the data should be.every frame
General rule of thumb, only use Update for stuff that you need to check every frame for. Usually stuff that is updating text only needs updates when the value changes. In the case of health, I usually have a method that takes a damage amount. This way I can apply the damage to the health, then check the health to see if the player/monster died, and update any gui to reflect current health/death.
Both johne5 and Brathnann pointed out very good matters. In summary I recommend you use something like this:
float _health;
public float Health
{
get { return _health; }
set
{
_health = value;
float displayHealth = Mathf.Clamp(_health, MIN_HEALTH_VALUE, MAX_HEALTH_VALUE);
txtHealth.Text = displayHealth.ToString();
if (_health <= 0)
{
// Game Over
}
}
}
You can easily increase and decrease your health by
Health += 5;
Health -= 2;
Hope it helps
2 Likes
It depends.
If every item has UI all the time, then having your game push data to the UI works.
On the other hand if you have a lot of things that sometimes display UI, polling the stuff you need can be more efficient.
No it doesn’t 
Don’t update UI in the setter of a property. Just…don’t…Even better - don’t use a setter for something like health. Expose TakeDamage and Heal methods. Make what you’re doing explicit. Use events to decouple your UI from the stuff that informs it.
1 Like
Having an event to separate UI from logic make a lot of sense. But I don’t quite get why you are opposed having a public property for health. What kind of control do you have in those methods that you don’t on a property?
Not opposed to a property. Opposed to a public setter that has a bunch of logic in it.
Property setters should do nothing more than sanity check the input and update the backing field. If you’re doing more than that then you should encapsulate the behavior into a method. Methods are for doing things so when your property starts doing things you probably want a method.
With that said - methods also allow you to be declarative. They’re verbs. There might be 35 different ways to increase a player’s health in a game but if all you ever see in the code is
player.Health += amount;
it can be hard to suss out what you’re doing. But if you see this
player.Heal(amount);
I don’t need to see any surrounding code to know what that does (philosophically of course). Build an interface into the player that informs programmers as to what they can do to a player. What those actions actually do to a player is a side effect.
Basically - don’t expose a setter to someone’s health directly and let others just jump all over it willy-nilly. Give them ways to manipulate health.
3 Likes
I do agree with @KelsoMRK here. I would rather have two methods (if we’re talking about the health example) if I wanted one to heal and one to damage. That way the damage method does the check for game over and handles that sort of logic. The heal one doesn’t need to check that sort of thing, but maybe it has additional logic for overhealing or something that the damage method doesn’t need to even check against.
2 Likes
Also, from MSDN:
1 Like
For reference I was suggesting if the UI polls the health for data or the health pushes data to the UI. I wasn’t actually looking at methods vs properties.
How you implement things under the hood is secondary.