Static Player Class: Bad idea?

My game is a 2D turn-based dungeon crawler. The player object is never seen or rendered. It doesn't use update or start, and doesn't really rely on unity's interface at all. It is only used as a reference for inventory, stats, etc. Rather than referencing the PlayerScript attached to the PlayerObject, would I be better off just keeping it a Static class since so its easier to reference in other classes? Currently I'm using "GameObject.Find("PlayerObject").GetComponent<Player>()" but this would let me just use "Player".
Im new to unity and am trying to self-teach myself C# after 4 years of no programming, so I'm not very familiar with the uses and limitations of different class types. None of the tutorials I've seen have set Player to Static, but they've also all been or different types of games, such as platformers or purely text-based games.

 

I would say it is fine, but you might want to consider an alternative, which is a singleton. The reason I suggest such is it is a bit easier to work with singleton with canned saving routine than with statics. Also, less important, if you ever decided to do multiplayer it makes doing so a bit easier.

Now a singleton is where you have a static reference to an instance of the class. So for instance, you have a class called Player, and in Player you have public static Player Current;
You can then initialize Current on game start, and use it to reference the Current player all the time. Now you have both a static reference to it so all your scripts can easily get at it, while also having an instance so that any canned that needs such will work fine.

 

Thanks, Derek! I'm a bit confused though, what would the initialization look like? I'm finding a ton of results for initializing singletons and I'm not sure which one I'm supposed to use in this case.

 

There are a few different ways to go about the initialization logic, but they all lead to the same two possible outcomes:

• A singleton that can be replaced with a new instance.
• A singleton that cannot be replaced with a new instance.

An example of the former:

Code (CSharp):

1. //Any time a new "SomeClass" object is created, the "Instance" property gets overwritten with the new instance.
2. public class SomeClass {
3.    public static SomeClass Instance { get; }
4.  
5.    public SomeClass() => Instance = this;
6. }

An example of the latter:

Code (CSharp):

1. //The reference to "Instance" will be assigned the first time "SomeClass" is created.
2. //Any time a new "SomeClass" object is created afterwards, the "Instance" property will not get overwritten.
3. //"Instance" will only reference the first "SomeClass" object created always.
4. public class SomeClass {
5.    public static SomeClass Instance { get; }
6.  
7.    public SomeClass() {
8.       if(Instance == null) {
9.          Instance = this;
10.       }
11.    }
12. }

It's up to you on whichever method you want to go with.

 

I advise against using a static player class. One reason is that it makes your code less reusable for other projects that you are going to work on.

I usually have a normal instanced player but keep a reference to it in a GameManager singleton.