Why aren't these two scripts well synced?

Hello everyone. Im new to Unity and in general new to using classes and accsessing variables from diffrent scripts. Btw, im making a 3D game. I made two scipts, one for health and other one for respawn and I think they aren’t synced together well. When player collides with monster, nothing happens. Here are the scripts. It would be good if u tell me whether there are any preformance boosts that i can implement in scripts as well

using UnityEngine;

public class HealthBar : MonoBehaviour
{
    public static float playerMaxHealth = 120;
    public static float playerCurrentHealth;
    public UnityEngine.UI.Image health;
    public static float monsterDamage;

    void Start()
    {
        HealthBar.playerCurrentHealth = HealthBar.playerMaxHealth;
    }

    void Update()
    {
        health.fillAmount = HealthBar.playerCurrentHealth / HealthBar.playerMaxHealth;
    }

    private void OnCollisionEnter(Collision collision)
    {
        if (collision.gameObject.name == "enemy")
        {
            playerCurrentHealth -= monsterDamage;
        }
    }
}

public class Respawn : MonoBehaviour
{
    [SerializeField] GameObject player;
    public float playerLifes = 3;
    [SerializeField] float DeadHeightY;
    Vector3 spawnCoordinates;

    void Start()
    {
        spawnCoordinates = GameObject.Find("SpawnPoint").transform.position;
        spawnCoordinates.y += 10f;
    }

    void Update()
    {
        if (HealthBar.playerCurrentHealth <= 0f)
        {
            Spawn();
        }

        if (player.transform.position.y <= DeadHeightY)
        {
            Spawn();
        }
    }

    private void Spawn()
    {
        player.transform.position = spawnCoordinates;
        HealthBar.playerCurrentHealth = HealthBar.playerMaxHealth;
        playerLifes--;
    }
}

Why is it not working? Difficult to say from here. perhaps you have not attached this code to a GameObject, perhaps you have spelt “enemy” without appropriate capitalisation. Test your by putting in Debug.Log(“Collision”); to see if the collider code is even being called. I often put in Debug.Log(111); 222, 333 etc in various places to check if code is called. Or follow a tutorial on debugging , breakpoints etc.

Since you ask, I’ll give you a few pointers but, first, when you post a question, please use the Code Sample button (ones and zeros). That will open a window where you can paste your code and it will look a lot better than in your original post. Meanwhile, I’ve reformatted it for you (and for others who might read this thread).

Some of the comments below may seem excessive but, as your game grows, you will find that separation of function makes life much easier. An example is when you die, you should to disable user input temporarily, stop enemies chasing you, play some sound, play an animation, put up some text on the screen and so on. It would be wrong to put all of these into a single class so let’s start by isolating function.

(1) Do consider making classes what we call “Single Responsibility”. The Healthbar class, for instance, handles collisions, which it not what that class is about at all. Likewise, the respawn class is decided whether to spawn or not, when that should, perhaps, only respawn when told. Other classes will decide when to respawn and you shouldn’t complicate Respawn with decisions that are outside its scope. Might you have a “Level restart” button at some point? That’s another example of causing a respawn. Also, when the games starts, there may be other initialisations that you want to introduce and it would be best to spawn on game start as well, so those initialisations are all done in one place.

(2) In HealthBar, you are updating the displayed health bar every frame. You only really need to do this when health changes.

(3) When I see public statics, I start to get itchy. Sharing data is a last resort, not a first. If a method needs some data, it’s often better to pass the data than to make it commonly available. Better still is not to pass data that can otherwise be kept local. If you are trying to debug where playerCurrentHealth is changed, it’s much harder when it’s public static. In fact, you often don’t need static either - certainly not in these cases (or at least for the amount of code that you’ve shared)

(4) You may see disagreement on this next point but it’s a common practice in small to medium sized games to have Manager classes. For example, Health Manager; UI Manager, even sometimes a Game Manager (which Unity think is so common that they give it a special icon, should you have a Game Manager GameObject). The issue then is how to communicate between them.

An example here is that a collision has taken place. The collider code doesn’t need to know who is interested. It simply puts out a message saying that the player has taken a hit. Other code that might be interested “subscribes” to that event and then acts. What you have in that case is a bunch of independent classes that are informed of changes but they are not directly coded in the Collision code. That way, you keep things separate. One of these subscribers will be the Health Manager. It can take the hit on Health and then decide if the player is dead or not. If the player has died, the Health Manager will send out an event, which might trigger audio, stop input etc as mentioned above. In turn the Health Manager might send out a message to the UI to update the health bar. To do this kind of messaging, you need to implement events (I have another post that might help on this topic).

(5) Don’t be afraid to put multiple scripts on a single GameObject. For instance, your player might have a movement script, a collision script, an animation script and so on. These are generally independent of each other and, if they need to communicate, you can use events or GetComponent to access them.

Making all these changes at once will be pretty tough (though it’s arguably easier to do it when you have written a little code than when you have written a lot). However, do take these as guidance from someone who has been coding for 40 years and made a great many mistakes along the way - and who continues to do so…

Thank you so much for the feedback. I will try to improve my scripts. Since I am new to almost all things you said, it might not be perfect, but this is my first game so it doesn’t matter.