5
votes

I am currently in the planning stages for a 2D game for mobile devices which I will be making in C++ using cocos2d-x. The game will be turn based and each turn will have a phase in which the physics simulations will take place. It will also be cross-platform.

I am new to multiplayer networking and am wondering what the best way to synch the physics would be since Box2d does not behave exactly the same on different devices.

The simulation does not have to occur simultaneously on each device but I do need the results to be exactly the same. Ideally the players will be able to witness, on their own device, the same physics simulation( i.e. projectile motion, bouncing, collisions ) and result that occurred during their opponents turn whenever they decide to start their own turn.

What would be the best way to do this? From my research I've come up with a couple of solutions. Should I write some server code on which I would take user input and handle all of the physics simulation, then send the results to each device? or is there a way I could handle the simulation on one device and send all of the information to the other?

Also how exactly does one send everything that happens during a simulation through the network since I can not run the simulation on each device and be guaranteed the same results? Would I just update the server( or device ) with information of what occurs during every few TimeSteps?

I would also consider implementing my own physics/collision detection.

1

1 Answers

1
votes

If the different devices cannot run the simulation and get the same results, that's out. You must run the sim in one place and distribute the results.

On one of the devices or on a separate server? Would it be significantly easier to implement the sim on a separate server? If so, then do it; if not, then there's no reason to involve an extra machine.

The update scheme you suggest is a good starting point. It need not involve everything that happens during the turn, only what the display routine needs in order to show the action to the user. Start with small time intervals (which means lots of data), then make them larger until the visuals start to suffer.