1

I want to create a health bar using information that I'm currently displaying in a GUItext. The behaviour I want is for the health to decrease over time (like a countdown timer), but increase by a small amount whenever the player collects an object.

Here is my current code:

using UnityEngine;
using System.Collections;

public class TimeText : MonoBehaviour {

    public GUIText timeText;
    //countdown
    public float timer = 99.00f;

    // Update is called once per frame
    void Update () 
    {
        timer -= Time.deltaTime*5;

        timeText.text = "Health: " + timer.ToString("0");

    }
}

Here is what I would like my health bar to look like: enter image description here

Serlite
  • 12,130
  • 5
  • 38
  • 49
mar97
  • 21
  • 1
  • 4
  • you appear to be using Unity's very old legacy "gui" system. **Do not use it**. Just use the ordinary Unity.UI system. it is very easy. – Fattie Jan 27 '16 at 15:23
  • simpy use Invoke or InvokeRepeating. google 1000s of QA on this – Fattie Jan 27 '16 at 15:25
  • Possible duplicate of [Unity. Function call after a certain period of time](http://stackoverflow.com/questions/21598444/unity-function-call-after-a-certain-period-of-time) – Fattie Jan 27 '16 at 15:25
  • 1
    Upon clarifying the question, this looks like multiple questions smushed into one: 1) Displaying a health bar graphic that corresponds in size to a changing number, 2) Increasing health during collision with a specific type/tag of object (and presumably destroying/deactivating the object). Addressing just part 1, I would suggest using the [`UI.Image`](http://docs.unity3d.com/ScriptReference/UI.Image.html) to display the health bar, and changing its `fillAmount` variable. – Serlite Jan 27 '16 at 15:44

1 Answers1

1

As @JoeBlow mentioned above, avoid the old GUI mechanics. They are super heavy, crude, and not performance-helpful.

@Serlite broke down the question for you. Those are what you need.

For the health-bar, I suggest using Unity UI's Image component. Use the image you want (possibly the same one you posted in your question?) for the health bar and change the fillAmount based on your timer variable (though personally, I would rename that to something like "health" to represent its purpose better).

It looks like you've already taken care of reducing the health over time. To add to the health, use Colliders as triggers in the scene, and OnTriggerEnter or any of the similar default monobehavior methods on the appropriate objects.

I suggest going through a couple tutorials online, so that you get a better understanding of programming logic in Unity. I hope that helps!

andeart
  • 935
  • 6
  • 19
  • I agree GUI is a bit awkward to use but I never read anywhere about UI being faster than GUI. Can you link a source, please? – Nika Kasradze Jan 28 '16 at 11:22
  • I have a unity3d version 4.5.1 and i don't have any UI Image. Anyway how would the animation of adding or removing character's health-bar work? – mar97 Jan 28 '16 at 14:23
  • @mar97 Have you considered updating your version of Unity? At some point it's necessary to let go of Unity's legacy systems, since they can really slow down your development. – Serlite Jan 28 '16 at 14:45
  • @NikaKasradze Apart from being able to see UI elements while editing and the ability to add custom scripts to UI elements, it's also performance-helpful because the UI elements do not need methods to be called for them every single frame, unlike older onGUI logic. Their only calls are from the events they receive. – andeart Jan 28 '16 at 20:34
  • 1
    Thanks for help. Here is my code on UI Image I stay the GUIText but as invisible. I'm very satisfied. public TimeText timeText; Image image = GetComponent(); image.fillAmount = Mathf.MoveTowards(timeText.timer/100,0f,Time.deltaTime*.5f); – mar97 Jan 29 '16 at 00:42
  • @andeart number of method calls is not a measure of performance. Yes, GUI is redundant and takes more development time to get proper result, on that I agree. – Nika Kasradze Jan 29 '16 at 07:40
  • @NikaKasradze Isn't zero method calls better (by degree of CPU usage) than many method calls, additionally executed over and over every frame? For the sake of this argument, let's assume that the actual *rendering* paradigms of both the old and the new mechanics are performance-equivalent (though I highly doubt that too). – andeart Feb 01 '16 at 18:54