The first two aren't really that much different IMHO. You still have a statically acquired instance on which you call the method to add messages. Singletons are global variables in disguise, so if you don't like the first approach because it remind you of a global variable (which it is), what makes you like the second any more?

The third approach is a step in the right direction.

Ask yourself if the observer really needs to know all the conditional stuff about the Hero or Skill, which couples it to those classes.

A better way would be to make the Observer an interface, and implement it in a CombatObserver. Also, to make it work, the addMessage method should have a messageType discriminator, which can be Combat, Trade, ExperienceGain (or what have you), and each inherited observer class only listens to a certain type of message, and logs it to the appropriate GUI element. And in your Hero and Skill classes, have a list of Observers (the interfaces) which were registered to listen to events in that class instance. Every time you do something you might want to log, simply invoke the addMessage on all observers with the type of the message and its contents, and let them decide if they should log it or not. This decouples your Hero/Skill/other classes from knowing what observer is listening to them, and makes it possible for more than one observer to listen to messages from that class instance.

A full blown solution might be implementing some sort of event system, so the observer simply subscribes to events that you classify as "combat event" and logs them appropriately, which decouples your Hero and Skill classes from even knowing they are being observed.

And in your Hero and Skill classes, have a list of Observers (the interfaces) which were registered to listen to events in that class instance.

So you saying have a static list in the classes (so I guess like a scoped global), or have a per instance list and some way to populate it without a global (perhaps a UnitCreated observer setup at the start of the game/level/map/whatever)?

One thing I found to be helpful, although more difficult if you want to have an event queue, was to have different methods for stuff, e.g. rather than "addMessage(type, parama, paramb)" or "addMessage(conts Message *message)" where Message can have derived types, is to just have like "unitKilled(const Unit *uint, const Unit *by, const Weapon *with)" and other specific things. Not sure what the standard way is as such, seen all three around. The first one I have only seen for Win32 events, and is a pain because in complex cases people start bitpacking the parameters, or say if type == foo then paramb is actually a pointer...

No, have it on a per instance basis, and fill it up in a factory, factory method or a special method that creates these objects for you. Maybe at some point you want to create a Hero instance, but not listen to any of it's combat logs? Simply don't register any observers. A static list might be useful if you want to listen to every combat (or any other type) event regardless of instance, but IMO that makes the system inflexible.

As for having specific functions for logging specific events, i see that as an evolution of the simple method addMessage(type, content), but it makes your event logging very specific and closed for reuse an another game. Passing a Message* into the method makes it a bit more generic if the Message class is an interface with a getEventString() method which the observer implementation can call to get the log text, again, not caring of what the text actually is.

I believe that every class should be made to know as little about other classes or their specific implementation as possible. You can do it either by using interfaces (thus only depending on the interface) or by passing events around, and dispatching them to handlers, again, via interfaces.