Question 1: A game clock
I use a CSyncTimer class designed independantly of the frame rate just as you imagined. It performs several key functions.
A) It controls the frame rate to keep things running smoothly. On fast frames, it pre-processes information for the next frame, and can optionally perform any number of sorting algos, and memory segment re-ordering (to speed up later access). On slow frames it is able to potentially flag some less important tasks as either to-be-dropped or to-be-performed-later. Most of this stuff may be a little over the top, but I got carried away...
B) It exposes a timer, starting from the moment the app begins. Additional custom timers can be requested from the interface, starting and stopping at any point. The main timer is what you'd use to syncronize your events. You record the time an event last occured, then check how much time has passed since then to determine if it's time for the next event.
Question 2: The entity heirarchy
I have a base engine class with controls this type of thing, and is (ideally) designed to allow different types of games to use its system... Only time will tell if this actually works.
I have a Base Entity class which has the potential to be basically any type of object. The Entity class holds all basic information, Location, Velocity, Mass, etc, as well as a pointer to a Base Visual class. This Base Visual class has several derived children which allow the entity to persist as either a Static Mesh, a Skinned Mesh, a Particle System, or any other custom object style you may desire, without changing the Entity interface.
/* Edit */
BobMcGee123 beats me to it, and ultimately, he's right, its all a matter of what works for you.
