Handling a latency issue in PVP game

时间:2015-08-07 01:36:22

标签: c++ networking cocos2d-iphone websocket cocos2d-x

I am building a 1 vs 1 tetris game using cocos2d-x(C++) and a node.js(websocket).
Currently, I am working on a PVP feature between two players.

The basic logic looks like this:

1. Client1 completes a horizontal line and destroy it.
2. In this case, Client1 sends an attack packet to a server.
3. A server sends an attack packet to client2.
4. Client 2 gets an additional line.

The problem is that this is a little bit slow even though I use the update() function with 10 frames per second. The delay must be caused by the long route(Client1 => server => Client2).

I am thinking about sending the packet to the opponent directly.
In this case, the client1 needs to know the IP address of the client2.

My questions is:
1) In a real game, isn't it dangerous for client2 to let client1 know the IP address of his?
2) In general, how do game developers handle this kind of latency issue?

1 个答案:

答案 0 :(得分:1)

1) In a real game, isn't it dangerous for client2 to let client1 know the IP address of his?

It's generally not a good idea to expose the ip of your user, at least without notice. While it is legal (I'm not lawyer), if people doing bad thing the user may get upset and complain to you.

2) In general, how do game developers handle this kind of latency issue?

First, what's the latency you measured? Have you tried host your server on local network and see how is it? To deal with this problem, we usually define the required latency (e.g. 100ms, 200ms, 500ms) and have game designed in way that information can be propagated in a delayed manner without impact on gaming experience. In your case of attack logic, the usual trick is to make a charge timer to initiate the attack, so that both client will agree on the same wall clock for the actual attack. So,

1. Client1 completes a horizontal line and destroy it.
2. In this case, Client1 sends an attack packet to a server, and start a 1 second charging timer (may show a charging bar)
3. A server sends an attack packet to client2.
4. Client 2 start a timer and show the bar. Note that you need to adjust the time to account for the round trip.
5. Client 2 gets an additional line after 1 second since 2. Client 1 show the exact scene at the same time.

Note that, Client 2 actually got attacked later than your original design, but since the player see a charging bar, the experience is however smooth.

You may also want to adjust the "1 second" according to your latency requirement.