Forever Skies Ongoing Development Update | July 2025
Hello Scientists.
As part of our ongoing efforts to show you what upcoming changes and features we’re adding to Forever Skies, we’ve got a big post to share some highlights on what we’re working on right now to help address the issues we outlined back at the start of June.
https://store.steampowered.com/news/app/1641960?emclan=103582791471296854&emgid=538855247335918021
While this isn’t everything we’re currently working on, we’re making this blog to give you a good sense of just how much is changing from the technical side to improve your experience with Forever Skies.
This post will go into some details about the following:
So let's dive into the three major areas we’ve been working on.
-----------------------------------------------------------------------------
We’ve recently given you a sneak peek at some of the new interior and exterior elements being added to locations that will be generated when exploring the world of Forever Skies. Now we thought it would be good to go into more detail about the system running under the hood and how it’s being designed to help tackle the issue of locations all feeling the same.
All the images below are in-engine blockouts we use to test how this system is working
The basic idea is we’re building a large set of visual and gameplay modifiers that will form a pool from which our algorithm can draw from, in order to generate varied locations throughout your game. Now, the easiest solution would have just been to throw ALL these modifiers into a giant pot and let the system pick randomly. However, this would likely just result in a disorganized mix of locations that quickly begin to feel repetitive again.
Instead, the system needs to be structured and governed by specific rules, ultimately reading the status of your current playthrough to decide which modifiers it should throw at you.
There’s another important factor to consider here: exploration is a form of progress. When you uncover something new, it feels like you're moving forward. Your brain takes note of where you’ve been, so if you start seeing the same environments repeatedly, it can feel like you’re not making any progress at all.
So with this in mind, we started prototyping an algorithm that would generate new locations within a set of core rules that need to achieve 3 primary things:
While the full workings of the algorithm are quite complex, we can highlight four key rules that will help illustrate how this system functions.
[h2]The “Category of Modifier” Rule[/h2]
It's important to understand that visuals aren’t the only elements changing between locations. We also want gameplay at each site to vary meaningfully. So, alongside the visual modifiers, there’s also a system that fills out a checklist of categories that will define a location’s overall composition. These categories currently include:
Size: Rather self-explanatory. Location can either be small, medium or large, which changes the time needed to explore and scavenge the location.
Connections: What elements link the main sections/platforms of the location together that you will traverse on. E.g. stairs, ladders, winches, etc. Each connection modifier will also have its own visual variants. Note: These refer to the main connections between platforms. A location might use winches between platforms, but still contain stairs or ladders within individual platforms.
Exploration Event: An event or obstacle that requires the use of specific tools to access valuable resources. E.g use the extractor, the knife, repair tools, a battery etc.
Threat Event: A collection of hazards or enemy modifiers that may appear at the location. These can be confronted directly or avoided. Examples include Thorn Bees, Crustpedes, toxic fumes, etc.
Side Quest: Some towers will contain a one-off side quest. If you trigger one, the system spawns the endpoint at a nearby location, which is then marked on your radar. If you miss the trigger, the system returns the quest to the pool for use at a future location. Not every tower will contain a side quest, so this category may sometimes be left empty.
Lore Scenes: There are currently 20 in the game, and they are designed to appear only once. These include story-driven elements like tablets or environmental objects to scan. If you miss one, the system will detect that and reintroduce it at another location. Again, not every tower will include a lore scene, so this category can also be left empty.
[h2]“Location of the Player” Rule[/h2]
This core rule is based on your location on the map. For starters, we mark the starting area as "ground zero" and define zones that radiate outward from that point.
As you move farther away from the starting zone, the system activates new modifiers that were previously locked out in earlier zones. This trick introduces variety via progress and reinforces the feeling that you are making this progress, just by exploring further into the world.
[h2]“Progress of the Player” Rule[/h2]
How long you’ve been playing for is also a crucial benchmark as we want the system to still be giving the player new content the longer they play. But simply taking into account the time played is not always a good indicator of how far someone has progressed. Two players could each play for 10 hours and be in completely different places in the story. Instead, we decided to tie certain modifiers to only start triggering once you have certain tools and upgrades unlocked. Since many of these are tied to main story milestones, it gives us a much clearer picture of your actual progress.
So when you reach a key point in the game, the system knows to start unlocking certain modifiers that were previously not an option for it. This keeps the content feeling fresh, ten, twenty, or thirty hours into the game.
[h2]The “What Was Before” Rule[/h2]
In very basic terms, the system must take into account what modifiers it recently generated nearby when generating the next location.
While some elements can repeat e.g. two nearby towers might both have bees spawned in as Threat Events, the system knows to at least lock out a handful of other variables to avoid having near identical towers next to each other.
This ensures that when exploring in a certain radius, the locations keep varying.
Overall, this system involves many moving parts, but we hope this overall breakdown gives you a clearer picture of how it will function. It also hopefully shows how much thought and effort is going into making this all work. So we appreciate your patience as we work to fully build and integrate this feature into the game.
We will be adding a new, revamped bug reporting tool to help make reporting easier and more effective.
It will be available from within the pause / settings menu.
The tool features a clean, simple layout that lets you quickly choose what kind of report you're submitting. We’ve categorized this into 4 categories:
From there, there’s a space where you can describe the issue if you'd like to share some more details.
If you're open to being contacted to help us investigate further, you can include your email address.
And finally, to help us understand the overall impact you feel this is having on your experience, there's also a basic rating option.
This is our first iteration and the one you’ll likely see in game soon, but we’re open to changing the categories, streamlining etc., based on your feedback.
Rest assured that Feature Upvote, where you can request and view new features or QOL improvements, will still be used and actively supported by us.
https://forever-skies.featureupvote.com/
This new reporting tool is simply to have an in-game option to more effectively report any issues you are having or to give quick feedback.
[h2]How We Approach Performance Optimization[/h2]
Before we explain our next performance optimization target, we thought it might be helpful to give you a better understanding of how this process works overall at a production level.
Our approach to performance optimization basically involves identifying resource-heavy elements in the game and tackling them one or two at a time, based on priority. This allows us to work in a much more controlled environment. If something goes wrong, we can trace it back to a specific fix more easily, rather than trying to juggle multiple changes and being unsure which one might be causing unforeseen consequences. Some fixes are straightforward, while others take much longer to identify and resolve.
For example, our last major fix revolved around our rain. Our initial system was calculating raindrop collisions on the CPU per raindrop and only at raindrop spawn. Since our thunderstorms involved between 6,000 and 10,000 raindrops, this placed a really heavy load on the CPU. Collision checks are expensive operations, and since the collision point was only calculated once at spawn, any movement of the airship afterwards could cause raindrops to appear inside your base.
We’ve now switched to a GPU-based simulation for rain. To give the GPU awareness of its surroundings, we capture two depth maps - one for the airship and one for the nearest location. These are stored as textures and used for collision calculations. This allows collisions to be checked every frame and prevents them from passing through the airship. Using the GPU for these calculations instead has resulted in significantly improved performance. It’s now about 50 times faster to run the same simulation, which also allows us to spawn many more particles without degrading performance.
We also introduced a system that spawns particles only where the player is present. This avoids wasting resources on areas far ahead or behind the player. As a result, although the number of particles is the same, the rain appears denser because it only spawns in front of you.
Here's a quick video showing how the rain now looks running on a machine that meets our recommended specs:
[previewyoutube][/previewyoutube]
While these changes may seem obvious in hindsight, they do take a lot of time. Identifying the problem, replicating it multiple times, testing possible causes, developing solutions and then testing it all. This rain optimization fix alone took our Technical Artist close to two months from start to finish.
[h2]Back to the Start - Stutter Hunting[/h2]
With the release of Patch 1.0.3 on July 15th, our performance team basically starts the whole process again, looking for areas or processes in our game that could be hindering performance. One of the best places to begin is by doing stutter hunting i.e. looking for exact instances where the game visually lags, as that can give us our first clue of where to start looking under the hood (this is exactly how we started the process of rain optimization fix)
Stuttering usually occurs when there's simply too much work being done in a single update or frame, overwhelming the system and causing a visible hitch. This can give the impression that the game is poorly optimized, even if most of the time it's running smoothly. The real challenge is that stutters may only occur in very specific conditions, making them harder to track down and fix.
Currently, we have a few potential candidates for stutterers that we are trying to zero in on.
Three current candidates under our microscope are:
If ongoing testing confirms that any of these are culprits to regular performance drops, we can then begin exploring new solutions, all of which can vary widely.
Sometimes the solution is rewriting the code to run faster and more efficiently. Othertimes, the solution is to move the processing work to another application thread to be executed on another CPU core. Sometimes we need to spread out some work over more frames of the game so it will become less noticeable (that's already how our world generation works in large parts).
So as you can see again, this a very prolonged and time-consuming process, especially with our small team like ours. But it remains a priority for us, and it’s why we have dedicated team members focused solely on performance improvements.
-----------------------------------------------------------------------------
That’s all for today’s post. As mentioned earlier, these aren’t the only improvements we’re working on, but since many of you have asked for behind-the-scenes updates, we thought this would be worth sharing. We hope this gives you a clearer idea of what to expect in the near future of Forever Skies.
We don’t have a set release date for these changes yet, but we’re aiming to have the update ready sometime between August and September.
Thanks, and let us know what you think in the comments.
- Team Far From Home
As part of our ongoing efforts to show you what upcoming changes and features we’re adding to Forever Skies, we’ve got a big post to share some highlights on what we’re working on right now to help address the issues we outlined back at the start of June.
https://store.steampowered.com/news/app/1641960?emclan=103582791471296854&emgid=538855247335918021
While this isn’t everything we’re currently working on, we’re making this blog to give you a good sense of just how much is changing from the technical side to improve your experience with Forever Skies.
This post will go into some details about the following:
- Location Diversity System: An algorithm is being introduced to generate varied locations based on visual and gameplay modifiers (size, connections, exploration/threat events, side quests, lore scenes).
- New In-Game Reporting Tool: An improved bug reporting tool will be added to the game. It will allow for quick reporting of bugs, framerate issues, co-op related problems, and general feedback.
- Performance Improvements: A quick look at how we approach performance improvements and what is our next big area of focus.
So let's dive into the three major areas we’ve been working on.
-----------------------------------------------------------------------------
1. THE SYSTEM BEHIND LOCATION DIVERSITY
We’ve recently given you a sneak peek at some of the new interior and exterior elements being added to locations that will be generated when exploring the world of Forever Skies. Now we thought it would be good to go into more detail about the system running under the hood and how it’s being designed to help tackle the issue of locations all feeling the same.
All the images below are in-engine blockouts we use to test how this system is working
The basic idea is we’re building a large set of visual and gameplay modifiers that will form a pool from which our algorithm can draw from, in order to generate varied locations throughout your game. Now, the easiest solution would have just been to throw ALL these modifiers into a giant pot and let the system pick randomly. However, this would likely just result in a disorganized mix of locations that quickly begin to feel repetitive again.
Instead, the system needs to be structured and governed by specific rules, ultimately reading the status of your current playthrough to decide which modifiers it should throw at you.
There’s another important factor to consider here: exploration is a form of progress. When you uncover something new, it feels like you're moving forward. Your brain takes note of where you’ve been, so if you start seeing the same environments repeatedly, it can feel like you’re not making any progress at all.
So with this in mind, we started prototyping an algorithm that would generate new locations within a set of core rules that need to achieve 3 primary things:
- Diversifies the generated locations within the range of each other
- Give a sense of progress
- Avoids total randomization
While the full workings of the algorithm are quite complex, we can highlight four key rules that will help illustrate how this system functions.
[h2]The “Category of Modifier” Rule[/h2]
It's important to understand that visuals aren’t the only elements changing between locations. We also want gameplay at each site to vary meaningfully. So, alongside the visual modifiers, there’s also a system that fills out a checklist of categories that will define a location’s overall composition. These categories currently include:
Size: Rather self-explanatory. Location can either be small, medium or large, which changes the time needed to explore and scavenge the location.
Connections: What elements link the main sections/platforms of the location together that you will traverse on. E.g. stairs, ladders, winches, etc. Each connection modifier will also have its own visual variants. Note: These refer to the main connections between platforms. A location might use winches between platforms, but still contain stairs or ladders within individual platforms.
Exploration Event: An event or obstacle that requires the use of specific tools to access valuable resources. E.g use the extractor, the knife, repair tools, a battery etc.
Threat Event: A collection of hazards or enemy modifiers that may appear at the location. These can be confronted directly or avoided. Examples include Thorn Bees, Crustpedes, toxic fumes, etc.
Side Quest: Some towers will contain a one-off side quest. If you trigger one, the system spawns the endpoint at a nearby location, which is then marked on your radar. If you miss the trigger, the system returns the quest to the pool for use at a future location. Not every tower will contain a side quest, so this category may sometimes be left empty.
Lore Scenes: There are currently 20 in the game, and they are designed to appear only once. These include story-driven elements like tablets or environmental objects to scan. If you miss one, the system will detect that and reintroduce it at another location. Again, not every tower will include a lore scene, so this category can also be left empty.
[h2]“Location of the Player” Rule[/h2]
This core rule is based on your location on the map. For starters, we mark the starting area as "ground zero" and define zones that radiate outward from that point.
As you move farther away from the starting zone, the system activates new modifiers that were previously locked out in earlier zones. This trick introduces variety via progress and reinforces the feeling that you are making this progress, just by exploring further into the world.
[h2]“Progress of the Player” Rule[/h2]
How long you’ve been playing for is also a crucial benchmark as we want the system to still be giving the player new content the longer they play. But simply taking into account the time played is not always a good indicator of how far someone has progressed. Two players could each play for 10 hours and be in completely different places in the story. Instead, we decided to tie certain modifiers to only start triggering once you have certain tools and upgrades unlocked. Since many of these are tied to main story milestones, it gives us a much clearer picture of your actual progress.
So when you reach a key point in the game, the system knows to start unlocking certain modifiers that were previously not an option for it. This keeps the content feeling fresh, ten, twenty, or thirty hours into the game.
[h2]The “What Was Before” Rule[/h2]
In very basic terms, the system must take into account what modifiers it recently generated nearby when generating the next location.
While some elements can repeat e.g. two nearby towers might both have bees spawned in as Threat Events, the system knows to at least lock out a handful of other variables to avoid having near identical towers next to each other.
This ensures that when exploring in a certain radius, the locations keep varying.
Overall, this system involves many moving parts, but we hope this overall breakdown gives you a clearer picture of how it will function. It also hopefully shows how much thought and effort is going into making this all work. So we appreciate your patience as we work to fully build and integrate this feature into the game.
2. NEW IN-GAME REPORTING
We will be adding a new, revamped bug reporting tool to help make reporting easier and more effective.
It will be available from within the pause / settings menu.
The tool features a clean, simple layout that lets you quickly choose what kind of report you're submitting. We’ve categorized this into 4 categories:
- BUG
- FRAMERATE
- CO-OP (positive or negative)
- GENERAL FEEDBACK (positive or negative)
From there, there’s a space where you can describe the issue if you'd like to share some more details.
If you're open to being contacted to help us investigate further, you can include your email address.
And finally, to help us understand the overall impact you feel this is having on your experience, there's also a basic rating option.
This is our first iteration and the one you’ll likely see in game soon, but we’re open to changing the categories, streamlining etc., based on your feedback.
Rest assured that Feature Upvote, where you can request and view new features or QOL improvements, will still be used and actively supported by us.
https://forever-skies.featureupvote.com/
This new reporting tool is simply to have an in-game option to more effectively report any issues you are having or to give quick feedback.
PERFORMANCE IMPROVEMENTS
[h2]How We Approach Performance Optimization[/h2]
Before we explain our next performance optimization target, we thought it might be helpful to give you a better understanding of how this process works overall at a production level.
Our approach to performance optimization basically involves identifying resource-heavy elements in the game and tackling them one or two at a time, based on priority. This allows us to work in a much more controlled environment. If something goes wrong, we can trace it back to a specific fix more easily, rather than trying to juggle multiple changes and being unsure which one might be causing unforeseen consequences. Some fixes are straightforward, while others take much longer to identify and resolve.
For example, our last major fix revolved around our rain. Our initial system was calculating raindrop collisions on the CPU per raindrop and only at raindrop spawn. Since our thunderstorms involved between 6,000 and 10,000 raindrops, this placed a really heavy load on the CPU. Collision checks are expensive operations, and since the collision point was only calculated once at spawn, any movement of the airship afterwards could cause raindrops to appear inside your base.
We’ve now switched to a GPU-based simulation for rain. To give the GPU awareness of its surroundings, we capture two depth maps - one for the airship and one for the nearest location. These are stored as textures and used for collision calculations. This allows collisions to be checked every frame and prevents them from passing through the airship. Using the GPU for these calculations instead has resulted in significantly improved performance. It’s now about 50 times faster to run the same simulation, which also allows us to spawn many more particles without degrading performance.
We also introduced a system that spawns particles only where the player is present. This avoids wasting resources on areas far ahead or behind the player. As a result, although the number of particles is the same, the rain appears denser because it only spawns in front of you.
Here's a quick video showing how the rain now looks running on a machine that meets our recommended specs:
[previewyoutube][/previewyoutube]
While these changes may seem obvious in hindsight, they do take a lot of time. Identifying the problem, replicating it multiple times, testing possible causes, developing solutions and then testing it all. This rain optimization fix alone took our Technical Artist close to two months from start to finish.
[h2]Back to the Start - Stutter Hunting[/h2]
With the release of Patch 1.0.3 on July 15th, our performance team basically starts the whole process again, looking for areas or processes in our game that could be hindering performance. One of the best places to begin is by doing stutter hunting i.e. looking for exact instances where the game visually lags, as that can give us our first clue of where to start looking under the hood (this is exactly how we started the process of rain optimization fix)
Stuttering usually occurs when there's simply too much work being done in a single update or frame, overwhelming the system and causing a visible hitch. This can give the impression that the game is poorly optimized, even if most of the time it's running smoothly. The real challenge is that stutters may only occur in very specific conditions, making them harder to track down and fix.
Currently, we have a few potential candidates for stutterers that we are trying to zero in on.
Three current candidates under our microscope are:
- How our locations are loading and unloading
- How some events are spawned in the game
- How auto-saves are happening in the background
If ongoing testing confirms that any of these are culprits to regular performance drops, we can then begin exploring new solutions, all of which can vary widely.
Sometimes the solution is rewriting the code to run faster and more efficiently. Othertimes, the solution is to move the processing work to another application thread to be executed on another CPU core. Sometimes we need to spread out some work over more frames of the game so it will become less noticeable (that's already how our world generation works in large parts).
So as you can see again, this a very prolonged and time-consuming process, especially with our small team like ours. But it remains a priority for us, and it’s why we have dedicated team members focused solely on performance improvements.
-----------------------------------------------------------------------------
That’s all for today’s post. As mentioned earlier, these aren’t the only improvements we’re working on, but since many of you have asked for behind-the-scenes updates, we thought this would be worth sharing. We hope this gives you a clearer idea of what to expect in the near future of Forever Skies.
We don’t have a set release date for these changes yet, but we’re aiming to have the update ready sometime between August and September.
Thanks, and let us know what you think in the comments.
- Team Far From Home