I've been doing quite a bit of reading on this topic, as I get ready to write a backend for my web game.
There seem to be two schools of thought about simulating a persistent, database driven, real-time multiplayer environment through a web browser. If you are not sure what that means, it can be summed up with a few names: Ogame, Ikariam, Travian, etc.. It does NOT, however, mean Farmville, City Ville or any other single player game with social networking aspects. They are two different designs and I am speaking about the first type. I feel I need to make that clarification as there seems to be a lot of confusion about what people think is a browser game and what I am actually seeking information on.
The basics: The game has steadily incrementing resources based on x increase over a unit of time. Players can construct improvements to modify the rate of increase. The player can attack and be attacked by other players and be penalized for losing or rewarded for winning, in direct proportion to one another. The losing player loses as much as the winner gains. These conditions must exist when a given player is not logged in and playing the game, which can be hours, days, weeks, or months. Since not everyone is playing at the same time or with the same frequency, "missing" players need to be updated regularly in order to make sure that their resource levels, building levels, etc. are valid if some other player decides to take action against the "missing" player. So far I have seen two ways of handling this:
[b]1)[/b] [b]The Just In Time update:[/b] Player information is updated every time someone initiates an action against them. This means that buildings that are in queue to be constructed and resources that are collecting don't exist in the database until an action from either a player or an opponent causes, through a mouse click, the "update" procedure to run. This is believed to be efficient in that it only calls for updates when needed, via a player interaction. Problems I see with this are:
[b]1a[/b]) What if nobody initiates an action against the player to cause an update and there are persistent "high scores" that everyone can view. These high scores need to be calculated from at least somewhat up-to-date player data. If a "missing" player has not had any updates for a week, but has been collecting resources, then their score will actually be much lower, because no update has been run and the database doesn't know a thing about the "to be determined" resource levels
[b]1b)[/b] Random events: If a random event occurs to a player while they are absent, the effects of that event still need to be calculated based on current data. For instance, there is an event where x resources are destroyed. Something has to "start" the event and write it into the database. Otherwise it "never happens" or "never ends" until the player logs in. This also applies to player-requested notifications. For instance, an email or SMS notification when an event has occurred or a condition has been met. Since the absent player actually never logged in, the events can't have happened because the player hasn't caused them to occur by logging in! (my head hurts)
[b]2)[/b] [b]Running a cron job[/b]: Player information is updated when a script is run at x time interval by some cronlike method. This updates all characters, resources, scores, battles, births, deaths, events, etc. Problems with this are:
[b]2a)[/b] Performance/Load barriers, possibly not scalable when large numbers of database rows need to be frequently updated.
Right now option 2 is looking really attractive, and I'm not thoroughly convinced of the performance problems that people here and elsewhere are predicting. Most people seem to favor option 1 however, and I can't figure out how I could make it work in a world that requires persistence even when a lot of people might not be playing. How is this done in other games? Does anyone even know?