Devlog #3: Starkeep - Foundations of a solar system
Coding the mechanics of a basic solar system
Starkeep is built around the premise of a solar system, and a big part of making that a reality is supporting the concept of orbits. I’ve spent a bit of time figuring out the best way to approach it, and it led me to a bit of a conundrum.
I began with a simple question: Do I build out real physics, or do I fake it ?
Faking is easy and predictable, but doesn’t really give as much visual satisfaction. On the other hand, using real physics can become chaotic very fast (think three body problem).
People coming from game development backgrounds or experienced with full-fledged game engines probably don’t see this is as an issue. But I’m concerned about my planets accidentally crashing into the sun.
So, I’m now implementing both (explanation and code below)
Co-existing physics
The main premise of my implementation is that it can support multiple kinds of physics in parallel. I’ve narrowed it down to 3 main strategies:
Static objects: Some objects should not be bound by rules of physics. Example: I don’t want the pull from cosmic objects to impact the position of the sun in any way.
Fixed orbits: Important game objects, such as planets, need to move in extremely reliable ways. They can’t be accidentally hitting other planets or even fall into the sun.
Real orbital mechanics: Around the game, smaller objects should be unbound and free to move (and crash) completely based on the pull of other objects. The main contender for such rules are comets/meteorites.
I’m pretty confident that having these 3 models should be sustainable for the scope of this game (famous last words).
Code peek
Starkeep uses the amazing Ashley entity framework, in which each entity can contain a series of custom components.
I’m still learning LibGDX best practices, but it made sense that each entity (e.g. planets) would contain a component responsible of the movements. The catch here, is that they need to vary based on object type.
Firstly, I defined custom strategies for each of the movement patterns I wanted to implement:
Next, I integrated them into a brand new component currently named “Orbit Component”
Lastly, I hooked-in that strategy update into the game loop using an Ashley System.
“EntitySystem derived classes contain the logic that process our game entities”
(source: Ashley wiki)
The key here was to use the OrbitComponent as a filter mechanism to determine which entities should be updated. Something Ashley supports out of the box:
So far, things have been working pretty well. I’m very curious to find out how good or bad this setup will serve me in the long run.