Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I am currently writing a sports strategy management game (cricket) in PHP, with a MYSQL database, and I have come across one stumbling block - how do I update games where neither player is online?

Cricket is a game played between two players, and when they (or one of them) is online then everything is fine; but what if neither player is online? This occurs when championship games are played, and these games need to happen at certain times for game reasons.

At the moment I have a private web page that updates every 5 seconds, and each time it loads all games are updated; but then I have the problem that when my private web page stops (for example my computer crashes or my web browser plays up) the game stops updating!

share|improve this question
1  
It sounds like your issue is that the stuff that updates the game is a webpage that reloads automatically in browser. It should be a cron job or similar backend device –  ashes999 Jun 4 '12 at 2:05
    
Thanks for that - will google 'cron jobs' now :) –  James Clifton Jun 4 '12 at 4:12
1  
Cron jobs are good, but the 'similar backend device' I might recommend is a daemon. It differs from a cron job in that your program constantly runs, and can take care of as simple or complex of an update schedule as you want, while cron is strictly for 'run this process every x units of time'. The usefulness of either depends on your hosting environment. Some webhosts may not let you use either, but if this is running on your own server then you can use whichever you like! –  Tristan Crockett Jun 4 '12 at 4:55
1  
could be more efficiently done by a timed trigger event running inside the database I think. Would consider that the correct place for business logic, rather than a cron job or other daemon which are more appropriate for technical maintenance (backup, etc.). –  jwenting Jun 4 '12 at 5:26
2  
I would argue that the database is a completely inappropriate place for game logic. A daemon is absolutely useful for things besides maintenance; your web server is a daemon, after all. Cron jobs also work fine for periodic updates, and for technical reasons may be necessary (many Web hosts don't allow for user-installed daemons or long running processes, but do allow custom Cron jobs). –  Sean Middleditch Jun 4 '12 at 19:56
add comment

1 Answer

up vote 6 down vote accepted

As some of the comments mentioned, the issue is that you are trying to get the behaviour of a real-time simulation via an event-driven application.

Your options are basically these:

  1. Create fake events to ensure the web page is accessed when you need to perform these updates. This could be a cron job that polls a certain page. (However, if you have a system capable of running periodic cron jobs to access a web page, you should probably just have that system perform the update itself. See below.)
  2. Make the system perform 'just-in-time' updates. Games don't actually need to occur when nobody is looking at the page - they just need to have seemed to have occurred whenever someone next looks at the site. So, you have a routine, usually included on every page in your game, which checks for overdue updates and executes them immediately, before returning the rest of the page as usual. So if nobody accessed the site for a week, the next visitor would trigger off one week's worth of updates, and would see those events as expected. This is probably the easiest route and I expect it would work well for you.
  3. Have the database perform timed updates. MySQL offers events that can run stored procedures. This is ok, providing that you can write all your game logic in your database's stored routine syntax. Usually this is impractical.
  4. Use your own long-running process (ie. a daemon as mentioned in comments) to host your game instead of one that only runs for the duration of serving up a page. There are many languages and systems that can do this, almost all of them arguably better for programming games in than PHP, but usually not as quick to get started with. They also tend to require more expensive hosting. But since they run permanently in the background while waiting for incoming HTTP connections, it is usually easy to implement background jobs that perform timed updates of your choosing, whether someone has connected to the site or not.
share|improve this answer
    
Keep in mind that in #2 you could have concurrency issues if updating takes a long time and two users connect at the same time. Be sure to use transactions to prevent them from simulating the same game(s). –  Richard Marskell - Drackir Jun 4 '12 at 15:51
    
You can have concurrency issues with games like this however you do it - anything that is based on a web interface to a relational database will need to consider this. –  Kylotan Jun 4 '12 at 16:30
1  
What I mean is that if you have a single updating entity (i.e. cron job, db event, or a daemon) updates are made in a single thread (unless you set it up otherwise). You may have an issue where the web page is out of date, but you won't be generating overlapping game data. –  Richard Marskell - Drackir Jun 4 '12 at 17:42
    
Yeah, it's a fair point, but it's worth stressing that similar problems can happen anywhere - a PHP game backed by a relational database is likely to be making many separate reads and writes to the database whether you start batching things up or not, and the system needs to be robust to that. –  Kylotan Jun 4 '12 at 18:03
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.