GravRogue

I decided to make the player's camera locked onto the planet so they appear to always be above the planet. This might not be a good idea and I am consider rolling that back as it can feel weird sometimes. For instance, it feels more like you are stationary and the planet is the one rotating. But before this, the planet was just a block of blue, now I added generated textures for planets. These textures are generated on the rendering thread and are cached to memory after they are done, but they take a while to generate as each texture is created pixel by pixel, I'm not sure how to make it faster, but for now, 256x256 textures is the largest I can do while keeping loading time reasonable. I'm looking for a no locked rendering model so this method of generation is bad as it violates it due to the thread being effectively frozen during texture generation. I will later delegate the rendering to another thread so the game's load time is instant and textures can be cached and used as they are generated.

I am now in the process of adding projectiles to the game that can be fired by the player. As I am somewhat lazy, the damage model will be the unified across the game for kinetic energy objects. Also, kinetic energy objects include you the player, the planet you orbit, and the enemies around you. The damage that projectiles (and anything you might collide into) will be resolved using the kinetic energy formula.

The amount of damage you take will be a function of
Damage = KE * damagemultiplier - damagethreshold

This means that I don't have to write separate collision and projectile damage code, they are the same thing.

I can't wait to write the AI and lose my mind doing that. Orbiting a planet using gravity is probably not going to be AI friendly, but I have some ideas on how to do that. But before that, it is projectiles and moons.

Effectively, moons are essentially just planets that orbit other planets. They spawn randomly on planets at orbitals. For now, I'll just have one moon for one planet at most. What makes them different from other orbitals is that they are too heavy to move most of the time, so their orbits will be quite stable. This should allow for more dynamic combat especially when the moon of a planet is affecting the gravitational field of the combat zone.

Expect the next devlog to be about projectiles (I know no one is reading this or expecting anything)

Demo ready to ship!

The star system generation and player movement is included as part of the demo. I tried my best to keep everything nice and clean but it kind of feels like spaghetti in some parts. I hate the Rust borrow checker, I hate the Rust borrow checker, I hate the Rust borrow checker. After fighting with the Rust borrow checker, I managed to port most of my old single thread gravitational simulation code into a multithreaded environment.

Gravity is done using Newtonian physics and equations, I have not used an integrator as I do not currently understand any of the maths on Wikipedia right now, so expect to see the law of conservation of energy to be broken at the moment. But generally, outside of f64 float errors, the accuracy of the gravitational simulation should be close enough to avoid immediate system instability. The future versions will feature generated star systems, so you'll probably never play for long enough in any one system for float errors to turn your star system into a singularity.

The demo is pretty basic, it's primarily just movement for now, but the next ship will include kinetic weaponry and moons for planets, and perhaps more coherent planet generation.

Enemies will probably come after, I still haven't worked out how to make AI, let alone AI that can orbit planets, I have a feeling that I will use Kepler's Third Law a lot though.

Added orbital bodies that follow Newtonian orbital physics but with a slight adjustment to the Gravitational Constant for gameplay purposes. As you can see, the movement seems a little clippy due to the i32 rendering that Raylib uses, so tiny changes in the f64 positions of the bodies only appear once they cross in integer, so small jumps will appear. I plan to fix this by making 1 simulation unit = 100 or 1000 rendering units to make smaller movements more smooth.

But really, I intend to make the point above irrelevant eventually as the player will be orbiting a moon orbiting quickly that is orbiting a planet faster, that is orbital a star even faster and even that star is orbiting a superheavy black hole.

The usage of multithreading to calculate the physics is done in two passes, the pass is purely to calculate the acceleration that each body experiences, the second pass is to apply that acceleration to the body. This means that there is no data race at all, as the first pass is using exclusively immutable and the second pass only mutates its own data. Therefore, multithreading can be used to speed up the simulation even once hundreds or thousands of objects are added.

Set up the channels required for the game to support multithreading. By decoupling the logic from the rendering, the game's GUI should feel significantly more responsive even if the heavy simulation backend is slow. I also added the orbital physics to be done in two passes, the first pass calculates acceleration without mutating data. This means that each object can calculate gravity recursively in parallel without data races. The second pass is done also in parallel with the acceleration being applied to the velocity and the velocity applied to the position. This can be done with multithreading as well as each entity will only mutate using it's own data. I'm not sure how I'll handle collisions yet, but that's for another time.

Added the base code to the game, the main rendering thread will host a detached logical thread so any slow downs in the computation of the game because I tried to spawn in 1000 bodies and now O(n2) amounts of bodies need to be calculated will not slow your rendering down. Maybe I'll even add LAN multiplayer, but to be honest, I have no idea what I'm doing