4

I have two questions about keeping timers running (like growing crops in Farmville) when users are not online:

  • Am I right in thinking that I should just calculate what would have happened when the state is requested, rather than actually running something every minute for example?

  • How should I keep the client in sync with the server? Should the client do things itself and then check every few minutes, or should everything be server side over Socket.IO?

Thanks! (apologies if this is in the wrong section, feel free to move it)

Oliver Dunk
  • 179

3 Answers3

3

To use a metaphor - would the world (the real world - i.e. planet Earth) stop spinning if suddenly all of its "users" (the human beings and other inhabitants) suddenly died or boarded a spaceship to migrate to another planet? No, of course not! The world would carry on spinning until the end of the universe.

If you're looking at implementing a persistent real-time simulation (a.k.a. "world"), then your world should also keep on spinning/ticking regardless of how many inhabitants (clients/users) are currently in that world.

How you keep the clients in-sync with your world is more a matter of how much data each client actually needs and cares about; including how frequently you expect that data to become stale, and whether it even matters to the client that the data may be stale. (Consider: if a tree falls in a forest, and there's nobody to hear it fall, does it still make a sound? Does anyone even care that the tree has fallen? Schrodinger doesn't care about his cat either).

Whether you choose a notification model, a streaming/broadcast model, or a request-reply model depends on what kind of data is being exchanged. You will probably find a use for all of those messaging patterns and more.

To use the real-world metaphor again, consider how much information each inhabitant of Earth gets to receive, out of all the billions of things which are happening at any one time.

An "inhabitant" sitting in a house might receive a news report (a newspaper) once per day, because newspapers only change once per day. However, when the newspaper is delivered, it's a fairly comprehensive "snapshot" of all news which has happened around them.

Then consider that same inhabitant receiving news reports on a TV; however the inhabitant only receives those reports when the TV is switched on (and the inhabitant decides when to switch on the TV, and when to switch off again). The TV station always broadcasts, without knowing who is watching. The inhabitant only watches when they choose; the broadcast doesn't go away just because they switch off the TV however.

This is analogous to having a constant 'stream' of micro-update messages broadcast in real time from a server, but client applications choosing to enable/disable their subscription to those message streams, depending on whether the client wants/needs to know at the time.

Finally, consider the case where the inhabitant has asked for specific kinds of news updates to be sent by e-mail (maybe those about Politics and Sport, but not about Health or Technology); there may be infrequent and unpredictable news reports sent at totally arbitrary times during the day; sometimes there might be 5 stories an hour, other times there may be no stories for several hours. Each notification is an update that the inhabitant has asked to be notified about because it's relevant to them. The reports about Health and Technology will not be sent to them even when those reports are published.

Overall - there is no right or wrong answer with regards to messaging patterns to synchronise client/server data; different types of data will have different requirements, and you need to choose whichever is most appropriate.

Ben Cottrell
  • 11,739
  • While I appreciate the metaphor, I think what is missed here is that we're writing a computer simulation and not the real world. There's no point knowing what's going on in the world of someone who never intends to return, and so we should just decide not to calculate this for the time being and guess what would have happened if they login in the future. – Oliver Dunk Mar 27 '16 at 14:59
  • @OliverDunk But as per your description "like growing crops in farmville" It seems that your simulation is real-time with temporal events and objects which are agnostic to whether the client is connected or not; or am I mistaken? In that scenario, consider the other problems you might have - e.g. what happens if a second user is connected and inspects the state of the first user's crops after that user has been offline several days? You could "freeze" objects belonging to offline users, but that sort of thing doesn't give a very real-time type feel to it. – Ben Cottrell Mar 27 '16 at 15:17
0

The old approach I think would be to model 'what would have happened' at the next request.

This is less computationaly expensive as at least some of these users will not log in again ever.

However, moden games and apps try to keep users engaged by sending push notifications 'you have more hearts/gold' etc.

You will have to make a trade off between the expense of running mutiple world simulations for non-users vs the gain achieved by enticing users back to play/spend in your game.

Ewan
  • 75,506
0

Although not crops related, I was actually dealing with similar issue where we had data which could be processed after certain time and this system had mobile application as well.

What we had done was we added a timestamp to the data, indicating when the data is ready for the next step (be it harvesting or anything else).

When a user logged in to the application, the client would fetch server data and based on the value, either displayed a button for harvesting or took current time and the timestamp from database, diffed the two values and started counting it down. When the counter hit zero displayed the button for harvesting.

On top of that we added a cron running every minute, dispatching notifications to clients if they had subscribed to them when a crop which has not been available to harvest before has become so.

We chose a 60 second cron task. Naturally this was good if a crop became available at x.59, then there would be basically no delay, but if it became available at x.60, the user would not know until a minute later. But it was good enough for our project and was done to ease the load on our servers.

Andy
  • 10,327