Abstract Interface for managing Init/Shutdown
I'm afraid to say I don't like this design. You seem to have put quite a lot of thought into it, but you really don't gain much with it.


This is not an interface in the usual sense: it has state. Interfaces are collections of (usually) pure-virtual functions (with perhaps a non-pure virtual destructor) with no non-static data members. Multiple inheritance is tricky, picking up state from multiple bases just makes it trickier.
Implementing your interface forces every user to add a bunch of boiler-plate code for your design to work. That doesn't scale, leads to copy-pasta bugs (or forgetting to copy/paste bugs).
Your goal: "make resetting [the components] easier". Your interface reads like "provide a way of initializing and shutting down things". Minor semantic nitpick but a reset interface should have only one method: reset. This ties into the next point:
"unless I track the [...] state of the object [...], undefined behavior could creep in." - this is not good C++ design. Your objects should be responsible for their invariants, not some third-party addon to their class structure. Constructors should establish the invariants, destructors should to whatever cleanup is required. In between, i.e. when the object is alive, all its public members should maintain a consistent state. That you're worried about undefined behavior if you call a method "out of sequence" seems to indicate that you're not (sure of) following this rule. If that's the case, then you should fix your classes to follow it rather than try to tack on something artificial from outside, with its accompanying boilerplate.


So if you want to stick with this resetting interface, I'd go with something much simpler:

struct Resetable {
  virtual void reset() = 0;
  /* or, if passing in the "new state of the world" is needed */
  virtual void reset(GameState &amp;) = 0;
};


Your classes must know if they need to release resources or not when reset is called (you can't write a correct destructor if they don't). For some of your classes that reset member will be trivial, for some others it might need to call into several helpers to get the job done - that's fine. Its the class's job to know how it needs to be reset, the public interface shouldn't expose that complexity.

You might also want to take a second look at your class hierarchies and figure out whether this actually should be an independent interface or if reset should be directly in the base class(es).

Or you could drop that interface completely and just use the C++ builtin stuff to create shiny fresh objects and get rid of them: constructors and destructors.



Random thoughts:


Your classes, methods and data members all start with capital letters. That seems a bit strange to me. But if you apply it consistently, well, that's your choice.
Init and Shutdown don't return anything, so the only way for them to signal failure is exceptions (or just terminating the program). That's fine if you use (and handle) exceptions, otherwise you should make them return some sort of status or error code (same for reset if you go that route).
Careful if you run multiple threads, the posted code isn't thread-safe.
const bool &amp;IsActive; seems like a pessimisation to me. I don't think compilers will optimize that reference member out, so you're adding something like a pointer on top of the bool overhead to each and every implementer of the interface. bool isActive() const { return IsActive_; } would almost certainly be inlined and has no per-object overhead.