Skip to main content
edited body
Source Link
Philipp
  • 121.5k
  • 28
  • 261
  • 342
public class Counter : MonoBehaviour
{
    public int ScoreAmount;scoreAmount;
    public Text scoreText;
    void Start()
    {
        ScoreAmountscoreAmount = 0;
    }

    void Update()
    {
        if (scoreText != null) { 
             ScoreTextscoreText.text = scoreAmount.ToString();
        }
    }
}
public class Counter : MonoBehaviour
{
    public int ScoreAmount;
    public Text scoreText;
    void Start()
    {
        ScoreAmount = 0;
    }

    void Update()
    {
        if (scoreText != null) { 
             ScoreText.text = scoreAmount.ToString();
        }
    }
}
public class Counter : MonoBehaviour
{
    public int scoreAmount;
    public Text scoreText;
    void Start()
    {
        scoreAmount = 0;
    }

    void Update()
    {
        if (scoreText != null) { 
             scoreText.text = scoreAmount.ToString();
        }
    }
}
deleted 42 characters in body
Source Link
Philipp
  • 121.5k
  • 28
  • 261
  • 342

This solution allows multiple Count script, but does not requires that they are not on the gameObject which does the collecting. So you can put it on a manager object or a UI element.

Why do it that way?

First, an object should contain the components which dictate its own behavior, not that of other things. Increasing the player's score and then disappearing is something the fruits do, not something the player-character does. So this behavior should be defined in a component of the Fruit gameObjects. Also, this allows you to do things like making the amount by which a fruit increases the player's score a public variable of that script. So you can create prefabs for different fruits which increase the player's score by different amounts.

Second, I would avoid putting a trigger on the player. Triggers should be on the objects in the world which other objects interact with. Not on the objects which do the interacting.

Third, detecting what the other object is in a collision by seeing what components it has allows you to create very modular and reusable code. The fruit doesn't care if whatever picks it up is a "Player". It only cares that it has the components which require it to be able to collect it. So you can have multiple players which collect fruit and even NPC characters which collect fruit, and you don't need to change anything about the fruits to do that.

  • an object should contain the components which dictate its own behavior, not that of other things. Increasing the player's score and then disappearing is something the fruits do, not something the player-character does. So this behavior should be defined in a component of the Fruit gameObjects. Also, this allows you to do things like making the amount by which a fruit increases the player's score a public variable of that script. So you can create prefabs for different fruits which increase the player's score by different amounts.

  • I would avoid putting a trigger on the player. Triggers should be on the objects in the world which other objects interact with. Not on the objects which do the interacting.

  • detecting what the other object is in a collision by seeing what components it has allows you to create very modular and reusable code. The fruit doesn't care if whatever picks it up is a "Player". It only cares that it has the components which require it to be able to collect it. So you can have multiple players which collect fruit and even NPC characters which collect fruit, and you don't need to change anything about the fruits to do that.

This solution allows multiple Count script, but does not requires that they are not on the gameObject which does the collecting. So you can put it on a manager object or a UI element.

Why do it that way?

First, an object should contain the components which dictate its own behavior, not that of other things. Increasing the player's score and then disappearing is something the fruits do, not something the player-character does. So this behavior should be defined in a component of the Fruit gameObjects. Also, this allows you to do things like making the amount by which a fruit increases the player's score a public variable of that script. So you can create prefabs for different fruits which increase the player's score by different amounts.

Second, I would avoid putting a trigger on the player. Triggers should be on the objects in the world which other objects interact with. Not on the objects which do the interacting.

Third, detecting what the other object is in a collision by seeing what components it has allows you to create very modular and reusable code. The fruit doesn't care if whatever picks it up is a "Player". It only cares that it has the components which require it to be able to collect it. So you can have multiple players which collect fruit and even NPC characters which collect fruit, and you don't need to change anything about the fruits to do that.

This solution allows multiple Count script, but does not requires that they are on the gameObject which does the collecting. So you can put it on a manager object or a UI element.

  • an object should contain the components which dictate its own behavior, not that of other things. Increasing the player's score and then disappearing is something the fruits do, not something the player-character does. So this behavior should be defined in a component of the Fruit gameObjects. Also, this allows you to do things like making the amount by which a fruit increases the player's score a public variable of that script. So you can create prefabs for different fruits which increase the player's score by different amounts.

  • I would avoid putting a trigger on the player. Triggers should be on the objects in the world which other objects interact with. Not on the objects which do the interacting.

  • detecting what the other object is in a collision by seeing what components it has allows you to create very modular and reusable code. The fruit doesn't care if whatever picks it up is a "Player". It only cares that it has the components which require it to be able to collect it. So you can have multiple players which collect fruit and even NPC characters which collect fruit, and you don't need to change anything about the fruits to do that.

added 935 characters in body
Source Link
Philipp
  • 121.5k
  • 28
  • 261
  • 342

But now the Counter loses its connection to the Text element it used to control. The reason is that it used the method B to get a reference to its own Text component, which now won't work anymore. How do we fix that? By using the solution C and tell it which text object to use to visualize its state. Make the ScoreText variable public and remove its initialization in Start:

public class Counter : MonoBehaviour
{
    public int ScoreAmount;
    public Text scoreText;
    void Start()
    {
        ScoreAmount = 0;
    }

    void Update()
    {
        if (scoreText != null) { 
             ScoreText.text = scoreAmount.ToString();
        }
    }
}

Then go to the Inspector and drag the Text object which you want to visualize the score on the "Score Text" inspector field of the Counter component.

Although personally I recommend to separate mechanics from UI visualization, so I would probably use a 3rd script for UI elements for visualizing the state of an arbitrary Counter on its own Text. But that's a different topic.

Why do I recommend option D?

Why do it that way?

Why do it that way?

But now the Counter loses its connection to the Text element it used to control. The reason is that it used the method B to get a reference to its own Text component, which now won't work anymore. How do we fix that? By using the solution C and tell it which text object to use to visualize its state. Make the ScoreText variable public and remove its initialization in Start:

public class Counter : MonoBehaviour
{
    public int ScoreAmount;
    public Text scoreText;
    void Start()
    {
        ScoreAmount = 0;
    }

    void Update()
    {
        if (scoreText != null) { 
             ScoreText.text = scoreAmount.ToString();
        }
    }
}

Then go to the Inspector and drag the Text object which you want to visualize the score on the "Score Text" inspector field of the Counter component.

Although personally I recommend to separate mechanics from UI visualization, so I would probably use a 3rd script for UI elements for visualizing the state of an arbitrary Counter on its own Text. But that's a different topic.

Why do I recommend option D?

Why do it that way?

deleted 93 characters in body
Source Link
Philipp
  • 121.5k
  • 28
  • 261
  • 342
Loading
added 1204 characters in body
Source Link
Philipp
  • 121.5k
  • 28
  • 261
  • 342
Loading
Source Link
Philipp
  • 121.5k
  • 28
  • 261
  • 342
Loading