High latency in an iPhone mmorpg

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?

Thanks.

Answer 1

On the server side you should be using some system that keep running and that keeps the database connection open all the time. Preferably it would also cache things instead of requesting them from database all the time.

Also, do not make a new HTTP request for every update. It would be best if you hadn't need to use HTTP at all, as it really isn't suitable for realtime comminunication.

GPRS typically has 600 ms ping time, 3G has 300 ms and HSPA has 100 ms. See which mode is being used. Notice that some devices (I don't know of iPhone) drop from HSPA to regular 3G for power-saving reasons whenever there is not enough traffic to justify the faster mode.

As for position, a rather common practice is to apply a linear prediction, i.e. make the character continue movement in current direction, at the current speed, even when no data from server is available yet.

Most importantly: benchmark/profile to see where the latencies are. Is it your server, the network connection or the application.

Answer 2

Loading the player positions that fast has downsides.

• It hammers your server.
• 3G isn't really meant to support low-latency applications

So I don't see a mmorpg working without some necessary shortcuts at this time, e.g. extrapolating paths based on their velocity and position. Loading positions will not work as fast as you want, especially with a server based on PHP of all things.

Either way, when developing for a mobile platform you're going to have to make sacrifices in terms of features versus a fully-featured desktop implementation.

I might also reimplement some of the more critical stuff if not the whole server in a faster language, e.g. C++.

Answer 3

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.