Question: I need to be able to execute certain events at a given time in my game, for example, say the player "Builds a building" this building should take 15mins to process. Implementing this seems straightforward enough, simply enter the event into the database and execute the event when the time comes for it to be completed.

However, it is my understanding that i would need a script that is running permanently on the server and continually checks the event database for delayed events to execute and process them as needed. My question is, is this the right approach or should i be tackling the "event que" differently?

Some of the events that will be processed can effect many different players so they would need to happen in real time, as opposed to be lazy loaded.

You can see similar such event queues in browser games such as travian, grepolis etc.

Update - If i was to implement a purely lazy load method, are there any flaws in the following pseudo code?

```
    ## upon player_x pages load

## start a loop that will only exit once all needed events have been processed

## check for any events initiated by player_x that are overdue

## get event and lock it for processing

    ## does this event involve another players object?

        ## if it does, then lets check if said object also has any events that should happen before this event

            ## if it has, then lets process one of those events instead, and loop again once processed

            ## if it doesnt have any previous events, then we're free to process this event, do it

## loop till all overdue events for player_x's object are done

```

Answer: 
I faced a similar problem before and, given your needs, I'd go for a slightly variation of your pseudo-code.

Considering that you could have events issued by other player but which can be needed for stats purpose, for example if I open the "Most resource ladder" I want to see the data up to date for every player, not only me, and stuff like this, I prefer to elaborate events belonging to every players when somebody opens a page, so you will have the "game world" synchronized every time.

Now somebody could say "The first player logging in will have to wait for a ton of events elaboration", but that's not completely true. In fact if you have such a huge amount of events, it means you have lots of players, which means lots of connections, which means that the elaboration load will spread over those connections. If you have fewer connections, they must be generating fewer events, so the load still is not too heavy.

An addition to this strategy could be creating your "event executor" as an independent script, called by users when they load a page, and also called by a cron set like every 15 or 30 minutes, so you can thin the queue even if nobody logs for a while. This way you are sure that the first logging player must at most wait for events expired in the last 15 minutes.

I found this solution pretty smooth in my projects, I hope it can also suit yours.
It's not uncommon to put in a cron script that invokes a PHP script or whatnot every minute or so.

If you need finer granularity, you need a running event processor.

You can also use a message queue service to submit delayed events that invokes an HTTP script when necessary. Batch processing events will be better for power consumption, though. It's easier to go the cron route, which is compatible with most cheap PHP/MySQL web hosts.