Question

Right now I’m trying to make a mmorpg for the iPhone. I have it set up so that the iPhone requests for the player positions several times a second. How it does this is that the client sends a request using asynchronous NSURLConnection to a php page that loads the positions from a mysql database and returns it in json. However, it takes about .5 seconds from when the positions are requested to when they actually get loaded. This seems really high, are there any obvious things that could cause this?

Also, this causes the player movement on the client to be really choppy too. Are there any algorithms or ways to reduce the choppiness of the player movement?

Answer 1

Start measuring how long the database query takes when you run it outside your iPhone.

Then measure how long it takes when you send the same http request from something other than your iPhone(It’s e.g. a 10-15 line c# program to figure this out).

If none of the above show any sort of significant latency, the improvements need to be done on the iPhone side. Some things to look out for:

• GPRS/3G has rather high latency

• GPRS/3G has rather high bit error rates – meaning there’s going to be quite a few dropped packets now and then which will cause tcp to retransmit and you’ll experience even higher latency

• HTTP has a lot of overhead.

• JSON adds a lot of overhead.

  Maybe you’ll need to come up with a compact binary format for your messages, and drop HTTP in favor of a custom protocol – maybe even revert to UDP

The above points generally don’t apply, but they do if you need to provide a smooth experience over high latency,low bandwidt, flaky connections.

• At the very least, make sure you’re not setting up a new TCP connection for every request. You need to use http keep-alive.

I don’t have any specific info on player movement algorithms, but what is often used is some sort of movement prediction.

You know the direction the player is moving, you can derive the speed if it’s not always constant – this means you can interpolate over time and guess his new position, adjust the on screen position while you’re querying for the actual position, and adjust back to the actual position when you get the query response.
The trick is to always interpolate over time within certain boundaries. If your prediction was a bit off compared to what the query returned, don’t immediatly snap the positon back to the real position. Do interpolation between the current position and the desired postion over a handful of frames.