Announcement

Collapse
No announcement yet.

Cleanest singleton "manager" pattern implementation

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Cleanest singleton "manager" pattern implementation

    I have been pondering the best way to implement singleton "manager" like objects in Unreal that are performant, mutliplayer-friendly, and clean (at least, as clean as a singleton can be).

    I was wondering if anyone had any input or prior experience that they could add. Here are the different solutions I have brainstormed:

    Each manager as a single replicated actor.
    Easy to contain state and logic within each actor, but not easy or clean to get references to these objects.

    Put state and logic in GameInstance
    Probably the most "correct" way to do it, but if all state and logic goes in the GameInstance it will quickly become bloated. Since GameInstance is not an actor, ActorComponents cannot be used to subdivide state/logic. C++ UObjects could be used, but replication would have to be done manually which would be a hassle.

    Put state and logic in GameMode
    Has the advantage of being an Actor so ActorComponents can easily be used to segment replicated code. However, it only exists on the server so if a client needed a piece of information it would have to go through a server call.

    Put state and logic in GameState
    Has the advantage of being an Actor so replicated ActorComponents can be used. Exists on both client and server as an easily accessible singleton. But, all documentation on GameState makes it seem like it should only be used to hold state, so this seems like a misuse of the class.

    If there are any others ways I should go about this, I'd appreciate other ideas. Using GameState seems like the most clean solution, even though it technically misuses the class.

    #2
    If you just want to store global assets you can setup a Singleton Class for that in project settings and access it through GEngine->GameSingleton.

    It's also a good idea to forget about Unity's pattern of "managers". There's plenty game mode classes to manage everything needed.

    One way I usually break (or expand) a little on game mode framework is that I implement state machine components on GameState and/or GameMode depending if it's a single-player or online project...

    This is also reason why I built a state machine based on Components instead of hierarchical UObjects.
    Last edited by BrUnO XaVIeR; 07-16-2019, 11:16 AM.
    | Savior | USQLite | FSM | Object Pool | Sound Occlusion | Property Transfer | Magic Nodes | MORE |

    Comment

    Working...
    X