Home > front end >  How to make the Script component of a GameObject inherit from its parent, including the Start method
How to make the Script component of a GameObject inherit from its parent, including the Start method

Time:08-29

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: Building Class in Editor

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:

enter image description here

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 Two Components With Separate Values

Now, if we create a small test script to look at the GameObject: enter image description here

We get this as the result: enter image description here

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!”);
    }

}
  • Related