joshujo

Minor backend refactoring update. I refactored the ID system for the assets and companies for easier scaling later. I did the same for the currency system, so why not use a new wrapper for the IDs too. Turns out, the blast zone of the was quite a bit so I had to go back and change all of the parts that previously used a raw u64 as the ID. This should make mixing IDs pretty much impossible now, and the code for generating new IDs is a lot smaller as it is just one short function rather than having to type and fill out an atomic operation function for every ID.

I don't have much to show for the frontend even after 9 and a half hours but the backend now sends player factory info to the frontend. Additionally, factories will now passively produce products over time. No news on the AI front yet, the player can't interact yet as well.

Next is going to be allowing the player to manage some things such as buying factories and selling products to the economy. Once I test the system and it works, I will get to creating primary and secondary industries before creating a save/load system.

I hate the Trial HSC btw, oh well

After almost 6 hours apparently, I have finally managed to get the generation to work. Apparently, my old system for preventing time drifting wasn't implemented properly leading to the entire core being eaten up and the tick system not working. It took me way to long to realise that and I did eventually figure it out. Then it turns out, after looking at my power and CPU usage, the crate I was using was probably used a spin sleep system. This made the tick timings more accurate and prevented time drift a lot, but the issue is that it does this by basically keeping the CPU awake, hence using up way too much resources and battery life.

Also, prior to fixing that bug, the window would become un-interactable the moment the 'server' backend started, and the RAM usage would start creeping up at a constant rate. I'm not sure why or how the memory was leaking, but it was something to do with that crate apparently, because now that I'm not using it, the memory usage is only 6MB! Prior to that, it crept up to 1GB before I ctrl + C it. I eventually made my own implementation of the tick cycle system. It went from 13% of a core to just 1% on release mode where it was 60 ticks/second and at 0.1% for debug mode at 10 ticks/second. To be honest, I think that smaller games would run better at 1 tick/second but I want to scale it to an extent where more ticks of smaller sizes are more effective.

Right now, the AI companies do nothing, but I can generate 1000 of them on one core basically instantly. I'm using shipyard ECS for the component management, which should heavily assist in the operation of the game thanks to its parallelism. I want the game to run at a constant tick rate with the minimal amount of work per tick so that the game can easily run a million AI companies while staying smooth. I think this goal can be achieved with good optimisation. Best case scenario, the primary bottleneck will be memory, not CPU.

In terms of the economy, for now, I intend to just have one currency, but this will probably be expanded into way after hackclub ends. The current currency system that I have keeps track on money as i128 microdollars for a very high degree of accuracy in terms of finances. I don't even keep that level of accuracy in my math exams, but apparently stock exchanges keep 4 decimal places of accuracy in their prices, so microdollars should be fine. Additionally, even if your currency happens to be Zimbabwean Reichsmarks, the insane range of i128 is more than enough to maintain even the most inflated of inflated currencies without any integer overflows.

Also, mandatory I don't know what I'm doing, Rust documentation is never clear and there's a lot of experimentation to ensure that my CPU doesn't catch fire or my RAM stick doesn't undergo nuclear fusion towards Fe56.

Added the initial create game page, future versions will feature more parameters. The game is designed to scale as high as your CPU can, with Rust multithreading underneath to support large amounts of AI companies. The game is planned to be an offline business simulator will you compete and co-exist with thousands (or millions with a good PC) of other companies that you will need to work with or against to thrive.

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