No, there is absolutely no standard pattern.
My advice is to avoid the novice OO design pitfall of trying to find a single common "base class" interface for everything. Your Dragon is vastly different from your Wizard, and there's nothing to gain by attempting to merge the two interfaces, except cute code abstractions. Remember, inheritance is not a tool for code reuse.
The simplest approach is for each object to maintain its own internal state (as you have already described), and be able to draw that state. This is where an old school switch statement may be more clear than using polymorphism for the same effect. Example:
class Dragon {
enum State { asleep, flying, breathing_fire };
public:
void draw () { /* old-school switch */
switch (cur_state){
case asleep: draw_asleep ();
case flying: draw_flying ();
case breathing_fire: draw_breathing_fire();
}
}
private:
void draw_asleep ();
void draw_flying ();
void draw_breathing_fire();
};
Experienced C++ developers will gasp at the above code (as they should), because the switch statement is almost exactly what a polymorphic method call would accomplish -- runtime dispatch. (Or even more cryptic: a table of method addresses.) My personal opinion is that for this specific type of class, i.e., a single public interface encapsulating a state machine, the switch statement is more clear and maintainable because it makes the state machine jump explicit. I think it's also clear that I recognize this is generally bad C++ design.
The friction of this design is caused by the dividing line between the state machine and the single public interface. A sleeping dragon is clearly not the same as a flying dragon. In fact, it will have just about nothing in common. But the higher level design says that the two are the SAME dragon. What a mess! Do you create different Dragon objects for each state? No, because that would expose the state concept to the caller. Do you create different internal helper objects for each state and dispatch to those? Possibly, but it gets messy quickly. The above approach is a compromise between the two. Think of the switch statement as isolating the ugliness. The public interface is clean, as is the private interface. Only the switch statement contains the dirty mess. Consider this approach, and also consider other suggestions as well.
Finally, to draw your Wizard and your Dragon, a simple wrapper template or functor will suffice:
struct Draw {
template <class S>
void operator()(S& s) { s.draw (); }
};
The point is that you don't have to merge two different classes just because they both support the same logical operation.