This is in the context of creating an RTS, in which the aim is to have several Units (Buildings; Movers : Workers, Soldiers...) that one can select as one or a group. When selected, the units can be moved (Mover), and can have specific methods (Building: can create a Mover...).
I have (heavily) based the selection system on:
If I add as a component the script Building.cs to the GameObject Building, does it inherit everything from Unit.cs ? Or does it need to have the Unit script as a component too ?
--> For fields and "normal" methods (not Start/Awake/Update), yes. So the GameObject Building only needs to have the Script Component Building
However, the Start method of Unit
is not called in the Building
class, which makes it not possible to add it to the unitList field of the class UnitSelections
.
How can the Start method of Unit
be called for an object with the Building
Script Component ?
--> Need protected virtual void Start()
for the TopClass
, and can call base.Start()
within the protected override void Start()
of the ChildClass
See solution answer for details
CodePudding user response:
As you can see the building component has all fields of unit component. So yes it inherits everything. The building component is unit component all inside (start, update, CreateMover). If you add building component and unit component then you have 2 unit components where one of them is extended with start, update and CreateMover.
CodePudding user response:
Just as Unit
inherits from MonoBehaviour
, Building
inherits Unit
(which inherits MonoBehaviour
). As such, you should ONLY add Building as a component to your GameObject. If you add both, you'll end up with two distinct components on your game object - the Building component AND a Unit component. Each component would have it's own set of variables, and listen and react to the Unity messages independently, for example Update()
if it were present if both classes.
It's also interesting to note that MonoBehaviour
inherits from Behaviour
, which inherits from Component
, which inherits from Object
(UnityEngine.Object, not System.Object). So Building.cs
in this case is just another subclass of a component and is treated as such. You can check out the lineage on the
Now, if we create a small test script to look at the GameObject:
As you can see, there are two "Unit" components on the HumanBarracks GameObject, a Unit and a Building which is also of type Unit.
Extra
public class Unit : MonoBehaviour
{
public int maxHealth;
public int health;
public bool isSelected = false;
public bool canMove = false;
public bool canCreateUnits = false;
public bool canAttack = false;
public bool canGatherResources = false;
// By making Start protected virtual, child classes will run it and can override it as well if they require a specific implementation.
protected virtual void Start()
{
Debug.Log("This Start method will now be called by all children.");
}
}
public class Building : Unit
{
protected override void Start()
{
// call the base Start method on Unit.
base.Start();
// Now add this building’s particular Start code.
Debug.Log (“Building specific Start code!”);
}
}