When a Game Server Should Lie

In my last post I discussed a system I use to track and respond to the passage of time. Without going into too much detail, the player can issue a command and the server will note when the command was started and when it should be complete. This command could be something like construct a building, or train a unit; it doesn't really matter.

Naturally a player wants to be able to check the status of a command to know when it is going to complete so they can plan their next action. When the command is initially sent to the game server and assuming the command is valid, the server responds with a date and time that indicates when the command should be completed. This information is then available to the display to the user.

When the timer expires its nice if the client can automatically update the display to reflect the game state post timer. For simple events it is possible for the client to predict the new game state. For example if the timer is to train a unit, when the timer expires the client can simply increase the unit count and assume that the server did the same. Both the client and the server are happy in this arrangement.

However some times the client can not predict the outcome. For example a timer may have semi-random outcomes such as a chance that an attempt may fail. In this situation the client must poll the server to check the new game state. In a perfect world the client would never react to the expiration of a timer before the server, but we can't guarantee that behavior. The best we can do is try to trick the client into not reacting until after the server does. 

In my last post I talked about how the timer system on the server reacts to expired timers at intervals. This is because there is a small program that sends a request to the server at regular intervals for the explicit purpose of letting the server react to timers. The problem is that I only run this request every five seconds. This is fine during development, and later when deployed on faster hardware I may shorten this interval. With this interval of five seconds it is possible that the server will not process an expired timer for four and a fraction seconds. What can happen if we don't account for it is the client could notice an event is due and attempt to update before the server has updated the game state. This results in the client having an incorrect game state. 

There are two solutions to this problem. One is to have the server process events a few seconds before they are due. The other is to give timer data to the client that is a few seconds later than its actual time. Both methods result in the server running a few seconds ahead of the client at all times.  Really it is a question of which implementation you prefer. Personally I like having the server process early since in my implementation the are fewer chances for me to make coding errors.

I feel like for predictable timers the client should still poll the server because this implementation allows you to change the server behavior without also reprogramming the client. Predictable timers that don't update from the server are an optimization that has a tradeoff against code maintainability.

When you look at the whole picture, the server tells the client one thing, and does another. Hence the server lies by design. At my day job servers always tell the truth, so this is somewhat counter-intuitive to me, but in the context of my game server it works and makes sense.

All this makes me wonder in what other situations a server might lie to the client. I'd like to hear about other lying servers in your comments.