Hello Cosmorists!
The technical month
After a year of distance, I'm coming back with a fresh perspective on the game that I otherwise wouldn't have gained if I forced myself to keep on working on the game this whole time. A lot of it is on the game's code.
The code refactor
The game's code has been refactored before, many times. This refactor however is more system-based, and much larger in scope. The code is clean in certain spots, messy in others. The messy parts are what's being organized. Sometimes, code responsible for one thing, like world loading logic, is sitting there in another bit of code, like player initialization logic, that should be responsible for something else.
UI code refactor
The UI code especially involves manual position shifts, separate mouse detection code repeated over and over again, and scale values. Because of this, adding a button to the game can sometimes take over an hour. Custom UI drawing code? That could take several hours because of the messy code. That's why I don't bother as much adding new UI.
This refactor now involves writing more scalable, expandable, and maintainable code. Instead of dozens of areas to detect mouse detection, it'll be a single tree that does all the rendering, mouse detection, positioning, and optional animations, all in one place. The primary challenge is migrating the spaghetti code over to the new system, which will likely take months, and be gradual, but once that's done, adding new UI will be as simple as adding one or a few lines of code instead of manually positioning them and giving it separate mouse detection logic. Instead of spending hours on mouse detection, custom draw code, positioning shenanigans, one place handles it all.
In other words, the UI is undergoing "code despaghettification", the process for when code goes from spaghetti, to clean, maintainable, and extensible!
Loading screen
While the game's inner workings are being rewritten, the game also got a loading screen, which will appear a few seconds after clicking Play or double clicking the .exe. It looks like this:
Not the most flashy feature, but the game window will pop up sooner followed by feedback, while showing the progress bars and spiral animation and rising percentage. Instead of 10 or so seconds of silence before the game window shows up, it's around 3 seconds of silence, then 7 seconds of feedback before showing up!
Save rework
New save file structure
This is the new file structure for upcoming saves:
A lot of code responsible for saving and loading game saves was also mildly disorganized, especially in the early days of the game (Saves from 2023-24 especially had hundreds of files each). Saves in the upcoming 0.2 update will soon have 6 files per save instead of dozens of small ones. The versions, play time, world seed, creation date, and last played date will all go into metadata.bin, all the world data will go into a single world.bin file (including the soon to be deprecated Luna and Aquatica), all the map data saved in the worlds folders will go into mapData.bin, and so on. Existing saves will still load as always, but automatically generate those six files when saved.
These files are subsequently larger, but at the scale of tens or hundreds of kilobytes at which the game's saves are normally, that's basically nothing for most hardware. This also means faster load times as a bonus because the disk only needs to read 6 larger, but still fairly small files, instead of dozens of files that could vary from a few bytes to a few 100s of kilobytes. It cuts down on file system overhead, and the CPU does the rest!
Drag-and-drop saves
I thought it might be fun to add the ability to drag-and-drop saves. Drop in a save file as a .zip in the game window, and the game immediately loads the save. This is what it looks like on a roughly 50 hour save of mine with File Explorer overlaying the game window:
It also works when the player is already mid-game. Drag-and-drop a save while you're already in the game, and the game will save your session, load the new save, and you'll be in that new save. If that .zip file is an invalid format, or has corrupted data, it'll take you to a "Failed to load " screen and redirect to the main menu.
That feature took me only about an hour thanks to the refactored save code that's easier to build on. If I didn't refactor, I wouldn't have added a feature like this because it might have otherwise taken a week.
Save folder button
There will be a button in the world selection screen that opens the save folder in File Explorer, right next to the create world button:
The combination enables something bigger
Drag-and-drop saves seems like a cool-but-not-game-changing kind of feature.
That save folder button doesn't seem all that special since many other games have it.
Saves with 6 files instead of dozens with slightly faster load times sounds more like technical work.
Saves that are tens or hundreds of KB in a survival crafting game is technically notable but not gameplay changing.
But drag-and-drop saves (smooth save hopping) + save folder button (easy save file access) + 6 files per save instead of dozens (slightly faster load times) + saves that are 100s of KB as a .zip (high portability even on 10+ hour saves), put together? That combination of features and what they enable will be the foundation of something much bigger involving saves than each one individually!
Space realm
Impact damage
If the player is moving faster than 20 tiles per second while in the space realm, the player will soon take impact damage.
The damage table is like this:
Speed (tiles / second)
Damage
0-20
0
25
4
30
15
35
34
40
60
45
94
50
135
55
184
60
240
This will be the game's equivalent of fall damage for a top-down 2D game like this, but instead of a "down" to fall from, it's impact physics in the space realm, on top of the zero-friction physics (drift danger) and oxygen scarcity that makes the mechanics completely different from the planetary surface.
That speed-to-damage curve also applies to enemies. An enemy hitting a wall at 40 tiles per second, will also take 60 damage, just like the player.
Since that curve goes up fast, this is gonna be one of the signature dangers of the space realm. Shields will protect against melee, ranged, explosive, and hazard attacks, but it won't protect against impact damage, so a player even with end-game gear will still be vulnerable to impacts. That's where the space realm is gonna feel tense at all times!
First space realm enemy!
Since there's no friction in the space realm, and everything is relative to each other and every entity will drift as soon as they have velocity, the physics rules up there aren't the same as on the planetary surface.
Initially, I tried to use predictive math where the enemy predicts where the player will be, all with zero friction physics and acceleration vectors, but it was too complicated to implement, risked possibly more spaghetti code I wouldn't understand, and abandoned it in favor of something easier to implement.
Instead, that probe will slowly try to match the player's speed by accelerating against the relative speed of the player from the enemy's perspective, and when that relative speed is within 1 tile per second, it'll do an ambush dive attack by accelerating 5x more than normal for about 1 second before it drifts, matches your speed, then dives again!
This is what it looks like:
That behavior was much simpler to implement for an environment like, only involving speed matching and enemy states instead of a full-blown orbital mechanics simulator wrapped in enemy behavior, while being a predictable enough danger to learn!
The infrastructure-centric approach
I'm now approaching everything about the game in an infrastructure-centric way. Last month, I already hinted at it, but now I'm going all in on this approach.
The game's code is where it's being applied the most. The primary bottleneck to adding new content wasn't drawing assets or composing music, but getting the spaghetti code to collaborate. New features make the game's code more and more complex, and less and less maintainable, and compound that over 3 years, and the lack of a vision for the game, and that was one big factor for the year's long gap from September 2025 (the last Latest in Cosmorists devlog before the gap) through August 2026 (breaking the silence).
Now though? I'm slowly paying off that technical debt by coding centralized systems that handles the logic for me, bit by bit. The code slowly gets despaghettified to centralized systems, and adding new content will get easier and easier.
0.2 progress
Now I'm considering releasing 0.2 in a month or two because it's been over a year since the last update. I could keep refactoring, but that'll delay the update even further into potentially next year.
Instead of doing all the refactoring now, all I really need to do now is to polish up the gameplay loop a little and add gameplay reasons to visit the space realm, and that might be where it'll finally be done. Even if it won't be perfect, as long as there are as few bugs as possible from 0.1.5.1 to 0.2, I'm a little more willing to let go of my inner perfectionist on the content side. I'm now increasingly focused on ensuring existing saves are compatible, and there are few UI bugs after the currently partial refactor.
So this was a much more technical month, and it's likely to stay that way for months, even after 0.2 launches. After so long, I'm not quite the same developer as I was in 2023-24, but the unglamorous parts of game development I never bothered to touch are now where most of my attention is being focused on!