God object or where to keep subsystems references

Question

I have many subsystems of my game. They can use each other. Earlier I was initializing and storing subsystems references into static Game object instead of making singleton. Now I see that Game has too many references to other classes and looks confusing:

public static PlayerSettings PlayerSettings { get { return _playerSettings; } }

public static CommunityClient Community { get; private set; }
public static DatabaseConnectionWrapper Database { get; set; }
public static LoginConnectionWrapper LoginProtocolConnection { get; set; }
public static WorldEmulatorConnection WorldEmulatorConnection { get; set; }
public static WorldPlayerConnection WorldPlayerConnection { get; set; }
public static WorldConnection WorldConnection { get { return IsEmulatorMode ? (WorldConnection)WorldEmulatorConnection : WorldPlayerConnection; } }

public static MusicManager MusicManager { get; private set; }
public static SkyboxManager SkyboxManager { get; private set; }

public static VKInfo VK { get; private set; }

What can I deal with it? I don't need abstraction for those subsystems. And I don't think singleton is nice for this situation - architecture looks splitted to pieces. I want to initialize all my subsytems in correct order from one place. But there are too many classes referenced...

---

ADDED
Looking at DI - I can send dependences to class constructor and initialize every class in static factory. This is what I'm looking for.
But I've just realized that my problem that when I'm trying using Unity3D object-component architecture I can't send dependences to constructor because class initialization is invoked from UnityEngine.
So in this case I need Singleton or Blob to keep references. if I throw Unity architecture out then I'll obtain all dependences from constructor and no singletons or blob is needed.
I need to rework my architecture that UnityEngine will not create objects which need to obtain references to subsystems but create these classes from my code and let them create and manage their UnityEngine "gameobjects".

Answer 1

Looking at DI - I can send dependences to class constructor and initialize every class in static factory. This is what I'm looking for. But I've just realized that my problem that when I'm trying using Unity3D object-component architecture I can't send dependences to constructor because class initialization is invoked from UnityEngine. So in this case I need Singleton or Blob to keep references. if I throw Unity architecture out then I'll obtain all dependences from constructor and no singletons or blob is needed. I need to rework my architecture that UnityEngine will not create objects which need to obtain references to subsystems but create these classes from my code and let them create and manage their UnityEngine "gameobjects".

Answer 2

I think you are over complicating things Vlad.

Since your managers, controllers and whatnots don't need to inherit from MonoBehaviour this becomes a simple case of organizing your subsystems under one object that will simply act as a convenience point of accessing them.

If you have manager objects that actually need to have MonoBehaviour then those references can be obtained from the loaded scene via a simple OnLevelLoaded event or something that you yourself will raise from whatever object that will actually trigger scene loading. Once your event is fired, use FindObjectOfType method that is provided by Unity api to find your GameObjects from the scene.

So, at the end of the day one singleton class aka your God object will keep track of all your subsystems, anything scene bound will be collected from the loaded scene by using a simple api call.

That's all there is to it. It may sound complicated but it's not.