Jump to content

The physics of the Don't Starve world


Recommended Posts

In order to implement a whirlwind behaviour in Up & Away, and fix some bugs in this implementation, I did some research on how the physics of Don't Starve works. This was done by reading the documentation and source code of the physics library behind Don't Starve (Bullet, an open source library) and running a set of tests simulating what would be done in a physics lab. The mod I wrote/used for these tests is attached, in case someone wants to check the results themselves or toy around with it.

I summarize below my main findings, in case this may serve as a useful reference for others. When discussing forces (and the corresponding accelerations), I restrict myself to the case of the gravitational force, since this is the only force field in the Don't Starve world. Equations should be understood as vector equations, i.e. as one equation for each coordinate. The function ln(x) denotes the natural logarithm.

Damping:

The damping coefficient (set via inst.Physics:SetDamping(value)) emulates air resistance. The higher the damping coefficient is and the faster an object is, the larger will be the acceleration acting against the current velocity of the object. A damping of 0 makes the object fall free of dissipative forces, with its speed ever increasing. A damping of 1 makes the object completely unaffected by gravity, staying static in mid air. Values for the damping coefficient outside the range [0, 1] get clamped to it (i.e., if less than 0 it gets set to 0, and if larger to 1 it gets set to 1).

Let v(t) be the velocity of a falling object at time t, g be the acceleration of gravity and d be the damping coefficient. Let delta t denote the update interval of the physics engine (which is half a frame). By the source code of the Bullet library, the next velocity of an object is calculated from its current one by

VpzfBpc.png

If we assume the update interval is small enough to make the changes in velocity almost continuous (a fair assumption), the dampened acceleration of a falling object with damping less than 1 is given by

aVAR6q9.png

this can be deduced from the formula for the velocity update like follows:

VkPsj4Q.png

Gravity:

From the expression of the dampened acceleration, an object with 0 damping falls with the acceleration of gravity, which is constant. Therefore, the average acceleration of a falling object equals the acceleration of gravity. This was used to compute it as the value

yHEM7UQ.png

that is, 40 units of distance per second square in the vertical direction (pointing down), or equivalently 10 tiles per second square.

Terminal velocity:

As it was discussed previously, if an object has a damping of 0 its speed is ever increasing during a fall. If an object has a damping of 1, it remains static (it may still be explicitly given a velocity, but it is immune to the effects of gravity). However, if the damping is greater than 0 and less than 1, a free falling object's velocity converges to a distinguished value, called the terminal velocity (i.e., the velocity gets closer and closer to the terminal velocity as time passes, provided the object is still falling, regardless of whether the initial velocity was smaller or larger than the terminal velocity). The terminal velocity can be calculated from the expression of the dampened acceleration, since it corresponds to the condition that the acceleration becomes 0. Therefore, the terminal velocity of an object with damping 0 < d < 1 is

KPATmPn.png

Note that, since ln(1 - d) is negative, the minus sign means that the direction of the terminal velocity is the same as that of gravity.

Partial and missing results:

The behaviour of the restitution coefficient in Don't Starve is not entirely clear. In the usual sense it has in Physics (and in the implementation of the Bullet library), when an object with restitution coefficient c collides with the ground it should bounce back with a vertical velocity equal to c times its value before the collision, but with the direction reversed (i.e., with the sign of the vertical velocity reversed). But my tests are not agreeing with that; instead, the ground seems to have an inherent restitution coefficient itself which gets multiplied with the object's, but the ground's coefficient seems erratic, oscillating between 0.6 and 0.8 (usually, sometimes oscillating even further) instead of being constant.

I haven't investigated friction, though I suppose it would act as usual: when an object is in contact with a surface, this object's friction coefficient multiplied by the magnitude of the acceleration of gravity acts as an acceleration against its velocity (provided the object is moving, and acting as a resistance to accelerations otherwise).

PhysicsLab.zip

Link to comment
Share on other sites

Jeez, math-illiterates like me should stay away from threads like these...

 

But, in effect, interesting findings. I do have to beg the question of when any of these variables (being that they're all Y variables, i.e. vertical) come into relevance? I suppose I'll have to follow your mod work more closely to see how you iterate these mechanics.

Link to comment
Share on other sites

But, in effect, interesting findings. I do have to beg the question of when any of these variables (being that they're all Y variables, i.e. vertical) come into relevance? I suppose I'll have to follow your mod work more closely to see how you iterate these mechanics.

They come into play when you're dropping things from the sky, launching things away (for example in an explosion effect), and more generally in anything where gravity plays a role.

Link to comment
Share on other sites

If the camera were to follow, wouldn't the game go all fugly and pixelated? I didn't know the game could handle that stuff. Looking forward to your compositions. :3

If the camera were to follow what? The player falling or being thrown? If so, no, the game would look correctly.

Up and Away already has things falling from the sky (loot, when you chop down a beanstalk, and whatever gets sucked into a whirlwind; the latter case includes the player). We are also planning a "throw" move in a boss fight which would launch the player (or whatever the boss is fighting) biomes away. The major obstacle in implementing things like this is that the player and many mobs have a damping of 5 (which is the same as a damping of 1, i.e., they just remain static mid air), so the damping coefficient needs to be tweaked and then reset to 5. When you account for the player Save & Quitting in the middle of that... it's a nightmare to get things right.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.

×
  • Create New...