I'm working on a tile game currently, but I'm not quite certain on how I'm going to handle objects. My current plan is to make a base "thing" type, which everything, from npc's to objects are derived from. If it can be seen/interacted with, it's a thing. Is this a good approach to handling this? Or are there any other ways which to handle this?

That's certainly one way (and indeed the way I'm implementing my current game).

There are other ways that are "better" in certain circumstances, but slightly more complicated - like ECS ('Entity Component Systems'). However, I'd stick with a base-class 'Abstract Entity' until you complete at least one decent-sized game. I'd not use ECS on smaller games, anyway.

Also, don't force everything into the base class - some things would just be better separated as something else. Walls, for example, may be better off separated in their own class. Depends on the game and the rest of the project's architecture, though. Just pay attention to how much you have to force-fit one class like a 'wall' into the virtual interface of something like 'Thing', and also watch to make sure Thing's virtual interface isn't getting bloated - recognizable if it gains too many virtual functions, especially if most derived classes don't implement most of those virtual functions.

Yep that's a perfectly acceptable way. Personally I use function pointers to implement polymorphic function calls, general stuff, like send message, update, animate, init, shutdown, etc. These look like normal C-style functions. And then for things that belong in groups I use some kind of iterateable data structure like a linked list, array, or hash table, depending on the scenario. For example say we have some bumpers and when the player knocks into them they play a sound. These bumpers have init and shutdown functions. On init they place themselves into the broadphase and collision system, which is pretty much a hash table. They also place themselves into the array of "live" game objects, so they will get update and animate calls. When shutdown is called, the bumper shutdown function knows to remove itself from these data structures.

Thanks heaps guys, informative stuff!
@Servant of the Lord - Yeah, not going to bruteforce stuff into an abstract system if there's a more viable way to go about it!

@Randy Gaul - I had an idea somewhat similar, this is good stuff thanks!

Time to die and regret my choice of hobbies!

No reason not to use a base class. In my own project, I have a polymorphic and base class which most of my objects actually derive from. The functions are actually context sensitive as well. So I don't need a "OnRead" event for a book. As if you use a book, you're probably reading it anyways. Instead it uses "OnUse" just like any other actor in the game.

If a certain actor does not allow a certain function to be used on it. It either asserts, or does nothing.

This design was actually inspired off of the Elder Scroll games.

One piece of advice is to prefer composition over inheritance. Pushing "common" features upwards in the hierarchy can suddenly start to slow you down if you're not careful. Having a common base class is very helpful, but be sure to not fall in the trap of having a huge feature blob class and many child classes which override a very tiny amount of the features. The transition from a good hierarchy to a bad one is often subtle and hard to notice until it became serious...