I'm overriding Timedelta, and it... seems good.

I'm making a game that uses a lot of small physics objects as a controllable swarm. If the framerate goes down (eg, on older computers), the physics seems to get less accurate, and a lot of things clip through each other. I'm using TimeDelta in events that apply force to the swarm, but that doesn't make much difference.

If I use override TimeDelta, the game slows down to cope with the load and the physics works perfectly. A bit of slowdown in this type of game won't cause problems or make the game unfair. I don't see any graphics problems so far.

So... can I use override Timedelta under these circumstances, or will it cause other problems in the long run? I'm willing to sacrifice the ability to scale time.

Are there any alternative ways to keep the physics accurate?

Link to .cap: http://www.mediafire.com/?tdzzvpdjjwj

i just have to say that you have a very novel game idea here and i'm looking forward to seeing more

Thanks for the feedback!

I came up with the swarm idea by accident (it started out as smoke in a completely different physics-based game, but the smoke became more fun than the core gameplay). I'm hoping to make a sort of exploration/puzzle game, with an underlying sci-fi plot - I'll put it up when I have a few levels done.

overriding time delta will destroy the very fabrics of this universe!

Na overwriting timedelta shouldn't have much of a side effect, except how fast it runs on peoples computer. btw this game is really awesome!

That's a really cool game concept, I hope you work on it more .

You can use 'Override Timedelta', but be aware of what it does.

TimeDelta is the time between two frames at runtime, and is measured very accurately. This is used to move objects so they move at the same speed no matter what the framerate is. The problem is if the framerate drops a lot, TimeDelta (the time between frames) becomes large, and Physics can be unstable when TimeDelta is large, because objects are often jumping large distances instead of moving smoothly, so objects can end up inside each other etc.

Overriding TimeDelta makes it always return the same value, so even at low framerates, objects are basically moving the same distance every frame. This means the entire game slows down if the framerate drops. It also means if you're V-Synced (and you should be) then your game runs twice as fast on a 120Hz monitor as opposed to a 60Hz monitor. If you're happy to accept this, then overriding timedelta is a good way to keep your physics stable.

Okay, thanks Ashley! The issue with 120hz monitors wouldn't destroy the fabric of the universe, I think. I'll see how demanding the game ends up being; maybe I won't need TD override after all.

now that was a fun game

Wow, that's really sweet . Nice, simple use of physics, but the gameplay is all the better for it.

Sell this.

Really I'm serious this could be a very innovative game on the Indie scene. I personally like it better than Towers of Goo(or whatever its called

Thanks for all the positive feedback!

I will indeed sell this, if it turns out well enough (and I'll definitely send a percentage back to Construct). That's an awfully long way off, though.

So far, I'm spending a lot of time on the maths (eg, figuring out the mean or median of the swarm to cause clumping). If anyone has any tips on that stuff, I'm all ears - I get the feeling there might be a more elegant way of working. For example, to get the mean X of the swarm, I do a For Each loop on each object, adding each X value to a variable. I increment another variable that so I know when the loop has added up all the objects; using that, I trigger an event that divides the variable containing the X coords by the number of objects. So far, I haven't worked out how to measure dispersion or find the standard deviation.

Fortunately, I'm living with two engineers at the moment, and they're helping with the physics. I'll post anything we come up with that seems useful. I've almost finished a method of having attraction between physics objects proportional to their distance from each other (which is good for a gravity-like effect). It isn't at all difficult, especially compared to some of the stuff I've seen posted, but maybe it'll do some good for non-maths guys like me.

sweet idea! looking forward for the finished game :)

It sounds like you're on the right track for calculating the mean X - but you can possibly simplify it simply by dividing by the count when the for-each has finished, like:

+ Always

-> Set x_sum to 0

-> Set y_sum to 0

+ For each swarm_object

-> Add swarm_object.x to x_sum

-> Add swarm_object.y to y_sum

+ Always

-> Set mean_x to x_sum / swarm_object.count

-> Set mean_y to y_sum / swarm_object.count

Remembering events and actions are read in top to bottom order, this leaves you with the mean x and y in mean_x and mean_y.

That's a much better method. Thanks Ashley!