1
\$\begingroup\$

I have been working on a client-server architecture for my multiplayer game.

The server is used for communication between Clients. There is no cheat control because I trusting all clients :) I don't want to control any Physics, Cheats in the server.

My game/connection structure is like:

Client 1 (Admin/Host) <---> Server <---> Client 2

Moving Client 1: sending positon every frame - broadcast to Client 2
Moving Client 2: sending positon every frame - broadcast to Client 1

The movements is interpolated and Client 1 can move smooth in Client 2 screen, Client 2 can move smooth in Client 1 screen.

There is 200-300 ms delay in clients but movements working perfectly.

There is no any problem so far. But... How to SYNC World/Level objects?

I should SYNC World / Level objects because world objects (pushing box) is out-of-sync after few movements. But how I can SYNC it?

I tried, send world object positions from Client 1 to Client 2 every frame. Update world objects in Client 2. But not working, objects is unstable and jumping because 200-300 ms delay in Clients.

I searched solution from http://www.gabrielgambetta.com/fpm3.html but I can't figure out it.

\$\endgroup\$
3
  • \$\begingroup\$ Could you run a "canonical" physics simulation on the server? (I have no idea how well this would work) \$\endgroup\$
    – ThorinII
    Nov 15 '13 at 0:09
  • \$\begingroup\$ Yes, if I simulate the physics in the server and send the results to clients can be help but I can't do it. Client is written in flash with AS3, the server is C++. I need re-write game logic for C++ but I can't. \$\endgroup\$
    – MSTF
    Nov 15 '13 at 0:34
  • \$\begingroup\$ Ok, I get you. You'll have to see if anyone else can help you with syncing multiple clients (your situation seems like a p2p physics simulation) \$\endgroup\$
    – ThorinII
    Nov 15 '13 at 0:36
2
\$\begingroup\$

Your best bet is really to just add the physics and game logic to the server. You could write the server in Flash via Adobe AIR, I believe, if you want to reuse code.

One option if you really want to keep the physics in the clients is to do a combination of prediction and "client as authoritative host" logic. The former means that clients not only move smoothly on each others' screens but that they are roughly in the same position. A dead-reckoning approach is a good way to do this on simpler games. Send over position and velocity for each object. Take into account RTT estimation to adjust position by velocity * RTT/2 when receiving it. That is, if you have 300ms latency, then the position of an object received over the network will be set to the sent position plus the sent velocity times 150ms. Without this you'll end up with a lot of glitches in the second part.

Next you'll want to make objects authoritatively owned by one of the clients. Not all objects need to be owned by one client; they can distribute the objects' ownership however you want. The physics for an object is performed solely by the owner of that object (along with the simulated character position). For instance, if player A's client owns box C then player A's client is responsible for moving box C when player B runs into it. Player B's client will never try to move box C unless told to do so by client A. This is essentially making your clients act like authoritative hosts. This is much easier if the server does everything since your clients don't need lots of checks for "do I own this object" all over the place, but it works.

You can alternatively just make one client authoritative over everything, even movement of other players. This essentially has almost all the advantages of having a central host server. The only potential issue is that the "host" player has an unfair advantage in that he has no latency and could in theory cheat.

You can with either of the second approachs allow "host migration." That is, if Player A is the host but quits mid-game, Player B takes over ownership of all objects. When you have more than two players you need some system for determining who the host player is. One good option is for every player to "bid" on being the host based on who has the least latency to the server (and hence will cause the least latency for other players). The server can be authoritative for this one thing easily enough.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.