[web] Tick implementation in webgames

I prefer Cron. If you have 2 players (A and B) and player A logs in each hour (thus changing the game state for him) and B logs in every 3 hours, then B will inevitably suffer some serious disadvantages. If you rig it such that one 'login' attempt updates the game state for each player, then you risk either no-one logging in during a specific hour, or player A and B logging in simultaneously. With Cron, you update each hour, only once, period. Its the safest way to do it... and as long as your update functions are written and spaced correctly, you shouldn't suffer any major server down time. My update functions usually took a whopping 0-4 seconds for ~100 players.

But how do you know where in the hour the cron job executes? Does it always happen at :00?

The cron job sounds like the best idea.

The "process which sleeps for 1hr" would be ok too, provided you know what it's up to and are sure it's doing the right thing. This would be especially helpful if ticks were happening very often (e.g. 2 mins).

Consider having some kind of locking which prohibits people from using the web interface while the tick processor is running. Most games are going to be sufficiently intensive that the tick processor will take at least a few seconds to run.

Mark

Ah, the wonders of Cron.

Cron can be set up to run whenever you want it to. For example:

* * * * * runs every minute while
0 0 * * * runs at midnight.

The breakout is minute, hour, day, month, weekday.... so every day at the 0th minute and 0th hour is midnight.

I warn you though, you have to have your site hosted on a linux server to have access to this feature. There should be some sort of utility for setting up a Cron job, and most hosts ask that you not run a script any more than once per hour. FYI, the script that you use to actually update the game state can be placed above the public_html folder such that only Cron has access to it. On the command line, you'd need to have something simlar to the following:

php /home/ftpusername/update.php > /dev/null

Where ftpusername is the ftp UserName you'd use to FTP into your site.

I hope that helps!

Yes, except:

1. I'd never redirect the output to /dev/null as I might want to see it
2. FTPuser? I never use FTP for anything, ever.
3. IMHO, you should never run anything on the stroke of midnight, or the hour. Instead try a few minutes ahead or behind. This is to stop a "stampeding horde" on a multiuser or complex system where lots of cron jobs fire at once.

4. The tick runner script can be placed anywhere you like - I place mine in the main directory with the rest as it makes include() work in a more intuitive way. It is trivial to code something which detects if it's being run from the web, and stops.

Mark

1. I'm sure he'll set up a file to read any sort of output if he needs it, but dev/null should at least make the site tick until he gets around to logging outputs.

2. I'm saying use the FTP username as a quickfix. I guess I'm technically off with my advice. Most of the hosts that I've used set the default admin FTP username to the same folder name the server uses to track the site. IE, 'www.thisreallylongname.com' may store the site in folder 'thisreallyl' and thus set the default admin username to 'thisreallyl'. Instead of looking for what that folder is called (and I believe I had to find it once by doing , the quick way to try it is to use the FTP username.

3. While 'on the hour' ticks do suffer from the stampeed of other sites trying to run on the hour, while the site is small, it won't impact execution times dramatically, and it makes for better game play. It just seems wierd to me as a gamer having a game update at 5 past the hour. And once the game gets large enough to potentially need off-hour ticks, people tend to get their own dedicated server at that point.

4. For my update file, I have a file called update.php which looks something like this:

require_once('/public_html/allmyfunctions.php');
update_gamestate();
?>

So while the actual code for updating the game is placed on the public half of the server, it can only be executed with this one file that remains out of touch.

At any rate, I still believe CRON is the simpliest yet most stable solution. If you can code it such that the game updates upon user login, and you can make it stable.... then great. But, I just don't see that being plausable.

My games (here) fake it. They update themselves once a day, but the updating is actually done by the first person to log in for that day.

Basically like this.

1. A user (first of the day) logs in at 12:30 AM CST to play my game.
2. Applet tells server that it needs game data.
3. Server notices that current game-state is out of date, as existing stat files are dated from yesterday. Server updates game-state and updates statistics for previous days (as HTML and RSS).
4. Server passes new game data to the Applet.

When the next user logs in (say at 12:40 AM CST), the server sees that the game stats are dated today, so it skips step three.

I considered having a cron-job handle step 3, but it's thus-far been unnecessary.

So what happens if you go several days without anyone logging in?

should be simple enough to figure out how many 'ticks' have passed since the last time someone logged in and simply run the update that many times

Johnattan's idea was exactly what I ment with option 2.

About the cron job: I don't think it's that good of an idea. First there's the need for a Unix machine, and of course the 'stampede'. However, I don't think the stampede would be that much of a problem in my situation :)

I still think option 2 would be best. It avoids the stampede alltogether, and doesn't require anything of the system or a process constantly running in the background.

Thanks for all your comments.

Option 2 is VERY bad.

What happens if the tick takes longer than that user is prepared to wait? What happens if other people try to access it while the tick processor is running in another web server thread?

What happens if the user gets bored and presses "stop" during the tick?

Also the game won't run at a constant rate, as during off-peak hours, nobody may log on for several minutes.

The "constantly running process" works well where the ticks are (e.g.) every 1-5 minutes. For longer, use cron for best results.

But be SURE that your locking works so you don't get race conditions (i.e. DO test it).

Mark

Quote:

Original post by markr Option 2 is VERY bad. What happens if the tick takes longer than that user is prepared to wait? What happens if other people try to access it while the tick processor is running in another web server thread?

I think the page would set the lock and fire up a serperate process that would actually do the tick. The users trying to reach the game are being served a 'please wait' page with an auto refresh.

Quote:

What happens if the user gets bored and presses "stop" during the tick?

Since the page starts a serperate process to do the actual update, nothing should go wrong.

Quote:

Also the game won't run at a constant rate, as during off-peak hours, nobody may log on for several minutes.

When the update is requested, the number of missed ticks are calculated and the update code is called that number of times.

Quote:

The "constantly running process" works well where the ticks are (e.g.) every 1-5 minutes. For longer, use cron for best results.

I do have a question about the 'constantly running process' method: the processing itself takes time too, so every tick will be a little more off. What's the best way to handlethis?

Quote:

But be SURE that your locking works so you don't get race conditions (i.e. DO test it).

Testing is important, as always.

Quote:

Mark

Thank you for your comments.

Quote:

Original post by Sijmen I do have a question about the 'constantly running process' method: the processing itself takes time too, so every tick will be a little more off. What's the best way to handle this?

The process just sits in a loop:

while (game not finished){  wait until next tick is due;  Process tick;}

And hence won't get out of sync. The next tick time should be calculated by taking the previous tick time and adding the tick delay, although it might make sense to limit how far behind the game can get e.g. if more than one tick behind, don't bother trying to catch up.

Otherwise a failure, e.g. a power cut or other server fault, would result in a large number of ticks being executed once the system is restored, all in one go.

Mark

Quote:

Original post by Instruo should be simple enough to figure out how many 'ticks' have passed since the last time someone logged in and simply run the update that many times

Exactly. Although that hasn't been a problem thus far.