Prevent physics non-determinism

Get help using Construct 2

Post » Thu Oct 31, 2013 10:31 pm

My game that has no random elements, behaves differently every time I run it. I use the Box2D stuff so I wonder if that's the source and if anyone knows the fix?
B
14
S
5
G
1
Posts: 60
Reputation: 1,052

Post » Thu Oct 31, 2013 11:19 pm

fps and with that dt will be different (even if differences are very minimal), so the physics calculations will be carried out at different positions in time and space (I believe)mindfaQ2013-10-31 23:19:49
Visual Novel 'Engine' in 100 Events
if you ever have to choose between buying Construct 2 on scirra.com or on Steam, read this: Review
B
22
S
9
G
1
Posts: 788
Reputation: 3,788

Post » Thu Oct 31, 2013 11:25 pm

Unfortunately it so far seems that C2 doesn't use an improved fixed timestep. C2 uses a simple version so I'm sure it's going to be impossible for solid deterministic physics using C2 current implementation of Box2D :(
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,028

Post » Fri Nov 01, 2013 12:15 am

you stars. I found a stepping mode in physics which does it!
www.scirra.com/manual/98/physics

EDIT: hmmm that doesn't quite cut it due to my other timers going off every XXX seconds and interacting with the physics.

I once implemented a time accumulator for a physics engine to properly decouple these things (gafferongames.com/game-physics/fix-your-timestep/)

I wonder if its possible to get that kind of approach into construct 2

EDIT 2:

yeah running my behaviours off of "every tick" with physics stepping on fixed made it deterministic. However my frame rate suffers. I believe, that if you were able to switch physics on and off rapidly and not process interactive behaviours every tick, you could play catchup with the frame rate like a time accumulator. There is no global on and off for physics though so I don't think it is feasible at this point.tlarkworthy2013-11-01 00:46:21
B
14
S
5
G
1
Posts: 60
Reputation: 1,052

Post » Fri Nov 01, 2013 12:13 pm

You can't have it both ways. Either it's framerate independent and non-deterministic, or framerate dependent and deterministic. I would recommend framerate independent, and design your game with wide enough tolerances that the random variations are not significant to the gameplay.
Scirra Founder
B
398
S
236
G
88
Posts: 24,441
Reputation: 194,681

Post » Fri Nov 01, 2013 2:30 pm

That's not true. Havok and suchlike decouple their physics from the frame rate and still achieve determinism via a time accumulator (which I linked, but here it is again http://gafferongames.com/game-physics/fix-your-timestep/).

Basically you only step the physics a fixed amount k, after after dt > k wallclock time has passed. You keep track of the remainder k-dt and use it in future calculations to decide whether to perform a physics step or not.

In summery, you decouple the physics stepping from the rendering thread entirely.


This means several frame renders may occur in series before actually updating positions. To stop jerkiness, you integrate the time remainder with the velocity and last updated positions. i.e. you linearise the motion model and project into the future when demanded by the rendering thread.

This decoupling physics from framerate is a common pattern in game development. But its not obvious unless you have seen it before, see also gamedev.stackexchange.com/questions/1589/fixed-time-step-vs-variable-time-step

In construct 2 a event tick is tied to frame rate. So to decouple physics we have to decide whether to step or not. So we would need functionality to globally enable or disable physics evaluated every tick. Or choose to manually tick the physics ourselves in the event sheet.
B
14
S
5
G
1
Posts: 60
Reputation: 1,052


Return to How do I....?

Who is online

Users browsing this forum: lesthevrlover and 33 guests