Sign in to follow this  

Timers and things that need timers.

This topic is 4200 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

A bunch of things in my game will eventual need timers or some knowledge of the passage of time. Sprites need to know when to change to the next frame in an animation. The characters/particles/bullets will need to move a certain distance over time. certain events or actions should need to happen at specific time intervals apart from each other. What’s the best way to handle this? Have a master system timer call in the main loop and pass a delta value down to all objects by iterating over all of them while calling their individual "update methods"? ----This is what I used in the past. Have each object call the system timer and maintain its own delta value? Using some kind of messaging system where by objects request they are sent a notification at a certain time by a central time keeper?. ---- never done any thing like this before so I would need to be told how. Have objects send themselves messages, a message to the future so to speak, where objects start a timer with a callback that sends the notification to it self?

Share this post


Link to post
Share on other sites
Whatever.

It depends on the number of objects that will need to be updated, the accuracy of time needed, if there's some synchronization (with network clients) to be wary of...

Share this post


Link to post
Share on other sites
There's two points here.

Firstly, you need some sort of global 'what time is it' source. There might well be one already, but if it doesn't expose the right interface for your problem, you should write your own. It just needs to be a thin cover on some other form of updater. For example ...

public class Time {
public static int MsecSinceStart { return (int)((DateTime.Now.Ticks - StartTicks) / 10000;) }
static long StartTicks = DateTime.Now.Ticks;
}


You ought to be able to call this from anywhere, and it should be threadsafe (not hard for such a simple task). This is one of the few places where a global (or static class) is good, time ought to be synched across the application.

The other thing is updating objects so they can perform their action. There are a variety of ways to do that, depending on how many objects there are and other factors. Two common ways are (i) within your game loop, call each object's Update method; (ii) have an event dispatching system that notifies objects when they ought to do something. Most games will have a combination of frame-by-frame updates and events.

Share this post


Link to post
Share on other sites
I use two methods for handling updating of objects.

The first is to derive objects which require continuous updates from a class called Process. The objects do not become operating system processes; the name merely indicates that the object is one which requires the processor's attention at some point. My typical Process class has a VUpdate function, which is overridden by classes derived from Process. VUpdate takes one argument: the time elapsed since the last update, fTimeDelta. I also generally implement a ProcessMgr object. It is a process itself, and updates all of the child process it manages in it's VUpdate function. Process and ProcessMgr usually have useful additional features, like the ability to pause an individual Process, or all processes attached to a ProcessMgr. As ProcessMgr is a Process itself, you can add one ProcessMgr to another. This is particularly useful for handling different game states; each game state has a ProcessMgr, which it can be paused or restarted as required. Also, by linking to one master ProcessMgr, all game updating can be done with one call to your timer, to get the time since the last update, and one call to the master ProcessMgr's VUpdate method.

The second method addresses events, things which are triggered at a certain time. An EventMgr (which is a Process) keeps track of time, and of which events should be triggered at a certain time. Combined with a messaging system, any object which is a MsgReceiver can become an event-driven object.

[Edited by - iNsAn1tY on June 15, 2006 6:24:12 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Bob Janova
Two common ways are (i) within your game loop, call each object's Update method; (ii) have an event dispatching system that notifies objects when they ought to do something. Most games will have a combination of frame-by-frame updates and events.
How should I determine which kinds of things use which method?

Also could someone give me a quick rundown of how to implement an event dispatching system, I've heard about them here and there but never implement one myself? I know they consist of senders, receivers and a manager, but not much else beyond that.

Quote:
Original post by iNsAn1tY
I use two methods for handling updating of objects.

The first is to derive objects which require continuous updates from a class called Process. The objects do not become operating system processes; the name merely indicates that the object is one which requires the processor's attention at some point. My typical Process class has a VUpdate function, which is overridden by classes derived from Process. VUpdate takes one argument: the time elapsed since the last update, fTimeDelta. I also generally implement a ProcessMgr object. It is a process itself, and updates all of the child process it manages in it's VUpdate function. Process and ProcessMgr usually have useful additional features, like the ability to pause an individual Process, or all processes attached to a ProcessMgr. As ProcessMgr is a Process itself, you can add one ProcessMgr to another. This is particularly useful for handling different game states; each game state has a ProcessMgr, which it can be paused or restarted as required. Also, by linking to one master ProcessMgr, all game updating can be done with one call to your timer, to get the time since the last update, and one call to the master ProcessMgr's VUpdate method.

The second method addresses events, things which are triggered at a certain time. An EventMgr (which is a Process) keeps track of time, and of which events should be triggered at a certain time. Combined with a messaging system, any object which is a MsgReceiver can become an event-driven object.
Your methods seem like they require me to derive many of my objects from either MsgReceiver, Process or both as well as any other inheritance Hierarchies they might be part of . Id like to avoid multiple inheritance if possible would these still work if my objects contained either a MsgReceiver or process instead of inheriting from them?

Share this post


Link to post
Share on other sites
Generally, things that need to perform small amounts of computation frequently (like every frame) should be updated continually, which is what Insanity calls a 'process'. Things that need to do complex computation infrequently, i.e. when something happens or less often than about once a second, should be event driven. All an event is is a message, so if you have a simple message dispatching system (a way of passing information to specific in-game objects) event driven objects are easy.

A simple event system consists, as you say, of a manager which deals with passing the messages around, and objects that can send or receive messages. Pseudocode would be something like:
class GameObject {
public string ID; // used to identify the object

// override this method to do something when an event
// is received
public void HandleEvent(string eventname, object[] args){}
}

class EventManager {
// might just be your main game world
Hashtable<string,GameObject> objects;

public void Register(GameObject obj){ objects[obj.ID] = obj; }
public void SendMessage(string targetname, string eventname, object[] args){
GameObject target = objects[targetname];
if(target == null) return;
target.HandleEvent(eventname, args);
}
}

Share this post


Link to post
Share on other sites

This topic is 4200 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this