This question is not language specific but a more generic approach on how to deal with lazy updates for some game variables.

Let's say, for instance, that I want to implement a "character age system" for a game.

I guess that the "age" attribute does not need to be updated 60 times per second for each of my 10.000 or so RTS/MMO characters.

So, how to implement in the game loop the update of this "long term" variables that may have it value changed very sparsely?

At the moment, I would implement some global variables to accumulate the delta time between the frames until it reaches a certain value, then, it resets and updates that variables.

Is that correct? I mean, that's how things work? Or depending on the language/plataform you would set some timers, or events that trigger the update of these variables?

  • \$\begingroup\$ Things like age can be fit to a formula such that given time T, you can just plug it into the equation and get what you want. For example, if an actor ages 1 year every 1 hour of gameplay, at 4 hours, the actor is 4 years (+ initlal) years old. This only has to be calculated whenever you need it. \$\endgroup\$
    – CobaltHex
    Sep 26 '17 at 2:37
  • \$\begingroup\$ Related: gamedev.stackexchange.com/q/115008/40264. \$\endgroup\$
    – Vaillancourt
    Sep 26 '17 at 10:20

Another approach for handling events on a larger time scale is using a Heap. In short, a Heap is a binary tree that always brings the largest or smallest item to the top.

If you maintain a min-heap (smallest at the top) of events, compared by the time the event is meant to occur (game time triggered + time until event), then on each update cycle you need only check the root the heap. If that event should occur, then trigger it, and check the next events in the heap. Trigger each if needed, remove all triggered events, and then restore the heap.

While many of the other answers are better for specific situations, this can be applied as a more general solution.

  • \$\begingroup\$ That's it... Using a heap to store and retrieve the "future" knowable events is indeed a good approach to this problem. Btw, my code atm has exactly an implementation of a heap library. Ty. \$\endgroup\$
    – J. Doe
    Sep 27 '17 at 20:56
  • \$\begingroup\$ This would be the best approach and not something I could've thought of by myself. Thanks for this answer :) \$\endgroup\$ Sep 28 '17 at 5:05

Store your birthday and calculate your age on demand.

When I buy alcohol the shopkeeper sometimes checks my ID to make sure I am not underage. However, my ID card doesn't have my actual age, and I don't have to update it every year. Instead, it shows my birthday, and the shopkeeper compares that date to the current date to calculate my actual age.

This is the same thing you can do in your game, but instead of birthday and the current date, it will probably be a game time counter. It's a common way to implement timed events.

Similarly, you can pre-calculate the result to make the comparison cheaper. For example, I always forget various anniversaries of family members because I'm an imperfect human being. Instead, I calculate the next anniversary and mark it in a calendar. Then I can check the calendar every day, and see if there's an anniversary. You too can do this for your game, if your timed events have expensive calculations.

  • \$\begingroup\$ Hey, man, I just loved your answer but the "age system" is just an example. The real thing is how to update discrete variables sparsely on "continous" time, so that change has effect in the game loop event. Such as in render routine it may "know" the age of a char to know if it has to render it as a baby, a lad, or an old man, gotcha?... So the Heap approch is much more generic and can hold many other possibilities... ty anyway ;) \$\endgroup\$
    – J. Doe
    Sep 27 '17 at 20:53

Non-Real-Time Variables

Some variables don't need to be calculated real-time, those will include a lot of stuff, from deadlines to stuff like age and from how many players are in the game to how many gold you have in your bag. Even some variables that seem to be updated real-time are actually just updated when they need to be (see hit points example down below).

Calculate On Demand

Your gold, for example, is only ever updated when you spend it or get more added to it. The number of players in a server is only ever updated if a person joins or leaves the server.

The age of a player's character should only ever be updated if it is shown on the screen, in other words, when the player opens his character sheet. So, if a player wants to see his updated age, he will have to close and re-open the character sheet if it's already open.

Even stuff like hit points or mana need only ever be updated if they're changed. In games that do not have regeneration, it would be a waste to update the hit points every frame. Even in games that do have regeneration, it's still a waste to update it every frame, every second would be more than enough.

This is all to avoid heavy CPU usage.

Delegate To The Client

As an example, in a game like FarmVille, there are many timers and many times more players and it's impossible to do all the timers real time on the server side. So, the server sends when the timer will end to the player' computer (the client). The client will handle the calculations, and when the timer ends, it will send a request to the server and the server will either approve it or reject it. Usually rejection means the client's timer ended too soon and the server will most likely send a new timer value or delay the action if it's just a few seconds.

  • \$\begingroup\$ Nice answer, and it may fit perfectly on games that has timers as the ones you mentioned. But as I mentioned into another comment the question is that the "long-run" variables may indeed has effect on the game-loop routine, such as in render routine. \$\endgroup\$
    – J. Doe
    Sep 27 '17 at 20:59

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.