Physics repeatable?

[Vico]

Real-time, man!
Yeah, latency is to be considered, that's why I'm making special efforts to pass only light weight datas (integers or arrays of integers) Any substential infos about it is welcome, btw cuz I'm doing it as I feel without any concret knowledges.
Actually it runs fine when moving players or aiming, because each device updates the graphics based on light input datas, but I don't know how it will react on specific old devices (ipad 1, iphone 3GS)...

The initial state of the scene will be the same for each player, so technically it should stay consistent over the match time, the thing who could screw it all is if there's a small part of random values used in simulation... there is?

[slembcke]

Regardless of the determinism of the physics, latency is still going to be a way bigger problem. When you send a message, it's entirely probable no matter how small it is that it won't make it to the other device before it starts simulating the frame the message was for. You *must* be constantly resynchronizing the state of the game between the devices unless you run them in lock step. Your game would not run in real time if you did.

A common way such things are done is to make one of them the definitive gamestate (the server), and the other be the client. The client takes the user input and both uses it to run it's own copy of the simulation as well as sends it to the server. The server then uses that input (which may now be a frame or more late) to run it's copy of the simulation. It then periodically sends a copy of it's simulation to the client. The client then replaces it's simulation with the server's version and continues on it's way.

That is why in a lot of games with very bad latency, your actions might not happen right away, or you may things jump around on the screen. If you input takes too long to get to the server, it will delay your actions for that long. When the server takes too long to send a copy of it's gamestate, yours might get off and then objects will snap into place when the server's corrected copy arrives.

There are a ton of articles about how to do networked multiplayer games, and there isn't really a correct or best way to do it.

Anyway... I guess that's all a little off topic. If it works fine now I wouldn't worry about it. Everything from the 3Gs and up have been using the same CPU, and the results on armv6, ppc or i386 aren't really going to be that different. The rounding errors are certainly going to be a thousand times smaller than errors due to latency. The big issue is when you have a pile of 1000 objects simulated for 1000 frames and expect each and every one of them to have the exact same position at the end.

[Vico]

Yeah, I remember those high ping matches on Call Of Duty where you shoot the guy right in the middle but he teleports 5 meters away and you missed that kill, I cried so much :_(

So, there is 3 options of doing it with different gameplays in consequence:

A-Player 1 press the shoot button, it runs locally on his device and send the message to other device. Latency will make the player 2 could have moved before the shoot message reach him. Applying a post-synchro would definitely deceive one player or the other because of "teleportation effect".

B-Player 1 press the shoot button, it sends the message to the other device with a callback who reponds "OK I got it", then action runs on both devices. The action will be synchronized but neither real-time, player cannot deal with the fact he shoots then the bullet is fired 1 sec later;

C-Player 1 press the shoot button, the game enters in "Freeze mode" where datas are synchronized with method B, except the player 2 will see its position going back to the one the player 1 was seeing when he fired, no one can moves or fire again while the bullet is flying (with some slo-mo "bullet time effect"), then things get alive again when it's done.

I would be interested to get you point of view about that, if you don't mind (are you a player?)

[slembcke]

So a bit of a confession. The only networked game I made was a 2D top down shooter for a 24 hour networked game competition. So I'm not exactly an expert on networking.

I read a few interesting papers a few years ago written by the guys that did the Quake, Unreal and Source engines. I think this *might* be the Source one? Seems close, but it's been a while. The date on it seems a bit early... I couldn't find the others, but I'm sure some more Google searching will turn up something else.

http://web.cs.wpi.edu/~claypool/courses ... ernier.pdf