C # Programmer's Consolidation of Unity 3D notes (13): Unity 3D component-based thinking

If you have been exposed to design patterns and software architecture programming ideas, you will know good design guidelines: "Combination is better than inheritance ".

This is a short sentence, but when I started to learn oop, it was really--not very well understood (in my own case).

The inheriting thought of OOP

In the design of the protagonist (Player), in order to be able to reuse the functions of a, B, C, I began to put a, B, C in accordance with the inheritance to write, a number of virutal\override\protected and other modifiers, function without any problems, is somewhat awkward. If the start, Update method can only be used in a template method of processing, in case B, C, player directly using the start, Update method, will lead to strange problems; At the same time, in the base class of inheritance, there is a lot of invisible baggage, for the player has to use a, B , c functions, variables (not private).

The whole relationship has become:

• Player is a A
• Player is a B
• Player is a C

Psychologically Gegedada, always feel a bit awkward.

The combination idea of OOP

The previous use of combinatorial thinking is the construction of tree, leaf model, such as the network element model in telecommunications. This idea belongs to the core idea of unity 3D – components. In player, A, B, C can freely use the start, update function (please do not consider the order of execution, the sequence of script components can be adjusted externally, but not significant), most importantly, the relationship straightened out-the protagonist becomes more active, active.

• Player has a A
• Player has a B
• Player has a C

in Unity 3D, almost all of the reusable is packaged for components, Eg:transform, Rigibody, Render, camera, ***.cs scripts, and in order to facilitate the use of non-built-in components, You can use Gameobject.addcomponent<t> (), gameobject.getcomponent<t> () to add, get components (typically custom scripts).

Here I give a practical example, in the second edition of "Unity 3D mobile game development" in the "Space shooting game", there is a need for the gameobject in the game to add automatic destruction of the function (through the time timer, or trigger add), the code is very simple, less than 100 lines, To add the Gameobject have 5, 6, although the workload is not small, but always can not be copied over the code.

At first I did it according to OOP,

Looked for a few days, very uncomfortable, and later reconstructed as:

This makes the function of the auto-destroying component more flexible and maneuverable, that is, it does not have to adhere to the static idea of inheritance.

From this refactoring process, I learned the sparkle of unity's idea of components ...

Appendix: Complete Auto-destroy component code:

public class Autodestorycomponent:monobehaviour
{
#region Icancache
Public particlesystem[] M_pss = null;
public int m_life = 1; 3 lives
public float m_autodeadtime = 3;//3s Automatic Destruction

private int m_life_base = 3; 3 Life "Recovery"
private float M_autodeadtime_base = 3;//3s automatically destroys "Recover with" "-1: means not automatically destroyed, such as enemy"

    void Update ()  
    { 
       //need to automatically destroy  
        if (m_autodeadtime_base >= 0)  
         { 
            M_autodeadtime- = Time.deltatime;

             if (m_autodeadtime <= 0)  
             { 
                 Innerdead ();  
                 return; 
            } 
       }

         if (m_life <= 0)  
        { 
             Innerdead ();  
        } 
   }

   //< summary> 
   ///Set automatic destruction data  
   //</summary> 
   //<param name= "life_base" > Default health </param> 
   //<param Name= "Autodeadtime_base" >-1 not automatically destroyed; Other data represents the destruction time (unit s) </param> 
    public void Setbasepara (int life_base = 1, float autodeadtime_base = 1)  
    { 
         m_autodeadtime = M_autodeadtime_base = autodeadtime_base; 
         M_life = M_life_base = life_base; 
   }

   //whether enabled &NBSP
    public bool Isuse {get; set;}  
   //post-death position  
    public Vector3 deathposition 
     { 
        get 
         { 
            return New Vector3 (2000, 2000,  
       } 
   }

   //Resurrection  
    public void Init (Vector3 position, quaternion rotation)  
    {  
        transform.gameObject.SetActive (true);  
         transform.position = position; 
         transform.rotation = rotation; 
        isuse = true; 
        foreach (Particlesystem item in M_PSS)  
         { 
            item. Play (true);  
       }

Some around
M_life = M_life_base;
M_autodeadtime = M_autodeadtime_base;
}

private void Innerdead ()
{
Isuse = false;
Transform.position = deathposition;
foreach (Particlesystem item in M_PSS)
{
Item. Stop (TRUE);
}

This.gameObject.SetActive (FALSE);
}
#endregion
}

Includes the audio, Transform, Camera, Image, button, and so on that comes with the system. Gameobject is a container that does not have an image of Gameobject, as long as a new empty Gameobject is added, and the image component is an extremely image Gameobject object.

That is, in the Unity3d, rarely use the concept of gameobject.id, but with Gameobject.tag, gameobject.name to distinguish between different gameobject, and Tag, name is not unique.

Conclusion: in Unity3d, everything is Component.

C # Programmer's Consolidation of Unity 3D notes (13): Unity 3D component-based thinking