Question regarding multiple UI menus.

News & General Discussion
1

Hello all,

I am relatively new to the Unity Canvas system. In the current game we are creating, we have multiple menus for player upgrades, inventory, and quest hub. I was wondering if there is an easier way to construct the menus with the canvas system to keep them prefabbed and connected rather than building a giant script for functionality and having to reconnect it every time it is moved to another scene or manipulated. Can I add the functionality to the canvas itself if its SetActive state keeps being manipulated? Ill post the top of my script to show all of the connection that the town currently has. Should this be broken down further into smaller scripts or should be fine as is?

using UnityEngine;
using UnityEngine.UI;


/// <summary>
/// This script is for the functionality of the port. It handles the switching between screens and the functionality of buying
/// an upgrade.
/// </summary>
public class PortFunctionality : MonoBehaviour

[Header("Script Links")]
    public PauseMenu pause;
    public StatsHandler stats;
    public ShipMovement shipMovement;
    public PlayerHealth health;

    [Header("Header Text Object")]                      //Header text of the upgrade screen. Can be manipulated to change per screen.
    public Text headerText;

    [Header("Window Objects")]                          //Port Windows. Main Port/Upgrade Window/Quest Window. All screens are seperate.
    public GameObject portWindow;
    public GameObject upgradeWindow;
    public GameObject questWindow;

    [Header("Upgrade Windows")]                         //Upgrade Window with different tabs per skill.
    public GameObject introWindow;
    public GameObject dmgUpgradeWindow;
    public GameObject armorUpgradeWindow;
    public GameObject speedUpgradeWindow;

    [Header("Damage Upgrades")]                         //Upgrade slot for each upgrade.
    public GameObject damageOneBlock;
    public GameObject damageTwoBlock;
    public GameObject damageThreeBlock;

    [Header("Armor Upgrades")]                          //Upgrade slot for each upgrade.
    public GameObject armorOneBlock;
    public GameObject armorTwoBlock;
    public GameObject armorThreeBlock;

    [Header("Speed Upgrades")]                          //Upgrade slot for each upgrade.
    public GameObject speedOneBlock;
    public GameObject speedTwoBlock;
    public GameObject speedThreeBlock;
2

For example.

Let’s say you have an UI on-screen health gauge for the player and its state is managed by component attached to the gauge itself.

You can update its state without directly linking it to the player.
To do that, introduce a global function which returns currently active player. “Player.getActivePlayer()”, and have the gauge call THAT instead of drag and dropping connection.

Let’s say you have a more complex UI screen that can be attahed to the player, or can be attached to another creature, there’s ton of components in it, and you don’t want to reconnect each of them by hand.

To do that. Add some sort of “DataSource” component at the root of the canvas. Within DataSource add a method called “getTarget()”, which will return what we’re pulling the data from.
For every component that is a child or a grand child (or a grandgrandgrand… child), that has to display some information, grab DataSource instance within OnEnable(), using GetComponentInParent, and within Update use the DataSource you got to get the data you need.

That reduces number of manual connections you need to specify to zero or one, regardless of how many buttons you have.

Basically, it is better to program components in such way that they do not need manual linking and find linked components by themselves.

In your example, you can remove ALL those variables or majority of them, and have them update themselves instead of trying to update them from within one component.

3

Thanks for the response! I will try to give that a go today. That’s the direction I thought I had to go, but was unsure if that was the right process or not to pursue. Thanks again!