# How to schedule 'events' inside a game?

Within a game I want to schedule 'events', like a resource is running out, some storage is full, or a person is born. I see two ways of achieving this:

1. Check on all the parameters every fixed time interval. At that given time, the number of persons are adjusted, the resources are calculated...

2. Calculate the time at which something happens and use a database to store all these events. Create a 'scheduler' which sleeps until the first event happens, and do something. However, if one piece of data changes, all the other items also changes and need to be recalculated.

Is there a general approach how to solve this problem in game design? I hope my question is somewhat clear...

• Are you designing your game or are you programming it? You seem to be mixing both concepts and it makes it hard to understand what you exactly need. Oct 1 '15 at 11:35
• I want to design before programming. Thats the reason I ask this question...
– Alex
Oct 1 '15 at 11:38
• @alex do u really want that on specific intervals ? (Not real-time) Oct 8 '15 at 16:48

Most games go with #1 and a variant on #2

For timed events they use a priority queue to keep the events and in the game loop check for events to occur at this time step.

This means that an event gets a trigger time in the future with which it gets inserted into the queue.

In the game loop you extract only those events which trigger time are now and leave the rest for a future iteration.

For triggered events, as in triggered by another event depending on some condition like a harvester emptying the last resource from a field, then the event is run as the other event triggers it. For example to remove itself as a target for harvest.

void HandleHarvest(HarvestEvent e){
resources -= e.harvestAmount;
if(resources == 0) Game.triggerEvent(new EmptyFieldEvent(this));
}


Instead of running immediately these could also be set as a delayed event with a 1 tick timeout to avoid infinite recursion caused by events triggering each other freezing the game.

Note that neither of these solutions use sleeps or multiple threads.

• I cannot quite understand your answer. I would be grateful if you could rephrase your sentences to make them more clear, or to put a link to some other page, as this must have been discussed in length already (I don't know the keywords to use to search myself).
– Alex
Oct 1 '15 at 11:58

Option #1 is a very reasonable method with making games. Making a variable which can hold a very big number and incrementing it every frame is an easy way to make multiple timers which can be reset when needed without messing up the flow of the game. I personally don't see the need of checking the parameters every other few frames (unless it's intense collision detection) because this easily creates bugs. While it can sometimes be annoying to pour through tons of if statements, if you lay everything out in an orderly manner, it's quite effective. This is my preferred approach.

As for option #2... I think this is more of an option for programming teams. While it makes the code neat and somewhat easy to understand, mess up in the data management in one place or with one sequence of events and the game wrecks itself completely and the user has to lose their current progress, reset the game, or uninstall and reinstall depending on the structure and how many disaster possibilities there are. This is just with my own experience - I've completely messed up the structure, gotten confused, and ditched my entire programs by doing this.

Obviously, both methods have upsides and downsides but both methods can work. Depending on your skills in certain areas like lists, other data structures, and/or creating flow control, you may find that one way is way easier than the next. There's also nothing wrong with combining these methods. You may find that most of the game can be done with if statements, but you'll need more event lists for maybe a continuously changing game arena. Although often you will want to lean towards your skills, it really just depends on what you're programming.