Take a game with a persistent state that can continue even when players are not online. E.g. your player enters into a fight and loses some health points which are replenished 1 point every five minutes. There are a number of ways to implement this "update stuff even when the player isn't logged in" scenario. E.g. run a server-side background worker that performs scheduled updates (e.g. +1 to health) once a second.

Or, forgo the background worker and store the next-update-time for an attribute (e.g. health) in your Player model. Then, anywhere you fetch/get a Player, perform any attribute updates lazily. That is, if the next-update-time is earlier than the fetch/get time (e.g. "now"), update the attribute and then return the updated Player.

My goal is to make this system as simple as possible.

What are your thoughts? How would you do this?


If these things are occurring while the player is offline, then simply use calculations to determine what the values should be when they're logged on next (and do the same whenever another player in the game accesses their publicly viewable statistics that would be effected by this).

For example, a player sustains a sickness that can be half-way recovered after 5 minutes, and fully recovered after 10 minutes, regardless of whether they're logged in -- you could implement this with a special table in the database for tracking such updates, and then when various players or login events occur, the calculation is run accordingly:

  • 08:28 Player sustains sickness, record is added to the tracking table which includes the relevant calculation details and player ID number

  • 08:29 Player logs out

  • 08:31 Another player views this player's statistics, and the game checks the table to determine that the player is sick because not even 5 minutes have passed

  • 08:35 Another player views this player's statistics, and the game checks the table to determine that the player is half-recovered from their sickness because more than 5 minutes have passed, but 10 minutes have not yet

  • 08:37 Player logs back in and the game calculates the statistics, and the player can see that their character is 50% sick (and will be recovered after approximately one more minute)

  • 08:38 Player's client software automatically queries the server and the server determines that a full recovery occurred, sends the update to the client and deletes the record from the table

There are other ways to do this as well, and this probably isn't the most efficient solution (I look forward to seeing other answers with different solutions). Of course, if the player logged in after 10 minutes, or another player checked the player after 10 minutes, then the server would automatically take care of deleting that record and none of the players would know that there was any sickness.

One advantage is that there is less work for the server due to being player-event driven rather than cron-tick driven (which could result in more work for the server).


These updates typically take place in "game time," not real time. Slipstream the code to update statistics and effects that should change over time right before the sequence that inserts the character into the world. At that point you know how long it has been since the character logged out and now when he's about to log back into the game environment, your calculations can be done using that delta instead of a cron like tick.

The only time you would need to tick when someone is offline is if their character were left active in the game world, in which case the normal game logic would handle all the updates so nothing special needs doing.

  • \$\begingroup\$ Good answer (+1). One addition to consider is for the expected "completion time" for the given state to be stored as well so that delta calculations can be avoided altogether -- simple time comparisons may be easier to code. \$\endgroup\$ – Randolf Richardson Jul 14 '11 at 4:32
  • \$\begingroup\$ That feels like optimizing before there's a measured need, and having two systems where just one is needed? \$\endgroup\$ – Patrick Hughes Jul 14 '11 at 8:10
  • \$\begingroup\$ Optimization doesn't need to be justified by a "measured need" -- it's generally good practice all-around, especially if it can be preventive. \$\endgroup\$ – Randolf Richardson Jul 16 '11 at 18:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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