This is the third day of my participation in the August Text Challenge.More challenges in August

Recommended reading

  • CSDN home page
  • GitHub open source address
  • Unity3D plugin sharing
  • Jane’s address book
  • My personal blog
  • QQ group: 1040082875

One, foreword

Unity is a component-based game engine. This article explains what this is and how to use it effectively.

Second, the GameObject

In Unity, GameObject is almost an empty object. It’s the foundation of everything else. It’s just a raw object with component space. The GameObject itself does nothing unless we add a component to it.

Third, the Components

We wanted to create a monster in the game. In Unity, this is done as follows:

  • Create a GameObject
  • Add 3d model Conponents
  • Increases health Components
  • Added skill Components
  • Add a moving component
  • Added AI Components
  • Add a few musical Components
  • Added to display the name GUIComponents

So basically every time we want to add something to our unified world, we create a GameObject and then add components to that GameObject. In Unity, components can be scripts, sounds, grids (3D models), rigidbodies, colliders, and so on.

In the example above, life, skills, movement, AI, and GUI could be scripts. This raises the question: Why don’t we just create a Monster script and put it all in instead of breaking everything up into components?

Well, you can do that. If you like it, do it. But imagine this: we want to create another thing in our game world, this time the player. We will take the following actions:

  • Create a GameObject
  • Add 3d model Conponents
  • Increases health Components
  • Added skill Components
  • Add a moving component
  • Add a few musical Components
  • Added to display the name GUI Components
  • Add an experience Component
  • Add a sword component
  • Add a shield component

Now, here’s the beauty of component-based systems: we can reuse the components we use for monsters! So, all we need to do to create a Player is take most of the components we used for monsters earlier (like Health), add them to the playplayer, add some new components (like swords and shields), and we’re done. This would save us a lot of work compared to creating a single Player script, where we would have to reprogram everything.

That’s it. It’s that simple. It’s just a clever way to keep us from doing too much work.

Component-based development: Tips and tricks

Accessing components on the same gameobject

Thus, our player has two scripts (also known as components) :

  • Life script
  • Move the script

A component with current maximum health and current health worthiness might look like this:

using UnityEngine;
using System.Collections;

public class Health : MonoBehaviour {
    public int current = 50;
    public int maximum = 100;
}
Copy the code

A move component can be moved to where the player clicks, as shown below:

using UnityEngine;
using System.Collections;

public class Movement : MonoBehaviour {
    void Update() {
        if(clickedSomewhere()) { moveToDestination(); }}}Copy the code

We then drag the two scripts onto the Player’s GameObject so that they look something like this:

Now obviously dead people can’t move, so how do we stop the moving component from doing its job when the player dies? We need a way for components to communicate with each other. Obviously, they are in the same gameobject (Player), so there must be some way.

Good news: There’s a very simple method called GetComponent.. Here’s how to get a game object:

GetComponent<Health>()
Copy the code

Note: This means “get a component of type Health.” Now that we know this, we can easily modify our move script so that it can only move when the player is still alive:

using UnityEngine;
using System.Collections;

public class Movement : MonoBehaviour {
    void Update() {
        if (GetComponent<Health>().current > 0) {
            if(clickedSomewhere()) { moveToDestination(); }}}}Copy the code

That’s all. We need to keep in mind that the same GameObject can use the GetComponent function.

Access a component on another gameobject

Ok, so the question is, how does the component relate to other game objects. For example, how do we extract monster health from the player’s script?

Our GetComponent function only works with the same gameobject, so we need to come up with something else.

Don’t worry, it’s easy too. Suppose we have a Monster GameObject that comes with the Health script above:

We have a Test script:

using UnityEngine;
using System.Collections;

public class Test : MonoBehaviour {
    void Update() {
        // ToDo: is monster alive?
        // then do something}}Copy the code

It will be attached to the player’s gameobject:

So the question is, how do we extract monster health from the player’s Test script?

That’s easy, too. We just need to use a common type of Health variable, which can be made up of any type of Health (in our case, it will be the monster’s Health). At this point we modify the test.cs script:

using UnityEngine;
using System.Collections;

public class Test : MonoBehaviour {
    public Health monsterHealth = null;

    void Update() {
        if (monsterHealth.current > 0) {
            // do something}}}Copy the code

If we look at it for a second, we’ll quickly realize that it doesn’t make sense at all. The monster health component is NULL, so accessing it is a bad idea. But wait, because it’s public, we can now see one of its fields in the “Unity Inspector panel” :

That means we can drag something into it so it’s no longer empty. So let’s drag a monster GameObject from the Hierarchy panel to the monster health slot of our Test script:

The slot looks like this:

This means that our public health variable points to the monster’s health. So our Test playbook works.

This is how we access components on other gameobjects!