Is it ok to create a static class for easy access to scripts initialized often from...

Unity Engine
1

other objects? Is this better from a perspective of performance compared to having do a GameObject.Find()? Thanks.

2

As long as you understand the limitations that come with the structure you define in said static class.

You’re basically describing a very loose version of the Singleton pattern. Google about that for the various debates about how that pattern is often abused and leads to bugs and spaghetti code.

2 Likes
3

Ok, I won’t use it unless necessary then, thanks :).

4

Do note, GameObject.Find() is also a slow beast of a bad design.

You should really be setting up references via properties on your script.

1 Like
5

Ok, I’ll look into that. Thanks again.

6

I had to do the following to be able to use the transform as a property:

private Transform playerTransform = GameObject.Find(“Player”).transform;

Is there any better way to do it?

7

make the field ‘playerTransform’ public, and drag the playerTransform onto it.

1 Like
8

You’re of great help.

9

Keeping it private and using the [SerializeField] attribute allows this as well.

1 Like
10

I’m not sure how to make this work when creating properties in a class inheriting from MonoBehaviour. Do I have to make the class static?

11

nope, just public properties (or private with SerializeField), attach the script to a gameobject, and you’ll see the property in the inspector.

12

I’ll copy paste my code so I can try to explain it better:

public class PlayerInputs : MonoBehaviour
{
   ...
    public CapsuleCollider playerCapsuleCollider;
   ...
 
    public CapsuleCollider PlayerCapsuleCollider
    {
        get
        {
            return playerCapsuleCollider;
        }
    }

void Awake(){
    playerCapsuleCollider = GetComponent<CapsuleCollider>();
}

how do I access that property? I tried:

private PlayerInputs myPlayerInputs;
private CapsuleCollider playerCollider;
...

Start(){
        myPlayerInputs = new PlayerInputs();
        playerCollider = myPlayerInputs.PlayerCapsuleCollider;
...
}

This returns null. I also tried: myPlayerInputs = gameObject.AddComponent();

13

I never feel the drag approach is the correct one. But then I did get a corrupt scene that one time, so yeah. Easiest approach for learning though.

14

You don’t create ‘new’ MonoBehaviours.

They’re components, that you drag and drop onto GameObjects.

Unity uses a component design pattern… watch this:
https://unity3d.com/learn/tutorials/modules/beginner/editor/game-objects-and-components

15

Ok, so I guess I have no choice but to not have the class inherit from any other to make it work then? I have some planning to do.

16

you can create a base class that inherits from MonoBehaviour, and then inherit from that, if you have some design pattern that requires it.

And if there are any classes that already exist outside of the unity framework, you composite them into a MonoBehaviour.

1 Like
17

Thank you, this will solve a lot of my headaches.

So I created a class :

public class PlayerPropertiesMonoAdd : MonoBehaviour
{

}

and let PlayerInputs inherit from it, but that didn’t solve the problem:

public class PlayerInputs : PlayerPropertiesMonoAdd
{
…
}

I’m probably missing something :/.

18

For now I’m doing it in a very ugly way, I really don’t like using 2 ‘Find’. Any further help is greatly appreciated.

public class PlayerPropertiesMonoAdd
{
    private Transform playerTransform = GameObject.Find("Player").transform;
    private CapsuleCollider playerCollider = GameObject.Find("Player").GetComponent<CapsuleCollider>();
 

    public Transform PlayerTransform
    {
        get
        {
            return playerTransform;
        }
    }


    public CapsuleCollider PlayerCollider
    {
        get
        {
            return playerCollider;
        }
    }
}

        myPlayerInputs = new PlayerPropertiesMonoAdd();
        targetTransform = myPlayerInputs.PlayerTransform;
        playerCollider = myPlayerInputs.PlayerCollider;