Using the “on-view” method instead of cron

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 (
	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++) {

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.


In a quick e-mail, bardic has mentioned that this idea came out of a discussion from his blog – most notably, these two posts:

Wish there was more?

I'm considering writing an ebook - click here.


Luke is the primary editor of Building Browsergames, and has written a large portion of the articles that you read here. He generally has no idea what to say when asked to write about himself in the third person.

Friday, July 18th, 2008 design
  • S Keilani

    We can use a timer that redirects the browser to another page (the updated result page) when it ends the count.

    Can be done with Java?

  • I think you're thinking of javaSCRIPT - which can do this for you, yes.

  • One could use a simple JavaScript timer or AJAX call to fire the server side CRON or serious of functions.

    I think this may depend on what your purpose for having the cron job is to begin with. For instance, to refresh player stats a simple AJAX call could do the trick, if you want to move mobiles around then you probably do want something that is handled on the server.

    In .NET one could initialize a timer in the application start event and have that handle mobiles movement, etc. The only problem there is that if the application stops, which it can in IIS 6, then your timer stops. Of course if players are actively using your site your application won’t shutdown but it is still something to be aware of.

blog comments powered by Disqus


Building Browsergames is a blog about browsergames(also known as PBBG's). It's geared towards the beginner to intermediate developer who has an interest in building their own browsergame.


Got Something to Say?

Send an e-mail to, or get in touch through Twitter at