The game’s background image is courtesy NASA/JPL-Caltech.
This is a simulation of planet formation, made with Unity. I want to make it into a game, but I’d need much more experience to make it good.
You can imagine guiding the formation of planets. There are lots of possibilities, like using your mouse to nudge planets around. Or maybe you can plant giant barnacles which shoot out tentacles and drag in nearby planets.
The goal isn’t to make a realistic simulation of planet formation. Things would progress way too slowly (like months rather than an hour), and scientific simulations of gas disks are very complicated. Gravity is simple, so that’s realistic, although exaggerated scales (time, mass, etc.) mess with the emergent effects of gravity.
Instead of realism, the goal is to create something which feels like real planet formation. The planet formation processes in the game are based on real planet formation, but my goal is to share their cool factor rather than the precise science.
To make this, I learned about planet formation, but the hardest part was actually making the movement look smooth.
It needs to look very smooth, because any jitter looks terrible. There are tiny things flying across the screen, making jitter super obvious, and I think there’s also a problem with the rendering. (It leaves behind fading afterimages each frame. Hopefully that’s why it’s a bit nausea-inducing.)
To make movement look smooth, it needs 3 things:
- The same number of physics ticks each frame. Otherwise, things can appear to suddenly jump forwards slightly.
- Minimize errors introduced by physics using discrete timesteps. Otherwise, the movement will look unnatural.
- Constant 60 FPS, with virtually no dropped frames (it uses vsync).
Let’s start with the constant number of physics ticks per frame. Each tick needs a constant timestep, because changing the timestep makes physics less accurate. Frames have a variable duration, so most games do physics ticks until the physics time is close to the exact time (article). This game does that too, except if it decides that it’s running at 60 FPS, it uses a constant 2 physics ticks per frame. Otherwise, it’d mostly do 2 ticks per frame, but little variations would introduce jitter. I’m not sure that’s still an issue in Unity (article).
Next, it needs to minimize errors introduced by discrete ticks. Unity’s physics use a 2nd-order integrator, whereas this uses a 4th-order integrator (eqn34 for explanation but use eqn22). Don’t ask me what any of that means, but the result is much more natural-looking movement. It’s actually pretty simple, just adding velocities to positions and stuff like that. The downside is it requires 4x as many force calculations, and force calculations are like 90% of the game’s computing.
Lastly, it needs to maintain 60 FPS, on my fairly old laptop. A lot of the performance gain was from miscellaneous code optimizations, which I won’t go into.
Multithreading gave a huge performance boost. However, that also added some overhead for running the multithreading code itself. It was something like 10-20% of computing time, but there were also other issues like garbage generation and variability. I don’t think C#’s task parallel library is meant for this sort of thing. For one thing, generating garbage isn’t really acceptable in games, because it can cause lag spikes. Also, this game runs 960 parallel steps per second, which is probably a lot more than normal. I ended up learning how to write multithreading code and optimized it for this situation.
I didn’t know how to do multithreading before that. Turns out multithreading is a nightmare, and also pretty fun. Compared to normal programming, it makes you a lot less certain about what’s going on, especially while you’re learning. I love that feeling of frustrating curiosity. It’s the same feeling I want to share with this game. That, and just something which looks cool.