Lag problems

Today I’m posting a small blog about our constant battle with lag, and what we have done to prevent it.
There are multiple things that are seen as lag:
Framerate lag
Network lag

I’ll focus on one at a time, starting with frame-rate lag

Frame-rate lag (or drop) is created when the game takes too long to draw or calculate the next frame.
A few examples of actions that could cause a slowdown:
A large amount of object creations, rendering a lot of layered transparent images, iterating over a very large loop, and rendering a lot of objects.
Of these possible slowdown’s, we have removed as many as possible by recycling used objects as much as possible and reduce the amount of objects that need to be drawn.
For example, every frame we would be making numerous objects to track events made by the user and received from the server (known as game events). Instead we now generate a large pool of these that will be used when required. And game events that are no longer needed will be put back in the pool. Only when the pool runs out, will we refill the pool with a new events. Even then, we will not just create the 1 event required, but multiple (in this case 100) events.
To fix rendering slowdowns, we have disabled many objects that where entirely see through, or off screen. The friends list was one these parts that was optimized greatly. Your entire list of friends was rendered off-screen when it was collapsed, instead of disabled (you don’t see it anyway).

Network lag is a tricky one, as there are many issues that could cause it. Bad connection between the player and the server, slow server responses, TCP networking, and flash networking in general.
We are however unable to fix most of these. We cannot provide you with a fibre connection, and flash what the game is made in. Flash also only supports TCP for network connections, so this is unchangeable as well. However slow server responses can be taken care of, and we have done our best to reduce the time that it takes for the server to respond.

Last we have tweaked the time syncing a little, which might be interesting to write about.
When a player presses a button, it sends a message to the server telling that it did, so that other players can see him turn.
However, how to tell the server WHEN the button was pressed?
For this we pass a “time stamp” which is simply the current time in milliseconds.
Again we will run into issues, as the current time on your pc might (and will) not be the same as the time on the server you are connected too.

We fix this by constantly telling the server what time it is, and having the server respond with its own time, and seeing the difference.
For example: We send our time, 0ms, to the server, the server sends back 100ms, and this arrives at time 50ms.
Since the message went to the server and back, we can guess it took 25ms for our package to reach the server, and have the server send it back again.
So our time difference with the server is 75ms.

We use this value the tell the server EXACTLY when something happened, which is then passed on to the other players, which can correct the time stamp with their own time values.
This has to be done to ensure that all player screens are exactly the same.

This is however also why is causing the “jumping around” of the players, as you might receive a message from the server that about 10ms ago player 2 pressed left, and is in a different place then you assumed.
We cannot fully fix this, as there will always be a time lag between server and clients.
However we can improve the accuracy of the time correction!

We are now correcting the times every round, instead of once per game, which should decrease the feeling of lag.

To end this blog, we are still looking at more ways to decrease the lag, such as moving the servers to a more favourable location, but are going to concentrate on adding something new in the next few months.