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.
> 
> 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?
> 
> 
> 

**Assuming your game is only played through player prompts/observation** (more on that later), there are simpler ways of doing this.

Assume I am building a house, and it is currently Jan 1, 2019 at 00:00 precisely. If you were to store the building's status as a history table, the game could register two statuses already:

```
 Player | Building | Status   | Timestamp
=================================================
 Flater | House    | Building | 01/01/2019 00:00
 Flater | House    | Built    | 01/01/2019 00:15

```

Note that the second line is *in the future*. But when you fetch the item's current status, you use a query similar to:

```
SELECT TOP 1 Status
FROM BuildingStatusHistory
WHERE Timestamp <= GETDATE()   -- GETDATE() give you the current date and time
ORDER BY Timestamp DESC

```

What you will notice is that when I refresh the page before 00:15, the query will return "Building". But when I query the page at 00:15 (or later), the same query will return "Built", even though we did not actually change the database since then.

If you want to show a progress bar, you can do this based on three values:

* The timestamp of the most recent (already active) status = left side of the progress bar
* The current time = progress of the progress bar
* The timestamp of the *next* event (that is not yet active) = right side of the bar

---

**Assuming your game is only played through player prompts/observation**

What I mean by this is that the game is played through player observation:

* The player sends a web request for information
* The backend runs a query on the DB
* The player receives the information they need

If your game is expected to e.g. send out emails to the player when their house is built, that's different. Then, you need some agent that sends that email *precisely* at 00:15 when the house is built, and this means you either need an always-online component, *or* (if it's acceptable for your use case) you used a scheduled service that regularly polls the database to see if there are actions that need to be taken (which means your players may have to wait for their email a bit longer).