Road to Stable Physics

When the idea for Prime Orbital Golf (POG) formed in our minds there was an immediate thought that popped into my head (my head being the head of the programmer for Nebulous Remote): 

P H Y S I C S

Sometimes demonised by those who've been scorned by unstable or unpredictable physics code, physics can be sometimes seen as the hard route to work with in a game. It requires patience, balancing, and tools to make debugging easier. Unstable physics code is horrible, it makes a game harder to test with people, causes obscure and hard to reproduce bugs to appear, and can kill motivation for a project quickly. We had once considered toying with the idea of a small 2D top-down racing game, but were put off by the idea of all the physics woes we'd probably have to contend with. But for POG the idea seemed simple and small enough that maybe we could produce a tight enough set of requirements to limit the scope of problems we may encounter. 

I thought it might be good to share what we decided to limit ourselves to for our early prototypes, and even the build currently available today. And what plans we have to further improve the stability and reduce the chance for bugs. 

(Note: Lots of this arcane knowledge need not apply if you're using Unity, Unreal Engine or Godot. the main beneficiaries of this advice are those who produce their own engine for the games they make).

Techniques & self-imposed limitations:

1. A fixed timestep was a must (see here for a popular resource on the topic). Deterministic & stable physics cannot be achieved without a fixed timestep. The natural variation you will encounter running on various machines, and users wanting to have v-sync or set custom framerates means without a fixed timestep, you're doomed.
2. Simple impulse based physics works wonders, we rely only on force application at the centre of bodies. We don't have angular momentum or any rotational behaviour, we rely solely on simple impulse based physics (that applies to body-to-body collisions)
3. Limit the number of bodies to a finite number, don't allow over a certain amount. The more bodies, the more problems, especially when applying forces to a body based on every other one in the scene (as is required for Newton's Law of Gravitation). 
4. The larger the floating point numbers, the more inaccurate the results. We keep our world to sensible range of float values, and try to balance all the whacky numbers for mass/big G/radii to keep forces sensible and velocities manageable.
5. Unit conversions and scaling between metres & pixels helped us with the above also.
6. Tunneling bodies suck, we encountered this with fast moving moons where they could tunnel past the golf ball and a collision wouldn't be registered. Rather than adding in a swept area test, we just lowered what the maximum speed could be.
7. Simple static & dynamic friction models worked well enough for us, although this was the point where some cracks began to show..

The above gave us enough that the builds of POG we currently have on itch are stable enough considering that it's all self-written physics & collision detection/resolution code. We don't utilise any external collision libraries, nor physics ones. However, our long term goal is to move towards box2d. For one thing there's a maintenance burden associated with keeping your own physics/collision code going, for another box2d has a bunch of extra features we could take advantage of. Our issues around friction and the golf ball rolling across a planet surface would be solved if we had box2d. So in our roadmap (some point in the distant future) we aim to have our physics powered by the new box2c: https://github.com/erincatto/box2c and we'll hopefully be able to produce a devblog about how that migration goes!