bardic commented on the cron post from yesterday, and he said:
While crons are a good way to do such a task, they aren’t the best solution. For a game with a large DB a cron can take too long to cycle through the DB.
bardic is right, here – in any situation where you need to deal with large amounts of data, using cron is a little less than optimal. In that case, you’d want to implement something that bardic refers to as the “on-view” event – essentially, you store information about the time a command was last run, and you use that time to figure out when the command should run next.
Implementing this in your own database is a trivial change; all you need to do is add a timestamp to the table you need to track times for, and then compare it to the current time. Here’s what an example table might look like:
CREATE TABLE actions ( id int NOT NULL AUTO_INCREMENT, user_id int, energy int, last_updated timestamp, );
And then all you would need to do in your code is something like this, on every page an authenticated user visits(pseudocode):
last_time = get_last_update_time();
current_time = get_current_time();
if(current_time - last_time >= tick_duration) {
number_of_updates = int((current_time-last_time)/tick_duration);
for(i = 0; i < number_of_updates;i++) {
update_energy_value();
}
}
And that would be essentially all you’d need to do – just check the last time a user’s information was updated, and then update it if it’s been longer than the amount of time you want to update a user’s stats in. Also, if you write your code in such a way that you can just pass in what to update the value with, you can reduce the overhead of using a for() loop as well:
update_energy_value(update_amount * number_of_updates);
Now, this will allow you to keep large amounts of data updated, without encountering any sorts of timeout issues – and is therefore perfect for making sure that things like player stats update themselves at the proper times. However, there are still some areas where it’s better to use cron.
For example, let’s say that you are building a browsergame where players health regenerates automatically, at a rate of 1 health every 30 minutes. In this game, time passes just like in the real world – every day counts as a ‘year’ in the game. In this situation, you would want to use the “on-view” method to update the player’s health – but a cronjob would be a much better way to update the “year” value every day. The in-gameyear isn’t really linked to a particular player, and it’s a micro-value – something that is only available in a single place. While you could certainly use the “on-view” method to update the year as well, it’s not quite as practical – a simple cronjob can easily keep your year updated for you, with the added benefit of only running as it’s needed – as opposed to every single time a player visits certain pages.
In summary, “on-view” is another way to achieve virtually the same functionality as cron – with a far more reliable way to keep large amounts of data up-to-date when there are many users playing your game. However, there are still places for cron – and both approaches can be used together to provide the best of both worlds.
Update
In a quick e-mail, bardic has mentioned that this idea came out of a discussion from his blog – most notably, these two posts: