How to achieve smooth gameplay in a physics based multiplayer game? (2d)

Question

I'm using cocos2d 2.0 and Gamekit for networking. I've got a server/client model. It works over wifi (local) and bluetooth. (Xcode 4.3, Objective C)

Basically, there's a ball and 2 or more players. What I wanted to do is:

The physics is completely simulated on the server. The clients send their inputs to the server and the server sends the position (only the position and rotation that's it) to the clients. The clients than set the position of the objects to the given position datas. The ball is also simulated on the server.

Problem: There can be a high latency and the gameplay would be not smooth on the client side. The players can freely move around and interact with the ball (just pusing it and such things).

I read about prediction but how should it be possible to guess the movement of the player? The player can move completely free (360°). I also read about Servertime and clienttime but I didn't get it very well :/

How could I reduce lag? Please explain your solution because I don't want to just copy and paste it, I want to understand it.

PS: Probably I will have very low ping (1-5 ms) on wifi (local, both devices on the same network), I guess but I want to implement Gamecenter too and than I would need to handle the lag. But handling the lag on wifi/bluetooth would be great to, to achieve smoother gameplay.

Answer 1

Lag results from the speed of light limitation, and the processing speed of network protocol translation and switching in intermediate networking devices and at end points. From yours and your players' point of view, these are invariant factors.

Game that deal effectively with lag do so by adjusting player perception of the impacts of lag. One example is in how Diablo II originally dealt with player damage in networked games, versus how it did later (and how consequently how WoW does it): never apply full damage all at once, because the player's in-game mistake that caused them to take damage may well have been caused by lag. In proportion to the round-trip packet time, then, be forgiving toward the player, such as (in D2) by dropping health at a certain (possibly increasing) rate, such that they know they have taken damage, they have a good chance of knowing how massive it's going to be, and they have fractionally more time to deal with it by drinking a potion.

You asked about prediction (extrapolation). Players' view of lag can be improved by running your rendering one frame behind, for reasons discussed here (see comments as well, search on "behind"). The idea is that you can extrapolate the next frame's state by looking at motion over the last two frames. Extrapolation works by looking at the deltas (eg. velocities, linear and possibly also rotational) over the last two frames, averaging them, and adding them to the current state. Doing this in 1 dimension (eg. along a straight train track), might be as follows:

• Train velocity in 2nd last frame is 15 units per second
• Train velocity in last frame is 12 units per second
• The delta between these two frames is 12 - 15 = -3 (last minus 2nd last)
• The new velocity in the frame you are about to calculate is 12 + (-3) = 9.

This is a very simplistic example, and there are certainly more physically accuracter ways of doing this (correct use of the equations of motion). However doing this in 2 or 3 dimensions is much the same, only you'll be using some trig (Pythagoras) to calculate actual vector magnitudes so as to do the extrapolation step.

Gaffer's Networked Physics article is a great place to get up to speed on the various concerns and potential solutions.

Possibly most importantly, you will not want to do your testing on your home network, cf. the experience of the X-Wing vs Tie Fighter team! Instead, get a realistic, even slow remote system that you can work with to do your testing, or alternatively use a lag-simulation app to give you a high latency, possibly packet-lossy environment in which to do your testing. This will be hard to start with but will reduce time spent on implementation in the long run.

Answer 2

Prediction is the way to go. It still works with 360° movement. All Quake games use it for example.

The thing with prediction is that it fails as soon as the direction of movement of a predicted object changes (significantly). If this happens very frequently, prediction can't help you much.

There is no other "magic" to fix latency, other than trying to reduce latency as much as possible. One being not to allow play over high-latency connections (3G).

You also have some influence by the amount of data you're sending, and how many packets you're sending. If you're choking the line with too much data, lag is increased. Or maybe what you perceive as lag is merely packets being dropped, never to arrive.

Most multiplayer games compress the data they send, or are very clever about when and how often they send certain information.

For example if you send position information, that's usually a CGPoint. A CGPoint consists of two float values (x,y). Each is 4 Bytes, which makes each CGPoint 8 bytes. You can safely reduce that to two Int16 to a total of 4 Bytes. Convert to Int16 by multiplying the point coordinates by 10, and on the receiving end divide by 10. For example: x,y = 1.2094, 204.7897 multiplied by 10 and represented as Integer gives you: 12, 2048. On the receiving end you'll divide by 10.0f and you get x,y = 1.2, 204,8.

In many cases it is ok to lose floating point precision in favor of saving bandwidth. Your object positions are also limited to a range of -3200 to 3200 (or 0 to 6500 if you use UInt16). But I doubt doing this optimization will have an effect on your game as it doesn't sound full of game objects.

Another issue is sending at 60 fps, which may easily be overkill. Imagine you accumulate 100 Bytes to be sent over the network every frame. At 60 fps that makes 6 Kilobytes per second. That's significant for mobile phone upstream rates. If you only send the same data every 6 frames you can cut the datastream down to 1 Kilobyte per second.