7
\$\begingroup\$

I'm interested in understanding how resource generation timers work on many of the mmorts type games out there. I can't wrap my head exactly around how the timers are synched with servers, especially with multiple users. If I need to provide more details, please let me know.

Thanks!

\$\endgroup\$
2

2 Answers 2

12
\$\begingroup\$

You mean games like Ogame? In my opinion it is best to calculate the value when it is needed, not on a regular event as Jari Komppa suggested. You could even go a step further and calculate the value on a client side sometimes.

In case of Ogame:

  1. Imagine that server increases amount of resources every minute for millions of users (where probably half or more are inactive). It's an overkill.
  2. Now imagine the server stores some value for every planet, named "last_calc" with a timestamp value. Everytime someone attacks the planet, the server will:
    • get "last_calc", mine levels and resources from database
    • calculate time_delta = (current_time - last_calc)
    • calculate new resources: new_deuter = deuter_mine_level * time_delta; new_metal = metal_mine_level * time_delta;
    • (in case of Ogame in above point you would also need to check if a particular mine is upgraded during time_delta, and if so, divide the time to two parts: one before mine upgrade, second after, then do the calculation as above with first part, increase mine_level, do the calculation again, and sum up both values)
    • add new resources to old resources, divide them by 2, then save these value as both, current planet resources and attacker's loot.
    • (again, in Ogame it's a little more sophisticated - you need to check if attacker's fleet have enough capacity)
    • update last_calc to current_time
  3. Now imagine a user is only spying on a planet. Such actions can occur much more often, then attacks, maybe even 100 times more often, so to keep things optimized, server will:
    • get last_calc and old resources from database (or cache if we're talking about optimizing things)
    • send it to a client together with current server time
    • and now the client does the math! Keep in mind, that such solution gives hackers a possibility to see when spied user was last active (on this planet at least); of course a hacker will never know if last_calc timestamp was updated by the planet owner or by another user sending spy drones, but if main planet of a user wasn't refreshed for 5 days, one can be pretty sure the user didn't login for at least as long.
\$\endgroup\$
1
  • \$\begingroup\$ Thanks for this post, this is exactly what I was looking for! \$\endgroup\$
    – Jehosephat
    Commented Oct 14, 2012 at 22:17
1
\$\begingroup\$

First step: Time difference between hosts

It assumes that it takes same time for packet to go from server to client and back. server sends packet with current time to client and client responses back with current time. After that server has total time. Divide that time on two and you know when packet was on client.

// Server code
int64 dtime = time2 - time1;
int64 dtime2 = dtime / 2;
int64 clientTime = time1 + dtime2;

Second step: Keep track of time difference Keep track of time difference. You may calculate moving average for time difference.

float movingExpAvg(float value, float oldValue, float ftime, float time){
    float alpha = 1 - expf(-ftime/time);
    float r = alpha * value + (1.f - alpha) * oldValue;
    return r;
}

Every request from server to client that requires instant response may contain server time and response may contain client time.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .