I realize that, for a lot of good reasons, many people here do not have a particularly high opinion of Evony. However, in testing the game, I have been unable to completely figure out how some functionality is implemented. I wondered if anyone may be able to offer some insights. Many player-initiated functions in Evony are based on timers. For example construction, research, and attacks are all initiated by the user and occur once, based on a countdown timer, at some future time. Other events, such as the production of resources (e.g. food, lumber, iron, and stone), the collection of taxes, recruitment of peasants, etc. occur continually and have their values updated at specific intervals (e.g. one second, one minute, six minutes) and affect all players on the server. There are many ways to handle countdown timers, most of which are pretty straightforward. However, I am a little confused as to how the perpetual timers which update production, taxation, recruitment, etc. are being managed. Does Evony loop through every player on a server at every tick and update resource production and other items? This would seem to be very processor intensive if calculations were constantly being made even for players who are offline. At the moment, I am not seeing another straightforward way in which it could be implemented--though I am sure there must be. Additionally, I assume that even if the server was performing updates at every tick, it would be too much network overhead to send all of these updates to the client. More likely, it would appear that both the server and the client are aware of the applicable rates of resource production and both are executing the appropriate calculations to increment resources. Is this correct, or have I reasoned incorrectly? If this is correct, how do the server and client verify that they remain synchronized? Does anyone know what the best practices are for implementing timer systems within games and where I might find additional materials on this topic? Any thoughts or guidance are much appreciated! Thank you!

I gather it would have one global timer for those calculations and when you commence an activity it will use the current time to determine when it should finish and simply store the time it will be completed. Then the page shows the difference in time between the global timer and the time when the activity will finish.

Should be better than looping though every timer for ever player.
/speculation

Quote:Original post by thePyro_13
I gather it would have one global timer for those calculations and when you commence an activity it will use the current time to determine when it should finish and simply store the time it will be completed. Then the page shows the difference in time between the global timer and the time when the activity will finish.

Should be better than looping though every timer for ever player.
/speculation

Yes. My presumption is that the management of timers for specific one-time events (e.g. construction, research, and attacks) is handled through the use of a global timer.

Specifically, if I was implementing such functionality, my first inclination would be store all of the pending events in a "pending events" table. I would periodically (based on a global "tick" timer) query the database for unprocessed events which had reached their expiration time. Once an event is processed, it would be removed from the global tick table. (I am not sure this is the best way. Its just the first approach that came to mind.)

However, items which are updated at recurring intervals (e.g. resources like food, iron, stone, lumber, gold (from taxes), and population) probably need to be handled a little differently. While a specific attack occurs only once and affects a specific player, resource production occurs continually and affects every player.

It seems like perhaps there might be a global "tick" timer which fires an event at specified intervals (e.g. one second, one minute, six minutes) to perform these types of continuing events for all users. If this is actually occurring, the load on the server might be overwhelming.

Let's consider the following. Assume there are 20,000 players in a given game. Each user produces food, iron, stone, and lumber at some rate which varies by player and resource. Suppose that for efficiency's sake, our system has already calculated what these rates are and has stored them in some sort of list (i.e. a dictionary) where each user's rates can be quickly retrieved as needed.

Suppose that after each interval (or "tick"), the server retrieves each user's production rates and updates each player's values. Given that we have four resources, this would require 100,000 calculations and their associated operations (e.g. data retrieval and storage) at every tick.

Even if the server is performing no other work, this tick processing would impose a very heavy load. If the server is performing any other processing, it seems like the server might be overwhelmed.

I am assuming that all of this processing is occurring on the server since we can never assume that a client application has not been compromised. However, this poses another challenge. If all of the processing is occurring on the server, what is the best mechanism for updating the client?

If the tick interval was one second and the client was being updated with data from the server at every tick, the amount of communication between the server and the client would be extreme. A better approach might be to pass the production rates to the client and have both the client and server make the calculations at each tick while only allowing the values from the server to be treated as "official". To verify synchronization, the current server production numbers and rates would be periodically (perhaps every 1-5 minutes) would be updated on the client.

The approaches I have mentioned here work but feel "klugey". I am sure there must be much better ways to implement this functionality.I am curious what the best practices for tick/timer processing and client synchronization might be.