Hm. What about this situation;
I have a class (GameManager) which keeps track of game object interaction. I'm only going to have
one game running, so it would be easier to just make it a static class that way I don't have to pass a GameManager object to each and every object that I create. Certainly it would be easier, but the easy way is not always the best way.
If I took this same philosophy, it could also be applied to my Map class. After all, only
one map is going to be loaded at a time. Okay, maybe I'm reaching with this example.
For some reason this is screaming "stay away!" yet at the same time it just seems to make some odd amounts of sense.
To give an idea, this is a quick run down of what my GameManager would look like if everything in it was made public static;
C#:
GameManager.StaticObjects // ArrayList
GameManager.MovingObjects // ArrayList
GameManager.Effects // ArrayList
GameManager.Update() // Updates Everything
GameManager.Draw() // Draws Lists & Map
GameManager.Ticks // Property
GameManager.Map // Property
Every single object in my game has to reference a GameManager object for several reasons .. 1) It needs to know what map to use for movement, 2) It needs to know where to add game objects (ie; a missile explodes, the missile needs to know where to place its explosion effect), 3) It needs to know about all other objects in the game for collision detection (or AI for computer controlled players), 4) It needs the current tick count to control how it's updated (Calling Environment.TickCount tons and tons of times per a single loop is out of the question, calling it once per loop and putting the value in GameManager.Ticks is needed)
Then of course, there's always making it a singleton rather then a purely static class. :/
One area which springs to mind and there are loads which use Singleton's is the game loop in games programming.
That sentence doesn't make sense.