MMDX: Not state-friendly

Programming in XNA, it seems like you subclass off Microsoft.Xna.Framework.Game, and that... I guess is expected to contain a bunch of basic objects, like a GraphicsDeviceManager. The GraphicsDeviceManager also has some functions it uses to draw things, except...

... I'm handling drawing in the game states right now. I've got a stack of states, each with a draw method, and to draw, they need to get to the GraphicsDeviceManager object. The models, in order to load themselves, need to get at the ContentManager object... which XNA will sets up automatically in Microsoft.Xna.Framework.Game, not my subclassed Game object (though as a subclass, it does contain both manager objects).

At first, I was just passing the instance of my subclassed Game all over the place, until I thought of how much of a pain that was. So I took a page from MMDX.

protected static GameIR s_Instance;

public static GameIR Instance {
  get { return s_Instance; }
}

public GameIR() {
  m_Graphics = new GraphicsDeviceManager(this);
  Content.RootDirectory = "Content";

  if (s_Instance == null) { s_Instance = this; }
}

So there - this is how MMDX handles the fact that only one instance of it should be around (you access it by using MMDXCore.Instance, a static accessor), and this is how I'm going for now. The conditional there is to prevent any overwriting from happening... though I imagine that a second Game object would never be created, this prevents my previous Game object from going away and drives in the point that your second Game object won't do jack. Anytime you need to get at those two managers, you get the Game instance with GameIR.Instance, then use whatever accessor you use for them.

The way MMDX does this actually is a bit problematic when dealing with state programming, as each call to GameIR.Update(GameTime) has the call...

MMDXCore.Instance.Update((float)Time.ElapsedGameTime.TotalSeconds);

... which as far as I know is mandatory if you want, say, the animation you're using to keep playing. This isn't a problem until you use states - all states that aren't active, their animations should stop, but every time you call this (perhaps to play an animation in the current state), all animations are updated, including the ones you don't want to be played. This is why I have Pause and Resume functions in each GameState, for when they become inactive and activated again.