Posted May 01, 2024 by Nebulous-Remote
#physics #engine-development
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):
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:
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!