3
votes

It seems like Box2D for actionscript 3 is not deterministic, it means, in the event of a multiplayer game wheere physics plays an important role in determining who wins/loses, the results would be different for each user if their microprocesors are from different technologies (intel and amd for example).

So, is there a way to implement deterministic physics in AS3?, was this achieved before?.

Thanks.

1
blog.handcraftedgames.net/?p=140 good read on that topic, you can't have deterministic engine in as3, unless you can write something very simplified and custom made for gmaeBartosz
you could maybe try to write the physics engine server-side in php or python, then every player should get the same resultsJonan
I see, how about having a matchmaking system that only matches players with similar cpu architecture?, would that help?.Artemix
@bejrut The primary aspect is "a bit" incorrect implementation of sin/cos/log etc, because they are always performed in coprocessor. One can refrain from using Math.sin() etc, and instead implement a fixed point interpolation table for approximation of these functions. Nothing too simplified, just use a pre-generated set of values, embed em into your SWF and there you have more deterministic physics than before. (I can't say "absolutely" deterministic, there are other issues to resolve, but it's certainly doable.)Vesper

1 Answers

0
votes

I once had this problem.

We used Havok engine in Shockwave Director to simulate a realistic 2-player 3D pool game.

This is best be processed on the server for both accuracy and security. However, I was not able to afford any server-side physics processing, and client-side processing gave different results for different clients even when starting parameters were the same.

Our case is not 100% applicable to any multiplayer game but can be adapted. It was a turn-based game, each player made a strike, balls were processed by Havok and both players would have to see the same final result.

So, we did the following:

  1. A player that is having his turn is the lead player. He performs a strike. His strike data (strike force, cue position and rotation) are sent to server and from server to the second player.
  2. Both players do simulation locally. They both have identical strike data so the results will be approximately the same.
  3. After the lead player's simulation has stopped, he sends the final balls positions to the server and server sends them to the second player. Once the second player simulation has stopped, he adjusts the final balls positions using data from the lead player. This will look like balls have stopped and then jumped into slightly different positions.

Overall this doesnt' look too smooth but it will ensure that on start of each turn players will see identical playing configuration.

Applying this method to a more generic kind of multiplayer games (like, continuous actions with no turns, more than 2 players) the similar thing can be done:

  1. Choose (maybe randomly, maybe based on some specific data like latency etc.) a lead player.
  2. Collect all action data from all players, run their simulations locally.
  3. From time to time, make a snapshot of data of the lead player and send it to other players via server updates. Other players must adjust their simulations according to the received data (change the objects positions and also their angles, impulses etc.) Doing snapshots more often will result in a smoother simulation but will increase traffic.