Impact

This forum is read only and just serves as an archive. If you have any questions, please post them on github.com/phoboslab/impact

1 decade ago by dblack

I'm inches away from buying Impact - looks great so far! But I'm curious if the game loop allows for deterministic physics. One of the game designs I'm most keen to working on depends on deterministic outcomes - ie game situations need to be perfectly repeatable from initial conditions.

From what I've seen in the api, you configure a desired 'fps' in Impact, which seems to indicate a timer based game loop, which - from my current understanding - wouldn't give me the deterministic physics I'm looking for. So, my questions is thus: can the developer configure this in Impact? Is it possible to pin the animation to the actually render rate so that all updates will process the exact same amount of 'game time' in each update call?

Thanks to anyone who can help on this,

Damon

1 decade ago by dblack

It occurs to me that what I'm asking here might not be entirely clear. I'm looking to configure the game loop so that my entities update at the same rate on each render call. So, rather then query a timer to see how much time has passed since the last render, and move the entity based on the elapsed time, Is simply want to move it the same amount with each render call. I'm aware that this will make for potentially inconsistent animation speeds - depending on the rate the browser is rendering - but in the game I'm working on that isn't as important as having consistent physics results. Again, I need to be able re-run any given situation and ensure that the results will be exactly the same.

Thanks again.

1 decade ago by dominic

The short answer is: yes, you certainly can. You get the full source code of the library, so there's basically nothing you can't do :)

Slightly longer answer: overwrite the ig.Timer.step method, so that the game time is always advanced by a fixed time step (untested):
ig.Timer.step = function() {
	ig.Timer.time += 0.04; // = 25fps
};

All timers in Impact - and thus all physics - use the game time provided by ig.Timer, so this should be the only change you'd have to make.

Edit: I just realized that this could still result in inconsistencies because of floating point errors in JS, so you might also have to overwrite the tick() method of ig.Timer instances (again, untested):

ig.Timer.inject({
	tick: function() {
		return 0.04;
	}
});

1 decade ago by dblack

Exactly the info I need. Thanks much.

1 decade ago by Kxen

Hi,

Two simple questions:

1. Where do I put this code? (I think I got it working but still want to make sure.)
2. 0.04 makes everything very fast. What value corresponds to how fast the game is normally?

Thanks.

1 decade ago by dominic

1) As long as it's executed before the game starts, it doesn't matter where the code is. E.g. your main.js would be fine.

2) Depends on the fps you set in your call to ig.main. E.g. 1/25 = 0.4. If you start your game with 60fps and your machine/browser is fast enough to render those 60fps, the correct value would be 0.01666.

Since you asked this question: are you sure you know what this code does? Impact uses a variable timestep because browsers are notoriously bad at firing timers at a steady rate. If you use a fixed timestep, game speed may vary.

1 decade ago by Kxen

Hi dominic and thanks for the reply. I ended up making a plugin for it.

I'm a web programmer with no prior knowledge of game development so some of the concepts are still a bit abstract, especially things like ticks, timesteps and how they affect physics. With that said I think or at least hope I'm on the right track with this.

Bascially I need it for a replay ghost which replays the level by executing recorded keystrokes. While I understand a simpler approach would be just to record the position I still need the ghost to interact with the level. Without the code above I noticed some randomness resulting in the ghost ending up outside of the recorded "path" etc. Maybe this is not even a solution to the sync problem but so far it actually seems to replicate the original run exactly so I'm hoping it is.

If you have a better suggestion how to solve it please advise. :)

Thanks.

1 decade ago by dominic

Yes, that's actually a good use case. I used a fixed timestep for the replay at http://html5-benchmark.com/ as well.

The problem with a fixed timestep is, that the game will run in slow motion if the browser is too slow to render at the desired frame rate. You should use a lower frame rate: maybe 30 instead of 60 - so that old/slow browsers can keep up.

1 decade ago by maryrosecook

Quote from dominic
All timers in Impact - and thus all physics - use the game time provided by ig.Timer, so this should be the only change you'd have to make.

Edit: I just realized that this could still result in inconsistencies because of floating point errors in JS, so you might also have to overwrite the tick() method of ig.Timer instances (again, untested):

##
ig.Timer.inject({
tick: function() {
return 0.04;
}
});
##

Just wanted to let everyone know that this solution worked. My game uses Box2D. I was having problems where a lag in frame rate would cause objects to jump large distances because the physics simulation proceeded while the game lagged. I solved this problem using Dominic's excellent suggestion.

1 decade ago by CACUser

Hi Dominic,

Could you enumerate the steps required to create a replay, as you have done at http://html5-benchmark.com/.

Thanks

8 years ago by Joncom

If anybody ever stumbles upon this thread looking to make their game deterministic via a fixed time-step, here is a plugin I threw together based on the above:

https://github.com/Joncom/impact-fixed-step-timer

7 years ago by Joncom

Nevermind my last post. Here is a further improved solution that is both deterministic and does not suffer from this issue:
Quote from dominic
The problem with a fixed timestep is, that the game will run in slow motion if the browser is too slow to render at the desired frame rate.

7 years ago by Fravio4

Using this smoothing value, you interpolate the visual transform of the object at the time of the last logic step and the transform at the time of the current logic step, based on the visual-framerate-derived smoothing value. This allows you to draw the object animating at small, incremental locations rather than the big 7-pixel steps that the logic simulation takes.
Page 1 of 1
« first « previous next › last »