How to make a custom event system framerate friendly?

Question

I have a simple event system:

class GameEvent{
    float executionTime;
    Action action;
}

class EventMgr : MonoBehaviour{

    List<GameEvent> events = new List<GameEvent>();

    void Update(){

        float timeNow = Time.time;

        for(int i=events.Count - 1; i >= 0; i--)
        {
            if(timeNow >= events[i].executionTime)
            {
                exents[i].action();
                events.RemoveAt(i);
            }
        }
    }


    public void ScheduleEvent(float delay, Action action){
        events.Add(new GameEvent(){
            action = action,
            executionTime = Time.time + delay;
        });
    }
}

Then,

I schedule events like this:

eventMgr.ScheduleEvent(0.1f, () => {
    // EVENT A - should be fired first
};

eventMgr.ScheduleEvent(0.15f, () => {
    // EVENT B - should be fired second
};

Everything works fine when I play on 60 FPS. Update() is fired once every ~0.016s. When I play the game on a device with 20-40FPS - things got a little bit tricky. Events seem to run in an incorrect order (Event B fired before event A).

The only possible cause is of course the framerate itself. If the game runs at 20FPS, Update() would be called less frequently and both of these events would be fired in the same frame - and then, the order of their execution depends on the list itself.

What to do here? Is there any trick to prevent this, is there any pattern for accurate, ordered event system in games which is FPS friendly?

Answer 1

This looks like you could solve it with a priority queue or min-heap. The code to process the queue would look something like this:

while(eventQueue.Count > 0 && eventQueue.Peek().executionTime <= Time.time) {
    eventQueue.Dequeue().action();
}

This means you have only one check to do on frames when no events happen - you don't have to scan the whole list.

The nature of the priority data structure ensures that the next event to fire is always the first one you check, and when multiple events fire in the same frame, you process them in non-decreasing order of executionTime.

Insertion and removal from such a data structure are typically logarithmic, so they remain reasonable even for large collections of events.

Answer 2

If sufficient time passes between Update calls to trigger multiple events, then as you note the actual firing order depends on the order in which you process the list. Since you process the list backwards you will evaluate and thus potentially fire "later" events sooner.

If you want your events to create an implicit dependency through their firing time (e.g., an event A with an absolute time Ta must fire before any events with absolute time Tn > Ta), then you need to ensure you process them in that order.

In your case, you could just sort the list by absolute time, either before you process it in Update or by ensuring during scheduling you put new events in the proper sorted position.

Sorting the list backwards by absolute time means you can continue to process it backwards and rely on the efficiency of removing items from the end of the list (versus from the beginning, which would require moving the remaining items down).