Question on Player UUID set to fixed value "player" on prefab

[Cat_Hill]

So I can’t help but wonder that this is a workaround to avoid having a Singleton class

Combined with GameObject.FindWithTag(“Player”) it seems functionally this is the same thing as a Singleton . It’s kinda funny that is has some analogous limitations… e.g. what if we want a two-player game?

I’m being a little silly. This is all fixable stuff honestly but unless I’m missing something I don’t see any practical difference with the exception that the Singleton is more explicit because it follows a well known design pattern.

[Brian_Trotter]

It both is and isn’t an end run around Singletons.

It is, in that the way we have our game designed, there can be only one. We’re choosing as a matter of design to have the player in every scene with some things hooked up in advance (like the cameras holding a follow, for example). We could work around that with initializers on the camera that looks for PlayerController.Instance and sets the targets.

It isn’t in that for our saving system to work, we still need a consistent identifier for the player’s save data, whether or not our player is a Singleton.

Here’s an interesting alternative setup that doesn’t keep the player from scene to scene but still allows you to use Instance.

private static PlayerController instance = null;
public static PlayerController Instance
{
    get
    {
          if(instance==null) instance = GameObject.FindWithTag("Player");
          return instance;
    }
    private set
    {
          instance = value;
    }
}

void OnDestroy()
{
     Instance = null;
}

Now the first time within a scene that a component calls PlayerController.Instance, the property will locate and cache the instance. As soon as the scene changes, that instance is destroyed and the cycle starts anew.

[Cat_Hill]

@Brian_Trotter

It isn’t in that for our saving system to work, we still need a consistent identifier for the player’s save data, whether or not our player is a Singleton.

Thanks. I look forward to seeing how you handled save and load with JSON and what parts of JSON’s inherent structure you took advantage of.

One question on the below here:

@Brian_Trotter

Here’s an interesting alternative setup that doesn’t keep the player from scene to scene but still allows you to use Instance.

Is the idea that when you de/serialize the above (or anything where you need that stable consistent identifier) you would do some special handling if the object in question is the player instance?

[Brian_Trotter]

@Cat_Hill

Is the idea that when you de/serialize the above (or anything where you need that stable consistent identifier) you would do some special handling if the object in question is the player instance?

In terms of serialization, no special handling is required. The Player is saved using the same manner and mechanism as any other SaveableEntity. That’s the beauty of the system, it doesn’t care what’s being saved, only that the SaveableEntity has a unique identifier and the components are ISaveable.

@Cat_Hill

I look forward to seeing how you handled save and load with JSON and what parts of JSON’s inherent structure you took advantage of.

Json purists might argue my solution isn’t a true Json structure, but NewtonSoft’s Json serialization library is rapidly becoming a standard and both Unity and Unreal now include the libraries automagically.

In the BinaryFormatter saving system, we serialize a Dictionary<string, object> where each of those objects are themselves Dictionary<string, object> and then the ISaveables convert the objects to their respective data.

In the Json saving system, we serialize a JObject (which is, in fact, a Dictionary<string, JToken>), each of those JTokens are actually JObjects (again, Dictionary, JToken), and each ISaveable decodes the JToken for it’s data. In my system, I make liberal use of JArrays and JObjects (all of these components are in the NewtonSoft library).

[Cat_Hill]

@Brian_Trotter

In terms of serialization, no special handling is required. The Player is saved using the same manner and mechanism as any other SaveableEntity. That’s the beauty of the system, it doesn’t care what’s being saved, only that the SaveableEntity has a unique identifier and the components are ISaveable.

Oh Ok. I think I misunderstood and thought you had a way without manually setting an ID on the Prefab. We’d still manually set a unique ID (e.g. “Player”) on the prefab with this approach right?

[Brian_Trotter]

That is correct. That’s just so that the Player in each scene has the same ID, so shares the same save data. We don’t want that with enemies, of course, so they get the GUID.