3D Masons, LLC

I notice you are using C++. However with your timer you only take a normal C function which breaks the C++ idea. If you wish to have a flexible way to assign events you could take a look at the event code I posted in the store. http://www.leadwerks...le/367-c-event/

 

This allows you to bind class methods as callbacks instead of normal C functions which end up breaking OOP. So for example my timer class looks something like:

 

class Timer
{
// leaving out variables. this is just to get the idea
public:
Timer(float interval);
void Start();
void Stop();
void Update();
Event0 OnTick;
};

// usage
class Actor
{
private:
Timer* tmrTest;
void tmrTestTick() {}
public:
Actor()
{
// create a new timer
tmrTest = new Timer(2000);

// bind the callback of the timer to a method of this class to keep the OO idea
// notice how I can even bind to a private method and it still works! this is great so that the tmrTestTick() isn't exposed to the outside world because why would you want it exposed right?
tmrTest->OnTick.Bind(this, &Actor::tmrTestTick);
}
};

 

When creating a framework these events can really help decouple your classes so they can easily be exchanged/changed without breaking things. For example in your actor class you can define an Event for OnHurt, which the actor will fire when they take damage. Any class can register to receive this event during the creation of the game.

 

Let's say you want a HUD class to know when the player was hurt. You could tightly couple the HUD class and player class together by passing references of each or 1 or the other. You could poll the player class and pass it or it's data to the HUD class every cycle OR by registering to the players OnHurt event at startup, your HUD class could get member methods fired automatically from the player class when it raises it's OnHurt event. No coupling of the classes, and no polling, so the code becomes more flexible and more efficient.

 

Just an idea.

Ah, thanks Rick.