An attempt without TurnSystem Singleton

Unity Courses Show
,
#1

After learning about the static events, I was curious if I could develop the TurnSystem and TurnSystemUI code without the singleton. It turns (no pun intended) out that it works. My revised TurnSystem class below. The caveat is that you must add the end turn button’s onClick listener through the inspector and not on the TurnSystemUI’s Start() method.

using System;
using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class TurnSystem : MonoBehaviour
{
    private static int turnNumber = 1;

    public static event EventHandler OnTurnChanged;

    public void NextTurn()
    {
        turnNumber++;
        OnTurnChanged?.Invoke(this, EventArgs.Empty);
    }

    public static int GetCurrentTurnNumber()
    {
        return turnNumber;
    }

}

Edit: I changed the name of the event to be OnTurnChanged just like Hugo has in the course. I found OnTurnChanged to be semantically more correct than what I had put (OnNextTurn). In the later lecture I found it very helpful to have that sematic cue that the turn already changed rather than a next turn request getting triggered but not necessarily executing.

#2

Note that while this is not technically a singleton, it still has - and suffers from - every ‘issue’ that singletons have, and it’s also a little harder to use.

#3

I’m going to caveat this with “I’m not an engineer” but that I am interested in learning. I also would like to avoid a philosophical debate :grinning_face_with_smiling_eyes:

My main change was to remove instance level fields so that the code could function the same regardless of the number of instances created. I figured that was an improvement. I guess the event could be changed to not require any parameters and the whole thing can become a static class? Interested in what would be material improvements here.

#4

I’m not discounting what you did here. There are so many ways to do things. I merely mentioned that it’s not much different from a Singleton. Not knowing your final goal at the time, my first assumption was that you were attempting to avoid a singleton.

Ditto. I personally have no issue with Singletons, but others do. So, I thought I’d just mention it

This would be the result, so you succeeded in that. Singleton does the same thing, though. The way a singleton is set up (in Unity, at least) doesn’t care how many instances are created either. It will just keep the first instance and kill all subsequent instances.

A MonoBehaviour cannot be static so this would not work.

#5

I’m curious if you would have approached it differently or if you think the Singleton is the best option here.

Since I haven’t taken the whole course yet I actually don’t know the full consequences of any one design choice. For me the purpose of my exercise above was really just practice and learning with trying things different ways and seeing the consequences and limitations first hand.

#6

Personally, I would have stuck to the singleton. It doesn’t necessarily make it the best option, but it’s fine for me. Your way will work, too.

Nothing wrong with that. It’s the best way to learn.

#7

For anyone curious - the approach I have breaks in a future lesson because I need to be able to call NextTurn() from outside the button and I don’t have a reference to it now that I don’t have the singleton.

While I’m sure I can create a workaround to get an instance reference to call NextTurn(), it does seem best to keep a consistent pattern across a few objects rather than have so many one-off implementations each having their own quirks. So ends the experiment.

#8

Wasn’t it actually mentioned one could do it by assigning the TurnSystem from the scene to the button and hook them up in the inspector, but that this would not be the way to go since later on the direct access will be needed? Or was this bit patched in later into the video?

#9

It’s been quite a while since I posted this but from what I remember, it ended up not being worth it. This little trick worked for one lesson but since so much of the game relies on singletons you’d need a bigger architectural change to get the whole game to work without singletons.

I don’t have a philosophical problem with singletons. It’s just that having multiple singletons seems to make script execution order a big problem. The 4-part RPG course teaches some nice techniques there to avoid circular dependencies if you’re having those sorts of issues.

Privacy & Terms