- Home /
Can I have multiple public variables of the same name is separate scripts?
Let me explain. I have 5 scripts for 5 enemies, and they all have the variable "activatedFlag" to determine when they are active and can move. These variable are declared as such:
object class
{
public bool activatedFlag = true;
start
{
if (activatedFlag == true)
{
do stuff;
}
}
}
The variable is only changed by another script, the Game Controller. It activates and deactivates enemies. Normally its set to false.
Now I already had this working with my enemies, but I was making a new enemy and was writing it from scratch and for debugging purposes had it set to true and to public. The problem was that it wasn't working. In the inspector, it stays false even though it's set to true. As soon as I changed the variable to private, it began to work.
Normally, my other scripts work. They're public and set to false, and so long as my Game Controller script changes the variables in every enemy instance on and off, they're good. But I'm not able to get them to work if I set the individual instance to true.
Why is this?
I declare and initialize the variables in the class space, not in any function. They're also not static so they shouldn't be causing problems outside of the class.
Am I not able to have public variables of the same name in different scripts?
Answer by JVene · Jul 10, 2018 at 04:32 AM
@gameangel147, the problems you describe are separate from the question you're asking.
The issue of the "fantom bool" state is not of C#, but of the Unity editor. You may be setting the value to true in your code, but check the interface on the inspector in Unity and you'll probably find it is overriding your code!
That's actually by intent.
It also only applies to public variables. Unity's editor doesn't show the private variables on the inspector. This is done so you can change values, for debugging and configuration, in the Unity editor without recompiling.
As to your headline question, sure, you can have the same name in different scripts because they are each different classes. The names enclosed within a class are limited to the class, and don't conflict with the same names in other classes. The subject is known as name mangling. Effectively, if you have class A and class B each with a bool "what", the names of "what" are actually A::what and B::what (I know, in code you write A.what and B.what - it's complicated, one is a scope, the other is a vector into an object - each variable has a position at some distance from the beginning of an object, and the '.' operator is how that is accessed).
However, you bring up an opportunity to point something out far more important about object oriented thinking and design. It's an important point:
Every time you find yourself doing something "again" (and again), you've hinted at the existence of an object you haven't written.
In this case, your "activatedFlag" is not merely something your doing in all those objects, but it represents a concept that is common to all those objects. This observation is all but jumping up and down, yelling at you to create a base object.
So, try this. I don't know your actual purposes of design, but I'll run with the fact this is an "activateable" object, so I'll call the class "activateable". Your common theme is very likely more complex, and a much better name is likely in your mind. In this example, "activateable" would be created as a base class to hold the "activateFlag", and would derive from monobehaviour if your original scripts derived from that. Then, each of the several classes you're creating, which currently inherit from monobehaviour, would instead inherit from "activateable". They would all "inherit" from monobehaviour as the "grandparent" class.
Now, however, each of your classes don't need their own duplicated code.
Read that again, because it is the purpose of doing this. It may not seem important for a single variable, but I seriously doubt there's only 1 variable these classes have in common.
JVene, I have a follow-up question for you. $$anonymous$$y issue is a little different, and I could use some input. Say for example you have three regions, all with 3 buildable items - house, farm, castle. Right now, they each have a private bool, that when I select the region, it becomes the active region, it updates the three public bool variables. $$anonymous$$y UI then reads what is in those public bools to deter$$anonymous$$e what buttons are active/inactive (can't build the farm if you already did, etc). However, this is not a good way to work it I am sure. I still have to find a way to update the active regions private bools. I was thinking of making all regions share the same public bools, and just have the active regions ones called/updated. Using what you said above, would a class of all these variables work? Is what I was thinking of doing better? Or, perhaps an array of arrays with all variables, and everything refers to it?
When considering where a variable should go, there's a 'standard' question to ask, does the concept represent "Has-A" or "Is-A". The class you're talking about is a region I assume. It seems to me that a region doesn't say "yes" to the "Is-A" question, that is, the region is not a house, nor is it a farm or castle. It seems to me the region owns a castle, a farm or a house.
Where a class "Is-A" concept, the variables store attributes that describe it; things like color, price, etc.
Certainly there are member variables which describe what a thing owns, but in that sense it is describing the ownership.
The key different in that point is where code applies to owned elements like the house or castle. If bools define the presence of these items you'll probably end up with code that operates the castle or house based on "if (hasHouse){}...else if(hasCastle)", doing what ever is appropriate for each of the cases. Where should that code really go?
It is likely that the house, castle and farm should be objects that holds that code. The region owns them, and operates them by calling them to do what they know about being a house or a castle or a farm.
Consider what happens if you design the game so the region can only hold one of these, such that region can't hold both a house and a castle. Current that would be done by testing bools, but if there was a class design based on a "RealEstate" base class, there could only be one, enforced by the simple fact the region already has a RealEstate member, be it a house, castle or farm.
On the other hand, if the design allowed several of these, a container of those owned would provide far more flexibility than a collection of member values held by the region.
$$anonymous$$ore importantly, there may be things having a house means in the game. Someone probably lives there, as they would in the Castle perhaps (maybe the Castle is haunted though). The resident of a farm is likely to produce crops. Each of these are probably best operated as part of a class embodying the concepts they represent, than being code in the region fired based on a set of bool states.
The presence of lack of presence of an object is the same as a bool state, but brings with it an entire object of knowledge an capability.
Answer by mremptybox · Aug 02, 2018 at 04:11 PM
That is an awesome way to work through this! Is it and has it, I will redo my concept and play with it. Thank you!
Your answer
![](https://koobas.hobune.stream/wayback/20220612170402im_/https://answers.unity.com/themes/thub/images/avi.jpg)