Search Unity

  1. Unity 6 Preview is now available. To find out what's new, have a look at our Unity 6 Preview blog post.
    Dismiss Notice
  2. Unity is excited to announce that we will be collaborating with TheXPlace for a summer game jam from June 13 - June 19. Learn more.
    Dismiss Notice

How do you guys handle the in-game GUI in this scenario ?

Discussion in 'Editor & General Support' started by NoradZero, Oct 14, 2014.

  1. NoradZero

    NoradZero

    Joined:
    Apr 24, 2014
    Posts:
    95
    Hi,

    I currently have this layout. 1 scene = 1 level in my game with a LevelManager which handle some level logic. I am now at setting up the GUI and i need some guidance.

    So the main question is "How do you guys handle the in-game GUI graphical representation and flow of information" ?

    By that i mean, lets say i have an health bar. The GameManager currently taking care of the player properties. So basically the GameManager know how much health the player have.

    1- Should i make a script at the health bar which ask the GameManager how much health the player have and update this accordinally? But won't it cause problem if that called each time? Should i use events?

    2- How do i make the health bar appear ? Since my layout is 1 scene = 1 level that mean i will need a kind of UIManager. Does the UIManager simply instanciate the health bar in the screen ?

    Thanks!
     
  2. Steve-Tack

    Steve-Tack

    Joined:
    Mar 12, 2013
    Posts:
    1,240
    There are a million ways to do anything, but having a global class have awareness of the player's health doesn't seem like a very Unity way of doing things (not component-based).

    My approach would be to have a script attached to the player for managing its own health. Perhaps that script could have a public method like UpdateHealth() that could process messages incoming from other classes.

    I'd probably consider violating the pure component-based approach on a UI, since that's more of a global thing, so for that I probably *would* have a global manager. One approach would be to instantiate your entire UI at the start of the game, mark it as DoNotDestroy, and turn individual elements on and off depending on the game state. I wrote my own screen manager that stores pointers to all UI elements so that I can access them at will, but Unity doesn't come with that out of the box.

    So in your player health script, your UpdateHealth method might look something like:

    Code (csharp):
    1. public void UpdateHealth(float healthDelta)
    2. {
    3.     Health += healthDelta;
    4.     Health = Mathf.Clamp(Health, 0.0f, 1.0f);
    5.     ScreenManager.CurrentScreen.SetHealthBar("PlayerHealth", Health);  /* You'd have to write the ScreenManager script */
    6.     if (Health <= 0.0f)
    7.     {
    8.         Die();
    9.     }
    10. }
    11.  
    Then an outside script, like a projectile or enemy can do SendMessage to the player with a negative value to make the player's health go down, like in an OnCollisionEnter event or whatnot. You could even have a health pack do SendMessage with a positive value to heal the player, etc. The specifics of everything would be highly dependent on how your specific game works of course.
     
    NoradZero likes this.
  3. NoradZero

    NoradZero

    Joined:
    Apr 24, 2014
    Posts:
    95
    Amazing answer. You somewhat right about the fact that the player should update his own health. That how the Unity model actually work so i should stay on track.

    For the UI i will simply make a UIManager as a singleton like i did for the GameManager and it will handle the whole UI stuff as you mentionned.

    There is just something i am curious about. If you instanciated the GUI at start of the game why do you need the CurrentScreen reference ? I mean CurrentScreen refer to what exactly ?

    Thanks you so much! !
     
  4. Steve-Tack

    Steve-Tack

    Joined:
    Mar 12, 2013
    Posts:
    1,240
    Well, that's just an example of how I'd use my screen manager. Yours will surely differ. In my case, I have a concept of different "screens" that I can display and I can address them via a singleton class like ScreenManager.Instance.Screen[x] (or something like that). As a shortcut, I can set what the current screen is and address it via ScreenManager.CurrentScreen. Don't worry about the details like that, I just meant it as an illustration of the sort of thing you might do.
     
  5. NoradZero

    NoradZero

    Joined:
    Apr 24, 2014
    Posts:
    95
    Alright then!

    Thanks!