Cheating at physics (loaded dice)

I want to simulate dice being thrown and rolling on the table in multiplayer environment. For single player, it works kind of ok - I can rotate dice randomly just before throwing (thus ensuring that positioning of the ‘hand’ throwing is not really affecting the outcome in predicable way) and after that let the physics simulation do the work.

Now, problem comes with multiplayer. I want other people to see cide being thrown and ending up with same results. I do not care about them rebounding in exactly the same way, etc - but the outcome has to be the same. This boils down to be able to distribute the results and have simulation ending up with dice being with certain face up after it is resolved…

I do not really trust physics enough to just distribute initial position/rotation/force and hope everything will end up being the same. I can basically see following possibilities:

  1. loaded dice - do the start of simulation in real way, but near the end, start manipulating rotations/etc manually, so dice will turn out to proper orientation; not tried it yet, but I assume it will look very awkard

  2. simulating entire throw, seeing the result orientation and preorienting the dice (or even only textures on them) to end up with expected number.

  3. ‘blurring’ textures on dice while they are moving and then correcting them after they come to stop…

    Of course, solution 2 is the best from user perspective - people would not notice that something is wrong (just first ‘randomization’ of the orientation of die would be not that random…). But to do that, I would need to perform physics simulation for few seconds in future, then back out any changes it might cause (optionally, I might end up making rest of scene not-movable for time of throw) and then perform it again in ‘real-time’.

    Do you think it will work ? How to do that in the way I can be 99.9% sure that results will be the same in simulation and final execution (I can probably survive faking results in 1/1000 of the cases) ? How long can it take (I assume that I will want to stop refreshes in meantime) ?

    Or maybe you see some other, easier solution ?

I’d say solution 2, but rolling a white dice, then map the correct texture on it when it stops…

This way you can let physics have their own path…and have the same result.

Of course the player will notice the trick…but does it really matters, as long as he knows that the roll is really random?

Do the throw on one client, save each 100 ms position velocity ect, and replicate that to the other clients.

Phoenix - this might actually work ! I would implement physics in assumption they they are deterministic, but then implement ‘synchronization’ points to get them in sync with ‘cinematic’ path. If everything works as expected, corrections will be almost invisible, but enough to guarantee the same result.

Yep it’s more like a prediction that way, but nothing solid. (Actually my whole network system works with that kind of replication every 75 ms, and clientside it interpolates between the values, instead of using real physic calculations)

As a side note I have done a quick test with reproducing exactly the same initial conditions - same client, same position of all geometries, just simulating same throws over and over. Results are suprisingly different, not only dice end up in different place each time, even results are sometimes different (but they tend to switch between one of two possibilities) - in the case I have checked, around 1 in 8 throws ended up as different number.

Prediction/cinematic correction comes next

Yep the results differ so much because of bullet being a game physic engine, they made much trade offs in terms of speed vs determinismus, normally you won’t see them since it looks realistic, which is the main purpose of most physic engines.

I agree in that dynamically correcting dices will probably look awkwards.

I think that your appoach is quite right, but here is my suggestion in case the environment is fixed.

  • Simulate hunreds of entire throws from hand from different positions and angles, and save the cinematics. This data would ship with your game.
  • When player throws dices, load one of your precalculated throws and set dices at the original initial position (hopefully your ‘hand’ mesh should hide this ‘gap’). Arrange textures so the outcome of the throw is what you want it to be.
  • Send clients the information about what animation to use and the expected outcome.
  • Clients would keep dices out of physics at least for whlie the animation runs.

    If the environment is not fxed, maybe you can simulate the throw on the server as fast as possible in the moment dices leave a player’s hand. But this may force you to stop game and show a “calculating” message while you do it.

    :s Nice problem :slight_smile: Let us know what you finally do :wink:

@jjmontes - world itself is fixed, but my idea so far is that dice will be thrown from camera position (camera of throwing player, others will see it appearing out of thin air) - and as camera is movable, this in fact means that world is very much moving.

I think Phoenix idea is perfect solution for me, I just need to find some time to implement it :wink: