Hi all, Lee here, developer of FE. We’ve decided to post the 2026 retrospective here at the end of September rather than closer to the end of the year since it’s already clear that development is going to roll over into 2027. I do feel like this year has flashed by so far, which has become a common feeling these past few years, but I wanted to sit down and take you candidly through what has been happening since the last Steam update post at the tail end of 2025. This post does feature a fair bit of text, so if you prefer a snappy video format instead, scroll to the bottom and I've got you covered =)
That was the year that had me finally take the plunge to replace the existing cobbled-together UI, and I was probably still working on implementing towards parity with the old system for the first quarter or so of this year. Virtually all of the old interface has gone by this point, except for that featured on the title/menu screen, which I consider unimportant for now. Much work has gone into streamlining things as I go along to avoid having heaps of polishing to do at a later stage. Assignments and mission tracking now has it’s own panel coupled to the messages panel on the right of the screen. Ship installed modules and inventory screens have all been fleshed out now to fulfil the requirements of the player, and we designed the Fleet Outliner to go from a random list of units to a more hierarchical one: showing any stowed or deployed units beneath the parent vessel, so that everything is more functional and easier to read. Hovering over a stored item in the inventory panel shows the number of that item carried by each of your fleet assets on the outliner itself, as an example of how we’re trying to anticipate the information you need to know on a minute-to-minute basis.
Alongside this work, the Fleet Builder (where initial/custom fleet setups are created) needed to be re-built, since the internal workings of fleet assets had been re-designed alongside their corresponding UI element. Up to six subcomponents per module slot, with that number established by the space available in the relevant hull section. No more abstract subcomponent volume requirements. Power had been made more discrete too, with units of power generated and consumed by active subcomponents, and a more ‘mechanical’ switch sliding back and forth to activate and de-activate subcomponents as required. Population, too, was re-thought: gone were the seven different kinds of population defined by their role: civilian, engineer, officer, scientist, medic, pilot and soldier-- replaced by a singular population type that represents them all, with specialists of the previous designations now being used to gate-keep certain functionality across ship systems and provide bonuses specific to that role.
Further changes to how things were structured led to the idea that support craft, including drop-ships and transport craft, would now be visible on the external hull, taking up a mounting location as defined for each ship type. These are shared with weapon hardpoints, forcing a choice between utility and defensive/offensive requirements, with the status of each more easily readable by their in-world conditions and associated UI hardpoint layout either side of the module status panel. With support craft now visible at all times, it also meant that they had to animate between mounted positions on the external hull, detaching and routing towards another ship or ground location in an elegant manner, before returning to their allocated slots. Logistics in general now needed to keep track of support craft locations in order to know whether it was quicker to wait for a craft on mission to return or just allocate one from another ship nearby.
Related to this, the inventory for each fleet asset (the storage panel) also changed to show items in fixed locations, with three pages of possible items only showing the items that your fleet has discovered thus far, and everything can always be found in the same slot regardless of whether you’re looking at a capital ship or a ground buggy. Items can be jettisoned or discarded by dragging them to the jettison region. And now you can jettison population too! Units of population used to be handled like items, but with a bunch of different rules applied to how they operated: now they’re just like items in practice, and you can just transfer passengers around between assets that have living space available. But then I thought it would be more interesting if you had to think about handling wounded crew members too, so now that’s an item type too. The wounded population typically grows as fleet assets take damage, and consume living space without being able to be assigned anywhere. Medical bays help return wounded population to health again, but if you don’t have the facilities available locally, you might want to think about transferring them to somewhere that does.
Further to this, I finally got around to adding food and water requirements for the citizens of the fleet. When you select an asset that has at least one population unit aboard, you will also see the current hunger and thirst bars of that collective population. In order to keep them fed and watered, you can add ‘dispenser’ components that distribute available supplies every day cycle. You can configure how many items you’re happy to be distributed each day, or just dispense manually whenever you like, and you’ll be alerted to any significant shortages or emergency situations when hunger or thirst start to cripple that assets’ effectiveness. Some amount of food (i.e. hydroponics) and water (i.e. water recycling) can be obtained from purely ship-bound sources, but you’ll need to explore more extensive farming options to truly build up your supplies of these.
Subcomponents (and their associated UI) across your fleet are typically implemented in fairly unique ways, such as how the food/water dispenser operates to distribute to the local population. Power supply components typically inject a particular fuel item to produce units of power, and show the rate of use of the current item before expending the next. Drives also consume items: in the case of the ion (sub-light) drives, they require Xenon to fuel any movement, with the item being depleted only whilst orbital movement is in progress. Some components link to a specified hardpoint slot and show the status of the turret or support craft mounted there. Turrets show firing status and ammunition selected, as well as the number of that ammo item remaining. They even show how many of the item have been loaded into chambers, and depletes as each shot is fired in sequence. Some components represent deck space for ground units or fighter craft, with each stowed unit taking up a valuable internal slot, and providing information on the current status of each.
Speaking of fighters, this year also saw a re-work of how fighters behaved. They used to be merely units that could move around in the orbital sphere, and whilst they can still do that once so ordered, they now launch from a home vessel and immediately move into an escorting pattern around it instead, travelling alongside the parent ship as it moves around. A whole squadron of these escorts can be deployed and subsequently docked again, their engines using local fuel supplies just as the home craft own engines does. Coming next for fighters is to allow them to be sent to engage targets, flying in loosely orbital precessions around it. Some prototyping of this was completed this year, alongside a similar framework that allows ground units to launch supporting drones that operate like a kind of guardian angel, hovering around it as it moves about.
In terms of combat specifically, much was done to improve the look and feel of space warfare somewhat more recently. Turrets used to be limited to a handful of placeholder effects, with no real variety in weaponry or player decisions pertaining to hardpoint selection. As ammunition requirements were finally added to offensive weaponry, it also meant that we could allow for multiple possible types of ammo to be loaded by a given type of turret, each with their own stats and effects. Beyond that, I also added missile launch capabilities and anti-missile systems, and missiles are of course yet another ammunition item you need to consider. I added more damage indicators throughout the UI, as well as to the fleet outliner, and started to play around with critical hits and armour penetration values, and to how damage can seep into nearby modules. I added power outages when generators are hit, and power losses for specific subcomponents during critical strikes or when hit by ammunition designed to disrupt such systems. As mentioned previously, I also added the chance for crew members becoming wounded if the area they are stationed in is hit. Items can also be lost/destroyed during combat too, with the most likely type of items to be stored in that area being at risk. There is still more to play with here, and I’ve limited investigations to space combat only for now, but ground combat is due a similar overhaul at some point, with more indirect weaponry and drone warfare to be added.
And just to touch on planet-related developments: I added some grass. I mean, we had grass before, but it was individual meshes dotted around the landscape, and it was a pretty feeble effort at covering the surface with vegetation that didn’t particularly scale very well. The new approach is based on fur shading ideas, with closely-packed layers of textured meshes sliding across each other in response to a planetary wind. It’s something of an abstract look overall, but it means we can have more substantial covering on Earth-like worlds, and I think it looks pretty alright. I’m hoping to extend the tech to allow for sand blowing through the desert regions and maybe even snow drifts in polar ones. By baking the average grass pattern into the planet texture itself, we also get a much more seamless transition between space and ground as the camera zooms around.
Finally, and much more recently, I have been working with a 3D modeller who has started to design and model some ships for the game! Given all the changes made to how things needed to work (such as support craft needing to mount externally, and escort ships needing a docking bay to launch/dock at) we finally had all the requirements pinned down enough to get that project started. So we will now be replacing all the existing placeholder ship assets and associated bits and pieces like turrets and drop-ships, until everything has a much more coherent aesthetic and unique flavour for the world of Fragile Existence.
So, yeah, lots of words, I know, but that does more or less encompass the progress of the year so far. Whilst 2025 was ultimately just the year of upgrading the UI, this year has been more about finalising game systems and starting to really balance how all of those systems need to interact with each other. At the time of writing this I am mostly just staring at charts and documents outlining all of the possible modules and subcomponents, and trying to organise them, merge things or cut others, in order to get to that sweet spot between streamlined and complexity. The six personnel roles remain at the heart of everything, with everything categorised into whether they are to be crewed by commanders, engineers, pioneers (scientists), operators (pilots of both ground and space units), stewards (medics) or sentinels (defence forces). Specialists in those fields unlock more powerful components, and bonuses typically amplify everything else from that role type. The goal is to make it possible for the player to lean more heavily towards particular roles without making it impossible for things to operate.
--
In the near future I will be working to finalise these aspects, as well as continue to collaborate on the new fleet ship models. I drift into optimisation or visual improvements from time to time, but I’m largely focused on finalising the game systems, and clearly we’re not quite there yet. I appreciate the development of Fragile Existence has not been as quick as anyone would really like (myself included), but the work continues, and I can only hope that this is evidenced enough to warrant continued enthusiasm for the project. Oh, and I made a little video that covers everything above too. Cheers all =)