1

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".

Vlad
  • 3,001
  • 1
  • 22
  • 52
  • 2
    This is also known as `The Blob` - see http://sourcemaking.com/antipatterns/the-blob. A possible alternative is to consider what your classes are doing; you could have a `PlayerManager` with the Player, Community and Login settings, a `WorldManager` with all of the world classes, and an `EnvironmentManager` for related classes. Each of these breaks down your problem into more manageable chunks. You can then also start to enforce SRP - http://en.wikipedia.org/wiki/Single_responsibility_principle – dash Jun 08 '13 at 22:42
  • I'd be curious to hear why you believe that it references "too many classes"? From your description, this appears to be a reasonable solution to the problem you've described--initialization in correct order. The next best approach would be decoupling each subsystem to the point where each subsystem can compile and function independently, which would also have the benefit of making testing easier :) – Ben Brammer Jun 08 '13 at 22:42
  • 3
    Dependency injection is the usual solution, but you already rejected that. It is not so much God that's the problem, it is how often you invoke His name in your code. Probably a lot when you have that many global variables. So maybe you shouldn't reject DI. – Hans Passant Jun 08 '13 at 22:45
  • @HansPassant, you crack me up man! I'm telling you. Now, as far as you're concerned Vlad, why not go along with what Hans is saying, make your life a little easier, and then use a DI container like Unity to both initialize ***and*** recover these objects. See, with the container you don't need to literally write the code to pass in all the dependencies, the container does that for you, and it can even handle custom initializations and singletons by itself. – Mike Perrenoud Jun 08 '13 at 22:49
  • Where is Vlad's disfavor toward DI mentioned? Did he edit it out during the grace period? – Kirk Woll Jun 09 '13 at 00:54
  • @Kirk Woll, I didn't edit. I mentioned "I don't need abstraction for those subsystems" because those are exist only as one instance and only with one implementation. Also now I'm not going to add unit testing for these systems. And this part of project is not needed to be extensible. – Vlad Jun 09 '13 at 09:04

2 Answers2

0

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".

Vlad
  • 3,001
  • 1
  • 22
  • 52
0

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.

Alex
  • 1,110
  • 8
  • 15