I’m a little confused as to how the GetComponent works in terms of accessing a variable and changing its’ value.
What I need is seemingly quite simple, the idea is the following.
I have a GUI text called “GUiScore”. It has a “Text” field which I want to be able to access from another script.
So far I made it so that this GUiScore is linked to a reference script and it works if I code something within that script (Script A).
Script A also has a public variable, which is the GUIText variable.
Now on another script (which is a system I made to count score) (Script B), I want to send the information of a variable within Script B, into that variable called GUIText from Script A.
How can I access GUIText variable from Script A and change its’ value/text?
I don’t know the code for it…
I tried things like:
GetComponnent(ScriptA.referenceVariable) = scoreVariable;
and so many other weird things that I’m sure aren’t correct, because I keep getting errors.
First you need to find Script A. You can either do this by setting it as a public variable on Script B, like you did with the GUIText on Script A, or you can find its GameObject and then the script by first using the built-in Find() method, e.g.:
GameObject scriptAGameObject = GameObject.Find("Name of Game Object which has Script A");
So, now you have Script A’s Game Object, and now you need to find the Script A component on the GameObject, like this:
ScriptA scriptA = scriptAGameObject.GetComponent(ScriptA);
Now you have a reference to Script A, and you want to change a GUIText attached to this script. You do this by accessing the name of the attached GUIText (I assume that’s what you were trying to do in your question):
If I understand this correctly the textfield is in the GUI and when you access it, it should already be shown on screen starting with probably a score of 0.
in ScriptA I would make the public variable static.
A game should be able to execute without a gui at all - that is, all of the logic and variables that control game execution should have zero awareness of a GUI.
The smallest exception to this are actions that are fired from a GUI of course, but even then, the actions should be called from GUI, but not need data from the calling.
If you can write your game like this, it means that each object that “owns” some piece of data, like the health of a player, the ammo reserve in a weapon, the name of a level, etc, will expose some method to retrieve that information and will update that information in its own container.
Using ammo as an example, it means that there (likely) be a “Weapon” class that contains information about the weapon, along with something like:
public int GetCurrentAmmo(){
return this.ammoCount;
}
Then, in the GUI, all you do is when it’s time to display the ammo, you call the appropriate method, such as: Player.CurrentWeapon.GetCurrentAmmo() and put the result on the GUI as appropriate.
A GUI is a “peek” in to variables belonging to the runtime execution of the game. No part of the game should be modifying the GUI directly unless that part of your game is part of the GUI. That means if you want to say - pause the game from input, you should change some state to “Paused” and the GUI should be able to see that state and show the appropriate paused gui.
By maintaining this level of segregation, you will greatly ease your debugging and be able to more easily change GUI elements as your game matures and you realize changes in scope of your game.