That's a much better method. Thanks Ashley!

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.

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.

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.

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